On 26 Aug 2006 01:45:38 -0700, galt_57@hotmail.com wrote:

>Daniel wrote:

>> 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.

This is a good way to use an RTOS. Just put the (l)user interface into
the lowest priority (NULL) task, which can be executed only when no
other high priority task needs the CPU to do any real work.

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.

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.

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

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

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

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
 

> 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 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

On Fri, 25 Aug 2006 00:02:36 -0700, Tim Wescott <tim@seemywebsite.com>
wrote:

><snip>
>PNATTMBTC

:)

Jon

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