-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
time facility and runtime dependencies for code in the "components" dirs #91
Comments
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.
How would this work for ZFP? Time handling will be different from a MCU to the other, maybe from one project to the other? |
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.
|
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. |
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. |
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
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:
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.
It "pollutes" the API with something that has nothing to do with applying the component itself.
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
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?
The text was updated successfully, but these errors were encountered: