• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 809 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 problem with host buffer reset

Teresa Seco
Prodigy 10 points

Hello,

I am using RTDX to send data from my target (C5416 dsp) to a visual c++ host application. I use Continuous mode to send the data to the host, therefore the data received from the target is recorder into a circular memory buffer by the RTDX Host Library.

I read the data in the host application with ReadI2(short* ) function. The host application works ok but each time that I execute the application, the same data is in the buffer. I would like to delete the buffer each time that I read the data with the host application.

The only solution I found is disable RTDX each time.

Is there some function or something like that to delete the buffer?

Thanks in advance.

Teresa

 

 

 

 

 

  • 0
    TI__Prodigy 10 points

    Teresa,

       I'm having the same problem.  Did you find a good solution?  Please reply to tretter@umd.edu

    Steve Tretter

  • 0
    TI__Prodigy 40 points

    Hi,

    The host side RTDX buffer cannot be deleted because there does not exist a Host Side API to accomplish this goal. Recall that the application is a COM client and CCS is a COM server. When your COM client (host application) exits the pointer to the RTDX object is also released. When you re-start your COM client (host application) the new handle to the RTDX object that is given to the application must by necessity, point to the beginning of a buffer for a given channel. If you want to read *new* data assuming that it has been delivered by the target appplication, you have to use the "Seek" APIs that are part of the Host SIde support to traverse old data and read new data. You can also do a "Rewind" if you wish to go back to reading old data.

    If you do not exit the host application then the current pointer to the data will point to the next word in the buffer and when the target sends the data you will read the latest data from the target.

    Prithvi

  • 0 in reply to Prithvi Rao
    Prodigy 10 points

    I ran into the same problem. I think Prithvi's explanation makes sense. However, there is still problem that the host side buffer will eventually become full with all the data accumulation. Is there any solution to it?

     

    Chi

  • 0 in reply to chi 16758
    TI__Prodigy 40 points

    Chi the short answer to your question is that there is a way to get around the issue of the host side buffer being filled.

    The RTDX protocol is a "producer/consumer" pattern that is running in "asynchronous" mode. This means that there is no explicit handshake that is built into the protocol that negates the possibility of the host buffer filling up by using "flow control" for example. This is designed that way and so it works as planned. Recall that the protocol guarantees delivery of all data between target and host accurately and in order.

    From a user standpoint there are several possibilities. One is to increase the buffer size from the RTDX plugin (before you enable RTDX there is an option to increase the host side buffer as well as the number of buffers). The second is to write the data to a log file. The assumption here is that you have a large enough disk that you won't have to worry about data being overwritten.

    However the best solution is to either implement an explicit handshake (create an RTDX channel for control purposes only) or to make sure that the host application is reading data from the DLL (consuming it) at least as fast as it is being produced. This requires a good understanding of how your application works with the Windows OS and other applications running concurrently under Windows. Understanding the windows event queue is one key issue here.

    Hope this helps.

    Regards,

    Prithvi

  • 0
    Prodigy 70 points

    Hello everybody, i have the same problem, and can't understand something.

    I want to transmit some small files to target and back to the host after processing in parts (32 bytes). For example 32 bytes  to  target -> processing -> 32 bytes to host and again.

    I tried simple example from tutorial (t2h.pjt), it works fine, but every time the same data is in the buffer, therefore i want to ask: Is it possible to transmit files in parts with RTDX ? In this case i want to transmit and receive new data every time when i read new part of file on the host, but can't understand how do this with RTDX

  • 0
    TI__Prodigy 40 points

    Teresa when you are sending data from the target to the host on a given RTDX channel you will *always* read the same data on the *same* channel  if you do not send *new* data.  So for instance if the target performs an RTDX_write() of 32 bytes and the channel name is *channel1*. When the host (PC) application reads *channel1* the same data will still be there the next time the host reads from the channel. If you want new data then the target must issue an *RTDX_write()* and this must happen *before* the host application performs the next read. Recall that RTDX is an *asynchronous* protocol. There is no explicit handshake between target and host applications. The user is responsible for making sure that the reads and writes happen in a timely fashion.

    One suggestion so that you can verify this for yourself is that you create a separate *test* channel and the host and target read and write to this channel to set up *handshake*. Once you see how it works then you can incorporate the appropriate timing into your RTDX application.

    You can also *disable* the channel in which case you should not see stale data.

    Prithvi N. Rao

  • 0 in reply to Prithvi Rao
    Prodigy 70 points

    Prithvi N. Rao thank's a lot, i understood this ~) it works!