Re: STM32F4 Discovery, communication and libraries

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

On Wed, 10 Sep 2014 01:52:27 -0700 (PDT), Roy Emmerich
<roy.emmerich@gmail.com> declaimed the following:

>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.
>
	If it helps, change "scheduler" to "dispatcher".

	"Sorting" is done by the operation to insert an event into the queue.
Inserting an entry would be done by traversing the queue from the front,
and as soon as you find an entry that has an event time that falls after
the new event being inserted you've found the position. (Of course, if you
reach the end of the queue, then the item goes on the end <G>)

	Suggest a linked list with extension. That is, the top level record has
no data, only the event time and the link to the next/previous entries.
Each distinct device class would extend the node with parameters specific
to that device.

	The queue/linked-list management and dispatcher only need to see the
links and event time to control the order. The dispatcher would have to be
able to invoke the proper process based on the extended type (I'd have to
study my books for this -- "Ada for Software Engineers, 2nd Ed" (Ben-Ari,
2009 Springer-Verlag) section 6.7 is a linked list priority queue (intro,
not fully developed), 12.2.1 introduces call-backs.

>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?
>
	The insert logic puts them in the order they arrived (so something that
has been waiting longer will get run before a fast-cycle event that has run
and requeued).

>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

	No real "priority" levels in this scheme -- the scheduled event time is
the only priority.

	You delay until the time of the next event, process that event (which
is then responsible for putting /its/ next invocation onto the queue), go
back and do the next event on the queue (always the front of queue).

	If multiples end up on the same event time, you basically process them
in order without a delay, only when the event time is greater than "now" do
you need to delay until xxx. Since each event process is in charge of
scheduling its next invocation, there is no way an event could suddenly end
up at the front of the queue while you are delaying (all other events are
already on the queue, and the event to be processed can't add itself until
it runs).


	I'm late for work... Hope this helps.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/