• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 1212 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.

RTDX for CCS5.x

Christoph Sulzbachner
Prodigy 120 points

Hi all,


For many years, I was using RTDX for data exchange between CCS 3.x and other Windows applications. For software development on C66xx devices I have to use CCS 5.x. Currently I have installed CSS 5.1.1.

- Is data exchange via RTDX still available in CCS 5.x?

- If not, what other data exchange mechanisms are possible?

- Are there data exchange demo applications with external components available such as the RTDX example displays in CCS 3.x?


Best Regards,

Christoph

  • 0
    TI__Mastermind 20480 points

    Hi Christoph,

    No. RTDX is no longer supported as of CCS v4.

    Instead of RTDX, I can think of two ways other methods:

    1. CCS provides CIO routines that would allow you to fopen, fclose function calls with a custom I/O device, such as UART, or SPI. These links provide some more information.

    Tips for using printf and printf support in compiler

    2. Using CCS DSS (Debug Server Scripts) to transfer raw data to the target. I haven't tried this method yet, but from the looks of it it can be extended with Java calls to perform file I/O.

    I don't know of any demos/sample projects that use these features but I'll look and ask around for one.

  • 0 in reply to Tom Kopriva
    Prodigy 120 points

    Hi Tom,

    thank you for the response.

    >> No. RTDX is no longer supported as of CCS v4.

    What is the replacement in CCS 5.x to exchange data between CCS and Windows applications during runtime?

    >> 1. CCS provides CIO routines that would allow you to fopen, fclose function calls with a custom I/O device, such as UART, or SPI. These links provide some more information.

    Of course, one can use file i/o to exchange data between applications, but this is not the solution that I'm looking for. My aim is to bidirectionally exchange data such as images between CCS and a Windows application during runtime. I would like to develop both send and receive functions for CCS and Windows. The following table shows a simplified workflow:

    // DSP          

    Image i;

    .

    .

    wait_until_received( );

    read_from_win( i );    

    process( i );

    write_to_win( i );

    -------------------->

    .

    .

    		 // Windows             

    Image i;

    read_from_anywhere( i );

    write_to_ccs( i );

    <-----------------

    .

    .

    .

    wait_until_received( );

    read_from_ccs( i );

    display( i );

    >> 2. Using CCS DSS (Debug Server Scripts) to transfer raw data to the target. I haven't tried this method yet, but from the looks of it it can be extended with Java calls to perform file I/O.

    Extending DSS with Java calls may affords accessing shared memory or semaphores. Is it also possible to call DSS functions as shown in the table?

    Best Regards,

    Christoph

  • 0 in reply to Christoph Sulzbachner
    TI__Mastermind 20480 points

    Hi Christoph,

    Christoph Sulzbachner said:
    What is the replacement in CCS 5.x to exchange data between CCS and Windows applications during runtime?

    There is no replacement for RTDX. I'm not familiar enough with DSS to provide you a solution, but perhaps someone from the Code Composer Studio forum could help with that. However, as you said, CIO and DSS aren't well suited for runtime, so perhaps here's another solution.

    To exchange data at runtime you might want to look into a Ethernet solution. The NDK is a TCP/IP stack is available for the C6000 DSP series.

    • Target examples using the NDK are available in a seperate NSP package, also available at the NDK link.
    • Windows examples are in the NDK package, under the "winapps" directory and have been compiled using Visual Studio C++. Instead of using the RTDX's OLE interface, the windows side would then transfer data via TCP/IP sockets.

    There is a correlation between sending and receiving data in the "client" examples in the NSP and the applications in the "winapps" directory of the NDK. Using this correlation you can perform the "wait_until_received()" and "write_to_win()" data exchanges as you described above. There is a NDK Getting Started Guide to help get you going.

  • 0 in reply to Tom Kopriva
    Prodigy 120 points

    Hi Tom,

    Tom Kopriva said:
    There is no replacement for RTDX. I'm not familiar enough with DSS to provide you a solution, but perhaps someone from the Code Composer Studio forum could help with that. However, as you said, CIO and DSS aren't well suited for runtime, so perhaps here's another solution.

    I used to post there, but I was moved by a moderator from the Code Composer Forum to the BIOS forum! I will try to post there again with a more detailed question.

    Tom Kopriva said:

    To exchange data at runtime you might want to look into a Ethernet solution. The NDK is a TCP/IP stack is available for the C6000 DSP series.

    • Target examples using the NDK are available in a seperate NSP package, also available at the NDK link.
    • Windows examples are in the NDK package, under the "winapps" directory and have been compiled using Visual Studio C++. Instead of using the RTDX's OLE interface, the windows side would then transfer data via TCP/IP sockets.

    There is a correlation between sending and receiving data in the "client" examples in the NSP and the applications in the "winapps" directory of the NDK. Using this correlation you can perform the "wait_until_received()" and "write_to_win()" data exchanges as you described above. There is a NDK Getting Started Guide to help get you going.

    Using the NDK does not fit to the simulation environment that I need to use. I would like to have a low cost i/o implementation without processing the NDK protocol stack.

    Best Regards,

    Christoph