We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I am working on LPC1768 and using example USB CDC. It is working on Bulk transfer. I want to convert that example to Isochronous transfer but when i changed the Endpoint number its not transfer or receive any data with host. what will be the reason as there is no error in code. Please Help me in solving this problem. Thanks advance
Main reason could be that all endpoints do not support any endpoint type for example on LPC1768 isochronous endpoints can be endpoint 3, 6, 9 or 12.
Second issue might be that Windows will not use that device as CDC if endpoints are not of bulk type.
There is an Audio example that uses isochronous endpoints for Embedded Artists board with LPC1788 in c:\Keil\ARM\Pack\Keil\LPC1700_DFP\2.2.0\Boards\Embedded Artists\LPC1788-32 Developers Kit\Middleware\USB\Device\Audio\
Thanks @Milorad Cvjetkovic for replying.
Is there any way that we can change the CDC class so that it works with isochronous endpoints? Thanks
It seems that you could use isochronous endpoints for Data Class Interface also, however I was not able to find if Windows support it natively (my guess is they do not).
Anyways, why would you want to use isochronous endpoints instead of bulk?
I am working on application where i have to send large amount of textual data from host to device and vice versa. As in bulk endpoints its support maximum of 64 bytes so slower data rate and in isochronous endpoints it support 1024 bytes so higher throughput.
Please guide me. Thanks
That was exactly the answer I had expected however you are wrong, bulk on full speed does have a limitation of maximum packet size of 64 bytes but as opposed to isochronous endpoint it does not have limitation of 1 packet per frame, so if bus is not busy by servicing something else bulk transfer can happen many times per frame thus nearing maximum USB bandwidth. Also bulk endpoints have handshaking thus better error mechanism that isochronous endpoints do not have.
I think you should go back to using bulk endpoints for CDC.
Thanks for your suggestion.
i have one more question. How can i start to write my own drivers?
Any link would be appreciated. Thanks
Drivers for what?
driver for usb. The class that fullfill all my requirements. As i stated above my requirements. Thanks
The class that fullfill all my requirements. As i stated above my requirements.
Above you expressed thanks for an explanation that those requirements of yours are wrong, because you arrived at them based on thoroughly misunderstanding the meanings of some central concepts of USB. Now you appear to be reverting to those same, wrong requirements, and want to driver that fulfills them. Do you really think that makes any sense?
Bulk is great for sending files over USB - grab all free bandwidth.
Isochronous is great when you need guaranteed bandwidth for some real-time stream.
If listening to music, it makes a difference if a damaged frame gives a short drop-out, or if the music freezes and the music then comes back with a time delay from the resend. That time-delay would mean everyone dancing to the music suddenly ended up being out of sync with the music.
There are several transfer modes for the simple reason that there are different needs to optimize for. So don't ignore Bulk, if it's actually Bulk that best matches your needs.
@Hans-Bernhard Broeker you are right. As i am new in USB development thats why i was confused. So please don't mind it.
@Per Westermark Thanks for the great help.
if you don't mind one thing i want to ask both of you. As bulk Endpoints support 64 bytes. That 64 bytes in per millisecond or per second and what will be the maximum of baudrate that it can support? Thanks in advance.
As stated before there can be multiple of 64 bytes per ms, for example mass storage device (USB Flash disk) using bulk transfers can get around 1MB/s transfer on full speed bus, so that is the maximum that you can expect on CDC also.