Re: STM32F4 Discovery, communication and libraries

[Simon Wright <simon@pushface.org>]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

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

OP might be interested in my ColdFrame[1], and in particular the top
page for Events[2], which is based on similar ideas.

Because I'm interested in state modelling, I have four event queues; one
for events-to-self, to be executed as part of one state machine action,
one for state machine events, to be executed in order of posting, one
for inter-domain communication, of lower priority but also to be
executed in order of posting, and one for "held" events, to be executed
in time order.

This is probably more complicated than you need :-)

[1] http://coldframe.sourceforge.net/coldframe/
[2] http://coldframe.sourceforge.net/coldframe/events.html