Re: STM32F4 Discovery, communication and libraries

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

Dennis thanks for your feedback. It is really helping to think of alternative ways to achieve my goal.

On Wednesday, 10 September 2014 03:41:16 UTC+2, Dennis Lee Bieber  wrote:
> 	I suspect all you really need is a scheduler based on a priority queue
> -- in which the "priority" is really the time-of-next-event... Closest
> event is in front. Presuming you initialize all the devices before starting
> the scheduler there should not be any problem of a suddenly an event crops
> up that needs to go "now".

When you say scheduler, is this some specific Ada construct? I have a simple array in mind, or maybe a linkedlist/hashmap (i.e. key/value pairs) with time-of-next-event as the key and values being references to the device handlers.

> loop
> 
> 	pull front of queue (event time, device handler/callback)
> 
> 	delay until event time
> 
> 	call device handler/callback
> 
> end loop
>
> 	Device handler/callback is essentially
> 
> obtain reading from device
> log reading
> compute next event time for this device (current trigger time + interval)
> put entry on queue (where it sorts to the proper place in the multitude of
> items)

How I understand it is the scheduler sorts all events by time whenever a new event is added to the queue. What happens when two events have the same time-of-next-event? Introduce a second priority level?

There will also be house keeping tasks such as syncing the on-board RTC to the GPS time. I am thinking of scheduling these based on time (e.g. once a day) but having a higher priority than the rest of the logging tasks. An additional priority level could be useful in this case. However, having said that, it isn't absolutely critical for the time sync to occur at a particular time. This is getting me thinking about time windows. In other words, do this task at least once a day, at this time +-5 minutes. In terms of RTC syncing this won't help much if you are logging something every second as it takes much longer for the GPS receiver to start up and lock on, in which case a variable being logged every second would just have to wait until the GPS syncing has finished, leaving a gap in the logged data. One could get more sophisticated and get the GPS sync event to have various states (e.g. first start the GPS receiver then wait in the queue until a valid signal is available, allowing other events to take place). This is essentially device specific.

> 	Obviously "device handler/callback" needs to somehow incorporate the
> parameters for the rate computation, the particular device ID if more than
> one device shares the code of a handler, etc.

My (Java) thinking is leading me to create a generic device handler class for each device to be monitored. Each device will have one or more variables to monitor (e.g a temp sensor is a device with one variable to monitor while an inverter is a device with many possible variables to monitor). Each device handler class will then instantiate separate variable handler classes for each variable to be monitored. It can't be assumed that all possible variables will want to be logged. Each variable will likely have a different sampling rate.  These variable handler classes will receive the sampling rate upon instantiation and will contain a callback function which will be inserted into the queue we spoke about above.

> 	Since the main loop doesn't pull the next item until the handler has
> placed its next invocation onto the queue, even a fast event rate won't
> vanish, it just becomes the next entry to be pulled.

I'm not quite understanding your phrasing here. Could you elaborate?

> 	You might want to look at "discrete event" information.

Okay. This is new territory for me :) Any reading tips?

> 	Your configuration information would contain something like:
> 
> device class (handler name), device ID, offset to first event time, delta
> between events
> for each instance of a device.
> 
> 	The event queue only needs to be large enough to hold one event from
> each configured device (each device only needs one pending event, and when
> that event is pulled and the device handler activates, it puts itself back
> on the queue).

That makes sense. Translated to my thinking the queue will be as long as the number of variables to be monitored.

The mists of confusion are starting to disappear! Thanks again for your help.