Re: Dumb RTOS Question

galt_57@xxxxxxxxxxx wrote:

Tim Wescott wrote:

galt_57@xxxxxxxxxxx wrote:


Starting on my first RTOS project and can't quite see the logic to the
interprocess communications. The Zilog RTOS offers message queues, but
if the queue is empty the reading process is suspended until something
shows up in the queue. Well sorry, that isn't good because my process
has multiple things it needs to monitor periodically. It can't get hung
on just one message queue. I thought a message queue would work or have
an option to work like a ring buffer but that does not seem to be the
case. My concept is to have this process check several "queues" and
then suspend for a safe amount of time before looping back to check
them again. Any sage advice appreciated. Thanks.



Queues are there for processes that only have reason to run if there's
something in the queue to be processed.

If you just want a FIFO but have no plans to block on it then don't use
the OS queue -- the OS queue adds significant overhead for just the
behavior that you're decrying.

I would use the word "monitoring" if I'm only interested in the current
value of something -- if this is the case then don't use a queue at all
-- just stuff your values (atomically, please) into registers, wake up
periodically, and read them.

On the other hand, if you have one RTOS task that's performing multiple
'real' tasks -- break it up, and do it now!

One of the biggest software disasters I ever had the misfortune to work
on featured a task that controlled two motors, with a single queue that
sent messages about target positions. The task wouldn't service the
queue until both motors were still, so you could pump messages in way
faster than the task would take them off. A user could sit down in
front of the system and flip a switch for a while until the queue
overflowed. Once that happened the whole messaging system for the
entire application got bent*, about half of the processes went into
snits and stopped talking, and the thing would limp along until someone
took pity on it and cycled power.

Had the task just woken up periodically and monitored target values for
the motors (or -- gasp -- had there been _two tasks_) none of that would
have happened.



Well maybe if I read enough it will start to make sense but right now
it seems that there are only a few allowed ways for process to talk to
each other in this Zilog scheme..

Unless you're using a processor with a memory management unit they can't stop you from looking anywhere you want. If you build the application and link it as one, then you have global access to anything you make global (I'm assuming you're programming in C or assembly here).

Some RTOS manuals will write about interprocess communication as if it must always be synchronous, but this is not necessarily so.

Having said that, I should mention that if you _do_ choose to communicate via register, you should assume that it will change at any time, and adjust your expectations accordingly.

--

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

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
.

Relevant Pages

  • Re: ipc/msg.c "cleanup" breaks fakeroot on Alpha
    ... avoid taking a lock on a message queue that just got freed? ... queue after a grace period. ... "volatile" shouln't be necessary. ... or the target thread was destroyed before wake_up_process completed. ...
    (Linux-Kernel)
  • Re: Dumb RTOS Question
    ... shows up in the queue. ... I thought a message queue would work or have ... then suspend for a safe amount of time before looping back to check them ... I just have not figured out this kooky RTOS stuff. ...
    (comp.arch.embedded)
  • netstat issue on Tru64. Kernel bug?
    ... I have noticed that many people were faced to the "netstat hangs" ... If a process writes in a message queue in such way that it overflows ... bash$ overflowQ ...
    (comp.unix.tru64)
  • Re: Need explaination of BeginInvoke timing
    ... it just queues the delegate invocation on the regular message queue for the control's owning thread. ... Actually, while you don't post enough code to be certain, it appears that the event handlers are just handlers for the regular Control events Enter, MouseUp, and MouseDown. ... The code is setting the flag, queuing a delegate that resets the flag which will be executed after all of the messages that are already in the queue, and then the remaining events are processed, including the MouseDown event and the delegate invocation that was queued via BeginInvoke. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Event handling mechanism in Windows
    ... The IRP that originated the request `points back` to the requestor thread. ... and the APC adds a message to the message queue of the foreground thread ...
    (microsoft.public.win32.programmer.kernel)