Forums » Software Development »
PROC_read()
Added by Terrence Lawrence over 11 years ago
I have a shared memory read issue between the ARM and DSP processor that I am trying to resolve. I am using PROC_read() function to copy data from DSP memory to a memory buffer used by the ARM. My question has to do with inter-processor semaphores. Does PROC_read() provide a way to synchronize access between writing/reading data from DSP shared memory via some type of semaphore? I think I may have an issue where my ARM application's read from the DSP's shared memory is slower than the DSP application's writes to shared memory. So, new data is written to the shared memory by the DSP, before the ARM application has an opportunity to read all the data from the share memory area. Not certain this is possible. But it seems like it. Is there a way to ensure that the access to the shared memory area is synchronized between the DSP and the ARM?
Replies (5)
RE: PROC_read() - Added by Terrence Lawrence over 11 years ago
To clarify. I am using Critical Link's API MityDSP::tcDspApp to load the DSP application, configure the shared memory region, and communicate with the DSP.
RE: PROC_read() - Added by Gregory Gluszek over 11 years ago
Hi Terrence,
What I've seen done here in situations like you are describing is to use the dsplink interfaces and send messages between the DSP and ARM to synchronize. In this way the DSP knows when it is safe to write and the ARM knows when it is safe to read. See the IPC_inbound and IPC_outbound classes for the ARM and DSP for passing messages. The Hello World example uses these classes if you want to see some example code.
That is the best solution I know of.
Hope this helps.
\Greg
RE: PROC_read() - Added by Wade Calcutt over 11 years ago
Greg,
Can you clarify your answer with a bit more detail? Are you saying that the DSP should send a message to the ARM via IPC to hold off on accessing shared memory then send a follow-up message to indicate accessing memory is subsequently allowed?
For example, if the DSP wanted to transfer a large block of data using shared memory:
[DSP] -> [ARM] : Hold off on reading shared memory because it's being written to
[DSP] -> [ARM] : You can access memory now
[ARM] -> [DSP] : Hold off on writing to shared memory because it's being read
[ARM] -> [DSP] : You can access memory now
This implies that the DSPLINK/IPC library does not inherently provide mutex access to shared memory. Is that correct?
Thanks,
Wade
RE: PROC_read() - Added by Michael Williamson over 11 years ago
The PROC_read() API is not guarded. It's effectively a memory copy (dealing with the VM addressing under linux).
For guarded transfers or synchronized transfers, you need to use some of the other DSPLINK framework APIs, such as MSGQ's or the RingIO implementations.
I would take a look at the DSPLINK documentation (should be included in the copy of dsplink in the 3rdparty folder, or you can check the TI website), there is some fairly good explanation of the various use cases and transfer frameworks DSPLINK will support.
We provide a simple wrapper for the MSGQ framework, which is synchronized (you allocate a buffer in a "shared" memory POOL, then transfer it to the other processor in a controlled fashion). It sounds like you might need RingIO.
-Mike
RE: PROC_read() - Added by Michael Williamson over 11 years ago
Or.... you can use PROC_read, but you need to build your own synchronization hooks. This is what Greg was alluding to - we used a simple MSGQ message to pass pointers to buffers between the two processors. It was a bit hokey, but worked out.
-Mike
