Re: STM32F4 Discovery, communication and libraries

[Roy Emmerich <roy.emmerich@gmail.com>]

On Friday, 29 August 2014 21:41:18 UTC+2, Niklas Holsti  wrote:
> On 14-08-29 19:47 , Roy Emmerich wrote:
> > 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?

Yes.

> 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.

Okay. I think I got that.

> > 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?

Okay, some new terminology for me here. For this particular application the response time doesn't have to be very fast (a few seconds). It will be monitoring battery state of charge and active power and turning the generator on or off. I do foresee the need to do reactive power control in larger off-grid systems. For this the phase shift between voltage and current is normally measured by a CE/UL certified power analyser (legal/safety issues) and transmitted, once again, via MODBUS RTU, to my device. As this kind of control is a lot more dynamic, a much faster response time would be required (20 ms thumb suck value, considering one 50 Hz period is 20 ms long). Sorry that it is still so vague. A bit of guidance wouldn't go amiss :)

> > ... 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.

Is there an AdaCore ARM BSP yet? I thought this is what Mike Silva was referring to when he said:

"I know that AdaCore is working on comms libraries for the ARM Cortex M parts, but I don't know anything about the projected availability."

assuming this would include stuff such as I2C, SPI, UART, etc. which is normally also part of the BSP?

Speaking of which...in order to feel like I'm making progress and Ada is going to work for me, I really need to get connecting to my peripherals. The only way I can see it happening within the next week is to call the STM C drivers supplied with their BSP. Does this make sense?

> > 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.

Maybe not if you know what you're doing ;)

This is where it gets a bit vague for me. The STM32F4 has an on-board RTC with full calendar functionality. My thinking is at start up and then once a day to enter a "clock_sync" state, fire up the GPS receiver, somehow sync the processor's RTC and then continue with normal operation. If I need the absolute date/time I can just get it from the RTC, so I don't know why I would want to use the Ada.Calendar functionality in the first place. Could you shed some light on this?