• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 683 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.

Migration from c6745 to c6748/omapl138

Risto Hedman
Expert 1770 points
Other Parts Discussed in Thread: AM3517, OMAP-L138, OMAPL138, AM1808, SYSBIOS

Hello,

We were forced to migrate from c6745 to c6748 to have SATA for SSD. Now we're wondering that should we go directly to omapl138 to have ARM (& Linux) for communication and storage control and DSP for real time calculus. We've used Linux with am3517 so some basic knowlege excists. We have been gathering information "how-to" but would like to ask your opinion and answers to some (basic) questions. Our new HW is something between  LogicPD's OMAP-L138 SOM and TI's LC kit. 

Excisting c6745 code is C++, currently STL (Standard Template Library) are not used but would like to in future, StarterWare low level functions are used. Application is very "objective": same operations done for 16 channels (LP- filtering, peak detection and classification) and objects-in-vector -approach is very convenient for that purpose. Timer interrupt is running at 20kHz and starting SPI/EDMA -transfer of 16 (16bit) ADC channels, each channel is filtered and decimated to 2kHz with which frequency further analysis is done. 

I've downloaded LogicPD's VirtualBox image (1024065_AM1808_OMAP-L138_Linux_PSP_SDK_03-21-00-04_VM) including Linux 10.04 and development environment; it works fine and is very simple and good approach.  I also loaded SysLink and MCSDK_1_01_00_02. So with this background I would like to ask:

1. All SysLink and more generally MCSDK examples I've found so far are using SYS/BIOS in DSP, is it possible to use SysLink without SYS/BIOS and if it is, could you please forward me to some examples.

2. Even if SysLink could be used without SYS/BIOS, would it anyway be easier to fit my excisting C++ code to SYS/BIOS than start to do research with SysLink without SYS/BIOS or is it a simple manouvre?

3. Project is development time critical, DSP power with 456MHz is definitely enough so solution does not need to be top optimized.

Thank you,

Risto 

  • 0
    TI__Genius 12865 points
    Hi Risto,

    SysLink requires the use of Sysbios on the DSP side. So your decision would ultimately depend on whether you'd like to use Sysbios.

    Best regards,
    Vincent
  • 0 in reply to Vincent W.
    Expert 1770 points
    Thank you Vincent,

    Are there alternative tools/solutions to transfer data in controlled way between ARM/DSP? I guess we could define a common memory area accessible by both cores but it does not sound very good....

    Best Regards,

    RIsto
  • 0 in reply to Risto Hedman
    TI__Genius 12865 points

    Hi Risto,

    What I can say is that SysLink is the software component for interprocessor communication that TI recommends for users to use in the SDKs. If your ARM application is very simple and has only one thread that communicates with the DSP in a locked-step fashion, you can maybe just write to some shared memory and send an interrupt across for interprocessor communication (which in Linux would necessitate access to hardware registers, i.e. writing a Linux device driver). But if your application is more complex and benefits from message queuing, mutual exclusion between cores, and/or more help with shared memory management, SysLink can be very helpful. In addition, SysLink has an API for the user to load and run code on the DSP core, so that may be another thing to consider. It's the only component I know of that has all these features on OMAPL138.

    There is also one non-SysLink module called 'CMEM' that could be helpful independently of whether you choose to embrace SysLink and Sysbios. It can be used on Linux to allocate physically-contiguous shared memory that is kept outside of the control of the Linux kernel (or by using the CMA mechanism in the more recent kernels). More information is available here: http://processors.wiki.ti.com/index.php/CMEM_Overview

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Expert 1770 points
    Thank you Vincent,

    I think I have to migrate to SysBios to make it "compatible", and easier to maintain and expand - most likely time to do "handmade" dual port ram type interface between cores will take more time than SysBios studies. My code is quite straightforward, C- like, I don't expect problems with it. SPI with EDMA transfer is a bit worrying detail, I've spent sleepless nights with EDMA - on other hand I will have so much overhead in DSP that I can make it interrupt- based.

    TI seems to recommend XDS100, 200, 560 emulators with OMAPL138, is BH-USB-100v2 somehow limited with OMAPL or SysBios?

    BR, RIsto
  • 0 in reply to Risto Hedman
    TI__Genius 12865 points
    Hi Risto,

    I am personally not familiar with the BH-USB-100v2 emulator. From the Blackhawk website it seems to be XDS100-based, so I wouldn't expect an issue. And as long as you are able to connect to the board in CCS, the tools for SysBios will work fine. If you are concerned about your emulator's compatibility with the EVM, you may wish to start a new thread on this topic on the OMAP forum or chat with a sales representative.

    Best regards,
    Vincent
  • 0 in reply to Vincent W.
    Expert 1770 points
    Hi Vincent,

    Thank you, emulator is not a problem: if one does not work, has to purchase another.

    Best Regards,

    Risto