Easy way to get lots of data over USB from K64 system

[gpontis]

I am working with a custom K64 system. It is to be used in a laboratory measurement system that generates a lot of data. If results were sent as 32b ASCII values, it would take a minimum of 160KB/s. There is at most 64K of the K64's RAM available to buffer measurement data, so that puts an upper limit on response time and throughput at the host. I am planning to use the USB interface, but the question is what type of device it should present to the host.

CDC-serial would be easy enough to work with, but I don't know if these rates would be doable. Maybe it is doable on the K64 but not on the PC side. Anyone with experience doing this ?

What about the virtual NIC using the RNDIS demo ? In this case the K64 would have to be the termination for communications, and not just forwarding to an Ethernet port as in the demo. This seems potentially interesting, but I don't know enough about RNDIS to anticipate what other support would be required. Can anyone say if this would be a practical form of communication ? And if so, any tips on how to connect from Windows, how to exchange messages, etc would be most appreciated.

MSD seems possible but it really doesn't suit the need well. Maybe the host would attempt to read a huge file, and the K64 would return measurement data at the speed that it becomes ready.

A fully custom solution would easily support the need but there is no time or stomach to support development of a USB driver on the PC side.

[mjbcswitzerland]

Hi George

I can confirm that sustained 1MBytes/s with the K64 to FS USB host via any bulk endpoint is not a problem.

USB-CDC is simple at the PC since it just reads from a VirtualCOM port (also old programs that already read from a COM port can be used).

It sounds as though you need the data in approx. real-time at the PC but other techniques are to save the data to an SD card and then copy later (retrieval - if off-line analysis is the goal - with USB-MSD). Or copy later via FTP (remote via Ethernet/Internet).

For a long distance real-time connection an Ethernet/Internet based Telnet connection is practical. Or saving streamed data to an FTP server is a further (off-line) technique.

All of these techniques are available as data logging applications in the uTasker K64 project.

USB-CDC can be used with up to 6 pipes if of use so that different types of data can be transferred to different USB endpoints rather than multiplexing different data types on one (with its additional protocol overhead);  The PC host application sees up to 6 virtual COM ports from the K64, each one dedicated to a particular data type.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis FRDM-K64F support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[Kan_Li · Accepted solution]

Hi George,

The CDC virtual Com is not limited to Com spec, but the USB spec, and for USB 2.0 spec, the full speed mode can reach up to 12Mbps, so 160KB/s is not a problem for a CDC-serial application.

Hope that helps,

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gpontis]

I implemented this and without any optimization observed 475 KB/s, which easily satisfies the needs of my application. Thanks for the helpful steering.

[annamol]

Hi,

I have been trying to implement USB CDC in K65 as well as K53 for a real time streaming application. In K65, I have interfaced 5 devices each pushing out 24bit data. Before sending via USB, a packet is created by combining these 5 channel data with identifiers and pushed via USB CDC send data() API.

I am getting only around 60-70KB/s, which is confusing. Was there any modification needed in BSP/PSP/project??

Is it possible to share your implementation?

The final application will have 8 x I2C reads, 2x SPI reads which will happen on interrupt basis and even USB CDC send data will be invoked on interrupt.

Without interrupt as well as any read operations and streaming continuously with a dummy packet itself  it is giving this low data rate.

Please guide me if I am doing something terribly wrong.