To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 47
46  |  48
Subject: 
Re: Idle process
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Thu, 11 Mar 1999 16:46:35 GMT
Viewed: 
1260 times
  
Lou Sortman wrote:
I think I can achieve a similar effect by putting the idle task at the
lowest priority in my structure.  The caveat would be that one should

The idle task actually has the lowest priority in my scheme, but there
was some efficiency gained in making the task list loop around. If the
idle task is always there, it makes for simplified code in multitasking
startup if you rely on that.

Of cause, changing the structure into a linked list of priority levels,
each of which is a linked list of tasks within a level might change
that. Within a priviledge level, you might want to make the lists
circular, too - saves reordering.

treated specially in the code.  If you really wanted to get crafty, you
could (already can, actually) insert a sleep task in the middle of the
chain to temporarily disable lower priority tasks.  This sort of thing,
I plan to mention in the documentation, once I get that far.

Task management is still missing suspend and resume functionality on a
task-specific level. I'm uncertain whether to favour the unix signal
mechanism or not, though. Do we need that many signals? 16 signals imply
32 bytes of handler vector table.

As you might have surmised by now, I am a sucker for elegance,
efficiency, and flexibility.

Heh... try and figure out how to keep gcc from saving r4...r6 when
entering and leaving tm_scheduler(). It's totally superfluous. You can't
change it in tm_switcher, otherwise you'd end up with r0..r3 from the
new task context and r4..r6 from the old one.

I think the hardest part of this is going to be sufficiently testing the
new code.  Do you have a jig for testing this stuff on the host system,
or do you just burn-and-crash on the RCX?

gdb has a hard time simulating interrupts, and I don't have an ICE
handy. That's why I cleanly seperated switching and scheduling - once
the switcher works, you can tinker with the scheduler all you want. It's
ANSI C, it will compile on any host system. You can pad it with all the
printfs and test rigs you want and use your favourite debugger. (Keep in
mind integer datasizes, they are quite a trap ;-)

--
Markus L. Noga noga@inrialpes.fr
Check out legOS! http://www.multimania.com/legos/
"Quand on n'a pas de caractere, il faut bien se donner une methode."
-Camus on Software Engineering



Message has 1 Reply:
  Re: Idle process
 
I guess my earlier posting got out after all. I got the message from the NNTP server telling me to register. That is why a slightly different version of my message appears later in the group. (...) I plan to keep the idle task, now that I understand (...) (26 years ago, 11-Mar-99, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  Re: Idle process
 
(...) I, too, consider power saving to be a valuable (indispensible) feature. That is precisely the sort of thing that I feared I might be overlooking. Up 'till now, I had not worked on an embedded project which would benefit from using (...) (26 years ago, 9-Mar-99, to lugnet.robotics.rcx.legos)

10 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR