Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24329 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2016-06-24 13:37 -0500 |
| Last post | 2016-07-14 20:44 +0000 |
| Articles | 20 on this page of 196 — 27 participants |
Back to article view | Back to comp.arch.embedded
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
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2016-06-28 06:20 +0300 |
| Message-ID | <nksqe7$vgg$1@dont-email.me> |
| In reply to | #24400 |
On 28.6.2016 г. 05:54, Simon Clubley wrote: > > ..... > I still think that's a polling loop > because you are reaching out to the sensor and asking it for it's > current value. "Polling" in programming means "as opposed to interrupt handling". How is this opposed to "interrupt handling". What you suggest to be polling is simply a loop of calls to subroutines. A "call loop" is what describes it - although it does not matter a lot what word is used as long as it is not an already widely accepted one like "polling" which you want to redefine. Nothing wrong with that of course - as long as you don't have to communicate with other people using your redefined term. So much talk about so little :-). Although Tim's topic idea worked, produced quite a discussion. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | raimond.dragomir@gmail.com |
|---|---|
| Date | 2016-06-27 22:57 -0700 |
| Message-ID | <4313524a-c1da-4b32-b2ed-a619bb1fce41@googlegroups.com> |
| In reply to | #24402 |
> So much talk about so little :-). Although Tim's topic idea worked, > produced quite a discussion. > > Dimiter > Indeed. Kind of super loop (I call it "main loop") which schedules some "tasks". The tasks are in fact FSM (finite state machines) so the "task loop" isn't quite ok of a name. I'm using this technique quite often in simpler systems. If you ask me what I do, I may say "A main loop running finite state machines".
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2016-06-28 09:40 -0500 |
| Message-ID | <TvidnV801c73Ee_KnZ2dnUU7-cGdnZ2d@giganews.com> |
| In reply to | #24402 |
On Tue, 28 Jun 2016 06:20:43 +0300, Dimiter_Popoff wrote: > On 28.6.2016 г. 05:54, Simon Clubley wrote: >> > > ..... >> I still think that's a polling loop because you are reaching out to the >> sensor and asking it for it's current value. > > "Polling" in programming means "as opposed to interrupt handling". > How is this opposed to "interrupt handling". > > What you suggest to be polling is simply a loop of calls to subroutines. > A "call loop" is what describes it - although it does not matter a lot > what word is used as long as it is not an already widely accepted one > like "polling" which you want to redefine. Nothing wrong with that of > course - as long as you don't have to communicate with other people > using your redefined term. > > So much talk about so little :-). Although Tim's topic idea worked, > produced quite a discussion. Well, I was hoping for a name of a design pattern, and I'm still not happy about my choices. So from that perspective it's a wash. "Super loop" seems closest, but it seems to more capture the notion of _always_ executing A, B, C, rather than executing only those bits that are ready. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2016-06-28 15:38 +0000 |
| Message-ID | <nku5le$ann$1@dont-email.me> |
| In reply to | #24407 |
On Tue, 28 Jun 2016 09:40:42 -0500, Tim Wescott wrote: > "Super loop" seems closest, but it seems to more capture the notion of > _always_ executing A, B, C, rather than executing only those bits that > are ready. I had called it a Round-Robin Loop, but nobody understands me because everybody calls it something else.
[toc] | [prev] | [next] | [standalone]
| From | raimond.dragomir@gmail.com |
|---|---|
| Date | 2016-06-28 08:57 -0700 |
| Message-ID | <2994c1e9-176a-40fb-98c1-53ccc3489164@googlegroups.com> |
| In reply to | #24410 |
marți, 28 iunie 2016, 18:38:26 UTC+3, Mel Wilson a scris: > On Tue, 28 Jun 2016 09:40:42 -0500, Tim Wescott wrote: > > > "Super loop" seems closest, but it seems to more capture the notion of > > _always_ executing A, B, C, rather than executing only those bits that > > are ready. > > I had called it a Round-Robin Loop, but nobody understands me because > everybody calls it something else. Arduino calls it simply "loop()" :-)
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2016-06-28 16:49 +0000 |
| Message-ID | <nku9qb$r07$1@dont-email.me> |
| In reply to | #24407 |
Tim Wescott wrote:
> On Tue, 28 Jun 2016 06:20:43 +0300, Dimiter_Popoff wrote:
>
>> On 28.6.2016 г. 05:54, Simon Clubley wrote:
>>>
>> > .....
>>> I still think that's a polling loop because you are reaching out to the
>>> sensor and asking it for it's current value.
>>
>> "Polling" in programming means "as opposed to interrupt handling".
>> How is this opposed to "interrupt handling".
>>
>> What you suggest to be polling is simply a loop of calls to subroutines.
>> A "call loop" is what describes it - although it does not matter a lot
>> what word is used as long as it is not an already widely accepted one
>> like "polling" which you want to redefine. Nothing wrong with that of
>> course - as long as you don't have to communicate with other people
>> using your redefined term.
>>
>> So much talk about so little :-). Although Tim's topic idea worked,
>> produced quite a discussion.
>
> Well, I was hoping for a name of a design pattern, and I'm still not
> happy about my choices. So from that perspective it's a wash.
>
> "Super loop" seems closest, but it seems to more capture the notion of
> _always_ executing A, B, C, rather than executing only those bits that
> are ready.
>
Which is how I usually implement it, but the first thing in A is
switch (state) {
case IDLE:
if (!input_ready) break;
The tasks usually wind up having to be state machines anyhow; why bother
pulling one transition out to a different place?
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-06-28 15:35 -0500 |
| Message-ID | <nkumro$d9t$2@dont-email.me> |
| In reply to | #24412 |
Rob Gaddi wrote:
> Tim Wescott wrote:
>
>> On Tue, 28 Jun 2016 06:20:43 +0300, Dimiter_Popoff wrote:
>>
>>> On 28.6.2016 г. 05:54, Simon Clubley wrote:
>>>>
>>> > .....
>>>> I still think that's a polling loop because you are reaching out to the
>>>> sensor and asking it for it's current value.
>>>
>>> "Polling" in programming means "as opposed to interrupt handling".
>>> How is this opposed to "interrupt handling".
>>>
>>> What you suggest to be polling is simply a loop of calls to subroutines.
>>> A "call loop" is what describes it - although it does not matter a lot
>>> what word is used as long as it is not an already widely accepted one
>>> like "polling" which you want to redefine. Nothing wrong with that of
>>> course - as long as you don't have to communicate with other people
>>> using your redefined term.
>>>
>>> So much talk about so little :-). Although Tim's topic idea worked,
>>> produced quite a discussion.
>>
>> Well, I was hoping for a name of a design pattern, and I'm still not
>> happy about my choices. So from that perspective it's a wash.
>>
>> "Super loop" seems closest, but it seems to more capture the notion of
>> _always_ executing A, B, C, rather than executing only those bits that
>> are ready.
>>
>
> Which is how I usually implement it, but the first thing in A is
>
> switch (state) {
> case IDLE:
> if (!input_ready) break;
>
> The tasks usually wind up having to be state machines anyhow; why bother
> pulling one transition out to a different place?
>
Agreed.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-06-28 13:54 -0700 |
| Message-ID | <nkuo5q$io7$1@dont-email.me> |
| In reply to | #24412 |
On 6/28/2016 9:49 AM, Rob Gaddi wrote:
> Which is how I usually implement it, but the first thing in A is
>
> switch (state) {
> case IDLE:
> if (!input_ready) break;
>
> The tasks usually wind up having to be state machines anyhow; why bother
> pulling one transition out to a different place?
Does each invocation of "A" have to begin at the switch?
I.e., do you implement "substates" so you can resume at a different
point *in* "IDLE" on the next invocation?
switch (state) {
case IDLE:
if (!ready)
break;
input = get_input(); // potentially time consuming or, perhaps,
// even requires a separate process to *do*
// the actual "getting" -- like clocking
// an SPI, etc. that takes far too much time
// to tie up the "big loop"
yield();
resume:
if (input ...) {
do_something() // transition routine for IDLE -> ACCEPTING
state = ACCEPTING;
} else if (input ...) {
something_else() // transition routine for IDLE -> REJECTING
state = REJECTING;
} else {
complain(); // blocks as complain is a lengthy operation
}
I.e., how does "A" return to "resume" on the next invocation (do you have
to split it out as an "intermediate sub-state?) or to the block *inside*
complain()?
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-06-28 14:04 -0700 |
| Message-ID | <nkuook$kmn$1@dont-email.me> |
| In reply to | #24417 |
On 6/28/2016 1:54 PM, Don Y wrote:
> On 6/28/2016 9:49 AM, Rob Gaddi wrote:
>> Which is how I usually implement it, but the first thing in A is
>>
>> switch (state) {
>> case IDLE:
>> if (!input_ready) break;
>>
>> The tasks usually wind up having to be state machines anyhow; why bother
>> pulling one transition out to a different place?
>
> Does each invocation of "A" have to begin at the switch?
> I.e., do you implement "substates" so you can resume at a different
> point *in* "IDLE" on the next invocation?
> I.e., how does "A" return to "resume" on the next invocation (do you have
> to split it out as an "intermediate sub-state?) or to the block *inside*
> complain()?
Said another way, is "state" the equivalent of (and only means of
representing) the "virtual program counter" for 'A'?
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2016-06-28 21:09 +0000 |
| Message-ID | <nkup1f$ltb$1@dont-email.me> |
| In reply to | #24418 |
Don Y wrote:
> On 6/28/2016 1:54 PM, Don Y wrote:
>> On 6/28/2016 9:49 AM, Rob Gaddi wrote:
>>> Which is how I usually implement it, but the first thing in A is
>>>
>>> switch (state) {
>>> case IDLE:
>>> if (!input_ready) break;
>>>
>>> The tasks usually wind up having to be state machines anyhow; why bother
>>> pulling one transition out to a different place?
>>
>> Does each invocation of "A" have to begin at the switch?
>> I.e., do you implement "substates" so you can resume at a different
>> point *in* "IDLE" on the next invocation?
>
>> I.e., how does "A" return to "resume" on the next invocation (do you have
>> to split it out as an "intermediate sub-state?) or to the block *inside*
>> complain()?
>
> Said another way, is "state" the equivalent of (and only means of
> representing) the "virtual program counter" for 'A'?
Yup. Each invocation of A runs through to completion without blocking;
if it's waiting for I/O then you're in
case SPI_WAIT:
if (!spi_finished) break;
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-06-28 15:14 -0700 |
| Message-ID | <nkusrr$6l6$1@dont-email.me> |
| In reply to | #24419 |
On 6/28/2016 2:09 PM, Rob Gaddi wrote:
>> Said another way, is "state" the equivalent of (and only means of
>> representing) the "virtual program counter" for 'A'?
>
> Yup. Each invocation of A runs through to completion without blocking;
> if it's waiting for I/O then you're in
>
> case SPI_WAIT:
> if (!spi_finished) break;
So, if you were bit-banging the SPI interface, you'd have to
keep the 'substate' (of "SPI_WAIT") in a "spi_clock_counter"
(so you could issue *a* clock then relinquish the processor for
"yet another big loop iteration" while remaining in the SPI_WAIT
state *or* issue the individual clocks "in-line" and ensure they
actually make it onto the I/O pins sequentially with the
required time between them (determined by the device).
In my case, this would be (*inline* with whatever was issuing the SPI):
count = CLOCKS_REQUIRED;
while (count > 0) {
issue_clock(HIGH);
load_timer(SPI_TIMER,SPI_HIGH_DURATION)
pause_while_high:
wait_timer(SPI_TIMER);
issue_clock(LOW);
load_timer(SPI_TIMER,SPI_LOW_DURATION)
pause_while_low:
wait_timer(SPI_TIMER);
clock--;
}
i.e., on the first load_timer() would effectively set the PC to
"pause_while_high" AFTER initializing the timer (though it would
"ret" to the caller after having done so).
Each wait_timer() would examine the specified timer and become
a "ret" iff the timer was not-expired. Otherwise, it becomes
a noop -- allowing the code to advance to the next statement.
All of this sitting *within* your "IDLE" (or <whatever> state)
[Other semantics are possible, this one has proven to be the most
expressive, IME]
So, you can do things like:
count = CLOCKS_REQUIRED;
load_timer(SPI_TIMEOUT,MAX_SPI_CYCLE_DURATION)
while (count > 0) {
issue_clock(HIGH);
load_timer(SPI_TIMER,SPI_HIGH_DURATION)
pause_while_high:
if (check_timer(SPI_TIMEOUT))
goto ABORT;
wait_timer(SPI_TIMER);
issue_clock(LOW);
load_timer(SPI_TIMER,SPI_LOW_DURATION)
pause_while_low:
if (check_timer(SPI_TIMEOUT))
goto ABORT;
wait_timer(SPI_TIMER);
clock--;
}
I.e., you can run code while waiting (instead of being BLOCKED in
the wait).
[Of course, this doesn't make sense for an SPI interface; OTOH, it can
be helpful for implementing "STUCK KEY" timers for keypads ALONGSIDE
the "DEBOUNCE" timer! In the real world, this seems to happen
quite a lot: starting a motor and waiting for it to hit a limit
switch -- yet KNOWING that it can't run "forever" unless the switch
or the mechanism are broken!]
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2016-06-28 22:30 +0000 |
| Message-ID | <nkutq4$9qk$1@dont-email.me> |
| In reply to | #24422 |
Don Y wrote:
> On 6/28/2016 2:09 PM, Rob Gaddi wrote:
>>> Said another way, is "state" the equivalent of (and only means of
>>> representing) the "virtual program counter" for 'A'?
>>
>> Yup. Each invocation of A runs through to completion without blocking;
>> if it's waiting for I/O then you're in
>>
>> case SPI_WAIT:
>> if (!spi_finished) break;
>
> So, if you were bit-banging the SPI interface, you'd have to
> keep the 'substate' (of "SPI_WAIT") in a "spi_clock_counter"
> (so you could issue *a* clock then relinquish the processor for
> "yet another big loop iteration" while remaining in the SPI_WAIT
> state *or* issue the individual clocks "in-line" and ensure they
> actually make it onto the I/O pins sequentially with the
> required time between them (determined by the device).
>
Although on a small enough processor that I wouldn't consider even
cooperative OS, you generally bit-bang SPI by flipping the port pins as
fast as you can and finding that it's just not all that fast. No reason
to multitask in the middle of it.
> In my case, this would be (*inline* with whatever was issuing the SPI):
>
> count = CLOCKS_REQUIRED;
> while (count > 0) {
> issue_clock(HIGH);
> load_timer(SPI_TIMER,SPI_HIGH_DURATION)
> pause_while_high:
> wait_timer(SPI_TIMER);
> issue_clock(LOW);
> load_timer(SPI_TIMER,SPI_LOW_DURATION)
> pause_while_low:
> wait_timer(SPI_TIMER);
> clock--;
> }
>
> i.e., on the first load_timer() would effectively set the PC to
> "pause_while_high" AFTER initializing the timer (though it would
> "ret" to the caller after having done so).
>
> Each wait_timer() would examine the specified timer and become
> a "ret" iff the timer was not-expired. Otherwise, it becomes
> a noop -- allowing the code to advance to the next statement.
>
> All of this sitting *within* your "IDLE" (or <whatever> state)
>
> [Other semantics are possible, this one has proven to be the most
> expressive, IME]
>
> So, you can do things like:
>
> count = CLOCKS_REQUIRED;
> load_timer(SPI_TIMEOUT,MAX_SPI_CYCLE_DURATION)
> while (count > 0) {
> issue_clock(HIGH);
>
> load_timer(SPI_TIMER,SPI_HIGH_DURATION)
> pause_while_high:
> if (check_timer(SPI_TIMEOUT))
> goto ABORT;
> wait_timer(SPI_TIMER);
>
> issue_clock(LOW);
>
> load_timer(SPI_TIMER,SPI_LOW_DURATION)
> pause_while_low:
> if (check_timer(SPI_TIMEOUT))
> goto ABORT;
> wait_timer(SPI_TIMER);
>
> clock--;
> }
>
> I.e., you can run code while waiting (instead of being BLOCKED in
> the wait).
>
> [Of course, this doesn't make sense for an SPI interface; OTOH, it can
> be helpful for implementing "STUCK KEY" timers for keypads ALONGSIDE
> the "DEBOUNCE" timer! In the real world, this seems to happen
> quite a lot: starting a motor and waiting for it to hit a limit
> switch -- yet KNOWING that it can't run "forever" unless the switch
> or the mechanism are broken!]
And at that point you've got a non-preemptive OS where you explicitly
yield the processor in each task. It's fine as far as it goes, but
you've just introduced all the issues of managing multiple stacks,
having a scheduler that keeps track of "tasks", etc. If you've got the
RAM for it, great, but I wouldn't want to try it on 1KB.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-06-28 16:06 -0700 |
| Message-ID | <nkuvt4$fof$1@dont-email.me> |
| In reply to | #24425 |
On 6/28/2016 3:30 PM, Rob Gaddi wrote:
> Don Y wrote:
>
>> On 6/28/2016 2:09 PM, Rob Gaddi wrote:
>>>> Said another way, is "state" the equivalent of (and only means of
>>>> representing) the "virtual program counter" for 'A'?
>>>
>>> Yup. Each invocation of A runs through to completion without blocking;
>>> if it's waiting for I/O then you're in
>>>
>>> case SPI_WAIT:
>>> if (!spi_finished) break;
>>
>> So, if you were bit-banging the SPI interface, you'd have to
>> keep the 'substate' (of "SPI_WAIT") in a "spi_clock_counter"
>> (so you could issue *a* clock then relinquish the processor for
>> "yet another big loop iteration" while remaining in the SPI_WAIT
>> state *or* issue the individual clocks "in-line" and ensure they
>> actually make it onto the I/O pins sequentially with the
>> required time between them (determined by the device).
>
> Although on a small enough processor that I wouldn't consider even
> cooperative OS, you generally bit-bang SPI by flipping the port pins as
> fast as you can and finding that it's just not all that fast. No reason
> to multitask in the middle of it.
Pick something that isn't "on the same timescale" as an opcode fetch
(e.g., debouncing keys on a keypad).
>> [Of course, this doesn't make sense for an SPI interface; OTOH, it can
>> be helpful for implementing "STUCK KEY" timers for keypads ALONGSIDE
>> the "DEBOUNCE" timer! In the real world, this seems to happen
>> quite a lot: starting a motor and waiting for it to hit a limit
>> switch -- yet KNOWING that it can't run "forever" unless the switch
>> or the mechanism are broken!]
>
> And at that point you've got a non-preemptive OS where you explicitly
> yield the processor in each task. It's fine as far as it goes, but
> you've just introduced all the issues of managing multiple stacks,
> having a scheduler that keeps track of "tasks", etc. If you've got the
> RAM for it, great, but I wouldn't want to try it on 1KB.
But you don't have to "manage multiple stacks", "have a scheduler", etc.!
Those things rely heavily on the choice of implementation language
that you choose for your product. I.e., if your product is small,
then the gains of a HLL are relatively insignificant AND any "hidden
costs" are likely to catch you unprepared.
[The LORAN plotter mentioned elsewhere this thread was coded in ASM
as HLL's simply weren't available in the i4004/i8080 days]
Apologies for the all caps but the tools available 40 years ago
weren't very tolerant! :-/ Note this is NOT running in an ISR
Why should it? if we can guarantee from the design of the system
(i.e., how quickly you can get around the "loop") that it will be
revisited OFTEN/frequently, why waste a foreground resource (ISR)
on something as silly as scanning and debouncing keys??
BigLoop:
Call TMHNDL ; system timers service
...
Call KYHNDL ; service keypad
...
ret
Main:
Call BigLoop ; run the machine
Call Otherstuff ; support diagnostics, performance counters, etc.
Jump Main
KYHNDL: YIELD ;BEGIN KEYPAD IDLE STATE
CALL KYPDCK ;CHECK IF ANY KEY CLOSURES
RET Z ;NO KEY CLOSURES HAVE BEEN DETECTED
LD E,A ;COLUMN DATA OF ROW DETECTED AS FIRST KEY CLOSURE
DEC A ;SET BITS TO THE RIGHT OF THE RIGHTMOST COLUMN DETECTED
AND E ;ANY COLUMNS DETECTED TO THE LEFT OF RIGHTMOST COLUMN?
JR NZ,TWOKEY ;TWO KEY CLOSURES DETECTED IN THE SAME ROW
DEC B ;SET Z FLAG IFF FIRST KEY WAS DETECTED IN LAST ROW!
LD D,B ;ROW NUMBER OF FIRST CLOSURE [0, NMKYRW-1]
CALL NZ,KYPDLP ;CHECK IF CLOSURE IN ANOTHER ROW IF NOT ALREADY IN LAST
JR NZ,TWOKEY ;TWO CLOSURES DETECTED IN DIFFERENT ROWS
LD A,D ;RETRIEVE ROW NUMBER OF ONLY CLOSURE [0, NMKYRW-1]
LD B,NMKYRW ;NUMBER OF ROWS IN KEYPAD
SUB B ;R.A = ROW NUMBER OF DETECTED KEY - NMKYRW
ONKYLP: ADD A,B ;ACCUMULATE KEYNUMBER AS (COL*NMKYRW+ROW)
RR E ;ADVANCE TO NEXT COLUMN TO THE LEFT
JR NC,ONKYLP ;NOT THIS COLUMN, TRY AGAIN.
INC A ;FORM KEYNUMBER AS (COL*NMKYRW+ROW)+1 [1,NMKYCL*NMKYRW]
CALL PUTKEY ;SEND CHARACTER TO KEYPAD BUFFER
;keypad buffer ultimately feeds anything that is interested in "keystrokes"
;so, keystrokes can be buffered to accommodate variations in how quickly
;PREVIOUS keystrokes are processed/consumed
TWOKEY: LOAD STUCK_KEY_TIMER 15 SEC ;SETUP STUCK KEY TIMER AND YIELD
CALL KYPDCK ;CHECK IF ANY KEY STILL DOWN
JR Z,NOTKEY ;ALL KEYS RELEASED
WAIT STUCK_KEY_TIMER ;A KEY IS DOWN, WAIT ON STUCK TIMER
LD A,STKKEY ;FLAG INDICATING KEY STUCK
CALL PUTKEY ;SIGNAL STUCK KEY ERROR
JR TWOKEY ;WAIT FOR STUCK KEY CONDITION TO GO AWAY
NOTKEY: LOAD DEBOUNCE_TIMER 50 MSEC ;SETUP DEBOUNCE TIMER AND YIELD
CALL KYPDCK ;CHECK IF STILL NO KEY CLOSURE
JR NZ,TWOKEY ;KEY HAS BOUNCED CLOSED
WAIT DEBOUNCE_TIMER ;NO CLOSURE WAIT ON TIMER
JR KYHNDL ;TIMER HAS TIMED OUT INDICATING KEYPAD NOW IDLE
[the keypad hardware exists in memory at the address KEYBRD -- which is
of the form YYxx (hex). The xx are individual bits, one per row, that
drive the row selects of the keypad; reading YY01 would read any key
closures in row 0 of the keypad, YY02 for row 1, YY04 for row 2,
YYFF for ANY row -- by enabling all rows simultaneously!]
KYPDCK: LD HL,KEYBRD+ALLROW ;POINTER TO ALL ROWS SELECT
LD BC,NMKYRW*256+ALLCOL ;NUMBER OF ROWS AND MASK
LD A,(HL) ;CHECK IF ANY KEY CLOSURES IN ANY ROW
AND C ;IGNORE UNUSED COLUMNS OF KEYPAD
RET Z ;NO KEY CLOSURES DETECTED ANYWHERE
INC L ;FORCE A SINGLE BIT FOR A SINGLE ROW TO BE SELECTED
KYPDLP: RR L ;SHIFT SELECT BIT TO GET THE NEXT ROW SELECTED
LD A,(HL) ;READ THE COLUMN DATA FOR THIS ROW
AND C ;IGNORE UNUSED COLUMNS OF KEYPAD
RET NZ ;A KEY CLOSURE HAS BEEN DETECTED IN THIS SELECTED ROW
DJNZ KYPDLP ;NOT DONE SCANNING ALL ROWS
RET ;ALL ROWS SCANNED BUT I COULD HAVE SWORN I SAW A KEY
Note that there is no need to save any "state" in any of these algorithms
beyond the state that is embodied in the Program Counter and the timers
(which are managed by the TMHNDL)
[I'd much rather have these capabilities/services than a HLL when coding
small (~16KB ROM) projects]
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-06-28 16:18 -0700 |
| Message-ID | <nkv0kn$hrc$1@dont-email.me> |
| In reply to | #24429 |
On 6/28/2016 4:06 PM, Don Y wrote: > TWOKEY: LOAD STUCK_KEY_TIMER 15 SEC ;SETUP STUCK KEY TIMER AND YIELD > > CALL KYPDCK ;CHECK IF ANY KEY STILL DOWN > JR Z,NOTKEY ;ALL KEYS RELEASED > > WAIT STUCK_KEY_TIMER ;A KEY IS DOWN, WAIT ON STUCK TIMER It will only be obvious to someone carefully inspecting the code (unfamiliar with the primitives being used) that the LOAD has redefined the entry point for this task to be immediately AFTER the LOAD *and* has yielded the CPU to the next "task" in the "loop". I.e., the next time around the loop, CALL KYPDCK will execute in this task's "timeslot". If the key (ANY key!) is still depressed, then the WAIT will execute. When the key is released, then we debounce the trailing edge of the key closure (i.e., require the keypad to remain "idle" for a certain amount of time before we actually return to the "IDLE" state). [Note that this code is shared between multiple key closures and a *single* key closure -- the difference being whether the single key closure was signaled to the rest of the system, while the multiple key closure wouldn't be!] If the STUCK_KEY_TIMER has timed out, then wait will be a NOOP. Otherwise, it will return to the "big loop". As such, WHILE the key is (stuck) depressed, this task will just keep executing these three statements (CALL, JR, WAIT). If the key remains stuck too long, then the code advances to signal the "key stuck" event (let something else decide what that means) > LD A,STKKEY ;FLAG INDICATING KEY STUCK > CALL PUTKEY ;SIGNAL STUCK KEY ERROR > > JR TWOKEY ;WAIT FOR STUCK KEY CONDITION TO GO AWAY > > NOTKEY: LOAD DEBOUNCE_TIMER 50 MSEC ;SETUP DEBOUNCE TIMER AND YIELD I.e., there's a lot of logic in this tiny state machine and no "state" variable to examine. The (real) "program counter" encodes the state of the FSM.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2016-06-29 01:32 +0200 |
| Message-ID | <dtgfosF8sbnU1@mid.dfncis.de> |
| In reply to | #24425 |
Am 29.06.2016 um 00:30 schrieb Rob Gaddi: > Don Y wrote: > Although on a small enough processor that I wouldn't consider even > cooperative OS, you generally bit-bang SPI by flipping the port pins as > fast as you can and finding that it's just not all that fast. No reason > to multitask in the middle of it. Easy for you to say ;-) The interesting part begins when bit-banging an entire SPI telegram takes as long (or longer...) than the minimum response time you have to guarantee on some other front. Likewise for busy-waiting for an ADC's conversion to finish, or bit-banging other serial protocols. E.g. reasonably short I2C telegrams can often still be bit-banged uninterrupted, with few or no NOPs to get the speed down. But try that with Dallas' 1-wire-bus and other parts of the system will quite probably be very unhappy. It's all nice and easy as long as the system's time slot lengths allow you to finish an entire operation in one go. But if they don't, and you still want to stay with the "no preemption" scheme of doing things, complications tend to start piling up like Jenga sticks --- and the resulting construct is often about as stable as a Jenga tower in a nearly finished game. Sooner or later there will be so many "have to check for event X again!" or "time for yet another Z to go out" kinds of calls creeping up all over the source code supposedly handling job Y, and vice versa, that it all becomes a total mess. Hardware units for SPI, I2C and such usually exist, and they offer event-driven notification, sometimes even FIFOs or DMA, for a reason. :-)
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2016-06-29 01:00 +0300 |
| Message-ID | <nkus11$vtg$1@dont-email.me> |
| In reply to | #24407 |
On 28.6.2016 г. 17:40, Tim Wescott wrote: > On Tue, 28 Jun 2016 06:20:43 +0300, Dimiter_Popoff wrote: > >> On 28.6.2016 г. 05:54, Simon Clubley wrote: >>> >> > ..... >>> I still think that's a polling loop because you are reaching out to the >>> sensor and asking it for it's current value. >> >> "Polling" in programming means "as opposed to interrupt handling". >> How is this opposed to "interrupt handling". >> >> What you suggest to be polling is simply a loop of calls to subroutines. >> A "call loop" is what describes it - although it does not matter a lot >> what word is used as long as it is not an already widely accepted one >> like "polling" which you want to redefine. Nothing wrong with that of >> course - as long as you don't have to communicate with other people >> using your redefined term. >> >> So much talk about so little :-). Although Tim's topic idea worked, >> produced quite a discussion. > > Well, I was hoping for a name of a design pattern, and I'm still not > happy about my choices. So from that perspective it's a wash. > > "Super loop" seems closest, but it seems to more capture the notion of > _always_ executing A, B, C, rather than executing only those bits that > are ready. > I encounter the "super loop" term for the first time here, but why not. Although I see nothing "super" about it, to me this is still an endless loop of calls to subroutines either of which may opt to do something or to just return if it has nothing to do. But like I said earlier I have almost never used this approach, it smells of oversimplifying - thus costing more than a decent scheduler does. Implement loops, state machines etc. as you like within tasks but having a true - preemptive allowing cooperative operation- scheduler costs very little in both machine resources and effort to put together so I see no point in trying to avoid it. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2016-06-29 00:20 +0200 |
| Message-ID | <dtgbimF83umU1@mid.dfncis.de> |
| In reply to | #24421 |
Am 29.06.2016 um 00:00 schrieb Dimiter_Popoff: > On 28.6.2016 г. 17:40, Tim Wescott wrote: >> "Super loop" seems closest, but it seems to more capture the notion of >> _always_ executing A, B, C, rather than executing only those bits that >> are ready. > I encounter the "super loop" term for the first time here, but why not. Which may be the foundation for another name for this which I remember having seen (possibly here, but can't remember when or from whom): "OBL", as in "One Big Loop". Which is right on the money, I think. > but having a true - preemptive allowing cooperative operation- scheduler > costs very little in both machine resources and effort to put together > so I see no point in trying to avoid it. Well, it does increase resource usage in at least one aspect, which can quickly become significant: memory, to store the state of currently preempted / waiting tasks. And because you'll have to swap between task states, including call stack and CPU register contents, that usually means the scheduler itself can't be written in the high-level language of choice.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2016-06-29 02:07 +0300 |
| Message-ID | <nkv009$fo4$1@dont-email.me> |
| In reply to | #24423 |
On 29.6.2016 г. 01:20, Hans-Bernhard Bröker wrote: > Am 29.06.2016 um 00:00 schrieb Dimiter_Popoff: >..... >> but having a true - preemptive allowing cooperative operation- scheduler >> costs very little in both machine resources and effort to put together >> so I see no point in trying to avoid it. > > Well, it does increase resource usage in at least one aspect, which can > quickly become significant: memory, to store the state of currently > preempted / waiting tasks. Yes of course, but things are not that bad. I have done it some 25 years ago on a HC11 with 512 bytes of RAM.... Of course there can be a situation where the stacks of the 5-6 tasks are exactly what the project needs but well, this is a bit extreme. I think the registers cost 11 bytes to stack (many years since), then providing some stack to each task etc., well, I'd say 20% of the 512 bytes go on multitasking. I am not sure the loop approach will use that much less to be worth it really. > And because you'll have to swap between task > states, including call stack and CPU register contents, that usually > means the scheduler itself can't be written in the high-level language > of choice. This is of course true, I just have never had the problem. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2016-06-28 22:21 +0000 |
| Message-ID | <nkut9m$88j$1@dont-email.me> |
| In reply to | #24421 |
Dimiter_Popoff wrote: > On 28.6.2016 г. 17:40, Tim Wescott wrote: >> On Tue, 28 Jun 2016 06:20:43 +0300, Dimiter_Popoff wrote: >> >>> On 28.6.2016 г. 05:54, Simon Clubley wrote: >>>> >>> > ..... >>>> I still think that's a polling loop because you are reaching out to the >>>> sensor and asking it for it's current value. >>> >>> "Polling" in programming means "as opposed to interrupt handling". >>> How is this opposed to "interrupt handling". >>> >>> What you suggest to be polling is simply a loop of calls to subroutines. >>> A "call loop" is what describes it - although it does not matter a lot >>> what word is used as long as it is not an already widely accepted one >>> like "polling" which you want to redefine. Nothing wrong with that of >>> course - as long as you don't have to communicate with other people >>> using your redefined term. >>> >>> So much talk about so little :-). Although Tim's topic idea worked, >>> produced quite a discussion. >> >> Well, I was hoping for a name of a design pattern, and I'm still not >> happy about my choices. So from that perspective it's a wash. >> >> "Super loop" seems closest, but it seems to more capture the notion of >> _always_ executing A, B, C, rather than executing only those bits that >> are ready. >> > > I encounter the "super loop" term for the first time here, but why not. > Although I see nothing "super" about it, to me this is still an endless > loop of calls to subroutines either of which may opt to do something > or to just return if it has nothing to do. > But like I said earlier I have almost never used this approach, it > smells of oversimplifying - thus costing more than a decent scheduler > does. Implement loops, state machines etc. as you like within tasks > but having a true - preemptive allowing cooperative operation- scheduler > costs very little in both machine resources and effort to put together > so I see no point in trying to avoid it. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff, TGI http://www.tgi-sci.com > ------------------------------------------------------ > http://www.flickr.com/photos/didi_tgi/ I think you're vastly underestimating the advantages of non-preemption. You get rid entirely of the need for mutexes and resource locking; all your accesses become atomic because you can't be interrupted. Now, once you start adding interrupts in it can get hairier, because you've just reintroduced preemption. But for projects where you have serious constraints on code, RAM, or power, something that doesn't need a scheduler is a real win. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2016-06-29 02:20 +0300 |
| Message-ID | <nkv0nq$i7f$1@dont-email.me> |
| In reply to | #24424 |
On 29.6.2016 г. 01:21, Rob Gaddi wrote: > Dimiter_Popoff wrote: > >> On 28.6.2016 г. 17:40, Tim Wescott wrote: >>> On Tue, 28 Jun 2016 06:20:43 +0300, Dimiter_Popoff wrote: >>> >>>> On 28.6.2016 г. 05:54, Simon Clubley wrote: >>>>> >>>> > ..... >>>>> I still think that's a polling loop because you are reaching out to the >>>>> sensor and asking it for it's current value. >>>> >>>> "Polling" in programming means "as opposed to interrupt handling". >>>> How is this opposed to "interrupt handling". >>>> >>>> What you suggest to be polling is simply a loop of calls to subroutines. >>>> A "call loop" is what describes it - although it does not matter a lot >>>> what word is used as long as it is not an already widely accepted one >>>> like "polling" which you want to redefine. Nothing wrong with that of >>>> course - as long as you don't have to communicate with other people >>>> using your redefined term. >>>> >>>> So much talk about so little :-). Although Tim's topic idea worked, >>>> produced quite a discussion. >>> >>> Well, I was hoping for a name of a design pattern, and I'm still not >>> happy about my choices. So from that perspective it's a wash. >>> >>> "Super loop" seems closest, but it seems to more capture the notion of >>> _always_ executing A, B, C, rather than executing only those bits that >>> are ready. >>> >> >> I encounter the "super loop" term for the first time here, but why not. >> Although I see nothing "super" about it, to me this is still an endless >> loop of calls to subroutines either of which may opt to do something >> or to just return if it has nothing to do. >> But like I said earlier I have almost never used this approach, it >> smells of oversimplifying - thus costing more than a decent scheduler >> does. Implement loops, state machines etc. as you like within tasks >> but having a true - preemptive allowing cooperative operation- scheduler >> costs very little in both machine resources and effort to put together >> so I see no point in trying to avoid it. >> >> Dimiter >> >> ------------------------------------------------------ >> Dimiter Popoff, TGI http://www.tgi-sci.com >> ------------------------------------------------------ >> http://www.flickr.com/photos/didi_tgi/ > > I think you're vastly underestimating the advantages of non-preemption. > You get rid entirely of the need for mutexes and resource locking; all > your accesses become atomic because you can't be interrupted. Well may be but my way of thinking has been incorporating all the multitask/interrupt implications for decades and frankly it was so at the start, this is how my mind works. Then I would say I am pretty practical about preemption, it does not have to be done in any state. Say if the machine is in supervisor state it will not be preempted by the "force out" interrupt brutally, it will exit just as it returns from the current system call it is in (being in supervisor state). Then preemption does not really have to occur a lot if at all, it is just a plan B most if not all of the time. I have a "hog" command under DPS which tests that, does a "bra *" :). Starting multiple instances at different priorities allows some testing but I very rarely use it. > Now, once you start adding interrupts in it can get hairier, because > you've just reintroduced preemption. But for projects where you have > serious constraints on code, RAM, or power, something that doesn't need > a scheduler is a real win. Yes, I just don't see a lot of cases where interrupts won't be needed. Then if the programming effort is so little so it can be done without them of course, I just would not put much thought about it and do it without my schedulers :). But I have not had anything like that for decades... Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web