• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 508 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.

OMAP-L138 DSP Code

dswag89
Prodigy 215 points
Other Parts Discussed in Thread: OMAP-L138

I am working with an OMAP-L138 EVM kit.  There are two ways I've found to build code for the DSP processor:

1. Build under CCSv3.3 on my PC and run the application within CCSv3.3 through the USB.

2. Using the SDK, build both the ARM code and DSP code on my Linux host, then using DSPLink, load the DSP code through the ARM processor.

I have successfully run both of these platforms, but now have a desire to mix the functionality.  I would like to be able to toggle the USER LEDs and/or read the switches from both the ARM core and DSP core, just to see what will happen (clearly nothing good, but at this point in my evaluation, every data point is a good data point).

I tried to substitute the test_led_dip output file from my PC-side-built application through the ARM and it failed miserably.  Through memory map checks in PROC_Load(), it determined that the DSP file I was trying to load (evmomapl138_test_led_dip.out) did not have DSPLink shared memory allocated properly, so it would not load the .out file.

Trying the other approach I can think of, I searched the entire tree on the Linux-side DSP Link code ( ...\OMAP_L138_arm_1_00_00_06\dsplink_linux_1_63\dsplink\dsp\ ) for something to access I2C (searched header files for "I2C") and found nothing.

Does anybody have a quick way to get either:

a) test_led_dip project built in CCSv3.3 with DSP-LInk capabilities built in?

b) a way to access the I2C port with the Linux-based DSP Link code?

c) a third alternative to reach my ultimate goal?

Thanks in advance for any suggestions!

  • 0
    TI__Expert 4930 points

    Hello,

    DSPLink provides functionality to boot load the DSP and also several IPC for data and message transfer between ARM and DSP cores.You will not find any code for i2c or any other DSP or ARM drivers.

    So option b is not possible.

    The solution is to write an integrated application which combines your functionality needs. There will be a single integrated application which will

    • On ARM, boot load the DSP, do any IPC with DSP and/or toggle the LED's
    • On DSP, a single DSP executable with the relevant memory map, IPC code and/or code in test_led_dip project.

    A link which might help you is http://wiki.davincidsp.com/index.php/Building_DSPLink_Applications#Sample_CCS_project_for_building_a_DSPLink_sample_application which talks about integration DSPLink DSP build in a CCS pjt.

    Deepali

     

  • 0 in reply to Deepali Uppal
    Prodigy 215 points

    Thanks for the link suggestion, I'll check into that when I get back to my detailed design.  In the mean-time, I have another "system level" question about DSP-Link, if anybody has an answer.  Am I correct in assuming that the DSP and ARM cores both share the EMIFA interface to the 1Gbit mDDR memory for code execution and data storage?  Further, is this same mDDR memory used to set up the "shared memory" interface on the OMAP-L138 instantiation of the DSP-Link interface?  If I'm wrong in these assumptions, can somebody please correct me?  If I am correct, any idea how much "muxing" there is between the two cores for the memory interface?  In the very limited timing data I have generated, I see about an 8% slow-down in the ARM operation running "DSP-Link" based code over running a user-app that does not include "DSP-Link".  The effects of "DSP Link" could be imagined on my part, but this is what I think I see.  Any constructive thoughts/comments would be appreciated.

  • 0 in reply to dswag89
    TI__Guru*** 125430 points

    dswag89 said:

    Am I correct in assuming that the DSP and ARM cores both share the EMIFA interface to the 1Gbit mDDR memory for code execution and data storage? 

    Yes, that's correct.  The ARM and DSP are both masters on the Switched Central Resource while the DDR interface is a slave on that interconnect.  See the "System Interconnect" chapter of the OMAP-L138 System Reference Guide for more details.

    dswag89 said:

    Further, is this same mDDR memory used to set up the "shared memory" interface on the OMAP-L138 instantiation of the DSP-Link interface? 

    That's configurable based on the placement of the DSPLINKMEM section, but in general, yes, it's in DDR.

    dswag89 said:

    If I'm wrong in these assumptions, can somebody please correct me?  If I am correct, any idea how much "muxing" there is between the two cores for the memory interface?

    Muxing?  I'm not sure what you mean by that.  Perhaps "conflicts", i.e. both trying to access memory simultaneously?  If that's what you meant this will of course be application dependent.  In general it's not an issue thanks to the magic of cache.  In other words even though the ARM and DSP might be using code/data from external memory almost all the time, the DDR bus will get utilized for a small percentage of that time because the code/data gets reused in the cache.

    dswag89 said:

    In the very limited timing data I have generated, I see about an 8% slow-down in the ARM operation running "DSP-Link" based code over running a user-app that does not include "DSP-Link".  The effects of "DSP Link" could be imagined on my part, but this is what I think I see.  Any constructive thoughts/comments would be appreciated.

    In general there is going to be overhead when doing communication between multiple processor cores.  That's why going to a 2-core system doesn't double your performance.  If the ARM and DSP are architected to be multi-threaded that helps out a lot because while thread is blocked related to inter-processor communication that allows other threads to execute such that the core is not idle.