AVR-Chat

Are there any C templates to perform multitasking?

Or do I have to use a timer interrupt to try to do some basic time-
slice activity?

Actually, I can have timer interrupts to perform certain functions, so 
true multitasking is not really necessary.  I was just interested if 
such exists.  For stuff like spawn() to run concurrently.

-Tony

>Are there any C templates to perform multitasking?
>
>Or do I have to use a timer interrupt to try to do some basic time-
>slice activity?
>
>Actually, I can have timer interrupts to perform certain functions, so 
>true multitasking is not really necessary.  I was just interested if 
>such exists.  For stuff like spawn() to run concurrently.
>
>-Tony
>  
>
I have not  tried it my self but take a look at http://www.freertos.org/

I wrote a small RTOS that is available at www.yahoogroups.com/avrx and on my
website (but really out of date) www.barello.net/avrx that works with GCC.
It is written in assembly and very small, but somewhat difficult to get up
and running.

Most (but not all) of my current projects use a foreground loop with Finite
State Machine (FSM) tasks and a high speed timer interrupt that increments
counters or runs additional FSM that need precise periodic execution (e.g.
motor or sensor control/input tasks, filtering, etc)  That structure is
pretty simple and works well for just about everything.  The top level
foreground loop typically runs 100k/sec or more when nothing is happening,
although it can be blocked by whatever time it takes to run the interrupt
stuff.  Oh, yeah, re-enable interrupts in the timer routine so you can run
fast & slow stuff nested (make sure you can't re-enter the fastest stuff or
you will be in trouble!).

Cheers!

-----Original Message-----
From: arhodes19044 [mailto:spamiam@comcast.net]
Sent: Friday, April 08, 2005 7:03 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Multitasking





Are there any C templates to perform multitasking?

Or do I have to use a timer interrupt to try to do some basic time-
slice activity?

Actually, I can have timer interrupts to perform certain functions, so
true multitasking is not really necessary.  I was just interested if
such exists.  For stuff like spawn() to run concurrently.

-Tony









Yahoo! Groups Links

Daniel, That looks like a nice idea.  I will look at it more.

-Tony

--- In AVR-Chat@yahoogroups.com, Daniel Adolfsson <da@g...> wrote:
> 
> >Are there any C templates to perform multitasking?
> >
> >Or do I have to use a timer interrupt to try to do some basic 
time-
> >slice activity?
> >
> >Actually, I can have timer interrupts to perform certain 
functions, so 
> >true multitasking is not really necessary.  I was just interested 
if 
> >such exists.  For stuff like spawn() to run concurrently.
> >
> >-Tony
> >  
> >
> I have not  tried it my self but take a look at 
http://www.freertos.org/

YEah, something like that was my idea, but I definietly do not have 
the skills (yet) do do it.

I had though about having a high speed timer to update counters.  
When some counter reaches a certain # then something is called and

As long as they are done quickly, then it is good.

Really, my application is fairly linear.  About every second a 
display needs updating with a few calculations.  Data entry happens 
on another display/keypad.  Whenever certain external hardware 
triggers (about 1Hz to 130hz), a counter is incremented, or(less 
freqently) a few integer and float calculations are done based on 
that counter and some vars are updated for display.

I will be using the external hardware to trigger interrupts which 
will do their brief processing and return.

Pretty simple.  So Simple that a BasicX-24 can do it, at least at 
the lower frequency range.  I think it will do it at the highest 
frequency range too.

-Tony

--- In AVR-Chat@yahoogroups.com, "Larry Barello" <yahoo@b...> wrote:
> I wrote a small RTOS that is available at www.yahoogroups.com/avrx 
and on my
> website (but really out of date) www.barello.net/avrx that works 
with GCC.
> It is written in assembly and very small, but somewhat difficult 
to get up
> and running.
> 
> Most (but not all) of my current projects use a foreground loop 
with Finite
> State Machine (FSM) tasks and a high speed timer interrupt that 
increments
> counters or runs additional FSM that need precise periodic 
execution (e.g.
> motor or sensor control/input tasks, filtering, etc)  That 
structure is
> pretty simple and works well for just about everything.  The top 
level
> foreground loop typically runs 100k/sec or more when nothing is 
happening,
> although it can be blocked by whatever time it takes to run the 
interrupt
> stuff.  Oh, yeah, re-enable interrupts in the timer routine so you 
can run
> fast & slow stuff nested (make sure you can't re-enter the fastest 
stuff or
> you will be in trouble!).
> 
> Cheers!
> 
> 
> -----Original Message-----
> From: arhodes19044 [mailto:spamiam@c...]
> Sent: Friday, April 08, 2005 7:03 PM
> To: AVR-Chat@yahoogroups.com
> Subject: [AVR-Chat] Multitasking
> 
> 
> 
> 
> 
> Are there any C templates to perform multitasking?
> 
> Or do I have to use a timer interrupt to try to do some basic time-
> slice activity?
> 
> Actually, I can have timer interrupts to perform certain 
functions, so
> true multitasking is not really necessary.  I was just interested 
if

> such exists.  For stuff like spawn() to run concurrently.
> 
> -Tony
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links

On Sat, Apr 09, 2005 at 02:02:40AM -0000, arhodes19044 wrote:

> Are there any C templates to perform multitasking?

Take a look at my threading library for an example:

     http://www.bdmicro.com/code/threads

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

> From: Larry Barello [mailto:yahoo@barello.net]
> 
> ....
> Most (but not all) of my current projects use a foreground loop with Finite
> State Machine (FSM) tasks and a high speed timer interrupt that increments
> counters or runs additional FSM that need precise periodic execution (e.g.
> motor or sensor control/input tasks, filtering, etc)  That structure is
> pretty simple and works well for just about everything. ....

On larger systems in a previous life I wrote a FSM "compiler" that consumed a
description of a state machine and produced a set of tables and source code
which was compiled into a communications application.  Support libraries
included debugging/trace tools that allowed symbolic debugging of a FSM.  Has
anyone done something like this for embedded C?

Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

At 11:50 PM 4/9/05 -0500, Chuck Hackett wrote:
> > From: Larry Barello [mailto:yahoo@barello.net]
> >
> > ....
> > Most (but not all) of my current projects use a foreground loop with Finite
> > State Machine (FSM) tasks and a high speed timer interrupt that increments
> > counters or runs additional FSM that need precise periodic execution (e.g.
> > motor or sensor control/input tasks, filtering, etc)  That structure is
> > pretty simple and works well for just about everything. ....
>
>On larger systems in a previous life I wrote a FSM "compiler" that consumed a
>description of a state machine and produced a set of tables and source code
>which was compiled into a communications application.  Support libraries
>included debugging/trace tools that allowed symbolic debugging of a FSM.  Has
>anyone done something like this for embedded C?


I know of a couple of commercial products

         BetterState from Wind River
         VisualState from IAR

Neither are cheap and both are dongled (Flexlm).  Both generate ANSI C. I 
use BetterState myself.  Both use UML statecharts as there source (and 
provide graphical editors).  I prefer BetterStates generation which allows 
in lines condition tests over VisualStates which insists everything be 
converted to an event first.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

On Apr 9, 2005, at 1:29 PM, arhodes19044 wrote:

> Really, my application is fairly linear.  About every second a
> display needs updating with a few calculations.  Data entry happens
> on another display/keypad.  Whenever certain external hardware
> triggers (about 1Hz to 130hz), a counter is incremented, or(less
> freqently) a few integer and float calculations are done based on
> that counter and some vars are updated for display.

I suggest that you capture data in an IRQ service routine but postpone 
any calculations until outside of user time. Especially don't try to 
update the display. The display won't update that quickly, also you 
will create a problem of knowing when your foreground process is 
allowed to write to the display so as not to be clobbered by writes 
from IRQ. Always do it in the foreground and not have any problems.

Sharing data between IRQ time and foreground time causes an issue. A 16 
bit value may change if an IRQ occurs half way thru reading its hi/lo 
bytes. Simplest solution is to disable IRQ, copy the values, enable 
IRQ.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Your point is well taken.  In my test-platform on a Basic-x BX-24 I 
have minimized the amount of processing done in the Interrupt 
handler itself.  There are three interrupt-type of processes.

As I said, one increments a counter.

Another is fairly low frequency (on a timer tick interrupt)and sets 
a flag for screen updates.  Because that screen may be in use for 
other user input, the one user screen is serviced by the same main 
polled loop.

Unfortunately, it is not quite so simple.  There is another screen 
(LCD display) that does need to be updated every second.  It ONLY 
gets info from this 1Hz interrupt, so I do not need to worry about 
crashing into other task's screen updates.  If I had to deal with 
that issue, I would have the interrupt routine read the current 
cursor position and return it when it was done.  My display can not 
read the cursor position.

The third routine is relatively rare, and has fairly minimal 
calculations.

I _would_ disable interrupts while I read data that might get 
updated by an interrupt routine, but on a BX-24 (another reason to 
upgrade) the interrupts are not maskable as far as I can tell.  You 
can "LockTask", but interrupts have priority.  So, I read the 
frequently changed data "quickly" and hope it is not changed in the 
middle.  I could read it repetetively until the reading is the 
same.  I have not noticed this being a problem on the BX-24, but it 
is possible.  I will try it out.

=Tony

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> 
> On Apr 9, 2005, at 1:29 PM, arhodes19044 wrote:
> 
> > Really, my application is fairly linear.  About every second a
> > display needs updating with a few calculations.  Data entry 
happens
> > on another display/keypad.  Whenever certain external hardware
> > triggers (about 1Hz to 130hz), a counter is incremented, or(less
> > freqently) a few integer and float calculations are done based on
> > that counter and some vars are updated for display.
> 
> I suggest that you capture data in an IRQ service routine but 
postpone 
> any calculations until outside of user time. Especially don't try 
to 
> update the display. The display won't update that quickly, also 
you 
> will create a problem of knowing when your foreground process is 
> allowed to write to the display so as not to be clobbered by 
writes 
> from IRQ. Always do it in the foreground and not have any problems.
> 
> Sharing data between IRQ time and foreground time causes an issue. 
A 16 
> bit value may change if an IRQ occurs half way thru reading its 
hi/lo 
> bytes. Simplest solution is to disable IRQ, copy the values, 
enable 
> IRQ.
> 
> --
> David Kelly N4HHE, dkelly@H...
> 
=====================================================================
===
> Whom computers would destroy, they must first drive mad.