rtems_message_queue_receive

[Steve Holle]

At 07:07 PM 11/11/2004, Ian Caddy wrote:
>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?

Good question.  I guess that because my interrupt is filling the buffer my 
idea was that I need to synchronize the data with the server thread.  I 
guess I could double buffer it.  Would it be possible just to call the 
socket sendto function directly from the interrupt?  I wasn't sure about 
that.  Also, if I need to receive data in a server, can I use the same 
socket or do I need to open another?


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

No.  My interrupt works as follows :
         Get the next buffer from the network receive rtems queue.
         Read the data from the DSP into a raw buffer.
         Put the data in a transmit rtems queue.

I have a server running that blocks on the socket receive and the transmit 
rtems queue ( separate threads ).
         When I receive a network buffer from the blocked socet recieve I 
put the data in the recieve rtems queue.
         When the blocked transmit queue runs because of the date stuffed 
in the interrupt, it sends it via the socket.



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

Yes, that thread blocks after sending the data via the socket.  That thread 
is in a while(1) loop.  If I comment out the blocking rtems queue, won't 
that thread loop forever and eat up all my time?

I should mention that we have another thread running that is doing serial 
handling, etc. and it runs with no apparent degradation when the GUI is 
frozen.  Both threads are have the same priority.



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

I'll try this and let you know.


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

We have tried this.  It almost always breaks in the task that handles the 
serial stuff and logic which is at the same priority level as the gui.


>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
>
>Steve Holle
>Link Communications, Inc.
>1035 Cerise Rd.
>Billings, MT  59101
>sholle at link-comm.com