Re: STM32F4 Discovery, communication and libraries

[Dennis Lee Bieber <wlfraed@ix.netcom.com>]

On Tue, 9 Sep 2014 14:56:19 -0700 (PDT), Roy Emmerich
<roy.emmerich@gmail.com> declaimed the following:

>
>Let me give a little bit of background to my thinking. Let's say at the top of every minute you want to measure ambient temperature (via analogue input), solar irradiance (via analogue input) and inverter current (via MODBUS RTU to the inverter) with my data logger. Going with a sequential mindset to start with, you will always know that with a single core (or multi-core) processor the samples will be sequential. The one sample follows the other and you have to programme things this way (e.g. iterating through an array of variables to sample). Threading (or tasking in Ada) on a single processor essentially does the same thing but the programming is done in a way that it looks like the three samples are taken at the same time (i.e. simultaneously sample ambient temperature, solar irradiance and inverter current at the top of every minute). The approach, however, is very different.
>
	<snip>
>
>* thread one, here's your configuration, you take care of inverter current sampling every 5 seconds.
>* thread two, here's your configuration, you take care of solar irradiance sampling every 1 second.
>* thread 3, here's your configuration, you take care of diesel generator control.
>* etc.
>

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

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)

	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.

	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.

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

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

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/