From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 10 Sep 2014 08:04:56 -0500 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: STM32F4 Discovery, communication and libraries Date: Wed, 10 Sep 2014 09:05:38 -0400 Organization: IISS Elusive Unicorn Message-ID: <80i01atqat8hrftl7lqeodf9psshlbqnk3@4ax.com> References: <1cjwzr30b24xy.11kpydntxhfo5$.dlg@40tude.net> <929e9226-e4aa-474e-843c-68ed800eefad@googlegroups.com> <5b5583ca-c7b2-40be-9090-6253f0514db5@googlegroups.com> <7feccd2d-dcfd-405e-ae5d-e27d6662daa9@googlegroups.com> <80av0adfkag3khjq5pjnsihtbqmgjqpkq7@4ax.com> X-Newsreader: Forte Agent 6.00/32.1186 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.79.221.165 X-Trace: sv3-IaDhHx3FS3/1hY6SN4Z7yL8GAPIkQUEycRrJXKWbleUbZotJzO+i/r4n/J8/PI5uiStc1vmBrKipVwg!G71FefJ39G+Cjh3Bh4vb0Vlz8FSpnsoLhSE2uG6pRu6iypm55csT9Tf7UzY2fg+YJl91OHoDB4DO!OGUBUYG+i3CwGxmuG57AHyrT4fRs X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5965 Xref: number.nntp.dca.giganews.com comp.lang.ada:188943 Date: 2014-09-10T09:05:38-04:00 List-Id: On Wed, 10 Sep 2014 01:52:27 -0700 (PDT), Roy Emmerich 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 ) 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/