rtems_message_queue_receive

[Ian Caddy]

Hi Steve,



Steve Holle wrote:
> Follow up :
> Is it possible that I am hogging the Message Manager by sending these 
> messages?  I'm sending 256 bytes of data every 16mS.

Why do you want to send that much data?  Wouldn't it be much easier to 
just send the pointer to the data instead?

> 
> At 09:52 AM 11/11/2004, Steve Holle wrote:
> 
>> Good catch about the interrupts.  I did find one interrupt that was a, 
>> shall we say, non-conformist, and fixed it but I'm still having 
>> problems.  Let me explain my problem with a little more detail.
>>
>> Our system has two main threads, one running our fltk based GUI and 
>> the other running everything else.  We also have a number of threads 
>> running network functions, such as telnet, ftp, and a webserver.  All 
>> this has been running fine up to this point.
>>
>> I'm trying to add a data stream that comes from one of the DSP cards 
>> in our system, streams data to a remote system over the network and 
>> receives data back from the network for output to the DSP.  The data 
>> transfer is initiated by an interrupt (conforming) generated by the 
>> DSP card which passes the DSP-to-net data via a blocking rtems-queue 
>> in another thread.  In the same interrupt, we are passing data from 
>> another rtems-queue to the DSP.  The last queue is filled in a 
>> blocking RX queue.

I am not sure about these last two sentences.  Are you saying that you 
are using a blocking RX queue in your interrupt?  This would be bad, so 
I assume that is not what you meant.

>>
>> I've tried to fashion my code based on the telnet server that we have 
>> running, a very simple one connection telnet app.
>>
>> If I comment out the code in the interrupt that sends the data to the 
>> queue that is read in the blocked thread waiting to transmit over the 
>> network, everything works fine.  As soon as I try to enable the queue 
>> write, the GUI locks up.  What I mean by that is that it becomes 
>> unresponsive and actually does not complete a screen refresh that is 
>> in progress.

I think I might see your problem here.  This thread that is waiting on 
the queue, is it a higher priority than your GUI thread (I would assume 
that it is).  What happens to it after it receives the message from the 
ISR?  Is it doing its thing and then blocking again, or is it then 
taking too much processor time and not allowing your GUI thread to run. 
  Try commenting out the code that does stuff in your thread after it 
receives the message from the ISR and see how it goes.

>>
>> I've read the GUI thread status from the streaming server with an 
>> assert if it is ever inactive and it always reads back active.  My 
>> other main thread seems to run fine.  I can communicate with it via a 
>> serial terminal and the response is snappy.
>>
>> When we run the BMD, before the call in the interrupt we are able to 
>> break in the main while loop of the GUI.  After the call, the program 
>> will no longer break inside the GUI main while loop.
>>
>> I'm not sure how to proceed from here.  Any ideas?

I don't think the problem is at the ISR level, but that something is 
wrong with your tasks.  The easiest way to check this is to see if the 
idle task is running at all.  Put a breakpoint in the idle task loop and 
see if you get there once things go spacko.

The other option is to just break using the BDM and check where it is in 
code.  If it is always in a particular thread, then chances are it is 
hogging the processor and that lower priority tasks are not getting to 
run.  If your tools contain profiling, then this will tell you where you 
are getting stuck, but the breaking the BDM every so often is also a 
good indicator.

I hope this helps,

Ian Caddy

>>
>> At 06:22 PM 11/10/2004, Ian Caddy wrote:
>>
>>> Hi Steve,
>>>
>>> rtems_message_queue_send is allowed from conforming interrupts.  In 
>>> other words interrupts that use rtems_interrupt_catch to establish them.
>>>
>>> It is also important to note that any lower priority interrupt than 
>>> the one where you are calling RTEMS functions must also be conforming 
>>> interrupts.
>>>
>>> When you say hangs, do you mean the processor stops (I think from 
>>> memory you are using a Coldfire?) you should be able to put a BDM 
>>> onto your system with gdb and run it normally until it stops.  Then 
>>> get control back in gdb and it should indicate where the more than 
>>> likely bus error is, to see if you can narrow down your problem.
>>>
>>> I hope this helps,
>>>
>>> Ian Caddy
>>>
>>>
>>> Steve Holle wrote:
>>>
>>>> I have what is probably a basic question about 
>>>> rtems_message_queue_receive.  If I am using 
>>>> rtems_message_queue_receive with the RTEMS_WAIT attribute set in a 
>>>> server thread, can I fill the thread using rtems_message_queue_send 
>>>> in an interrupt?  It seems almost as if the rtems_message_queue_send 
>>>> is being blocked by the rtems_message_queue_receive and my code 
>>>> hangs in the interrupt.
>>>> On the other hand, I may be doing something really stupid ;-}
>>>> Steve Holle
>>>> Link Communications, Inc.
>>>> 1035 Cerise Rd.
>>>> Billings, MT  59101
>>>> sholle at link-comm.com
>>>
>>>
>>> Steve Holle
>>> Link Communications, Inc.
>>> 1035 Cerise Rd.
>>> Billings, MT  59101
>>> sholle at link-comm.com
> 
> 
> Steve Holle
> Link Communications, Inc.
> 1035 Cerise Rd.
> Billings, MT  59101
> sholle at link-comm.com 
>