Re: STM32F4 Discovery, communication and libraries

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-08-29 19:47 , Roy Emmerich wrote:
> On Friday, 29 August 2014 15:06:07 UTC+2, Dennis Lee Bieber  wrote:
>> It works if the entire system including the "user application"
>> level is built "as one". It is NOT a very dynamic arrangement
>> wherein you may plug in a new sensor and have it magically install
>> itself to some list of sensors to be reported.
> 
> My requirements for dynamic behaviour don't extend so far as to be
> plug and play ready. What I do want, being a modular hardware
> platform, is to define, in a configuration file, which hardware
> modules are plugged into which socket. At start up the supervisor
> will read this file and instantiate the relevant software modules.

So the Ada program contains SW modules that can handle all known and
possible hardware modules, but the SW modules are all "data/table
driven" in the sense that the supervisor can tell each SW module where
(in which socket, &c) its HW, if any, can be found?

As far as I can see, the only problem that the Ravenscar profile can
cause for that design is the restriction No_Dynamic_Attachment, which
means that the connection between an interrupt source and its handler
must be established at elaboration time, by pragmas or aspects, and not
dynamically using a call of Ada.Interrupts.Attach_Handler.

In principle, the configuration file could be read at elaboration time,
and could provide the interrupt numbers to be used in the pragma/aspect
Attach_Handler. However, doing lots of computation at elaboration time
can make it tricky for the compiler to find a feasible elaboration order
(especially if the program has tasks).

The other solution is to attach handlers to all interrupt sources
statically, but to decide in each handler, at run time, based on the
configuration data, which SW module is to handle the interrupt, and to
call the suitable operation from that SW module. A kind of indirection step.

> This device will effectively aggregate the
> data from all of these devices into one, unified format and send
> control signals to the generator/inverters.

What is the highest control frequency, or shortest deadline or response
time, required of the SW?

> ... making it
> important for it to be a low power device (e.g. much less than say a
> beaglebone black embedded Linux board), able to run on a battery for
> at least 3 days, preferably much more

You may have to modify the Board Support Package and/or the kernel to
let the processor sleep between clock interrupts. I don't know if the
AdaCore ARM BSP has that ability off-the-shelf.

> It must keep accurate time (syncing once a day via GPS)
> and (periodically/in emergency) make the data available remotely (via
> GPRS).

Time in a Ravenscar system is provided by the predefined package
Ada.Real_Time. It is good for relative timing in seconds and ticks, but
does not provide calendar date and time. Probably you will have to write
your own Calendar-like package which is synchronised with GPS. Not a
very big job.

> Let's be frank. This is not a satellite. I WON'T be doing any
> schedulability analyses.

AFAIK few satellites are subjected to formal schedulability analysis...
typically, some kind of "nominal worst-case scenario" is defined and a
simple computation similar to response-time analysis is used to
demonstrate that all important ("hard real time") tasks are fast enough
in this scenario, and that a reasonable fraction of CPU time is left for
the less urgent tasks.

> Today Ada seems like a very good fit, no?

I think so.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .