Problem of overwrite buffer sending a large stream of data using CDC Virtual COM App

[FXPASTOR]

Hello,

I'm trying to set up an application to send a large stream of data using MCF51MM256. Specifically, I sample a signal which requires to send 500 frames/second by the USB port (each frame weight is about 500 bytes (some of them  more than that because of octet stuffing).

I used the "cdc virtual com project" from "Freescale USB stack with PHDC" as starting point so that I changed several things in usb descriptor & virtual_com files to achieve a full speed USB using Bulk transfer. The problem becomes when I want to send a large stream of data continuosly as I realized the new data overwrites a part of the send data buffer before the system ends the latest sending task. I mean, the time between sending tasks seems not to be as fast as it should be in order to have time to send all the data.

So, I'd like to know if somebody knows what I could change or maybe what I didn't setup properly to achieve my target as I think using a Full Speed 2.0 USB configuration, the speed should be 1.5MB/sec (more than enough for my application) unless the limitation comes from the virtual COM port. In that case, would it be possible to reedit the driver?

thank you very much

[FXPASTOR]

I forgot to say that I'm started from CDC Virtual COM App as a DEVICE, not the host one.

[JimDon · Accepted solution]

- The buffer is being overwritten because you are not waiting until the previous buffer has been sent.

- Full speed polls at a max rate of 1MS.

-The maximum packet size is 64 bytes.

So, with out modifying the code you will get 64K Bytes per second max, on a good day, if no other device is using the bus and there is no noise.

In a bulk transfer, you can get it to take more than one packet per transfer, but you will have to modify the code. I can't tell you exactly how with this stack/chip, but it can be done.

What's more, although the theoretical maximum thru put is 1.2M, you will never get more than 70% of that (about 840K), and I doubt this hardware will do anything close to that. You might get it to peak at 128K-192K.

[FXPASTOR]

First of all, thank you very much for your answer.

More or less I expected your answer but even though I was willing to accept I don't know a lot, I believed in a magic solution to solve that problem.

I setup the hardware to use the USB port as a Bulk Transfer. Actually, the example project I'm using, it lets you setup the USB stack as a Isochronous or Bulk Transfer and both it would be good enough for my application.  After trying several ways to make my application work as fast as possible and, also from your answer, I guess the hardware is able to be setup using USB 2.0 Full speed in a bulk transfer as a virtual serial port but just it works well if you send a small data stream.

Indeed, the bandwith of my application is less than 200Hz so, without using octet stuffing, I write the samples every time in the same position of the frame which means that the difference between samples is very small. Therefore, if sometimes one sample is overwritten, nothing happens. However, I'm a little bit disappointed with this hardware honestly.

Cheers

[FXPASTOR]

Just one question more:

Do you know any micro which would be able to send such a large data stream? Maybe the solution would be one with a greater buffer?

Thanks!

[TomE]

Is your data rate 500 * 500 bytes/second or what? You're mentioning 200Hz lately - perpaps that's the data rate of the 500-byte frames.

This chip is capable of doing this if you program it properly.

As stated by JimDon, this chip supports a "Full Speed" USB interface, and not a "High Speed" one. The difference is "Full" has a clock rate of 10MBits/sec and "High" is 480MBits/sec. If you really need "High" then it takes a far more capable chip.

We're using an MCF5329, which is a more powerful CPU. It has two USB controllers in it, and the "OTG" one can support "High Speed" with an external transceiver chip. We're using the other one in "Full Speed' and can easily get over 800 kbytes/second reading a USB Memory Stick.

10 MBits/second divided by 8 bits/byte is 1.2MBytes/sec and not 1.5. Thereis a huge overhead as stated, so the maximum "user data rate" is about 840k.

Like any communications protocol, you can't send the next byte/frame/whatever until the previous frame has been sent. I don't know what software you're using, or what interface it has, but there's either something you can poll to find out when a packet has been sent, or you may register a "callback function" that gets called from an interrupt.

Tom "A Random Poster"

[JimDon]

As Tome stated, it is now un-clear what your real required bandwidth is.

As for disappointed, that means you had expectations which were not realized, and i think that now you have a better idea of what to expect.

Don't forget that 64K bytes per second is the same as 640K baud on a serial port, and many micros of this class would have trouble keeping up with 115K baud on a serial port (which is 11.5K bytes per second), so for this class of part it is really quite good.

[TomE]

> many micros of this class would have trouble keeping up with 115K baud

Which is 11,520 bytes/second or 87us/byte, or 4340 CPU clocks at 50MHz. You'd have to have really bad code to require 3000-4000 instructions to service one interrupt and receive one byte! Primitive code that is polling the serial port instead of using interrupts may have problems.

These chips can also handle 10MHz and 100MHz Ethernet because the Ethernet controller handles large slabs of data at the same time. The USB controller is closer in design to an Ethernet controller than it is to a UART. So I don't see a problem getting 800-900 kbytes/second on 10MHz USB on these chips.

Tom (A Random Poster)

[JimDon]

Sounds like the random poster had been reading too many bechmarks and beliving them....

And not actaully using the parts....

[FXPASTOR]

Thanks for all your comments.

About how many bytes I have to send, in the worst case I need to send 400kBytes/second. However, as the device runs at different rates, in the best case I need to send 27kBytes/second which corresponds to 1 frame every 32ms, so it should work. I think the example of freescale is not setup properly to work with a large data stream. So, now I'm trying to use the MQX library which it also has a serial port example more focused to send such a large data stream.

I'll let you all know the results I get.

Cheers