Forums

Dumb RTOS Question

Started by Unknown August 24, 2006
On 24 Aug 2006 15:20:35 -0700, galt_57@hotmail.com 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.
When working with blocking queues, you should only have one receive queue for a single process. Either split your process functionality into several processes, so that each process receives messages only from its single private queue. Alternatively, keep all the functionality in the same process, but include a message-ID in each message sent to a single message queue, thus any message sent to this queue will activate the process and you can select the functionality according to the message-ID. If the process also needs periodic wakeups, just send Clock-Tick messages from the interrupt service routine to the queues of each process needing scheduled wakeups. Paul
Paul Keinanen wrote:

> On 24 Aug 2006 15:20:35 -0700, galt_57@hotmail.com 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. > > > When working with blocking queues, you should only have one receive > queue for a single process. >
-- snip --
> If the process also needs periodic wakeups, just send Clock-Tick > messages from the interrupt service routine to the queues of each > process needing scheduled wakeups. > > Paul >
I would question, in this case, if you weren't trying to do two things in one task, and therefore shouldn't split it up -- that doesn't mean you aren't doing the right thing, but it would seem that if it can't be handled properly with timeouts then you're really doing two independent things that should be split into two independent tasks. IMHO. YMMV. IIRC. PNATTMBTC. -- 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
On Fri, 25 Aug 2006 00:02:36 -0700, Tim Wescott <tim@seemywebsite.com>
wrote:

><snip> >PNATTMBTC
:) Jon
On Fri, 25 Aug 2006 00:02:36 -0700, Tim Wescott <tim@seemywebsite.com>
wrote in comp.arch.embedded:

> Paul Keinanen wrote: > > > On 24 Aug 2006 15:20:35 -0700, galt_57@hotmail.com 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. > > > > > > When working with blocking queues, you should only have one receive > > queue for a single process. > > > -- snip -- > > > If the process also needs periodic wakeups, just send Clock-Tick > > messages from the interrupt service routine to the queues of each > > process needing scheduled wakeups. > > > > Paul > > > I would question, in this case, if you weren't trying to do two things > in one task, and therefore shouldn't split it up -- that doesn't mean > you aren't doing the right thing, but it would seem that if it can't be > handled properly with timeouts then you're really doing two independent > things that should be split into two independent tasks.
I don't actually think that's always called for here. Sometimes you need messages from multiple sources to accomplish one logical task. I'm think of a manual motion task I wrote for a system. It receives messages from a low level i/o task of user button presses and releases. When it decides to start a motion, it fires off a message to the motion control chain of tasks. It eventually receives a message back from the motion control/validation chain indicating whether the motion was actually started or if not, what constraint kept it from starting. If a manual motion starts, it eventually receives a motion complete notification message from the motion chain indicating the reason why the motion stopped, which could be end of travel reached, emergency stop button pressed, or a host of other issues. This task also sets one-shot timers and so receives timer messages, because under some circumstances it starts a motion at a slow speed and then increases to a higher speed after several seconds if the button is still held. And it receives commands that come through a communications interface from a higher level computer, to enable and disable certain user control buttons during certain system operations. Given that RTOS tasks, message queues, and mutexes are all expensive, and given that all of these operations are related to the high level task of recognizing user button inputs and initiating manual motions, I don't see any way to do this more economically by splitting this task up. If it were split up, there would need to be a large amount of information shared between these tasks. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
> 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.
You should match your RTOS to your problem, not the other way round. Implement message queues when you see a need for them, not because everybody does it.
On Fri, 25 Aug 2006 00:02:36 -0700, Tim Wescott <tim@seemywebsite.com>
wrote:

>Paul Keinanen wrote: > >> On 24 Aug 2006 15:20:35 -0700, galt_57@hotmail.com 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. >> >> >> When working with blocking queues, you should only have one receive >> queue for a single process. >> >-- snip -- > >> If the process also needs periodic wakeups, just send Clock-Tick >> messages from the interrupt service routine to the queues of each >> process needing scheduled wakeups. >> >> Paul >> >I would question, in this case, if you weren't trying to do two things >in one task, and therefore shouldn't split it up -- that doesn't mean >you aren't doing the right thing, but it would seem that if it can't be >handled properly with timeouts then you're really doing two independent >things that should be split into two independent tasks.
While many systems would work very nicely during normal operation without message queue timeouts or tick messages from the timer interrupt, you quite often have to detect missing messages or missing interrupt e.g. due to disconnected external cables etc. in order to activate some alarm output or switch to a redundant system etc. Getting two clock tick messages (say once a second) from the message queue without getting even a single data message would be a clear indication that something is wrong. Paul
Daniel 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. > > You should match your RTOS to your problem, not the other way round. > Implement message queues when you see a need for them, not because > everybody does it.
The purpose of an RTOS is to guarantee that something can be handled on time. This means you have to be able to characterize the various tasks to ensure any postponement is not excessive. This allows you to handle the sort of thing where a signal means an incipient explosion, unless something is readjusted in time. For many purposes an RTOS is not the appropriate solution, and you will often be better off with a normal system that simply provides time sharing, possibly with assigned priorities. -- Some informative links: news:news.announce.newusers http://www.geocities.com/nnqweb/ http://www.catb.org/~esr/faqs/smart-questions.html http://www.caliburn.nl/topposting.html http://www.netmeister.org/news/learn2quote.html
Jack Klein wrote:
> I don't actually think that's always called for here. Sometimes you > need messages from multiple sources to accomplish one logical task.
And the typical answer to this problem is that the multiple sources put the messages onto a single queue. So the task in question doesn't have to monitor more than one queue, problem solved. If the message sources can't use messages, then some other communication method has to be used. Semaphores, etc. A message on a queue doesn't have to contain any data; it can be enough just to wake up the task so that it looks at the places where there might be waiting data. But for efficiency, the task should always be sleeping when there isn't any work; even if it's polling it should sleep instead of busy waiting. The purpose of an RTOS is to make things simpler, not harder. But the job of converting an existing "big loop" application into an OS based app can be frustrating, because they can involve two completely different ways of thinking about the problem. Messages queues can be very efficient. I'm surprised some think they're not. They're no worse than a semaphore wrapped around a normal queue. Of course, I'm coming from a large system perspective, where context switching time is larger than queue manipulation time. -- Darin Johnson
CBFalconer wrote:
> The purpose of an RTOS is to guarantee that something can be > handled on time.
Well... not everyone that uses an RTOS sees the R-T as its most valuable asset. IMHO, preemptive multi-threading is the more valuable piece of the pie. Dividing a complex application into multiple threads/tasks is another tool for problem decomposition and decoupling, that can ultimately simplify a the solution. But a power-tool in the wrong hands is a dangerous weapon. As always,understand your tools and use the right tool for the job. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Daniel 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. > > You should match your RTOS to your problem, not the other way round. > Implement message queues when you see a need for them, not because > everybody does it.
Yes, I think I need to reconsider my situation. I was brought in to help on a project where the wonderful RTOS was supposed to make everything easy. I don't know a thing about RTOS's and can't really tell if anyone else does. I'm supposed to do the menu and the other guys are doing the low level stuff, so the menu will be monitoring various events and reacting to them.