rtems_message_queue_receive

[Ian Caddy]

Hi Steve,


Steve Holle wrote:
> 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?
> 

I don't think it would be wise to call the sednto directly from the 
interrupt, as most of the TCP stack uses the calling tasks (or isr) time 
to make up the TCP frames, so it could spend quite a lot of time in there.

That said, the sendto function (or lower down) will copy your buffer 
into an mbuf (or cluster) so as long as the buffer is going to exist 
until after the task calls sendto, you should be allright just to pass 
the pointer over.



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

OK

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

What I meant was to remove the code *after* the receive from the queue, 
so all it does is go back to waiting on the receive queue again.

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

Hmm, is timeslicing enabled for these tasks?

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

Hmm, this serial task seems to be taking a lot of processor time.  As 
you mentioned earlier, it is the same priority as the GUI task, but if 
it is not yeilding and you do not have timeslicing enabled, then your 
GUI task will not get to run.

As a test, the easiest thing would be to up the GUI task so it is a 
higher priority than the serial task and see if this makes any difference.


regards,

Ian Caddy


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