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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.222.135 with SMTP id qm7mr4931646obc.41.1410339147506; Wed, 10 Sep 2014 01:52:27 -0700 (PDT) X-Received: by 10.140.91.75 with SMTP id y69mr553qgd.16.1410339147365; Wed, 10 Sep 2014 01:52:27 -0700 (PDT) Path: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!r2no18038153igi.0!news-out.google.com!q8ni1qal.1!nntp.google.com!dc16no2538220qab.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 10 Sep 2014 01:52:27 -0700 (PDT) In-Reply-To: <80av0adfkag3khjq5pjnsihtbqmgjqpkq7@4ax.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=77.8.88.109; posting-account=Fmp50goAAAA9sbkA2aX-X9YQy6-lkg3J NNTP-Posting-Host: 77.8.88.109 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: STM32F4 Discovery, communication and libraries From: Roy Emmerich Injection-Date: Wed, 10 Sep 2014 08:52:27 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:188939 Date: 2014-09-10T01:52:27-07:00 List-Id: Dennis thanks for your feedback. It is really helping to think of alternati= ve 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 starti= ng > the scheduler there should not be any problem of a suddenly an event crop= s > up that needs to go "now". When you say scheduler, is this some specific Ada construct? I have a simpl= e 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 han= dlers. > loop >=20 > pull front of queue (event time, device handler/callback) >=20 > delay until event time >=20 > call device handler/callback >=20 > end loop > > Device handler/callback is essentially >=20 > 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 o= f > items) How I understand it is the scheduler sorts all events by time whenever a ne= w event is added to the queue. What happens when two events have the same t= ime-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 ad= ditional 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 particul= ar 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 s= yncing 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 c= ase 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 m= ore sophisticated and get the GPS sync event to have various states (e.g. f= irst 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 tha= n > one device shares the code of a handler, etc. My (Java) thinking is leading me to create a generic device handler class f= or 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 whi= le an inverter is a device with many possible variables to monitor). Each d= evice handler class will then instantiate separate variable handler classes= for each variable to be monitored. It can't be assumed that all possible v= ariables will want to be logged. Each variable will likely have a different= sampling rate. These variable handler classes will receive the sampling r= ate upon instantiation and will contain a callback function which will be i= nserted 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: >=20 > device class (handler name), device ID, offset to first event time, delta > between events > for each instance of a device. >=20 > 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 whe= n > that event is pulled and the device handler activates, it puts itself bac= k > on the queue). That makes sense. Translated to my thinking the queue will be as long as th= e number of variables to be monitored. The mists of confusion are starting to disappear! Thanks again for your hel= p.