I am trying to pass (stream) data between two tasks. Currently, I am using dsp/bios mailboxes to pass the data and block taks based on data availablity. However, because of the fixed mailbox size this is becoming cumbersome. So, what I need is a data fifo with blocking on data ability. Dsp/Bios does not have one as far as I can tell. So, my question is: Should I write my own fifo with semaphores or is there a Dsp/bios API I should use? SIO (streaming io) seems like it might work but it seems like overkill for my application.
Thanks
Hi Bryan,
What versionof BIOS are you using. There is MSGQ (in DSP/BIOS) and MessageQ (in Ipc product that can be used with SYS/BIOS).
Both MSGQ and MessageQ are basically a FIFO queue and a synchronization mechanism (usually a semaphore). It is zero copy based (unlike mailbox) and allows variable size messages. Both MSGQ and MessageQ support routing to other processors assuming there is a transport that supports the communication (i.e. shared memory and interrupts, RapidIO, Ethernet, etc.).
Todd
Thanks for the quick reply.
I'm using DSP/Bios 5.41.
Let give you a better understanding of my application.
On one side I receive variable length packets of raw byte data (they can vary from 200 to around 1500 bytes). This can be thought of as streaming raw data that gets put into a fifo of some sort. The other side of the fifo needs this data in fixed (but can vary by a run time variable) size chucks. The sizes on the two sides are totally independent. Right now I am using MBX and the filling side breaks the incoming data into messageSize and posts messages to the MBX. The MBX pend side then must have a fixed (at compile time) size. I want the get size to be variable in run time. This is why I thought a simple fifo would be the way to go. That way the put side would just put the entire packet and get side just waits for as many bytes as it wants before getting and processing the data. I would like the two sides not to need to know how much the other side is putting or getting.
By the way the two sides are tasks on a single processor.
Bryan,
With MSGQ, the messages must have a MSGQ_MsgHeader as it first field. Given that, you could either have the messages contain the entire data packet or it can contain a pointer to the data (and probably a size). For example:
struct MyMsg { MSGQ_MsgHeader msgHeader; // required and do not modify directly...use MSGQ APIs Char data[1000];}
The above approach requires you to know the worst case data size. Note: you can have MyMsg1, MyMsg2, etc and use the MsgId field to help the receiving thread determine what type of message it is.
struct MyMsg { MSGQ_MsgHeader msgHeader; // required and do not modify directly...use MSGQ APIs Ptr data; Int dataSize;}
The above allows more flexible messages, but does not work on a multi-processor system.
For your case of having the sender (producer) put in X bytes and the receiver (consumer) take out Y bytes (where Y <= X), basically works with MSGQ. If you do the second use case (pass the pointer and size), the receiving thread could still consume the received data as chunks. It would not free the message (or return it to the producing thread) until it was completed with the entire data block in the msg though. There might be some edge conditions (i.e. received msg's dataSize is 500, but you want to consume in 128 chunks, so you'll have 116bytes in the last chunk). Not sure if this is a show stopper or not.
Please refer to the MSGQ documentation in the User Guide and the API Reference for more details.
Having said all this, it sounds like what you really want is a simple circular (or ring) buffer implementation. DSP/BIOS does not provide one. You might want to just take the afternoon and write one up instead of using MSGQ.
Did Todd's suggestion above for MSGQ meet your need, or do you have more questions on this topic?
Regards,RandyP
Search for answers, Ask a question, click Verify when complete, Help others, Learn more.
Yes it did thanks.