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

Simple guide for using the DSP on OMAP L138

Roger McCalman51
Intellectual 335 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138I would like to evaluate the performance of the DSP for our project but cannot find a simple process for building a small C program and running on the DSP. I don't want or need a IDE I just want a simple command line interface that generates the correct files. All the examples seem to use the CCS IDE.

  • 0
    TI__Mastermind 43955 points

    Hi Roger,

    For building the "C programs" which runs on TI DSP core, definetly, you need CCS IDE.

    But for running the executables of C programs on DSP core, there are alternate methods other than CCS.

    For example, consider you have a " *.out " generated from your C program OR from the released TI Starterware package. Using sfh utility, you can flash the program into memories such as NAND and run the program on DSP core.

    Simple guidlines to run the pre-built programs on DSP core of OMAPl138 LCDK board.

    • Using AIS gen tool, load the appropriate configuration file and convert the boot.out into boot.ais
    • Using out2rprc, convert the *.out into *.bin ( i.e., your C program )
    • On OMAPl138 LCDK board,set the boot switches for UART mode(1:4 = 0101 on OMAPL138 LCDK). Open serial terminals like teraterm and make sure you get the "BOOTME" message.
    • By sfh utility, flash the two images, boot.ais and *.bin ( your Cprogram) using the below command.

    $>sfh_OMAP-L138.exe -flash boot.ais *.bin -targetType OMAPL138_LCDK -flashType NAND -p COM3

    For more info, Please visit, http://processors.wiki.ti.com/index.php/OMAPL138_StarterWare_Booting_And_Flashing

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Prodigy 80 points

    Hi Roger,

    there is another possibility, which I use to completely avoid using CCS and JTAG connection and AIS gen tool stuff:

    You can use SysLink examples as a framework. You can build ARM & DSP code from command line (on linux machine).

    If you have linux running on ARM side you can load a DSP application from ARM linux command line and syslink framework allows you to control dsp application and communicate with it from ARM.

    But it is a bit tricky to make everything work.

    If you want to run just a bare-metal C application (non-bios dsp executable) there is an example in syslink framework too

    Regards,

    Jiri

  • 0 in reply to Jiri Freyvald
    Intellectual 335 points
    I have modified the syslink example 'messageq' to do what I want thanks. Using syslink will save me much effort as it only took a hour or so change it to do what I want. I just find the amount of small config files scattered through-out the source tree that is hard to deal with.

    I did try with CCS6 and tried to import the bios, ipc and syslink 'packages' with no success apart from corrupting the syslink tree so that when I installed the code on the DSP (from Linux on the Arm) Ipc_Attach panic'd the kernel. I then started with a fresh install of syslink, ipc and bios and it worked again.

    I am now trying to integrate the minimum amount of code from syslink into our build system such that I can just build a modified 'messageq' example.

    I really only see using XDC as a way to completely obfuscate the entire build process using several languages (Java, JavaScript, make and shell) to accomplish what is normally done using the C pre-processor and a Makefile. u-boot and the Linux kernel both use a simple text file that allows you to configure what and how you want it built. The single text file is then easy to put into something like svn to track changes.