Did you read my code? It does exactly the same but in a much simpler
way, the 'switch' and 'cases' are completely hidden by the macros and
you don't need to remember or manage the values of the switch control
variable.

My "scheduler" is much more complex and can be replaced by the simple
loop with consecutive calls to each task if needed.
Although more complex and somewhat slow, my scheduling method is much
more capable, even allowing the tasks to 'sleep'.

Isaac


Em 16/02/2014 20:20, Kerry Wentworth escreveu:
> Maybe my projects are "simple and small ". but what I do is set up each=20
> loop to do 1 simple task at each entry and return.
>
> main()
> {
> for(;;)
>
> {
>     extend_loop();
>     serial_loop();
>     etcetera_loop();
> }
> }
> extend_loop()
> {
> switch(extend_step)
> {
> case 0:
>     if(tray_at_nest && index_command)
>     {
>        set_conv_speed(256);
>        tray_feed_pusher(out);
>        extend_timer =3D timesince(0);
>        extend_step++;
>     }
>     break;   // Go back to main()
> case 1:
>     if(timesince(extend_timer) > 200) extend_step++; // 200mS delay,=20
> with no waiting
>     break;   // Go back to main()
> case 2:
>     tray_feed_pusher(in);
>     if(forward_slowdown) extend_step++;
> // In real life, there would be a timeout here
>     break;   // Go back to main()
> case N:
>     clamp_on();
>     conv_stop();
>     tray_at_ready=3D1;   // tell other tasks we are done
>     extend_step=3D0;   // ready for next tray
>     break;   // Go back to main()
> }
>
> Each loop runs for a couple of microseconds and returns.  Any task can=20
> be broken down inro a series of small steps.
>
>
>
>
> Isaac Marino Bavaresco wrote:
>> I started using state machines like that several years ago. After a
>> while I moved to co-routines, that are the same thing written in a
>> cleaner way using C macros (more on that later).
>> They both are great, but have a lot of shortcomings, the main one is
>> that as code grows in complexity things start to become complicated and
>> unmanageable.
>>
>> The problem with S.M. and C-R is that you can only transfer control to a
>> different S.M. or C-R from inside the body of the S.M. or C-R, not from
>> a sub-routine.
>> So, you cannot stay in a loop in a sub-routine waiting for something to
>> happen because your whole system will stop responding.
>> There are solutions for that also, but they are not straightforward and
>> the code starts becoming too complex.
>>
>> S.M and C-R usually force you to write code that is less modularized and
>> has long sequences of code repeated all over your S.M or C-R function
>> because you cannot put that code in a sub-routine.
>>
>> That's why I am an enthusiastic supporter of RTOSes.
>>
>> For simple and small projects, perhaps code for a S.M. or C-R approach
>> can be as simple and readable as for an RTOS, but when the size and
>> complexity starts to grow, the RTOS code will be much simpler,
>> modularized, readable and efficient.
>>  =20

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.