time facility and runtime dependencies for code in the "components" dirs

[pat-rogers]

Background: We want all component abstractions (the code in the "components" subdirs) to work with all runtimes. The components often require the ability to export time value declarations and execute delay statements. The ZFP runtimes do not include package Ada.Real_Time and do not support delay statements, therefore the components code cannot use them.

We can avoid the use of type Time_Span by declaring the quantities as named numbers, with a comment (or subtype of Integer) indicating what units are intended. For example:

Min_Sample_Interval : constant := 10; -- milliseconds

or

subtype Milliseconds is Natural; -- or Positive
subtype Microseconds is Natural;
...

Min_Sample_Interval : constant Milliseconds := 10;

or even derive the types so that they cannot be mixed accidentally.

Not ideal -- after all, Ada.Real_Time is included in the language to make this sort of thing unnecessary -- but acceptable.

However, that does not address the issue of delay statements.

Currently we have HAL.Time as a replacement for Ada.Real_Time:

package HAL.Time is

  type Delays is limited interface;

  type Delays_Ref is access all Delays'Class;

  procedure Delay_Microseconds (This : in out Delays;
                                Us   : Integer) is abstract;

  procedure Delay_Milliseconds (This : in out Delays;
                                Ms   : Integer) is abstract;

  procedure Delay_Seconds      (This : in out Delays;
                                S    : Integer) is abstract;

end HAL.Time;

with the intention of there being some concrete subclass implementations that do use delay statements, when a ravenscar-* runtime is in use, and other implementations that do not, when using a ZFP runtime.

Given that interface, we are using the access-to-classwide type as a discriminant in the declarations of the component abstraction types in order to make the components independent of the runtimes. For example, the Time discriminant:

type STMPE811_Device
(Port : not null I2C_Port_Ref;
I2C_Addr : I2C_Address;
Time : not null HAL.Time.Delays_Ref) is`

The problems with that approach are:

1. It makes the client (user) code responsible for what is otherwise strictly an implementation detail. This is a very serious flaw in terms of software engineering.

2. It "pollutes" the API with something that has nothing to do with applying the component itself.

3. It is a rather heavy approach.

My suggestion: make HAL.Time have concrete delay routines, with the selection of the body of the package controlled by the runtime selection, something like what we do now for the last chance handlers that can use an LCD when the board supports it. Then the components code could just call the routines directly, without the client code having to do anything in that regard.

Something like this:

package HAL.Time is

  procedure Delay_Microseconds (Count : Natural);

  procedure Delay_Milliseconds (Count : Natural);

  procedure Delay_Seconds (Count : Natural);

end HAL.Time;

although we would likely declare the subtypes or derived types

subtype Milliseconds is Natural;
subtype Microseconds is Natural;
...

in that package too.

Thoughts?

[Fabien-Chouteau]

I agree that the current scheme is not great and we will also need the same kind of timing features for the services and even MCU layers.

My suggestion: make HAL.Time have concrete delay routines, with the selection of the body of the package controlled by the runtime selection, something like what we do now for the last chance handlers

How would this work for ZFP? Time handling will be different from a MCU to the other, maybe from one project to the other?

[pat-rogers]

On 11/28/2016 5:08 AM, Fabien Chouteau wrote: I agree that the current scheme is not great and we will also need the same kind of timing features for the services and even MCU layers. > My suggestion: make HAL.Time have concrete delay routines, with the > selection of the body of the package controlled by the runtime > selection, something like what we do now for the last chance > handlers How would this work for ZFP? Time handling will be different from a MCU to the other, maybe from one project to the other?

Yes, selection based on runtime is not sufficient for ZFP so likely we'd want some other way of selecting whatever is cooked up for those runtimes. We'll have the basic problem -- how to provide delays on ZFP -- in any case.

[JCGobbi]

Perhaps the work I have done can help in how to provide delays on ZFP, including interrupt services. I have made facilities like clock configuration, interrupt service and real-time for a ZFP run-time for the STM32F334 CPU. Take a look at https://github.com/JCGobbi/Nucleo-STM32F334R8_ZFP.
I understand that each CPU family have a common NVIC and Sys-Tick hardware (like STM32 CortexM4 MCU), so each family would have a common time and interrupt interface for ZFP run-time. And in the project, that time and interrupt facilities would be selected by choosing the run-time, as has been suggested.

[Fabien-Chouteau]

Even if NVIC and Sys-Tick are available on most ARM micro-controllers (but not all), we want to support more than just ARM in this project. For instance this would not be applicable to RISC-V.