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.
As of 6/24/2010 RTDX is no longer supported. Alternative transports should be considered for the acquision of data, such as serial ports and ethernet. If you are currently using the technology and have no issues, there is no need to change. However, no action will be taken for support inqueries.
Overview of RTDX
Until recently, developers were forced to stop their application with a breakpoint to exchange data "snapshots" with the host computer in a technique that’ called "stop-mode debugging". This intrusive approach can be misleading, because the isolated snapshot of a halted high-speed application cannot show the system’ real-world operation.
To solve this problem, TI developed RTDX, or Real Time Data Exchange, which gives designers continuous, real-time visibility into their applications. RTDX was invented by TI in 1998 and was the first such capability in the DSP industry. RTDX enables real-time, asynchronous exchange of data between the target and the host, without stopping the target application. In essence, the RTDX data link provides a "data pipe" between DSP application and the host. The bidirectional capability allows developers to access data from the application for real-time visibility, or to simulate data input to the DSP, perhaps before real-time sensor hardware is available. This shortens development time by giving developers a realistic view of the way their systems operate.
RTDX is available on XDS510 and XDS560 class of emulators.
A higher speed version of RTDX is called "High Speed RTDX (HSRTDX)".
How does RTDX work?
RTDX (Real-Time Data Exchange) is a technology that allows the user to “non-intrusively” pass data from a target application to a host application and vice versa. The definition of “non-intrusively” used in this context basically means that the user can pass data between target and host without halting the target processor. RTDX is not completely non-intrusive because there is a small amount of target code that must be linked in and run with the user’s target application.
Example: Target to Host Transfer
The target portion of the RTDX application buffers data on the target and readies it for transfer up to the host. When the RTDX_write() function is called, the RTDX target code takes this data and transfers it into it’s RTDX buffer, where it patiently waits until the Host application calls RTDX_read(). The read function asks for a specific number of bytes/words, and this data is passed up to the host via the emulation scan interface.
Host to Target Application
The Host to Target application is very similar to the Target to Host application. In this case, the Host application will issue an RTDX_Write(). This data is buffered by the RTDX software on the host until the target is ready for it. Each target has one of two RTDX implementations.
Some targets have a POLLING based implementation (i.e. 54x and ARM devices). Polling based implementations require the application to periodically call the RTDX_poll() to have the target see if there is data available from the host. If data is available, the target calls RTDX_read() to transfer data from the host to the target.
Some targets have an INTERRUPT based polling implementation (62x, 67x, 64x, 55x) on which an interrupt is triggered when there is host data available for the target. In these cases, there is no need to call RTDX_poll(). The application simply calls RTDX_read() from the interrupt service routine for the RTDX interrupt.
There are two different RTDX_read() functions.RTDX_read() is a blocking read. If no data is available, and an RTDX_read() is issued, the target application will block and wait for data to become available. RTDX_readNB() is a non-blocking read.If RTDX_readNB() is called, and no data is available, it will return and allow the target application to continue.
