Re: STM32F4 Discovery, communication and libraries

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

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

Then you can probably ignore all interrupt-handling and just poll for
I/O completion -- if that is much simpler to do.

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

That might or might not require interrupt-handling -- depends on your
overall design.

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

In my experience (space domain), the BSP (at least when it comes from a
compiler vendor) usually includes only the functions needed to make the
compiler's run-time system work. For Ada/Ravenscar, this means mainly
that task switching and protected objects work as expected (including
POs used as interrupt handlers) and that some timer or clock HW is
configured to drive Ada.Real_Time and the "delay until" statements. I/O
drivers are not (in my domain) typically included in the BSP -- well,
perhaps the BSP contains a simple serial-port driver to make some
emasculated form of Ada.Text_IO work. I/O drivers typically come separately.

For ground-based embedded systems, I have seen that some compiler or
chip vendors package I/O drivers with their BSPs. Perhaps Mike Silva is
talking about some AdaCore activity in that direction.

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

Very much so, at least if the C drivers are designed as a passive
library which does not rely on any specific kernel.

>>> It must keep accurate time (syncing once a day via GPS)

Must the SW actions be accurately synchronized with GPS -- for example,
sample something exactly at the GPS pulse-per-second pulse -- or is it
enough that the SW can accurately label each action/sample with the GPS
time when the sample was taken?

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

Nice.

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

By "processor's RTC", you mean the one with full calendar functionality?
Sounds like a good plan, if that RTC device allows such synchronisation.

I would not try to sync or adjust whatever HW is driving Ada.Real_Time,
but would let that run in its own time. If necessary, I would adjust the
period of the cyclic tasks to keep them in phase with the GPS and/or the
RTC. That is, if a 1 Hz task finds that it is falling behind -- doing
fewer cycles than there are GPS/RTC 1-second ticks -- it would do a few
"delay untils" with a smaller period than 1 s until it has caught up.

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

I agree, you don't need Ada.Calendar if you have a calendar-capable RTC
and do not need to do date/time calculations such as finding the
calendar date of "now + 100_000 seconds".

From what I understand of your application, I think you should be fine
with Ada.Real_Time and the RTC.

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