Hi
I'm trying to use RTDX to capture sample channels into, between, and out of two DSP algorithms on our own TMS320VC5506 target system. The sample rate is 8kHz and I can choose at build time how many channels to log (1 to 5). It all works, up to a point in time, then fails. The time it runs for before failiing seems dependent on the number of channels, i.e. the volume of the data going across the interface:
The DSP algorithms are called every 10ms i.e. on 80 samples of data. Logging code can (via conditional build macros) be setup to log any of five channels (3 inputs, intermediate buffer, and output) channels to RTDX, also called in the same function as the DSP algorithms, every 10ms.
Logging 5 channels is 40,000 16-bit samples per second = 640,000 bits per second. This consistently goes wrong after 11.4 seconds;
4 channels, 32,000 SPS, 512,000 bps, goes wrong after 14.8s;
3 channels, 24,000 SPS, 384,000 bps, 26.6s;
2 channels, 16,000 SPS, 256,000 bps, 37s;
1 channel, 8,000 SPS, 128,000 bps, no RTDX problems seen, up to the duration of the test (120s).
I’ve added timing code which makes the a GPIO output high, to show how long the logging calls take: Best case is 1 channel (0.48ms, i.e. 4.8% CPU) and 2.3ms (23% CPU) for 5 channels. The output stays high in many ~155ms-long intervals when the logging breaks, so the DSP is waiting and is therefore aware of the hold-up in the logging system.
I have found two relevant settings in Code Composer Studio: Buffer Size (default 1024 bytes), and Number of Buffers (default 4). Increasing these to 10000 and 64 made no difference. The help says that the buffer size has to be bigger than the biggest message which, as my messages are 160 bytes, it is, at 1024 bytes.
CCS RTDX config claims that the JTAG link has a theoretical data rate of 6966.66kbytes/sec. This is well above my maximum of 80k bytes/sec.
RTDX can be disabled from CCS even though the RTDX write code is still present and running in the target. In this case an identical 4.8% - 23% CPU usage remains (as seen on the GPIO output), but nothing fails (and, of course, no data is transferred!).
I’m wondering if anything in the PC (setups?) or a faster PC would improve the transfer speed to hard disk, if that’s the problem. Looking at the RTD file size in explorer (keep pressing F5), it grows quite slowly (10 to 20 kB/sec) and keeps growing a long time after the logging has stopped (I realised that I should not halt the DSP until the file has stopped growing, or data is lost). This reinforces my belief that something at the PC end is to blame for the data-size-related failure times.
Cheers
Gavin