• AVR Freaks

Max USB Bulk transfer speed.

Page: < 123 > Showing page 2 of 3
Author
philpem
New Member
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2008/09/15 17:03:37
  • Location: 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 10:32:43 (permalink)
0
Based on looking through the examples that come with the 2.5b USB stack, it looks like the following example would be a good starting point:
USB Device - LibUSB - Generic Driver Demo
Does that sound about right?


That's more or less what I did -- you want to look at the ProcessIO function in user.c. Configure the USB stack first (usb_config.h), then remove everything you don't need (PORTB LEDs on the FS-USB devboard, etc) and add some basic functionality to ProcessIO (I usually make it echo data received on the OUT endpoint back on the IN endpoint). Then start adding your functionality to the code.

Also note that you can have bus transactions that last more than one packet. If you're using libusb, you can do stuff like this:
			// Read bytes from FPGA in chunks of USB_EP0_BUFF_SIZE
while (i > 0) {
// Spin while IN endpoint is busy
while (USBHandleBusy(USBGenericInHandle));

// Read USB_EP0_BUFF_SIZE (or i if i < USB_EP0_BUFF_SIZE) bytes of data
for (counter=0; counter< (i<USB_EP0_BUFF_SIZE ? i : USB_EP0_BUFF_SIZE); counter++) {
// Spin until there's some data available
while (SPPEPSbits.SPPBUSY);
// Read data byte from holding register
USBBuf_IN[counter] = SPPDATA;
}

// Send the data across the USB bus
USBGenericInHandle = USBGenWrite(USBGEN_EP_NUM, (BYTE*)&USBBuf_IN,
(i<USB_EP0_BUFF_SIZE ? i : USB_EP0_BUFF_SIZE));
// Update loop counter
i -= (i<USB_EP0_BUFF_SIZE ? i : USB_EP0_BUFF_SIZE);
}

// We handled the buffers ourself; don't need to send anything else
counter = 0;
break;


What this does is wait for the Streaming Parallel Port to have data available, then reads the data, and repeats until i=0. i is set from the incoming OUT packet, and can vary from 1 to 2^24 in my case (although it can be up to 2^32, it's an unsigned int).

This does the same thing the other way round --
			// Is there a data payload in this packet?
if (USBHandleGetLength(USBGenericOutHandle) > 4) {
// Yep. Copy the payload into ACQ RAM.
for (j=4; j<USBHandleGetLength(USBGenericOutHandle); j++) {
FPGA_WriteReg(FPGA_W_RAM_DATA, USBBuf_OUT[j]);
}

// Update the byte counter
i -= (USBHandleGetLength(USBGenericOutHandle) - 4);
}

// Loop until all the data packets in this write op have been processed
while (i > 0) {
// Rearm the OUT endpoint and wait for the next data packet
USBGenericOutHandle = USBGenRead(USBGEN_EP_NUM,(BYTE*)&USBBuf_OUT,USBGEN_EP_SIZE);
while (USBHandleBusy(USBGenericOutHandle));

// Now copy the data from the OUT buffer to the FPGA
for (j=0; j<USBHandleGetLength(USBGenericOutHandle); j++) {
FPGA_WriteReg(FPGA_W_RAM_DATA, USBBuf_OUT[j]);
}
}

// We handled the buffers ourself; don't need to send anything else
counter = 0;
break;


Just remember to set counter to 0 at the end of the case handler -- otherwise the USB handling code at the end of ProcessIO will try and send another packet after the "final" packet sent by the above code.

And now I've posted this, someone's going to say that I'm doing it completely wrong :)
(Quick note: yes you can assign the SPP to a USB endpoint, but the endpoint you use has to be set to either Isochronous or Interrupt mode)
#21
daveinca
Junior Member
  • Total Posts : 104
  • Reward points : 0
  • Joined: 2009/09/11 19:36:52
  • Location: Roseville, CA
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 16:55:44 (permalink)
0
Thanks for the help Philipem. What kind of data rates have you achieved using your code below? I need to get speeds around 5MB/sec initially and see if I can do better than that as I progress.
#22
Kiwi Mike AZ
Super Member
  • Total Posts : 2056
  • Reward points : 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 17:01:37 (permalink)
0

5MB/Sec = 5 Mega Bytes per second
This is not achieveable with Full Speed USB which tops out at just over 1MByte/sec max with Microchips products

Or do you mean 5Mb = 5 Mega bits per second = 640KBytes/Sec??

MB = Mega Bytes = n x 1024 x 1024 bytes
KB = Kilo Bytes = n x 1024 bytes

Mike
#23
daveinca
Junior Member
  • Total Posts : 104
  • Reward points : 0
  • Joined: 2009/09/11 19:36:52
  • Location: Roseville, CA
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 17:32:09 (permalink)
0
Yes, I meant 5Mb/sec to start. Typo on my part.
#24
philpem
New Member
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2008/09/15 17:03:37
  • Location: 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 17:54:28 (permalink)
0
You're not going to get anywhere near 5Mbit/sec with a PIC.

The closest I got was 300 kbytes/sec with the "fill the buffer and run" test code (which basically called USBWrite in an infinite loop). The SPP-based code I posted in #20 will do about 130kbytes/sec. Pingpong buffering has no effect on these times (in theory it should bring the number of NAK-POLLed IN transactions down -- in my tests it actually INCREASED the number of NAK-POLLs and slowed things down!).

So based on my tests you're looking at 2.4Mbit if you do nothing but sit there filling the USB buffer, and about half that if you're going to do some processing between packet loads.

If you want 5 MBit/sec, you're going to need something a little faster. A Full Speed SIE should be able to go up to ~6Mbit/sec comfortably (taking protocol overheads into account -- you won't get anywhere near 12Mbit/sec, that's the raw data rate), but the PIC's problem is that even at 48MHz you're only getting 12MIPS. That only gives you two or three instructions per byte.

To be fair, the Cypress EZ-USB FX2lp is no better in this regard -- it uses an enhanced 8051 core (the standard 8051 needs 12 clocks to process an instruction, the FX2lp only needs 4), but the fastest it'll run is 48MHz, leaving you with a 12MIPS instruction rate. The real power of chips like the FX2lp is that they have fast parallel port modules that can transfer at high speed (48MHz IIRC), and deal with just about any protocol you like. Even the USB interfacing and packet transfer work is done in hardware -- essentially all the firmware has to do is wait for a packet, then tell the GPIF which buffer to send from and how many bytes to send.

It's just a shame they cost about 4x as much as the 18LF4550, I think they're pretty neat chips if you need that kind of speed. I thought I needed one earlier this week (and actually have a couple in my spares box) but did some speed tests with libusb and realised that 150kbytes/sec is actually pretty reasonable in my application.

Basically I'm building a box that reads magnetic transition data from non-PC-format floppy discs (stuff like Amiga, NorthStar, Heathkit H89, Apple Mac 400K, Apple II, etc.). The goal is to have a h/w+s/w combination that reads discs at a reasonable rate, then takes the raw transition data and decodes it back into a disc image or similar. That disc image can then be written back to the disc if necessary. At this point the FPGA code is working, it's the cursed PIC that's causing all the trouble... :(
#25
Kiwi Mike AZ
Super Member
  • Total Posts : 2056
  • Reward points : 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 18:29:31 (permalink)
0

PIC24FJxxxGB1xx or PIC32MX4 can achieve what you need. The PIC32 can do it easily with plenty of time remaining. PIC24 is a little tighter (16MIPS on PIC24 compared to 80MIPS on the PIC32)
#26
daveinca
Junior Member
  • Total Posts : 104
  • Reward points : 0
  • Joined: 2009/09/11 19:36:52
  • Location: Roseville, CA
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 18:29:46 (permalink)
0
Well that's not encouraging. Based on what you are saying, how was mimemike able to achieve the speeds that he did (>1000kB/sec)? It sounds like better performance must be possible if you know the right tricks to use. Given that my specs for my project aren't available just yet, I'm just trying to see how fast I can push data out of the PIC32 via USB. When I'm actually up and running, the data collection portion of the project should take minimal amount of time but it will have to collect data at a pretty fast rate. We have discussed whether we need to move to some other USB interface but I'll have to wait and see what the requirements are first.

On a side note, you're project sounds interesting. The systems you mention really take me back to my early days as an engineer programming on the original Apple IIs (very early 80s). I'm surprised that disks from that era are still floating around.

Regardless, I'm going to give the demo code a try and see what kind of performance I can get out of it. I will keep what you've said below in mind. I think that initially I'll probably have a loop that does nothing but stuff the USB pipe to see how fast I can get the PC to suck it in. Thanks for the info.
#27
daveinca
Junior Member
  • Total Posts : 104
  • Reward points : 0
  • Joined: 2009/09/11 19:36:52
  • Location: Roseville, CA
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 18:31:08 (permalink)
0
Yeah, I'm using the PIC32 so hopefully I can really pump the data out of that guy.
#28
Kiwi Mike AZ
Super Member
  • Total Posts : 2056
  • Reward points : 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/17 18:32:42 (permalink)
0
phikipem is stuck in the 8bit PICS that is why he has not achieved what I have been able to.

The PIC24 and PIC32 are very different beasts as far as performance and USB go.

Mike
#29
oliglaser
Super Member
  • Total Posts : 257
  • Reward points : 0
  • Joined: 2009/11/01 01:20:59
  • Location: Manchester, UK
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/11/20 14:47:33 (permalink)
0
I have managed to get around 600KB/s from PIC to PC using a PIC18F4455 and a modified version of Microchips MCHPUSB generic firmware, I think I could increase this by streamlining the code in assembler.
post edited by oliglaser - 2009/11/20 14:49:29
#30
Antipodean
Super Member
  • Total Posts : 1948
  • Reward points : 0
  • Joined: 2008/12/09 10:19:08
  • Location: Didcot, United Kingdom
  • Status: online
RE: Max USB Bulk transfer speed. 2009/11/23 04:17:04 (permalink)
0
ORIGINAL: mimemike

1. You are using the CDC which has limitations
   I used Custom Class with BULK transfer and the Raw USB library calls (not USBUSART etc)

2. You keep monitoring if the buffer has been sent and feed it as soon as the buffer is ready, need a tight loop to do this.

3. I used the PIC32 specific stack

Remember USB only sends 64 bytes at a time so you need to keep feeding the buffer the instant it is empty to fill all available time slots.

Also at the PC end you need to read as much in one go, e.g. 1,048,576 bytes at a time (1MByte = 1024 x 1024)
This PC buffer size may be limited depending on the library you used, I think the max I managed was 1,000,000 bytes at a time using LibUSB.

Mike

 
I have done the theoretical possible maximum of 1.2MB/s on a PIC24, by modifying the CDC stack so it accepts an integer count instead of a byte count for the message length. It is then possible to get a full 19 packets of 64 bytes into a single USB transfer (see Jan Axelsons 'USB Complete' for the theoretical maximums). It did require a quad core desktop machine as a host to maintain that speed, my dual core laptop couldn't. Even then when the screen saver kicked in on the desktop, the transfer rate dropped (which isn't suprising as screen savers often send CPUs into 100% usage...).
 
Persoanlly I don't know why microchip have limited the count to 255, instead of allowing the maximum possible.

Do not use my alias in your message body when replying, your message will disappear ...

Alan
#31
daveinca
Junior Member
  • Total Posts : 104
  • Reward points : 0
  • Joined: 2009/09/11 19:36:52
  • Location: Roseville, CA
  • Status: offline
RE: Max USB Bulk transfer speed. 2009/12/04 17:18:32 (permalink)
0
I'm back and have finally gotten my benchmark code to work. I was able to achieve a maximum sustained bit rate of 7.899Mb/s. It's not quite as fast as Mike was able to get but it's getting close. I did my application in C# so that limits me a bit but I was able to make use of the LibUsbDotNet project to make my life a bit easier. Anyway, this is more than sufficient for the 3.2Mb/s that is required for my project at this point.

Thank you to everyone who contributed to my posts. All of your help was greatly appreciated. I knew that I would be able to find the answers I needed here at the forum.
#32
tarek_attia
New Member
  • Total Posts : 30
  • Reward points : 0
  • Joined: 2010/01/05 06:39:23
  • Location: 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/06 04:19:21 (permalink)
0
Hi davenci,

I got stuck in your previous problem ,I want to achieve the maximum transfer rate I cat get,,Also I dunno how to start either from the cdc_serial_device_demo or starting a new project and make a custom class ??


The maximum transfer rate I can get so far is :- 255 KB/S I can''t exceed it never :( ,however when I sent a packet with more than 255 byte ,512 byte for example only the first 255 byte are received by the host,,and the other bytes are discarded ...



BTW :-I's using a Java application on the host machine

Any help will be appreciated :)

Best Regards,

Who he says he can and who he says he can't usually both are right
#33
daveinca
Junior Member
  • Total Posts : 104
  • Reward points : 0
  • Joined: 2009/09/11 19:36:52
  • Location: Roseville, CA
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/06 09:51:50 (permalink)
0
When I wanted to achieve a significant increase in performance, I started a new project based on the LibUSB project (USB Device - LibUSB - Generic Driver Demo). I had originally used the CDC demo as a basis for my project but using a serial port is too limiting on the Windows side. At this point, I can achieve a sustained rate of almost 8MB. Using the LibUSB model allows you to create a cross-platform solution is you want to do so.

On the Windows side, I created an application using C# (I use SharpDevelop for my IDE since it's open source) and downloaded the LibUSB libraries (search for LibUSBDotNet) to create my own driver (INF) file. You may want to check if the LibUSB code offers a Java API. The LibUSBDotNet package offers a firmware example for Microchip processors (look at the Benchmark program within the package) so that would also be a good starting point for you.

If you want more specifics, I can probably provide you with some code examples. In particular, the code in ProcessIO() is very simple. Here is my version of ProcessIO():

void ProcessIO(void)
{
    WORD        rx_bytes;                // # received bytes
   
    if ((USBDeviceState < CONFIGURED_STATE) || (USBSuspendControl == TRUE)) {
        return;
    }
   
    // check to see if any data has been received on the endpoint
    if (!USBHandleBusy(USBOutHandle)) {
        //Re-arm the OUT endpoint for the next packet:
        USBOutHandle = USBGenRead(USBGEN_EP_NUM, OUTPacket, USBGEN_EP_SIZE);
        rx_bytes = USBHandleGetLength(USBOutHandle);
        if (rx_bytes > 0) {
            // some bytes have been received so let's see if it's a packet
            memcpy((void*)&rx_buffer[rx_count], OUTPacket, rx_bytes);
            rx_count += rx_bytes;
            // check to see if we have a complete packet header
            if (rx_count >= sizeof(packetHeader)) {
                packetHeader*    header;    // pointer to packet header
                uint16_t        size;    // size of packet + header
   
                // make sure we have a complete packet by checking the header
                header = (packetHeader*)rx_buffer;
                size = header->size + sizeof(packetHeader);
                if (rx_count >= size) {
                    // we'll process the command packet at this point
                    parse_packet(rx_buffer);
                    rx_count = 0;
                    memset(rx_buffer, 0, RX_BUFFER_SIZE);
                }   
            }
        }   
    }
    if (!USBHandleBusy(USBInHandle)) {
        if (started) {   
            USBInHandle = USBGenWrite(USBGEN_EP_NUM, INPacket, USBGEN_EP_SIZE);
        }   
    }
}


As you can see, the majority of it is to handle incoming packets. That part of the code is very specific to my project so don't get caught up in the details of that. But as others have stated, the key is the host side (the Windows application) since that is what drives the transfer rate. I use a buffer size of 262144 in my Windows application (I recall that Mike had used 1MB buffer but this seemed to work for my purposes) so that is really the important part.

I hope this helps you out a bit.

dave
#34
tarek_attia
New Member
  • Total Posts : 30
  • Reward points : 0
  • Joined: 2010/01/05 06:39:23
  • Location: 0
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/09 15:52:23 (permalink)
0
Thank you very much for your help :) ,,really appreciate it .

But I have another problem ,I can achieve up till 800 kB/Second using the demo CDC_SERIAL project ,,but in a strange manner as following :-

When putting the transmit function just in a while one I achieve max. transfer rate by sending a buffer of 64 byte ,,However when sending inside the gState state machine I can only send 63 Byte ,,and can't send 64 byte ,,by tracing the code the portion of code that makes this is the if statement of "USB receive ready" any one has any idea about that ??!


Thanks ,

Who he says he can and who he says he can't usually both are right
#35
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/09 18:17:36 (permalink)
0
Max transfer speed on bulk is achieved when device and host exchange greater transfer size. But depending on the application protocol over USB, you cannot always exchange such a transfer size. You may want to apply command - reply exchange between the host and the device. Usually, command and reply packets consist of a couple of bytes.

For smaller transfer size, the transfer speed is proportional to the transfer size.
For example,
a) one byte transfer is exchanged in one byte per single USB frame ( 1 byte / ms ).
- A packet of 1 byte payload is exchanged.
b) The speed of 256 byte transfer is 256 bytes per single USB frame ( 256 bytes / ms ).
- PC app puts read/write call of 256 bytes. Four full-size (64 bytes) packets are exchanged on the device side.

The transfer speed saturates when the transfer size reaches to the theoretical max, 19 full-size packets (64 x 19 = 1216 bytes). Actual max is limited by the PC performance. You'll get 17-18 full-size packets / frame on a standard PC sold in these a couple of years. Of course, bulk transfer is "best effort" type. When the bus is busy by other devices on the bus, the max transfer speed reduces.

As we've seen above, transfer timing is tightly bound to USB frame.
This character derives from bus scheduling on the host controller (HC). HC refreshes bus schedule for transfer on every USB frame. In this reason, every transfer starts on a new frame. Even when bus is idle, new transfer doesn't occur until next frame.

Above discussion is based on full-speed host controller, which works when a full-speed device is attached directly to the PC USB port. When a high-speed (USB2.0) hub is inserted between the device and PC, you'll see better transfer speed for small-size transfer. In this connection, the hub translates the bus speed from full- to high-speed. A high-speed HC works on the PC side, which schedules transfers in micro-frame (125 us).

Tsuneo
post edited by chinzei - 2010/01/09 19:06:04
#36
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/10 00:04:17 (permalink)
0
Buffer size on the device for faster bulk transfer

Greater transfer size on the PC side achieves faster transfer speed on bulk transfer.
Then, does greater buffer size need on the PIC, too ?
Not necessarily.

On the device side, transfer is split into packets, and the transfer arrives to / leaves from the device, packet by packet. Therefore, a buffer of single full-size packet (64 bytes) works fully with much greater transfer size. While the device processes the data on the buffer, PC waits the transfer until the firmware passes the buffer to the endpoint again. Behind the scene, NAK flow control (USB hardware flow control) works between the device USB engine and the PC host controller. No data drops occurs on the USB line.

A buffer of two full-size packets (128 bytes) works better than single.
While the first half of the buffer is armed to the USB engine, the firmware processes the data on the latter half, and vise versa. In this double-sized buffer scheme, data transfer occurs in parallel with data process, though they run alternately in the single-sized buffer. Double-sized buffer is still effective on non-ping-pong buffering.

After all, overall transfer speed of large data is determined by the data process speed of the PIC. When the data process speed is less than the transfer speed, transfer delay occurs even on the double-sized buffer. This is the major reason that PIC24F and PIC32 shows better transfer speed than PIC18F.
For small-sized transfers, there isn't so much difference among these PICs.


CDC bulk transfer
a) The discussion on my above post is based on generic device driver, such as WinUSB or libusb. On generic device driver, the size for read/write call on PC application matches to the transfer size.
But on CDC device driver, the read call size doesn't match to the IN transfer size, for CDC bulk IN endpoint.

CDC device driver issues bulk IN transfer by itself repeatedly, regardless of read call from PC app. Transferred data is stored in the input buffer on the device driver once. The read call from PC app reads out data from this input buffer.

The device driver usually requests 4K Bytes IN transfers. Therefore, device firmware has to terminate the transfer by a short packet (a packet of less than 64 bytes). When the transfer finishes with full-size packet, a ZLP (Zero-Length Packet) should be added. Until the firmware terminates the transfer with a short packet, the host controller holds the entire transferred data, and the data doesn't appear on the input buffer.

b) CDC firmware stack functions on MCHPFSUSB (getsUSBUSART(), putUSBUSART(), etc) copy the data between user buffers and stack EP buffers. Also putUSBUSART() runs state machine on CDCTxService(), in which data copy and ZLP addition is handled. It reduces the transfer speed performance.

When your firmware manages the buffers using USBRxOnePacket() and USBTXOnePacket() directly, you'll get better speed performance, which is comparable to the case of generic device drivers.

Tsuneo
post edited by chinzei - 2010/01/10 06:27:14
#37
stefanopod
Super Member
  • Total Posts : 1285
  • Reward points : 0
  • Joined: 2007/06/25 02:33:59
  • Location: Bologna,Italy
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/10 04:04:42 (permalink)
0
to chinzei:
I haven' t clear this point: as you say, stack 2.6 example about usb audio speakers employs 2 buffers, one is trasmitted while the other is being filled with data.
Is this tecnique possible only if ping-pong buffering option is selected (with 2 descriptors per endpoint- the stack 2.6 case) or would it work  also in a non pingpong scenario?

provando e riprovando
#38
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/10 17:15:01 (permalink)
0
Is this tecnique possible only if ping-pong buffering option is selected (with 2 descriptors per endpoint- the stack 2.6 case) or would it work also in a non pingpong scenario?

For bulk transfer, two buffer scenario works even on non-ping-pong mode. Using ping-pong mode, this scenario improves the speed performance a little better.
For isoc transfer, two buffers on ping-pong mode is necessary.

The difference lies in the transfer timing requirement.
For bulk transfer, IN and OUT transactions can be delayed by NAKing. No data drop occurs with this delay. Therefore, the transfer timing is not so strict. Also, IN and OUT transactions come from host many times in a single USB frame.
For isoc transfer, however, the transfer timing is strict. IN and OUT transaction occurs just once in single USB frame. The transaction may starts at the beginning of the frame (*1). Therefore, the buffer descriptor for next transaction has to be prepared while current frame is running. That is, ping-pong buffer is required.

(*1) UHCI and EHCI host controller assign isoc transaction as the first transaction of the frame. OHCI reserves the first period for control transfer.

Tsuneo
#39
stefanopod
Super Member
  • Total Posts : 1285
  • Reward points : 0
  • Joined: 2007/06/25 02:33:59
  • Location: Bologna,Italy
  • Status: offline
RE: Max USB Bulk transfer speed. 2010/01/11 00:49:46 (permalink)
0
If I understand well, passing from a scenario of ISO transmission with 2 buffers and no pingpong to a scenario of 2 buffers+pingpong, we spare in firmware on the time of preparation of the buffer descriptor switching from even to odd.

But I don't unterstand how and where this sparing is performed: the firmware calls
USBRxOddHandle = USBRxOnePacket(AS_EP,(BYTE*)&ReceivedDataOddBuffer, NO_OF_SAMPLES_IN_A_USB_FRAME); over the odd buffer, then the same  over the even buffer.

Both are calls to USB TransferOnePacket.

At the end of the first call I have the preparation for the next buffer :( ((BYTE_VAL*)&pBDTEntryIn[ep])->Val ^= USB_NEXT_PING_PONG;).

But  the next call of USBTransferOnePacket on the other buffer doesn't make any use of this preparation and acts as a non pingpong call. So I don't see where this sparing is performed.

I imagined firmware skipping some steps that could be perfomed in hardware, but I can't see that.

I apologize in advance, probably the question is silly and I'm not at all  an expert  about this issue.

Thanks a lot.
post edited by stefanopod - 2010/01/11 01:06:55

provando e riprovando
#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2020 APG vNext Commercial Version 4.5