Usb mode to transfer data from pic24 to PC ?

[catslab]

Hello all,
I'm playing with a PIC24FJ64GB002 and USB to check if I can achieve 10Khz 16bits sampling of 4 channels and sending the data over usb.
I use external ADCs (ads8326) and sampling is done on timer1 overflow interrupt.
I checked CCS examples and used hid example, linux on the other side, no specific driver needed.
PIC is sending 9 bytes after each convertion.
I see data incoming, and while I'm not an expert programmer, I suspect that the usb bus is polled on the PC as I can see that not all the data is received.
Only 1 group of 9 bytes every 80.... Lost of bytes lost ! ;)
My question is: what is the most effective way to tranfer 9 bytes every 100us to a PC ? Is it HID, CDC, bulk ?
I never used Usb to send that fast before, only CDC for terminal debug.

Thanks for your help.

[Ttelmah]

There is a bit of confusion here over 'device classes' versus transfers.

Might as well use CDC. You are only talking 90000 bytes/second.
CDC uses bulk & interrupt.

A CDC device uses bulk transfers for the payload data, and interrupt transfers for line notifications.

Now on Linux, depending on the core you are using, there is a bug with some chipsets, that limits HID to around 32K/second. It only offers 64K/sec anyway. (1000*64byte packets). This will be what you are hitting.
The point about HID, is it uses interrupt transfers to guarantee low latency (things are responded to quickly), but at a cost in total data rate...

There are similar problems in Windows with the serial CDC driver on versions before W10, that can tend to throttle the throughput on this, though even on these well over 200K/second is achievable. CDC picked up a bit of a bad reputation partially because of this. With a PIC24, running to a Mac, I have managed to push up to 1MB/sec with CDC.

Now the fastest would be MSD, but you'd then have to write the entire driver both to support this. I've seen over 4MB/sec transferring from a PIC 24 using MSD and DMA, but it was a custom driver....
MSD, does not guarantee response times. It uses the 'spare' capacity on the bus, but without the quick response guaranteed by interrupt transfers.

Key thing though is that you need to be ensuring you are not stalling the transfers with your data. So do your readings, and buffer these values to the USB driver.

Do a simple test. Just load the standard serial CDC driver on the PIC, and send a few KB of data. Have your Linux code just stream this into a file, and do a timestamp at each end, so you can see the speed you are getting, and check the data for any missing bytes.

[catslab]

Thanks Ttelmah.

Yes, I'm a bit confused about USB. I have to read and learn a lot !

I used the 24bit wizard and ticked HID and interrupts on the pic side.

The main loop is simple:

[Ttelmah]

Since you are using HID, you will get a maximum of 64000B/sec.

With HID, every 'tick' of the USB driver will check the device and transfer one packet if data is available. This gives the guaranteed response (so low latency), but that is all that gets transferred. So with full speed USB, where the packet is 64bytes, and the tick is 1mSec (minimum that can be specified), you get 64000bytes/sec.
HID is guaranteed to be serviced, CDC is not. CDC instead uses bulk transfers (so if the bus gets busy will have to wait for a timeslot), but can transfer much more data.
I'd get/borrow a copy of 'USB Complete'. It explains the capabilities of the transfers and classes.

[catslab]

Thanks for your time and advice.

I checked with CDC, and looks like I get all the data on the linux end. I put a serial in the first byte and saw no disruption in the sequence.
So I will go with that for more in depth testing of my circuit.

[Ttelmah]

Good.