real time data transmission over USB by using LUFA

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Experts, 

 

In a project I have to send near 96 KB of real time data from USB device to host computer.

 

I use arduino leonardo board which is based on atmega32u4  uC.

 

 

I tested different implementation of LUFA project but It seems that only AudioInput sample fits my requirements.

 

But my problem is that this AudioInput sample is sound card device and windows operating system changes the data based on volume setting and I do not get exactly generated data of my device.

 

Thus I come to the conclusion that I need a generic device (Like bulkvendor sample) which has isochronous endpoint type.

 

Now my problem is how to produce such a device. 

 

And how to produce sample driver for windows 7.  (based on libusbk if possible.)

 

AudioInput sample does not have any distinct driver and generic sound card driver of windows is loaded for it. 

 

Please help me. 

 

Thanks in advance 

 

Mehrdad,

 

 

 

 

 

 

 

This topic has a solution.
Last Edited: Tue. May 23, 2017 - 05:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mehrdad_58 wrote:
I have to send near 96 KB of real time data

So what does that actually mean?

 

How long do you have to transmit this 96 KB ?

 

In other words, how fast ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If this is just about getting some bytes from one end to the other then surely just about any class of USB device could be used? Bytes are bytes are bytes - doesn't really matter what the bytes represent whether it be audio or whatever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Again

 

I forget to write 96 KB in a second.

 

Suppose that I have a Leonardo which is connected to several hardware sensor via ADC modules and each of those modules produce 8065 bytes per second and I have 12 number of those hardware modules. 

 

Now I think it is a real time data transmission problem. 

 

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to simply send data from the micro to the PC, using USB, then I'd have a look at the USB CDC, (Communications Device Class).

This Class essentially replaces the old RS-232 serial port, and is designed for bi-directional serial data transfer.

This Class also has a built in Windows driver, so you don't have to write your own Windows driver, (hard), you just open a serial Com Port, (easy).

 

IIRC the USB host will poll the CDC device once every one millisecond, at which time the device's buffer will upload its current data.

 

I don't recall the maximum buffer size for a CDC device, and I don't know how large the CDC transmit buffer is in Dean's LUFA, but if it is > 96 Bytes you are done!

 

JC

 

Edit:Typo

Last Edited: Thu. May 18, 2017 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks DocJS

 

But CDC for full speed devices limits the endpoint size to 64.

 

In LUFA CDC sample, the size of endpoint is set to 64 also. 

 

But I need to get a higher speed and if I can handle it then It will be possible to add more channels.

 

Thus getting answer from isochronous endpoints is some sort of VITAL for me.

 

I mixed bulk vendor and audioInput samples from LUFA project to form a device which has following spec:

 

0. device has only one input endpoint (address == 129)

1. Endpoint size changed to 512

2. Endpoint  type is changed to isochronous

3. Endpoint set to have 2 banks in configuration function.  (    ConfigSuccess &= Endpoint_ConfigureEndpoint(VENDOR_IN_EPADDR,  EP_TYPE_ISOCHRONOUS, VENDOR_IO_EPSIZE, 2);)

4. data is send to host in interrupt routine(exactly like AudioInput sample.)

5. driver for this device is ganerated by using zadiq 2.3 based on libusbk library and it has no problem. 

http://zadig.akeo.ie/

 

6. By using following program I test the module and my device was enumerated and opened but problem is that I can not receive data yet. 

 

http://libusbk.sourceforge.net/U...

 

 

As you see I have very hardworking guy.  laugh

 

Now Proceeding.

 

If you have any hints please let me know.

 

You know , USB is very nice invention of human  and trying to get more and more data from it is better especially in open source projects like LUFA.

 

BR

Mehrdad,

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mehrdad_58 wrote:
But CDC for full speed devices limits the endpoint size to 64.

That doesn't matter, surely? - you just send your data in 64-byte "chunks"

 

But I need to get a higher speed

FTDI seem to manage over 1 Mbps on CDC ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mehrdad_58 wrote:
I forget to write 96 KB in a second.

 

mehrdad_58 wrote:
But I need to get a higher speed

 

USB 1.1 which is the slowest is 1.5Mb/second or 12Mb/second  Thats not fast enough to spit 96K to your host pc?

 

I cannot remember what speed the AVR can send sorry, but it's at least 1.5Mb/second.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

64byte endpoint * 1000 1m frames per second says 64KB/s to me.

 

As you say if you could do 128 byte endpoints then presumably the max rate is 128KB/s

 

Can't help thinking you have chosen the wrong micro for the job. There must be 32 bit micros not far beyond AVR that offer a faster USB link. (and can keep the "pump primed" easier because they can process/stuff the bytes quicker)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
USB 1.1 which is the slowest is 1.5Mb/second or 12Mb/second  

But those are just the raw USB signalling rates - not  the achievable payload throughput rates ...

 

EDIT

 

and they are bits per second - the OP is talking bytes per second.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. May 18, 2017 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Can't help thinking you have chosen the wrong micro for the job.
The Teensy 2 (mega32U4) is capable of some speed.

PJRC

C code for Teensy: USB Serial

https://www.pjrc.com/teensy/usb_serial.html

USB: Virtual Serial Port

(bottom)

Transmit Bandwidth Benchmark

...

Windows 7 Beta (build 7100), 32 bit; 823 kbytes/sec

Maximum Theoretical Bandwidth USB 2.0 Specification Section 5.8.4, Table 5-9, Page 54; 1056 kbytes/sec

clawson wrote:
There must be 32 bit micros not far beyond AVR that offer a faster USB link. (and can keep the "pump primed" easier because they can process/stuff the bytes quicker)
Teensy 3 is one of many.

High-speed USB is common for those.

chipKIT is one of the Arduino compatible PIC32.

 


https://www.pjrc.com/teensy/index.html

chipKIT® Development Platform – Inspired by Arduino™

http://chipkit.net/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Experts,

 

My problem is that I designed the PCB because I thought USB speed is not an important issue then.

 

As I mentioned earlier this project is a real time project and I need to send 96KB/sec in current phase. 

 

As Isochronous endpoint is designed to be used for real time application, I would rather try to use this type of endpoints and if I come to the conclusion that I could not get data by using that then I switch to CDC.

 

But as atmega32u4 is a full speed usb device, endpoint size limit for it is restricted to be 64 bytes max for CDC devices, thus 64KB/sec would be  achievable in CDC mode.

 

Thus for the sake of GOD give me some hints how to get answer from isochronus endpoint.

 

If I can get answer from isochronous, then I have a good hope for the future to increase the number of channels of my device from 12 to 16 or more wink

 

BR 

Mehrdad,

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehrdad, if your first version of the project, its software, its hardware, and the PCB all work then that is great!

 

For me that is often not the way things work out, even with a lot of careful thought and planning.

 

Sorry, I don't have any more USB suggestions to fix your current setup.

 

I would suggest, however, as was mentioned above, that simply adding a FTDI USB Bridge chip to your current system might be an easy, and fast, "fix" to the problem.

Route the micro's USART TxData and RxData lines to the FTDI chip and you can have fast CDC communications.

FTDI USB bridges can be purchased on small breakout boards, pre-assembled, or you can wire up your own.

 

As with any project, you have to decide how much time and effort to spend optimizing the solution to any problem you encounter, instead of accepting a possible, working, solution and moving forward with the rest of the project.

 

JC

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks DocJS

 

I think I get answer from isochromous endpoint just by changing following codes:

1. I changed the USB endpoint size from 512 to 256, as atmega32u4 supports double buffering for only 256 byte length endpoints. 

2. I removed the 'StreamingAudioInterfaceSelected' flag from the code.

 

Now I can read 256 bytes isochronous data from hardware.

 

I have not checked the values yet but as you know hardware projects always proceed step by step and my next step is to check to see if data is correct or not. 

 

Thank you all and best wishes

 

Mehrdad,