• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 981 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SYSBIOS IPC Server/Client via MessageQ

christian bach
Prodigy 200 points

Hello

I have a TMS320DM8148 on a TMDXEVM8148BTA Evaluation Board and using a LAN560 JTAG Emulator to connect to the processors via the 20Pin JTAG Port.

Based on the MessageQ Example in the CCS5.1 Environment I tried to write my own MessageQ Program which shall be a Server who's computing the jobs the Clients are sending. So far it work's quite well when I start both Programs (the one on the ARM and the one on the DSP) at the same time. But it's supposed to be a Server/Client System, where multiple Clients shall be able to give the Server some jobs and won't be started at the same time as the Server.

My problem is that the Server and the one Client are waiting for each other. They both wait in the "Ipc_start()" function for the other. That is not what I had in mind: I wanted a Server who's running all the time and is waiting for a job. And when I start a Client, it connects to the already running Server and sends a job. After that an other Client may connect and send an other job... and so on...

I attached my Code in the hope someone knows what to change to achieve my goal...

 

Thanks for looking into it...8424.TestProject.zip

  • 0
    Genius 4375 points

    Hi Christian,

    In your example scenario, the ARM plays the role of the server and the DSP runs the client, correct?  You'd like to avoid the server having to wait for the client to start.  You can accomplish this as follow:

    1) Change the behavior of Ipc_start so that it doesn't attach to each remote core automatically. In your .cfg file either remove the following:

    Ipc.procSync = Ipc.ProcSync_ALL;

    or change it to the following:

    Ipc.procSync = Ipc.ProcSync_PAIR;

    2)  You will be required to call Ipc_attach manually for each remote core.  That is, the server will have to Ipc_attach to the client or vice versa.  You can use a dedicate thread on the server to attach on the client so that the server perform other work simultaneously. 

    i.e. in your attachTask() on the server:

    while(Ipc_attach(clientProcId) < 0) {

         Task_yield() or Task_sleep(xx)  to allow other threads on the server to run.

    }

    This way, when the client finally comes up, the server will attach to the core.

    Regards,

    Shreyas

  • 0 in reply to Shreyas Oppanthaya
    Prodigy 200 points

    Hi Shreyas

    Thank you for your answer but that's not the solution; It may be part of it but not, what I was looking for...

    What I'd like is the following system:

    DSP: Server -> Clients can connect and put Jobs into it's pipeline

    ARM: Client -> puts Data into the shared Heap and sends the DSP a signal, what to do and where to get this data

    or, for example:

    M3: Client -> captured a lot of Data from an Audio device into the Shared Heap Buffer. then sends the DSP a request for processing the Data. while the DSP is processing, the M3 captures new data into an other Shared Heap Buffer. After the DSP has finished it returns the processed Data to the M3 and the M3 sends the new data to the DSP and the processed Data to the ARM... and so on...

    Although the IPC module is supposed to make my life easier, it really is making my life much harder. Isn't it possible to use the MessageQ Module without having to explicit attach one thread to the other?

    LabView (I'm not a big fan of LV but I have to admit their MessageQ is pretty neat) for example has a MessageQ where you have to specify the Name of this Queue and after creating it, you're able to open it from everywhere in your system and pass on messages (Including the attached datas)... Something like that, but in a smaller scale would be nice...

    Best regards

    Chris

     

  • 0 in reply to christian bach
    Genius 4375 points

    Hi Christian,

    The Ipc_attach API sets up the required infrastructure to allow MessageQ to work across cores, so you need to call this in order to use MessageQ.  A benefit of this design (i.e.  the requirement to synchronize the processors first in Ipc_attach) is that the caller of MessageQ_put() is guaranteed to have a message transport available between the two cores if MessageQ_put() is called after Ipc_attach().

    What you are trying to accomplish is still possible.  The DSP (the server, in your case) simply needs to Ipc_attach in a loop waiting for the ARM (the client) to attach to the DSP using Ipc_attach itself.   Once complete, MessageQ_put can be used between the cores.   At that point, the ARM can allocate a message (using MessageQ_alloc) from the shared heap, put it on the MessageQ and the DSP will receive it. 

    If you have two clients and one server, the server can run two different SYS/BIOS tasks that each independently try to Ipc_attach to their respective client cores in a loop.  This way, if one of the clients (client #1) attaches first, MessageQ can be used between that client #1 and the server while the server is still trying to attach to client #2.

    christian bach said:
    Although the IPC module is supposed to make my life easier, it really is making my life much harder. Isn't it possible to use the MessageQ Module without having to explicit attach one thread to the other?

    If you ever need to tear-down the processors, you can use Ipc_detach() to destroy the connection between two processors.  I apologize in advance if I missed this in your e-mail, could you explain why Ipc_attaching'ing between cores poses a problem for you?  The use-case that you describe sounds fairly typical.

    Regards,

    Shreyas

  • 0 in reply to Shreyas Oppanthaya
    Prodigy 200 points

    Hi Shreyas

    Thank you for your answer. Ipc_attach()'ing is a problem, because the DSP has to actively poll to get a connection when I want it to process Jobs (without interruptions)... When I poll for connection every 10ms I'm not loosing so much computational power but the processor might miss some connection attempts. If I tell it to poll every 10us I'm loosing quite a lot of CPU time to the connection attempts... further more, when I'm using a Linux on the ARM with multiple programs on it only one can actually connect to the DSP and send Jobs. It makes it very hard (maybe even impossible) to have several individual programs to communicate with the DSP...

    That's the way I see it but maybe I'm mistaken and just don't yet see how to manage all that with this framework...

    Regards,

    Chris