ADC channel read with usb_dev_bulk

Might that ADC speed (1MHz) be much confined to the ADC's FIFO capture of data - and not include follow-on processing - and then data transfer?  Thus 1MHz may not be a proper (nor realizable) target.

And - while USB offers some connection convenience - does it not introduce complexity - and possible PC/USB delaying issues?

Recently, client bumped against this - multiple channel UARTs (plentiful - these MCUs) is now under design as an alternative.  Might this work in your application?

I understand that 1 MHz is the theoretical maximum.

What do you think is the maximum sustained ADC conversion  rate possible?

I would like to get the maximum output speed possible from the ADC and hence looking for the USB solution, since the UART speed limit is 115200 baud.

By the way my Tiva Launchpad baud rate seems to be stuck at 9600 baud. I am raising a separate forum question about that.

Don't agree that UART is restricted to 115KBaud.  From our LX4F (nearly 2 year old) manual, UART section:

Programmable baud-rate generator allowing speeds up to 5 Mbps for regular speed (divide by 16) and 10 Mbps for high speed (divide by 8)

Your 9600 rate likely results from a programming limitation w/in your stdout file.  (review should quickly reveal)  There is no such limitation inherent w/in Stellaris/rebrand...  Instantly "cured" by switching to UART code listings w/in Stellaris/rebrand Ware.  Programs\Examples\UART\

Maximum rate achieved much depends upon several variables/factors - requires more detail...

Since baud rate is a different issue, I have started a new topic for that.

Going back to my original question can some one provide an example combining usb bulk read with adc channel read?

I can reduce the adc conversion rate to 100 KHz.

If I use a 20K RAM buffer I might get a  a 100 ms buffer with 100 KHz conversion rate which might take care of the USB latency. (I hope my calculation is correct!)

Take a look at the ek-lm4f232\qs-logger example.  This example takes ADC data from a selection of channels and sends them to USB through a virtual serial port connection.  The virtual serial port will not be as bandwidth constrained as physical UARTS.  When not using virtual serial to bridge to a physical serial port the baud rate setting is effectively ignored and things move at USB speeds.  

We also have usb_dev_bulk examples for the same board that do bulk transactions if you still want to go that route.  

After you examine and learn both applications adding ADC to usb_dev_bulk is one option or change qs-logger to bulk instead of virtual serial.  either way merging these two examples should be very close to what you are looking for.

Dexter

@ Dexter,

Thanks for this - always appreciate your insight/guidance.

Have you/others on staff - any "numbers" which illustrate possible bandwidth gains - achievable via "virtual serial port?"

And - as USB has far outstripped older UART - might "other activity" (most likely via USB) degrade this bandwidth gain?

(please do not interpret this in any way as a challenge - seeking some limited benchmarks which we can pass along to the benefit of our stable of Stellaris/rebrand clients...{justifies their added effort})   Thank you...

I don't believe we have done anything formal.

I know when we developed the ICDI firmware that runs on our devices on the newer kits we did some investigations and actually had versions of the code running serial and bulk for the JTAG data.  Bulk transfers were a bit faster but not by much.  In that case i believe we ended up with serial for driver simplicity and ease of use across all the tool vendors that support our ICDI.  Other bottlenecks on the embedded side also limit speed probably to far less then what our ADC is capable of generating.

Yes all USB devices share the same total bandwidth and a system with a lot of devices hanging off the bus (common these days) may be less speedy then a dedicated one to one USB connection.  I would probably only start to hesitate if i know the other end of the USB was a hard drive or some other device that was also transferring GB of data often.  In general i think even on a busy bus you will still see a faster overall transfer speed on USB over a traditional serial.  A dedicated embedded to embedded serial that can run over 1Mhz perhaps becomes a different story.  For embedded to embedded i would go SPI for high speed transfers.  For communication to a PC/Mac/Linux machine USB seems the best modern bet.  All a matter of opinion of course.

For fun i opened up the logger application for the 232 board. It appears it is limited by the app to 32 samples per second.  A good exercise or the intrepid listener would be to find and change that limit to more and more samples and see if you can find a threshold.  I think 32 / second was chosen arbitrarily for display and long term logging not because it was a speed limit.

Dexter

Well answered - especially appreciate the "inside history" recitation.

Listeners (even Intrepid ones) and more casual readers - express their thanks...

I have changed the baud rate from 115200 to 230400 KB/s in LM4F udma_demo code.

I got a higher UART transfer speed 46.0 KB/s.

it's 23.0 KB/s in 115200 baud rate. 

Any help?

Regards,

Any help?

Any help for what? what is not OK, what are your expectations? do not use SMS like shortcuts....

Petrei