Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24369
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Common name for a "Task Loop" |
| Date | 2016-06-26 00:14 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <nknvbj$c93$1@dont-email.me> (permalink) |
| References | (2 earlier) <demdnXpvG7ArX_DKnZ2dnUU7-KudnZ2d@giganews.com> <nkkhog$g23$1@dont-email.me> <5qqdnVVzu89jcfPKnZ2dnUU7-VGdnZ2d@giganews.com> <nkmthf$gc1$1@dont-email.me> <NradnWLD6PFMmfLKnZ2dnUU7-RednZ2d@giganews.com> |
On 6/25/2016 3:25 PM, Tim Wescott wrote:
> I can only assume from how you think the world should work that you
> simply do not work on products that need to have tasks of markedly
> different time-scales working at the same time. Because your approach
> would crash and burn immediately on most of the stuff that I work on.
You seem to have selective amnesia. Here's what I said when introducing
my version of the "big loop":
"I've used (*really* slim!) multitasking executives that used the
loop as a general framework for 'scheduling' tasks -- but allowed
voluntary rescheduling directives to be invoked by the individual
'function calls' invoked from that loop: "
Yet, from that, you CONCLUDE that I "simply do not work on products that
need to have tasks of markedly different time-scales working at the same
time." I guess I fail to see the logic in that conclusion.
And, the fact that *this* approach "would crash and burn immediately on
most of the stuff that I work on" is equally useless to draw conclusions
of the types of projects that *I* have applied it to.
Here's the "Job list" (main loop) from a product I designed with this
approach ~35 years ago:
Jobs: Debugger // interactive debugger, when present
Timekeeping // Timer service
PowerMonitor // AC, battery backup and line frequency clock
Display // Display and Indicator update
Keypad // keypad scanning
Barcode // Barcode decoding
Sensor // sensor array scanning
Operator // Console operator user interface FSM
Diagnostic // Diagnostic Mode user interface FSM
Supervisor // Supervisor Mode user interface FSM
Port0 // Port0 comm channel user dialog
Port1 // Port1 comm channel user dialog
ret // done
The Debugger task lets a developer plug a proprietary piece
of hardware into the running (production!) system to examine
and control the system at all levels (i.e., live patches to
memory, stepping individual tasks, altering register contents).
Most of the time, it's just refreshing the display on *that*
device and polling for keystrokes. When it encounters one, it
implements the command associated with it altering the device's
operation in "real time". After deployment, it's dead code
(and can be elided)
Timekeeping updates the system timers made available to any
task that needs them. So, no need to watch a hardware
counter/timer to determine elapsed time, delays, etc.
"Wait 3 seconds"
and your code will block for 3 seconds,
"Test KeystrokeTimeout"
and your code will check to see if the "KeystrokeTimeout"
has expired.
PowerMonitor monitors the AC "line frequency clock" (essentially
the 50/60Hz mains) so the unit can adjust sampling intervals and
display refresh to frequency lock to the mains voltage. It also
provides an indication of absence of primary power. And, whether
that is due to the user manually flipping the power switch "off" *or*
a power outage. The device can then either shutdown as "intended"
or alert the user (via the "Operator" interface task) that he's
now working on borrowed time -- perhaps wise to unload the
database stored in system RAM, now. And, eventually, bring about
an orderly shutdown when the battery actually is ready to fail. Or,
alerting the user when power returns!
At the same time, it informs the timekeeping software that the
"stable" AC mains line frequency reference is no longer available
and the most recent "crystal calibration" must be used to create
synthetic time. So, the timescales are 50/60hz as well as the
fractional hour the device can run on battery.
The Display task ensures the display is updated synchronous with
the AC mains (so you don't see a beating in the display) as
well as ensuring the "content update" is synchronized with the
"scan line refresh" to eliminate visual artifacts. It implements
features like "blink" (in-phase and out-of-phase), "reverse", etc.
so you can say:
DisplayCenteredMessage:
// copy pointer to message into "message"
Send to Video // select device and wait to obtain lock
SetAttributes(NORMAL+REPLACEMENT+FORWARD+SHOWIT+SOLID+INPHASE)
CarriageReturn // leftmost column in line 0
Call(SkipOverLeadIn) // skip leading whitepace
SetAttributes(NORMAL+REPLACEMENT+BACKWARD+SHOWIT+SOLID+INPHASE)
ClearToEol // clear all LEADING whitespace!
// display cursor now at LEFTMOST column
Call(SkipOverLeadIn) // skip leading whitepace
SetAttributes(NORMAL+REPLACEMENT+FORWARD+SHOWIT+SOLID+INPHASE)
CarriageReturn // leftmost column in line 0
Print(message) // show error message
ClearToEol // clear all TRAILING whitespace!
Done // release the lock on the device
SystemError:
EnableAttribute(FLASH)
"System Error"
DisableAttribute(FLASH)
" Detected!"
End
Initializing:
"Initializing..."
End
FailedToInit:
"Unable to Initialize"
End
SensorShorted:
"Sensor Shorted"
End
The audio annunciator (handled as part of the Display "job") emits tones.
So, you can say:
Send To Audio // select device and wait to acquire lock
Print(DropOfBlood) // "play" the annunciator
Quit // end of output -- but retain lock on device
... // do other stuff while annunciator is playing
Send To Audio // select device, already have the lock!
Flush // block until output queue is empty
Done // release the lock on the device
DropOfBlood:
Rate 150*60 Beats per Minute // underlying timebase
Flush // ensure any previously queued are done
Gather // queue data, don't play, yet
// default glissando so it sounds "fluid"!
Play C_Natural(4) for 3 Beats
Play D_Natural(4) for 2 Beats
Play E_Natural(4) for 1 Beats
Play F_Natural(4) for 1 Beats
Play G_Natural(4) for 1 Beats
Play A_Natural(4) for 1 Beats
Play B_Natural(4) for 1 Beats
Play C_Natural(5) for 1 Beats
Play D_Natural(5) for 1 Beats
Play E_Natural(5) for 1 Beats
Play F_Natural(5) for 1 Beats
Play G_Natural(5) for 1 Beats
Play A_Natural(5) for 1 Beats
Play B_Natural(5) for 1 Beats
Release // release queued data for playing
End
So, the timescales there are 1/150ths of seconds.
The Keypad task scans the key matrix and debounces keys providing
rollover etc. It feeds "events" to the Operator FSM in much the same
way that the AC line monitor fed POWER_FAIL, POWER_OFF, POWER_RESTORE
and BATTERY_FAIL events.
The Barcode task continually monitors for the user's presentation
of a barcoded label to the device. The user protocol doesn't
require the operator to inform the device of his desire to do so;
that would be an inefficient use of the operator's time! Instead,
the operator can swipe a barcode at ANY time. The barcode
hardware consists of a photodetector feeding an edge triggered
interrupt pin, through an XOR. The other input of the XOR allows
the ISR to indicate that it is looking for the black-to-white
edge (of a bar) or the white-to-black edge (of a space) as the
times between them are the "data". The ISR simply stores the
contents of a freerunning counter along with another value
(from the same counter) that effectively tells how long *ago*
the edge occurred. I.e., the barcode *handler* will be able to
adjust the observed counter value to reflect this interrupt
latency to yield the *actual* time between successive "edges".
At 100 ips, a minimal bar/space of 0.007" can pass the detector
(i.e., time between edges) in 70 microseconds. Even smaller
if you allow for ink spread (which causes space shrinking).
You'll see an entire set of ~100 transitions in a bit less than
a second -- an "entire code". I.e., the ISR is *really* fast
cuz it has to catch each edge and reprogram the XOR for the
NEXT edge. All this on a 1980-vintage machine processing 1.5M
8b opcodes per second.
The Barcode task implements the "handler" -- that retrieves the
raw data from the circular buffer managed by the ISR as it
arrives (and taking note if it is ever too sluggish revisiting
the buffer before it overflows!), does the latency compensation
and then begins the analysis of the actual bar/space widths to
create a code -- which it then verifies as legitimate or not.
If the ratios of bar/space widths don't fit a defined pattern,
the "oldest" bar and accompanying space are discarded and the
process repeats -- until a set of bar/space widths consistent
with a "legitimate character encoding" are discovered. Then,
the bars and spaces that follow are analyzed to (hopefully)
arrive at another "valid character".
Once *a* character is available, we hesitate to discard anything
until we know if that character -- and any that might follow -- are
representative of a valid label (which might be "followed" by crud).
;Validity ::= Valid_ID | Alpha_ID | Null_ID
;
;Valid_ID ::= NumericID
;Alpha_ID ::= AlphaID
;Null_ID ::= NullID
Wildcard NumericID for Validity is keyed with Valid_ID
Wildcard AlphaID for Validity is keyed with Alpha_ID
Wildcard NullID for Validity is keyed with Null_ID
;IDVals ::= NumericID | AlphaID | NullID
;
;NumericID ::= PADDING DIGIT DIGITS
;AlphaID ::= PADDING ALPHAPART NUMERICPART
;NullID ::= PADDING
Grammar for NumericID is <<PADDING,DIGIT,DIGITS>>
Grammar for AlphaID is <<PADDING,ALPHAPART,NUMERICPART>>
Grammar for NullID is <<PADDING>>
Wildcard PADDING for IDVals is keyed with 'p'
Wildcard DIGIT for IDVals is keyed with '#'
Wildcard DIGIT? for IDVals is keyed with 'e'
Wildcard DIGITS for IDVals is keyed with 'd'
Wildcard ALPHAPART for IDVals is keyed with 'a'
Wildcard NUMERICPART for IDVals is keyed with 'n'
;PADDING ::= ASCNUL PADDING | ''
;DIGITS ::= DIGIT DIGITS | ''
;DIGIT? ::= DIGIT | ''
etc. I.e., a grammar for what constitutes a "valid" label in terms
of "recognized characters" -- so the handler can reject any PROCESSED
data that might LOOK like (and may even *be*!) a set of legal characters
but that doesn't ACTUALLY satisfy the criteria for a label.
Once *a* code/label has been read, it has to note if another VALID
label is encountered within a "half inch" of the end of the previous
label (of course, it can't measure distances, only *times* -- what's
a half inch at the scan rate that is apparent from the bar/space
times in the data already recognized?). If the start code of the next
label is compatible with the end code of the previous, seamlessly glue
these labels together AS IF they had been a single, continuous label.
Up to three labels can be concatenated like this *in* the Barcode
handler so the rest of the system is unaware of this capability
(the adjoining start and end codes are elided when the label's contents
are reported to the application)
When valid, it signals a BARCODE_AVAILABLE event to the Operator
FSM task. Which can then interpret the event as applicable to the
current user context (is a barcode valid at this stage in the protocol?
is *this* barcode valid, here?)
So, times from 70 microseconds through a second or more to ensure the
label has completely passed the scanner (can't control how fast the
user moves his arm!)
The Sensor task scans an array of 60 RC oscillators at a rate that is
frequency locked to the AC mains with the same sort of interrupt latency
compensation that was applied to the barcode detector. In addition to
noting the current frequency of each oscillator, it also has to detect
an "open" cap (the caps are formed from large, widely spaced plates that
allow changes in frequency to be used to detect the presence of 10 microliter
blood samples placed between any pair; if a plate breaks off, that detector
is obviously unreliable), a shorted cap (if the user bridges the gap between
the plates with something of "relatively" low impedance the sensor is
unreliable) or a disconnected sensor assembly.
These data are signaled to the Operator FSM as well so the FSM knows what
the operator has done in his "interaction" with the sensor array. So, you're
sampling at some multiple of AC mains clock periods (the sampling interval
changes based on what the Operator FSM is expecting from the sensor; faster
intervals for reduced resolution, etc. A user typically pipettes samples
(or reagents!) at a few second interval -- sort of like tapping on a keyboard.
The Operator FSM task is a giant state machine that processes events
and conditions sourced from other tasks. It steers the user interaction
accordingly. Events can be sourced at varying timescales: as often as
a user presses a key or scans a barcode, as often as he pipettes blood
samples into the array, as often as the power fails/recovers, etc.
It runs forever (as do all of these other jobs)
The Diagnostic and Supervisor FSM's are other operating modes for the
device. Typically, only one of these three modes are engaged at a
time. Splitting them into three FSM's allows them to operate concurrently
as well as reducing the complexity of the "user interface" FSM.
Port0 and Port1 are handlers that service the two UARTs. Each talks to
a respective UART ISR to retrieve incoming data and status (from software
FIFO's with overflow protection -- this predates UARTs with big internal
buffers). They also implement the hardware handshaking and character
"pacing" (so the ISR's can remain lean -- just read the data and status
registers... don't bother with the handshaking in the foreground!).
As such, they deal with "character times" -- too sluggish and the
remote device can be overrun *or* overrun the local device.
Additionally, they feed two instances of the same state machine that
implements the interface language specification by which external
devices can query and control the device and the data that it maintains.
The system is resilient enough that you can take a barcode label and
rub it vigorously back and forth over the detector -- keeping in mind that
each black/white transition triggers an interrupt -- and not crash the
device *or* corrupt its execution. And, when you get tired of
waving the barcode labels in front of the detector, the system will
respond with the *correctly* decoded barcode -- despite the overload
that it experienced.
Of course, it *has* to be -- else you'll report the wrong diagnosis for
some patient!
What "priorities" would you like me to assign to these tasks? Maybe force
the user to press a "Read A Barcode" key so the barcode task can be
made ready? Then, once it has seen a barcode (or, perhaps, timed out?),
it can make itself NOT ready until manually called upon, again?
Maybe the Port0 servicing should only run when the user isn't busy
interacting with the device? And, Port1 should wait until Port0
is no longer active?
Maybe ignore the power subsystem while the user is in the middle of
a sampling cycle and only worry about power availability BETWEEN
those cycles? (e.g., POLL it?). Unless, of course, he takes too
long and we have to abort his action lest we starve the power
monitor task. And, we can just use a higher quality crystal oscillator
instead of calibrating it against the (reliable) AC mains. And, only
check the line frequency each time we power up (hey, if it's 50Hz,
it's gonna stay 50Hz, right?). If the line frequency drifts, we can
always live with a low frequency "beat" in the display. And, errors in
the sensor array, right?
As I said elsewhere, everything ends up running at essentially the same
"priority" -- because everything CAN happen at the same time! Those
activities that have truly tight timeliness constraints move into the
foreground. And, ONLY do what they absolutely *must* while there.
E.g., the barcode ISR doesn't waste foreground time computing the "time
since the previous edge"; the UART ISR's don't waste time twiddling
with handshaking/pacing features; etc.
And, the *background* routines aren't piggish, either! They do enough to
have justify their invocation "this time around the loop" but not too
much that they delay the other tasks (who are ALL "ready"). So, the barcode
handler quickly tries to empty any "edge times" from the barcode ISR's
FIFO -- and converting them to widths. This allows 4 bytes of FIFO data
to be reduced to a two byte "width" -- in the *handler's* "width FIFO".
So, the ISR FIFO can stay small and still accommodate the amount of
activity likely to be encountered BEFORE THE HANDLER COMES AROUND, AGAIN,
to empty it.
Likewise, the higher layers in the barcode handler try to aggressively
discard "widths" that are incompatible with "valid character codes".
Again, trying to keep as much space available in the *width* FIFO so
there is always room for the raw "edge" data from the ISR FIFO.
And, even higher layers try to invalidate individual characters as
being incompatible with a valid *label* format -- again, so some widths
can be removed from the width FIFO.
And, ultimately, concatenated labels that fail to satisfy the criteria
for a "glued together" label can be discarded. Always keeping the door
open to harvest as much data from the ISR as possible. Because a FIFO
overrun (anywhere) wedges the label in question. And, that means the user
has to rescan the label (this is not a Good Thing).
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-24 13:37 -0500
Re: Common name for a "Task Loop" Lanarcam <lanarcam1@yahoo.fr> - 2016-06-24 21:04 +0200
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 15:21 -0500
Re: Common name for a "Task Loop" Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-06-24 22:46 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-24 14:51 -0500
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 15:10 -0500
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-24 20:11 +0000
Re: Common name for a "Task Loop" gtwrek@sonic.net (Mark Curry) - 2016-06-24 20:31 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-24 13:21 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 18:31 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-24 17:03 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 10:52 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 01:07 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 14:00 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 08:27 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:50 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:45 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 17:28 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:40 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 12:41 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:46 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:42 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:43 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:36 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 17:25 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:14 -0700
Re: Common name for a "Task Loop" Paul Rubin <no.email@nospam.invalid> - 2016-06-24 14:00 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 15:27 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 09:41 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 17:59 +0000
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 16:24 -0500
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:36 +0000
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-26 19:00 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-27 05:53 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-27 09:43 -0500
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 02:39 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 15:08 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:54 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 18:12 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 02:54 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-28 06:20 +0300
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-27 22:57 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-28 09:40 -0500
Re: Common name for a "Task Loop" Mel Wilson <mwilson@the-wire.com> - 2016-06-28 15:38 +0000
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-28 08:57 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 16:49 +0000
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-28 15:35 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 13:54 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 14:04 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 21:09 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 15:14 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 22:30 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:06 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:18 -0700
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-29 01:32 +0200
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 01:00 +0300
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-29 00:20 +0200
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:07 +0300
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 22:21 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:20 +0300
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-28 17:39 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:29 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-29 09:50 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 15:43 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:40 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:56 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-29 08:04 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 23:22 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-30 09:02 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-30 02:33 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-02 14:27 +0300
Re: Common name for a "Task Loop" Wouter van Ooijen <wouter@voti.nl> - 2016-07-02 14:50 +0200
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-02 20:18 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-02 07:36 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-02 21:44 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-02 14:36 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-03 06:23 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-03 00:43 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 11:36 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 09:55 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 12:53 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 11:29 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 13:41 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 11:49 -0700
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-02 20:48 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 03:07 -0500
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-03 08:06 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 12:39 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-03 21:44 +0300
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-03 16:39 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 23:57 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-04 14:39 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-05 06:04 +0300
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-07-05 11:58 -0500
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-07-06 10:39 +0800
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-06 10:11 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-05 21:57 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 12:20 -0700
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-04 10:08 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 11:59 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-05 22:51 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 13:16 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-06 11:31 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-06 03:06 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-06 21:37 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-07 00:50 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-06 23:16 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-07 21:36 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-07 12:06 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-07 23:09 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-08 11:06 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 12:50 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-08 23:33 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:40 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-08 23:47 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:48 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:37 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-09 14:26 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 00:48 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-10 03:29 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-11 06:51 +0300
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-11 16:11 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-11 12:04 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-12 11:31 +0300
Re: Common name for a "Task Loop" mac <acolvin@efunct.com> - 2016-07-12 15:08 +0000
Re: Common name for a "Task Loop" Robert Wessel <robertwessel2@yahoo.com> - 2016-07-12 21:24 -0500
Memory scrubbing [Was Re: Common name for a "Task Loop"] Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 21:11 +0300
Re: Common name for a "Task Loop" Robert Wessel <robertwessel2@yahoo.com> - 2016-07-12 21:11 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-08 23:35 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-08 23:54 +0300
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-09 09:34 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-09 10:28 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-09 14:39 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:56 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 15:46 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-10 02:41 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 17:55 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-16 16:34 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-17 09:56 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-18 00:08 -0400
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-18 21:16 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-18 23:54 -0400
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-19 10:02 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 02:56 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 02:40 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-25 17:32 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 16:56 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-26 06:27 -0400
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-26 15:59 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 06:55 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-26 17:14 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-26 12:50 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 22:07 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-27 14:22 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-08-03 04:58 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 06:38 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-09 01:28 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-09 09:25 +0300
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:47 +0300
Re: Common name for a "Task Loop" Mike Perkins <spam@spam.com> - 2016-07-09 11:18 +0100
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:41 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-09 20:52 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-10 02:01 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 17:34 +0300
Re: Common name for a "Task Loop" [long] Don Y <blockedofcourse@foo.invalid> - 2016-07-17 01:17 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-07-07 16:02 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-30 04:14 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-30 17:07 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-01 02:28 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 12:02 -0700
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-28 23:19 +0200
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 11:51 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-01 06:54 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-25 21:08 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 15:24 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 21:52 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 01:04 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 13:46 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 05:11 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 15:35 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 06:57 -0700
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 21:18 +0800
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 07:07 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 17:35 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 07:50 -0700
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 22:37 +0800
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 08:18 -0700
Re: Common name for a "Task Loop" Dave Nadler <drn@nadler.com> - 2016-06-25 22:00 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-26 11:01 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-26 19:28 -0500
Re: Common name for a "Task Loop" FreeRTOS info <noemail@given.com> - 2016-06-27 08:33 +0100
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-28 09:48 -0500
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-28 08:25 -0700
Re: Common name for a "Task Loop" Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-07-03 17:39 +0000
Re: Common name for a "Task Loop" WangoTango <Asgard24@mindspring.com> - 2016-07-14 16:27 -0400
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-14 20:44 +0000
csiph-web