Common name for a "Task Loop"

On Sun, 26 Jun 2016 23:36:43 +0000, Simon Clubley wrote:

> On 2016-06-25, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>
>> Except that -- for my code at least -- if you add a command at the end
>> to sleep if no tasks are ready, then it's no longer a polling by your
>> definition architecture.
>>
>>
> Yes, I would agree with that; it's no longer a purely polling
> architecture in that case. If you only come out of sleep as a result of,
> say, an external interrupt causing a task to become ready then I would
> call that more of an interrupt architecture.
> 
> Simon.

Everything I do ends up being event driven, as long as you allow that a 
hardware timer popping off in an "event".

And for the least mods in the code that I originally presented, the 
"sleep until interrupt" opcode (whatever it's called in your context) 
should go _before_ the string of if statements.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Dave Nadler wrote:
> On Friday, June 24, 2016 at 12:37:16 PM UTC-6, Tim Wescott wrote:
>> ... So -- is there a common Google-able term for this?
>
> Kludge?
>
> OK, OK, I've done it too...
>



Nah. It's anything but, really. There's just a slightly ...
jerky continuum of increasing abstraction starting with a big
loop being the least abstract ( and potentially the most
deterministic ).

--
Les Cargill

On 6/26/2016 4:54 PM, Simon Clubley wrote:
>>> In the example you post below, I therefore consider that to be a classic
>>> polling architecture because the code is going out and asking the sensors
>>> on a continuous basis if something has happened.
>>
>> So, generating fibonacci numbers would be...?
>> Processing paychecks?  (or, would you see "asking for hours worked
>> and wage rate" as "polling" for current state?)
>
> Are you trolling ? :-)
>
> Neither of those have anything to do with reading sensor data.

I'm trying to finely identify the criteria that you consider qualifies
something as a "polling loop".

Savitzky (see reference elsewhere) defines this as:
    "... the program examines (polls) each of its inputs in turn to
    determine whether an event has occurred which requires a response.
    If it has, the program takes the required action before proceeding
    to the next input".

This is similar to your description.

But, makes the explicit mention of a *conditional* in the code:
    if (event_has_occurred) {
        generate_response();
    }

This is also similar to Tim's "big loop" structure -- except he
moves the responsibility for "signaling" the "events" to
something "set offstage (in an ISR, or by one of the
task_n_update functions) and reset within the tasks".

The example:
    while (FOREVER) {
        V=readADC();
        writeDAC(V);
    }
you termed as "polling" -- despite the fact that there are no
visible conditionals.  (I don't consider the hardwired while()
to be a conditional -- it could be implemented with a goto.)

However, to guard against the possibility that you are
considering the "readADC" function to *contain* some conditional
logic (i.e., start conversion, wait for result, acquire result,
return value to caller) instead of a "flash A/DC" sort of
implementation (i.e., just an UNCONDITIONAL *read* of a memory
location/IO port), I pose the Fibonacci example -- there is NO
conditional logic contained therein; the "inputs" are ALWAYS
available and this is known *in* the algorithm.  I.e.,
there isn't even an "if (1) ..."

There's no "polling" in the sense of "asking if something
needs to be done".  The code runs "forever" (as the sequence
never ends so you don't even have to see "if done"!)

I.e., *my* example shows no conditionals (at least not in the
context of the "big loop").  And, unless you look under the hood,
you won't realize that tasks are producing events (even Fibonacci
numbers) and *conditionally* consuming them:
     if (another_fibonacci_number_available) {
         // do something
     }

So far, your distinguishing criteria is "if interrupts are used,
then interrupt driven; else polling (even if no conditional logic
involved)"  ??

On Sun, 26 Jun 2016 23:36:43 -0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2016-06-25, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>
>> Except that -- for my code at least -- if you add a command at the end to 
>> sleep if no tasks are ready, then it's no longer a polling by your 
>> definition architecture.
>>
>
>Yes, I would agree with that; it's no longer a purely polling
>architecture in that case. If you only come out of sleep as a result
>of, say, an external interrupt causing a task to become ready then I
>would call that more of an interrupt architecture.
>
>Simon.

Even if a timer interrupt is used ??

Just before entering the sleep, program the timer to expire say, at
the next full millisecond, i.e. generating exactly 1000 polls/second ?

On 24/06/2016 19:37, Tim Wescott wrote:
> So, this is the third time in a month or so that I've needed to tell
> someone "use a task loop" -- but I'm not sure if I can say "just Google
> it".
>
> So: When I say "task loop" I mean that I'm _not_ using an RTOS, but
> rather that I'm doing some small thing in a small processor, and
> somewhere in my code there's a loop that goes:
>
>    for (;;)
>    {
>      if (task_1_ready)
>      {
>        task_1_update();
>      }
>      else if (task_2_ready)
>      {
>        task_2_update();
>      }
>      else if (task_3_ready)
>      // et cetera
>    }
>
> The "task_n_ready" variables are set offstage (in an ISR, or by one of
> the task_n_update functions) and reset within the tasks.
>
> So -- is there a common Google-able term for this?
>

Assuming a single thread, I would just call this a 'super loop', and, to 
the best of my knowledge, believe that is the common way of describing 
it.  A quick google for '"super loop" software' brings the following:

http://uhaweb.hartford.edu/kmhill/suppnotes/SuperLoop/SuperLoopC.v1.htm
https://en.wikibooks.org/wiki/Embedded_Systems/Super_Loop_Architecture

which I think is inline with your structure.


Regards,
Richard.

+ http://www.FreeRTOS.org
The de facto standard, downloaded every 4.2 minutes during 2015.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, TCP/IP, FAT FS, Training, and more...

On Mon, 27 Jun 2016 05:53:53 +0300, upsidedown wrote:

> On Sun, 26 Jun 2016 23:36:43 -0000 (UTC), Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> 
>>On 2016-06-25, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>>
>>> Except that -- for my code at least -- if you add a command at the end
>>> to sleep if no tasks are ready, then it's no longer a polling by your
>>> definition architecture.
>>>
>>>
>>Yes, I would agree with that; it's no longer a purely polling
>>architecture in that case. If you only come out of sleep as a result of,
>>say, an external interrupt causing a task to become ready then I would
>>call that more of an interrupt architecture.
>>
>>Simon.
> 
> Even if a timer interrupt is used ??
> 
> Just before entering the sleep, program the timer to expire say, at the
> next full millisecond, i.e. generating exactly 1000 polls/second ?

_I_ would call that event-driven.  The important thing (in my definition) 
is that you're responding to the world external to the software in a 
timely manner; marching in step with the clocks in the rest of the world 
counts for that for me.

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

On 2016-06-27, Tim Wescott <tim@seemywebsite.com> wrote:
> On Mon, 27 Jun 2016 05:53:53 +0300, upsidedown wrote:
>
>> On Sun, 26 Jun 2016 23:36:43 -0000 (UTC), Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> 
>>>On 2016-06-25, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>>>
>>>> Except that -- for my code at least -- if you add a command at the end
>>>> to sleep if no tasks are ready, then it's no longer a polling by your
>>>> definition architecture.
>>>>
>>>Yes, I would agree with that; it's no longer a purely polling
>>>architecture in that case. If you only come out of sleep as a result of,
>>>say, an external interrupt causing a task to become ready then I would
>>>call that more of an interrupt architecture.
>>>
>> 
>> Even if a timer interrupt is used ??
>> 
>> Just before entering the sleep, program the timer to expire say, at the
>> next full millisecond, i.e. generating exactly 1000 polls/second ?
>
> _I_ would call that event-driven.  The important thing (in my definition) 
> is that you're responding to the world external to the software in a 
> timely manner; marching in step with the clocks in the rest of the world 
> counts for that for me.
>

Actually if the external event is a timer and not, say, an interrupt
from an external sensor, I would still call that a polling loop.
I would consider that to be no different from (for example) a PID loop
which runs at a fixed rate.

For me, a polling architecture is where you reach out to the sensors and
ask them if they have something to tell you. An interrupt architecture
for me is where you don't do anything until the sensors contact you.

To me, it doesn't matter if that polling loop is a fixed rate polling
loop or an "as fast as possible" polling loop; it's still a polling loop.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2016-06-27, Don Y <blockedofcourse@foo.invalid> wrote:
>
> The example:
>     while (FOREVER) {
>         V=readADC();
>         writeDAC(V);
>     }
> you termed as "polling" -- despite the fact that there are no
> visible conditionals.  (I don't consider the hardwired while()
> to be a conditional -- it could be implemented with a goto.)
>

It is an interesting example. I still think that's a polling loop
because you are reaching out to the sensor and asking it for it's
current value.

It's possible to have polling loops in which there is no conditional
logic, but instead a pure mathematical transformation of an input
to an output is performed. While there's no obvious maths going on
in the above loop, you are still driving a second device based on
the current value of the first device.

>
> So far, your distinguishing criteria is "if interrupts are used,
> then interrupt driven; else polling (even if no conditional logic
> involved)"  ??

To me, it's more like if you have to reach out to the sensors and ask
them what their current status is, then it's polling. If you don't do
anything until the sensor tells you via some mechanism that there's
been a change in the sensor then to me it's an interrupt architecture.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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/

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