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

C2000 - DSPLIB/DSPLink - C6000

Michael Nolin
Prodigy 190 points
Other Parts Discussed in Thread: TMS320F28335, TMS320C6747, OMAP-L137

 

I've had great success building and running the "Example DSPLIB/DSPLink" Application on OMAP-L1x on a Linux host workstation.

I'm hoping it can also support our other Inter Processor Communication needs on a TMS320F28335 connected

through the external XINT/HPI Host Port interface to a TMS320C6747.  I understand that the DSPLink can be ported to

other devices and even Linux, WinCE and ProOS.  ... DSPLINK FAQ

Attempting to download the DSPLink package I was confused by the 2 options Linux or 'porting kit for WinCE and ProOS'

C2000 tools are not available for Linux hosts currently only CCS so the porting kit may be appropriate. though we have no plans for

a third party OS currently.

Does DSPBios Link require a running OS on both GPP and DSP?  or is it possible to run the GPP as a simple microcontroller

while(1) schedule loop? Perhaps I don't need DSPLink to implement shared memory in this case DSP/BIOS supports this without

the need for BIOS Link? 

 

 

Michael Nolin

  • 0
    TI__Guru*** 125430 points

    Have you considered just using the MSGQ interface in BIOS?  That's actually one of the main things dsplink leverages.  In a BIOS-to-BIOS system you could just directly use MSGQ.  You will of course need to implement the underlying message queue transport (MQT) for doing communication over HPI, but you would have to do that with dsplink as well.

    In this scenario I would not recommend dsplink.  It was designed specifically to interface between an ARM and a DSP.  It's not meant for DSP-to-DSP.  Yes it requires an OS for things like mutex, deferred procedure call, etc.  Also, in the scenario you describe you will likely want both devices to boot independently.  That is, you would not want to store your 6747 executable inside your F28335 flash since you wouldn't have enough space!  The dsplink software paradigm expects the ARM to bootload the DSP, but that wouldn't be the case.  You would instead have each of them boot independently and then have some kind of handshake which would be more along the lines of MSGQ.

  • 0 in reply to Brad Griffis
    Prodigy 190 points

     

    True the MSGQ interface is really the core utility I would like to integrate for this C2000 to C6000 project. 'not meant for DSP-to-DSP'  I was getting this impression as I continued with downloading and trying to build dsplink for the TMS320F28335.  

    With the ARM and DSP example running on the OMAP-L137, leveraging older legacy implementation of the TMS320F28335 may not be all that effective for us. After implementing a MQT (transport) on the 335's XINT/HPI interface I would not expect the performance from the existing ARM-DSP  transport shared memory interface..

     

    Mike

  • 0 in reply to Michael Nolin
    TI__Guru*** 125430 points

    So how are you planning to proceed?

    Michael Nolin said:
    With the ARM and DSP example running on the OMAP-L137, leveraging older legacy implementation of the TMS320F28335 may not be all that effective for us.

    What did you mean by "leveraging older legacy implementation of the TMS320F28335"?  Was there a version of dsplink that supported F28335 in the past?  I don't remember that.  :)

    Michael Nolin said:
    After implementing a MQT (transport) on the 335's XINT/HPI interface I would not expect the performance from the existing ARM-DSP  transport shared memory interface..

    Certainly an MQT that passes pointers around (like OMAP-L137 shared memory MQT) will be faster than an MQT that is required to send data over a physical link.  However, there's no avoiding the fact that data will need to be sent over the physical link.  If you take the time to write the MQT now the potential benefit is that if you ever move to a multicore device you will just plug in a different MQT and your software won't have to change at all.

  • 0 in reply to Brad Griffis
    Prodigy 190 points

    Our target hardware was built with both a TMS320F28335 and a OMAP-L137 (on some boards) and theTMS320F2833 and a pin compatible C6747 (on other boards). We will need MSGQ for 335 - 6747 communication and DSPLink for the boards with OMAP-L137 parts.  The target hardware was build far in advance of any software effort.

    Legacy:  Existing software ran entirely on the 335 with no DSP/BIOS only a while(1) controller loop. Interprocessor or DSP-DSP / GPP-DSP communication is a new undertaking for these designs. DSPLink has not previously been supported for the 335 true. We are addressing lots of IPC related questions will at the same time explaining the value of embedded OS's (TI/DSPBIOS, MV_Pro_5.0) 

    I found the "Example DSPLIB/DSPLink Application on OMAP-L1x" easy to follow well thought out and clean to build and integrate.  Makefile, Linux, IPC all well defined stuff. The 335 will require the integration of DSPBIOS which has not been undertaken here before hence the value of MSGQ for DSP-DSP communication was over looked as it was defined in the bios_5_xx_/docs  User Guide. Writing MQT does not appear all that complicated as there seems to be ample example code.

  • 0 in reply to Michael Nolin
    TI__Guru*** 125430 points

    Thanks for the explanation and good luck with the project!

    I also have been seeing more and more value in an OS like BIOS over the last few years.  I feel like the guys who wrote it have great vision because much of this stuff was designed many years ago!