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.

OMAP's ARM and DSP link

Hello,

 

First of all I'm new to OMAP and I have some basic questions concerning my app. What I want to do is to drive some peripherials such as a touchscreen and a USB communication within the ARM core and to process some audio data in the DSP core. I'm assuming that we'd be using a development board here.  So, here it goes:

 

1. Is it  possible to run the ARM core on linux and the DSP core as a standalone, or the linux in the ARM core will control the DSP processes as well?

2. Are both cores totally independent? I mean, could I for example run some basic code on the DSP depending on requests made by the ARM Core?

3. How is the ARM-DSP link made? Can I communicate with the DSP whenever I want and however I want?

4. How can I develop the ARM core code and the DSP core code? Which softwares I use for each?

 

Thanks you very much,

 

Edgar

  •  

    Hi Edgar,

    I hope my message clarifies a few points for you.

    On OMAP processors it is possible to use ARM and DSP completely independently. That is to say Linux can run on ARM while the DSP can even run using a simple scheduler with no RTOS at all. In a typical communication device application the ARM would handle all aspects of the formal protocol (e.g. GSM/3G/TETRA comms protocols) while the DSP would look after the RF front end and the physical layer aspects such as modulation/demodulation, error control coding, compression/decompression etc. Of course, while the two processors operate independently, in a practical application you would share data between the ARM and the DSP via the shared bus within the OMAP. This data sharing would be as simple as message passing between the two processors and nothing else. Once each processor is synchronised with the other each one can go and do the legwork completely independently.

    I must add here that if you use a JTAG debugger (such as spectrum XDS510 USB) while developing code, you will only be able to debug one processor at a time. Therefore, if your application requires intercommunication between the ARM and the DSP, while you debug one of them the other should have a valid code running on it to ensure that the synchronisation is not lost between the two processors.

    For the details of the ARM-DSP link, it will be worthwhile reading the datasheet for your particular OMAP of interest. I would concentrate particularly on L3 interconnect part of the datasheet as this is the shared bus ı mentioned above. Getting ARM to talk to DSP is not as complicated as it may sound. You simply need to perform some initialisations and develop a simple interprocessor messaging interface code in C/C++.

    Depending on your application, you may not always need an RTOS to run on both processors. I generally prefer developing my own state machines with callback functions and interrupt handlers to do most of my work. I even got rid of DSP BIOS (which mistakenly is treated as a must have by most developers) in my last design and implemented everything in pure C which I am very happy about ! This strategy works very well but you need to give a good thought to the design aspects of tasks and data ownership and control.

    I hope you will find the abouve pointers useful.

     

    Regards...

     

     

     

     

     

     

     

     

  • Thanks for your answer Cryptoman. It clarified a lot. 

    One other question: so there is no way of debugging them altogether? 

     

    Thanks,

     

    Edgar

  •  

    Hi Edgar,

    I am glad to hear that I could be of assistance.

    You cannot perform multicore debugging using the Spectrum digital's XDS510 USB emulator, which is what is most often used. I don't think BlackHawk's equivalent emulator can do it either.

    I would say Green Hills' MULTI environment may provide some answers even though I have not personally used MULTI in OMAP environment. Please have a look at the following link for possible anwers. ( I know that their tools  do support OMAP 3530 and 3525 besides other OMAP flavours )

    http://www.ghs.com/products/TI_OMAP_development.html

    It may also be worth contacting Green Hills directly to get an exact answer. However, I must also add that even though Green Hills' debugging tools are very very reliable and highly recommended, they do not come cheap. (Last time I checked, cost per seat was circa $8000 per annum) One must be working in reasonably high volumes to justify such an expense therefore these tools are definitely not for hobbyists in my opinion.

    Good luck.

     

    Regards...