Searching \ for '[PIC:] General question about RTOS' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'General question about RTOS'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] General question about RTOS'
2004\07\18@025409 by Thomas

picon face
Says my  program has 4 tasks.  Each of them requires
1ms to execute and I want to run them every 10ms.  If
the OS initializes all tasks at the same time (this is
usually the case), after 10ms, all 4 tasks are ready
to run.  Regardless of how the OS determines which
task to run first, the last task won't be executed
until 3ms later.  This is quite inefficient because
for the next 6ms, the system will sit idle, doing
nothing.

Would it be better if the OS:
- starts the first task at time 0
- start the second task 2ms later
- start the third task 4ms later
- start the fourth task 6ms later

With this way, when it is time to run any of the
tasks, the OS can call the task right away because no
other task is ready to run.

The above example is simple because the duration a
task is known and the executing period is the same.
What would happen if they are all different?  What
would you do to avoid having two or more tasks ready
to run at the same time?
Regards,
Thomas



__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\07\18@040411 by Colombain Nicolas

flavicon
face
Hi Thomas,

> Says my  program has 4 tasks.  Each of them requires
> 1ms to execute and I want to run them every 10ms.  If
> the OS initializes all tasks at the same time (this is
> usually the case), after 10ms, all 4 tasks are ready
> to run.  Regardless of how the OS determines which
> task to run first, the last task won't be executed
> until 3ms later.  This is quite inefficient because
> for the next 6ms, the system will sit idle, doing
> nothing.
>
> Would it be better if the OS:
> - starts the first task at time 0
> - start the second task 2ms later
> - start the third task 4ms later
> - start the fourth task 6ms later
It would be better sure :)

> The above example is simple because the duration a
> task is known and the executing period is the same.
> What would happen if they are all different?  What
> would you do to avoid having two or more tasks ready
> to run at the same time?

- Let the user specify the max duration of each task. Then compute the best
time schedule.....
or  Do nothing....

The best arrangement can only be done by the user depending on each task.
Perhaps an RTOS with more options can be foreseen:
- fixed task duration + time of the task
-  max task duration + min
-  unknow task duration
- synchronous task
- Asynchronous task
With all these informations, you can try to find the best time schedule.
Regards,

Nicolas

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\07\18@044427 by Roland

flavicon
face
I presume it's a pic;

Look at Sergio's XCSB software, it handles multitasking on the pic

If the tasks initiate simultaneously, and it's critical that they be
performed as soon as possible, you might have to go to a faster processor,
or split the processes into multiple, smaller pics. The fact that the
processor sits idle for 99.5% of the time is not inefficient, it's doing
exactly what you want it do, that is getting the job done ASAP.

You might want to interrupt drive the system, so every 200us it switches to
another task. They'll all run at once, slighty slower, and all finish close
to each other. Essentially multi-tasking, but can get messy if task 1 has
to service some critical I/O while the pic is busy on task 3, which for
example, is why windows is bad news for operating servo motors!

Regards
Roland


At 10:38 AM 18/07/04 +0200, you wrote:
{Quote hidden}

Regards
Roland Jollivet

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\07\18@074710 by Jan-Erik Soderholm

face picon face
Thomas wrote :

> Says my  program has 4 tasks.  Each of them requires
> 1ms to execute and I want to run them every 10ms.  If
> the OS initializes all tasks at the same time...

Per definition, a processor like the PIC's can't do more
then one thing "at the same time". Anyway... :-)

> (this is
> usually the case), after 10ms, all 4 tasks are ready
> to run.  Regardless of how the OS determines which
> task to run first, the last task won't be executed
> until 3ms later.

Does "the last task" KNOW it have been delayed 3 ms ?
Does "the last task" even CARE it have been delayed 3 ms ?
If not, what's the problem ? Are "the last task" syncronized to
some external event so it have to "respond" within some
specific time limit (less then 3 ms) ?

And besides, apart from the initial "delay", from the second run
on ongoing, all tasks will run at even 10 ms intervalls, right ? And
there will not be any "last task" anymore ! No task is either the
"first" or the "last" task after the initial 10 ms.


> This is quite inefficient because
> for the next 6ms, the system will sit idle, doing
> nothing.

Well, run it at a lower speed, so each task takes 2.5 ms, then
you will have no idle time at all. Or add another 6 1.0 ms tasks...
But what's the problem realy ? If it's a PIC, you could make
it sleep for 6 ms and save some power...

> Would it be better if the OS:
> - starts the first task at time 0
> - start the second task 2ms later
> - start the third task 4ms later
> - start the fourth task 6ms later

Your PIC would still be idle for 6 ms each 10 ms...

Doesn't matter a single bit, if each task is completely
independent from each other, *and* not dependent on
some external event. Each task will run once each 10 ms
no matter how you start/init them.

> With this way, when it is time to run any of the
> tasks, the OS can call the task right away because no
> other task is ready to run.

Now, if a task to be run "right away" (whatever *that* is ) is an
requirement, then it's a whole other question !
Usualy this is what interrupts are there for.
And what does "when it is time" mean ?? If it's just the
scheduler counting to 10 ms, then it doesn't matter if the
actual task would have been deleyed 9 ms each time, it
would still run each 10 ms, right ?

> The above example is simple because the duration a
> task is known and the executing period is the same.
> What would happen if they are all different?

Nothing, as long as the sum of the execution times is still
withing (in this example) 10 ms (that is, withing the capacity
of the actual PIC).

> What
> would you do to avoid having two or more tasks ready
> to run at the same time?

If it matters, something !
If it doesn't matter, nothing...

And besides, that's what the RTOS is there for !


It's hard to be more specific without having some
specific application at hand.

A few other things...

If one are looking at a "RTOS" in the first place, I expect
that there are *something* in the application that has to be
performed in "Real Time" (whatever that is).

A PIC can very well be programmed to respond in "Real Time"
without using any "RTOS" at all.

Regards,
Jan-Erik.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\07\18@164212 by Gerhard Fiedler

picon face
> Says my  program has 4 tasks.  Each of them requires
> 1ms to execute and I want to run them every 10ms.  If
> the OS initializes all tasks at the same time (this is
> usually the case), after 10ms, all 4 tasks are ready
> to run.  Regardless of how the OS determines which
> task to run first, the last task won't be executed
> until 3ms later.  This is quite inefficient because
> for the next 6ms, the system will sit idle, doing
> nothing.

Usually, you resolve something like that by one of the following, if it is
a problem:
- assigning priorities to tasks (if you have a preemtive system and one of
the tasks can't wait) and/or
- scheduling the tasks the way you want. (Nobody forces you to start all 4
10 ms timers at the same time -- you can start them one after the other,
with something like 2 ms in between.)

But it really depends on what the exact problem is.

Gerhard

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\07\19@030426 by Thomas

picon face
Thanks all of you for your reply!  Wow, I didn't
expect to have so many responses in a short amount of
time.  Instead of replying to each of you in separate
Email, I am replying to all of you in this Email.
Please see my answer to some of your
questions/comments:

Wouter van Ooijen: do you mean that you want to run
each task at 10 ms with great accuracy on that 10 ms
interval? (As opposed to long-term accuracy on that
interval)?
Thomas: What I want to avoid is to have one task
waiting for two or more tasks to finish.

Jan-Erik: Per definition, a processor like the PIC's
can't do more then one thing "at the same time".
Thomas: Yes, I do understand that the PIC is not an
Intel's HT uP!  When one task is initialized few
cycles after another, I consider it "at the same
time". I don't think I should use this term any more
because people always give me the same comments like
you did. :-)

Jan-Erik: Does "the last task" KNOW it have been
delayed 3 ms ? Does "the last task" even CARE it have
been delayed 3 ms ? If not, what's the problem ? Are
"the last task" syncronized to some external event so
it have to "respond" within some specific time limit
(less then 3 ms) ?
Thomas: The task doesn't know that it gets delayed.
Anyways, I don't think it matter much now.

Jan-Erik: Well, run it at a lower speed, so each task
takes 2.5 ms
Thomas: Why would you want to run a task at lower
speed?  Are so trying to fill up the idle time so that
it appears efficient... to me?

Jan-Erik: Now, if a task to be run "right away"
(whatever *that* is )
Thomas:  OK! OK!  Please don't pick on every single
word I use in my Email because English is not my first
language.  "right away" in my term, is the OS is
scheduling this task and only this task to run.  Is
this good enough?

Bertrand: What is the OS you use?
Thomas:  I am trying to write my own.

For everyone else:
Thomas:  Thank you for your effort to help me!  All I
am looking for was to see if there is any way I can
write the OS so that it spaces out the tasks to avoid
having too many waiting tasks at the same time.

Regards,
Thomas
--- Colombain Nicolas <colombain.nicolasspamspam_OUTWANADOO.FR>
wrote:
{Quote hidden}

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\07\19@033048 by bertrand.rozier

flavicon
face
Hello Thomas,

Do you prefer to contribute to an existing OS?
I suggest to you PICos18 ;-)
it is a GPL RTOS for PIC18 based on OSEK standard.
check here : http://www.picos18.com
For further information, you can contact me on the forum(http://www.picos18.com\forum)

Regards

Bertrand


Selon Thomas <RemoveMEmcu_stuffTakeThisOuTspamYAHOO.COM>:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu

2004\07\19@054705 by Jan-Erik Soderholm

face picon face
Thomas wrote :

> Thanks all of you for your reply!  Wow, I didn't
> expect to have so many responses in a short amount of
> time.

> Wouter van Ooijen: do you mean that you want to run
> each task at 10 ms with great accuracy on that 10 ms
> interval? (As opposed to long-term accuracy on that
> interval)?
> Thomas: What I want to avoid is to have one task
> waiting for two or more tasks to finish.

But then, isn't that what an RTOS (or any other "OS")
is there for ? To keep tasks waiting for each other ?
Or use priority levels, interrupts or any other method
if a single task need faster respons times then the
standard scheduler provides.

> Jan-Erik: Per definition, a processor like the PIC's
> can't do more then one thing "at the same time".
> Thomas: Yes, I do understand that the PIC is not an
> Intel's HT uP!  When one task is initialized few
> cycles after another, I consider it "at the same
> time".

You consider, yes :-)
Some would call "withing the same second" as "the
same time". This shows how hard it is to discuss
this matters without firm definitions of terms. :-)

> I don't think I should use this term any more
> because people always give me the same comments like
> you did. :-)

He he...

> Jan-Erik: Well, run it at a lower speed, so each task
> takes 2.5 ms
> Thomas: Why would you want to run a task at lower
> speed?  Are so trying to fill up the idle time so that
> it appears efficient... to me?

Yes, from your post it sounded like it was a problem
that there was any "idle" time at all. But, yes, I wasn't
100 % serious there :-) :-)

> Jan-Erik: Now, if a task to be run "right away"
> (whatever *that* is )
> Thomas:  OK! OK!  Please don't pick on every single
> word I use in my Email because English is not my first
> language.

It wasn't any single English word, it was a definition of
"right away" I was missing.

> "right away" in my term, is the OS is
> scheduling this task and only this task to run.  Is
> this good enough?

Fine. But then, I can see why you need any OS at all...
As soon as there are two or more tasks, there is nothing
the OS can do to prevent having on task waiting for the other.

So, to answer this question, "right away" has to be
quantified in real time units (micro seconds, processor
cycles or whatever). Some OS'es are better on the "RT" part,
some are better on the "time sharing" part. It depends on
the environment where each OS is supposed to be used.

> For everyone else:
> Thomas:  Thank you for your effort to help me!  All I
> am looking for was to see if there is any way I can
> write the OS so that it spaces out the tasks to avoid
> having too many waiting tasks at the same time.

But that isn't something the *OS* can take care of.
It's more of an overall application specific design issue,
no matter was "OS" is runnit it "under the hood".

If you write your application so it looks like *one*
large task (to the OS), you would never have any
tasks waiting, right ?

On the other hand, as soon as you have two tasks
or more, it's the responsability of the OS to keep
any of them waiting *if needed*.

The OS (any OS) should not "space out" the tasks, it should
just run anything as fas as it can, using the tools it was
given when designed (interrupts, priority levels and so on).

Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu

2004\07\19@081953 by Olin Lathrop

face picon face
Thomas wrote:
> What I want to avoid is to have one task
> waiting for two or more tasks to finish.

Why do you care?  As long as your latency spec is met, it shouldn't make any
difference what the processor was doing before each task got run.

Do these tasks all respond to the same external event, or different ones, or
each other?  It seems like you are making this way too complicated.  You've
already shown that the PIC has about 3x more cycles than all the tasks
require, so the rest is just making sure no one tasks hogs the processor too
long for the other tasks to meet their latency requirements.

In my opinion, a full RTOS is overkill and undesirable on a PIC.  In fact
it's not even strictly possible on all but the 18 and 30 families.  It is
sometimes useful to have separate tasks managing specific inputs or outputs,
like handling a command stream from a host.  On the PIC 16 and 18, I have
the main event loop run each task once after no other events were found that
needed processing.  Each task is a subroutine that returns when a timeslice
has completed, which takes it back to after the call in the main loop.

On the 30 family I sometimes don't use a main loop, and everything is done
with tasks.  When a task has nothing to do, it calls TASK_YIELD, which
causes the next task to run.

In your case, the first task would run for 1mS, then give up its timeslice.
This runs the second task for 1mS followed by the third task for 1mS.  After
that there would be lots of very quick task swaps while each task detects it
has nothing to do and yields the processor.  Eventually one of the tasks
will detect something to do, crank for 1mS, then yield the processor.  Where
do you need an RTOS in all this?

> I am trying to write my own [OS].

Sounds like a waste of time, and then you end up with a white elephant not
appropriate to a PIC anyway.  All you really need is a simple way for a task
to yield the processor to whatever the rest of the code wants to do next.
One example is in my QQQ_CMD.ASPIC module at http://www.embedinc.com/pic.
The GETBYTE macro makes it appear to the task code that it goes and "gets"
the next input byte from the host.  What it really does is return to the
main event loop, which runs the task again the next time it gets around to
it and there is a new input byte available from the host.  Note that GETBYTE
must only be called from the top task level (not in a subroutine) since the
call stack can't be accessed on a PIC 16.  I've got a version for the PIC 18
that performs some unnatural acts on the stack to loosen this restriction,
but I don't think it's on the web site yet.

> All I
> am looking for was to see if there is any way I can
> write the OS so that it spaces out the tasks to avoid
> having too many waiting tasks at the same time.

Again, why?  Is this some asthetic issue?  What are the real time
requirements of each task?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu

2004\07\19@084314 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Olin Lathrop" <RemoveMEolin_piclistspam_OUTspamKILLspamEMBEDINC.COM>
Subject: Re: [PIC:] General question about RTOS


> In my opinion, a full RTOS is overkill and undesirable on a PIC.

While I tend to agree with Olin, I'm not always willing to make sweeping
statements because of the differences in applications.

Basically, though, an RTOS saves programming time at the expense of
processor resources.  If you are doing development for a relatively small
market, where the development time is large compared to the hardware cost,
then an RTOS may well be worthwhile.  Keep in mind, however, that with a
limited processor like the PIC, the price in terms of what you can do within
a specific part is pretty high.

On the other hand, if you are planning large runs, or if you are a hobbyist
with more time than money, then a little extra time planning each
application is going to result in lower hardware costs.

Another dimension has to do with determinism.  RTOS's typically aren't
deterministic.  In safety critical applications, this can be an important
requirement.  Where it is, a general purpose RTOS isn't an option.  You need
to keep the code simple enough that you can understand exactly what will
happen under all circumstances  This typically means a purpose-built
scheduler.

For an example of the sort of scheme Olin is talking about (not identical
but similar), see http://www.amqrp.org/elmer160/lessons/E160L13.pdf.

--McD

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu

2004\07\19@105054 by Sergio Masci

picon face
----- Original Message -----
From: Thomas <EraseMEmcu_stuffspamspamspamBeGoneYAHOO.COM>
To: <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Monday, July 19, 2004 8:04 AM
Subject: Re: [PIC:] General question about RTOS



{Quote hidden}

Thomas,

Spacing out tasks so that they have some slack between them is not a bad idea
but you must be careful that the task time slices do not slowly come together
and stay together.

make your RTOS maintain a system clock.

within your RTOS there will be a way to make a task sleep for a period of time,
maybe you have a function called TASK_SLEEP that causes a task to be suspended
for N microseconds.

Create a new function called TASK_SLEEP_UNTIL. This would cause your task to be
suspended until the system clock reached a certain time.

Each task cound have a local variable which it just adds N to, each such
variable would be initialised at an offset from all other such variables. The
task would simply increment this variable at the end of its cycle and use it to
call TASK_SLEEP_UNTIL.

The TASK_SLEEP_UNTIL function would simply perform the calc "system clock" -
"time to wakeup" and call TASK_SLEEP with this value.

e.g.

task1()
{
       task1_time = 0

       while (1)
       {
               // something

               task1_time = task1_time + 10
               TASK_SLEEP_UNTIL(task1_time)
       }
}

task2()
{
       task2_time = 2

       while (1)
       {
               // something

               task2_time = task2_time + 10
               TASK_SLEEP_UNTIL(task2_time)
       }
}

task3()
{
       task3_time = 4

       while (1)
       {
               // something

               task3_time = task3_time + 10
               TASK_SLEEP_UNTIL(task3_time)
       }
}

TASK_SLEEP_UNTIL(int N)
{
       int    N2

       N2 = system_clock - N

       // take care of N2 wrap not shown here

       TASK_SLEEP(N2)
}


This is the simple way to do it. A more complex way would be to maintain the
local variable (taskN_time) in the RTOS and use this as a task relative clock.
Then change the TASK_SLEEP_UNTIL function so that it uses an offset from the
relative clock

e.g.
TASK_SLEEP_UNTIL(int N)
{
       int    N2

       task_time[current_task] += N

       N2 = system_clock - task_time[current_task]

       // take care of N2 wrap not shown here

       TASK_SLEEP(N2)
}


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu

2004\07\19@175418 by Thomas

picon face
Hi Bertrand,

I don't think I understand the kernel enough to modify/improve codes yet.  I just downloaded the OSEK standard, but I haven't got time to read through it.  What I can do now is to test the OS and report to you if there is anything wrong/broken.  Sounds good?

Regards,
Thomas

spamBeGonebertrand.rozierSTOPspamspamEraseMEPRAGMATEC.NET wrote:
Hello Thomas,

Do you prefer to contribute to an existing OS?
I suggest to you PICos18 ;-)
it is a GPL RTOS for PIC18 based on OSEK standard.
check here : http://www.picos18.com
For further information, you can contact me on the forum(http://www.picos18.com\forum)

Regards

Bertrand


Selon Thomas :

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\07\19@211952 by Thomas

picon face
Hi Sergio Masci,

Sounds like a good idea!  I will need some times to make my OS stable first, then I will see if I can implement your method.  Thank you!
Thomas

Sergio Masci <.....smplspam_OUTspamNTLWORLD.COM> wrote:
{Original Message removed}

2004\07\19@214536 by Thomas

picon face
Hi Olin and all,

Thank you for your reply and welcome back!
First, I am not looking for or trying to write a "full RTOS".  Even if I want to write a "full RTOS", I don't think I am capable of.

For all the programs I wrote in the past, all the tasks are in a big while (1) loop.  Each task has its own time ticks variable, which is decremented periodly by a system ISR (i.e. 1ms tick).  When its value reaches zero, the task is executed and itstimer tick variable is reloaded.

The program runs fine without any problem.  However, I _heard_ that a RTOS helps you write codes a lot faster, like going from programing in ASM to programming in C!  You don't have to worry about bank switching and other stuff.

I am not writing any mission critical codes and I am not writing any program for any consumer product either.  I am just a hobbyst whose tries to learn more about programming and to get his Hexapod Robot to walk and play!

Regards,
Thomas
Olin Lathrop <TakeThisOuTolin_piclist.....spamTakeThisOuTEMBEDINC.COM> wrote:
Thomas wrote:
> What I want to avoid is to have one task
> waiting for two or more tasks to finish.

Why do you care? As long as your latency spec is met, it shouldn't make any
difference what the processor was doing before each task got run.

Do these tasks all respond to the same external event, or different ones, or
each other? It seems like you are making this way too complicated. You've
already shown that the PIC has about 3x more cycles than all the tasks
require, so the rest is just making sure no one tasks hogs the processor too
long for the other tasks to meet their latency requirements.

In my opinion, a full RTOS is overkill and undesirable on a PIC. In fact
it's not even strictly possible on all but the 18 and 30 families. It is
sometimes useful to have separate tasks managing specific inputs or outputs,
like handling a command stream from a host. On the PIC 16 and 18, I have
the main event loop run each task once after no other events were found that
needed processing. Each task is a subroutine that returns when a timeslice
has completed, which takes it back to after the call in the main loop.

On the 30 family I sometimes don't use a main loop, and everything is done
with tasks. When a task has nothing to do, it calls TASK_YIELD, which
causes the next task to run.

In your case, the first task would run for 1mS, then give up its timeslice.
This runs the second task for 1mS followed by the third task for 1mS. After
that there would be lots of very quick task swaps while each task detects it
has nothing to do and yields the processor. Eventually one of the tasks
will detect something to do, crank for 1mS, then yield the processor. Where
do you need an RTOS in all this?

> I am trying to write my own [OS].

Sounds like a waste of time, and then you end up with a white elephant not
appropriate to a PIC anyway. All you really need is a simple way for a task
to yield the processor to whatever the rest of the code wants to do next.
One example is in my QQQ_CMD.ASPIC module at http://www.embedinc.com/pic.
The GETBYTE macro makes it appear to the task code that it goes and "gets"
the next input byte from the host. What it really does is return to the
main event loop, which runs the task again the next time it gets around to
it and there is a new input byte available from the host. Note that GETBYTE
must only be called from the top task level (not in a subroutine) since the
call stack can't be accessed on a PIC 16. I've got a version for the PIC 18
that performs some unnatural acts on the stack to loosen this restriction,
but I don't think it's on the web site yet.

> All I
> am looking for was to see if there is any way I can
> write the OS so that it spaces out the tasks to avoid
> having too many waiting tasks at the same time.

Again, why? Is this some asthetic issue? What are the real time
requirements of each task?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu


---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu

2004\07\20@033238 by bertrand.rozier

flavicon
face
In the fact, you do not need an RTOs, but a simple scheduler based on a timer and some software IT.

I had not read all post, but I have seen "In my opinion, a full RTOS is overkill and undesirable on a PIC. In fact
it's not even strictly possible on all but the 18 and 30 families. It is
sometimes useful to have separate tasks managing specific inputs or outputs,
like handling a command stream from a host. On the PIC 16 and 18, I have
the main event loop run each task once after no other events were found that
needed processing. Each task is a subroutine that returns when a timeslice
has completed, which takes it back to after the call in the main loop.

On the 30 family I sometimes don't use a main loop, and everything is done
with tasks. When a task has nothing to do, it calls TASK_YIELD, which
causes the next task to run."

Olin, are you sure of that? Personnaly I think that a real Préemptive RTOS is a good thing for PIC18 and dsPIC30. That right when you use an RTOS, you loose "CPU time", but the developpment is easier (independante task implementation, etc..) and deterministic!
I have write many application with PICos18 ( http://www.picos18.com), and I am sure that I save time in debug.

Bertrand


Selon Thomas <RemoveMEmcu_stuffspamspamBeGoneYAHOO.COM>:

> Hi Sergio Masci,
>
> Sounds like a good idea!  I will need some times to make my OS stable first,
> then I will see if I can implement your method.  Thank you!
> Thomas
>
> Sergio Masci <spamBeGonesmpl@spam@spamspam_OUTNTLWORLD.COM> wrote:
> {Original Message removed}

2004\07\20@090634 by Olin Lathrop

face picon face
bertrand.rozier@PRAGMATEC.NET wrote:
> I think that a real Priemptive
> RTOS is a good thing for PIC18 and dsPIC30.

I've done dozens of PIC projects and never once even wished I had
*preemptive* task scheduling.  Multitasking is a powerful concept, but
preemptive task switching comes at a high cost on small resource limited
systems.  It is more difficult to write task code that could be interrupted
by other tasks at any time.  This will also require task interlocks around
shared data structures.

While a preemptive scheduler would be reasonably straight forward on the PIC
30, it would generally be less efficient on the PIC 18 than a cooperative
one.  That is because the entire stack needs to be saved and restored on the
PIC 18.  You can't just switch to a different stack already sitting in
memory.  In a cooperative system, tasks usually yield at the start of a top
level loop, which is usually not deeply nested in subroutines from the top
level.  This requires less stack swapping on a PIC 18, which also implies
smaller save areas for the swapped stacks.  On the PIC 18 I can limit how
deeply nested a task may be when it yields, but still allow it to use the
full stack between yields.  In a preemptive system the save area must be
able to hold the stack to the maximum possible call depth of the task.

For a simple cooperative task manager for the PIC 30, check out the
QQQ_TASK.DSPIC module at http://www.embedinc.com/pic.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...