USB to transmit real-time data in the least time possible

[wfarid]

Posted on April 16, 2011 at 00:20

USB to transmit real-time data in the least time possible

[wfarid]

Posted on May 17, 2011 at 14:31

Hi PICguy,

1) I guess by '' pre-digest/select real-time actions '', you mean perform the computations on the cortex-M3, right ? If so, then the answer is ''No'', as the algorithm that will use this data is really complex and that is why I'm using a high-end processor to do it.

2) The system that is going to receive the data is either a PC or a high-end processor. I'd say a high-end processor and it will be have peripherals ( GPIOs, USB, UART, SPI, I2C, ETHERNET ..... ). 

3) The data is digested by this high-end processor.

4) You mean FSMC using DMA to replace parallel-transmission with handshaking, right ?

5) So, you're recommending USB using HID( which I think is interrupt mode ) or isochronous mode. I just want to add, that if I'm using USB, then at most 2 peripherals will be connected to USBs to the high-end processor.

6) Ethernet ... UDP I think, right ? How fast can I send the data using the STM32 ? I think Ethernet is only available on the connectivity line but not the high-density, right ? Are there any tutorials on STM32-Ethernet ?

Thank you,

 Walid

[picguy2]

Posted on May 17, 2011 at 14:31

Can you pre-digest the data / perform select real-time actions?  What kind of system is going to receive your data?  And where does it go from there?  These questions may be as important as your quest about rapid data transport.

Ethernet may work.

Or you could use FSMC with DMA.

USB?  It’s easy to transfer 64-byte blocks (almost) every millisecond using HID.  I’m told that isochronous USB only beats [I think it’s called interrupt] transfers when your USB host is seriously busy.  

But you wrote:

>Are there any STM32 USB & USB tutorials that will facilitate my understanding?

At least you recognize you need assistance.  I recommend that if you plan to use USB and have the budget you should get a USB expert to assist.  I.e. trade off money for time.  Part that assistance should be teaching you.  You want to be able to maintain the project without refilling your consultant’s wallet.

[tsuneo]

Posted on May 17, 2011 at 14:31

walid.farid > Are there any STM32 USB & USB tutorials that will facilitate my understanding ?

ST distributes this USB device library on their web site.

STM32F10x and STM32L1xx USB full-speed device library

http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/um0424.zip

STM32 USB-FS-Device development kit

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/CD00158241.pdf

You may find another USB libraries/examples made by compiler vendors like Keil, IAR.

As of ST library, I recommend you to start with \Project\Virtual_COM_Port example. This example transfer data from on-chip UART to PC over USB. Also, in the other direction. On the PC side, the chip is exposed as a COM port. Therefore, you don't need to change your PC code so much.

You'll modify this example so that it picks up data from GPIO instead of the UART. As this example gives full source code, you may be lost in the forest of the source code. These functions are ones you have to focus on,

1) EP1_IN_Callback() in \Project\Virtual_COM_Port\src\usb_endp.c

2) Handle_USBAsynchXfer() in \Project\Virtual_COM_Port\src\hw_config.c

Both of these functions moves packetized data from the UART RX buffer to USB endpoint buffer using USB_SIL_Write() (or equivalent). Handle_USBAsynchXfer() is periodically called by USB SOF (Start Of Frame) interrupt, ie. every 1ms. It moves the first packet to the endpoint buffer after interval. EP1_IN_Callback() is called by the endpoint interrupt, which occurs just when the last transaction (a packet transfer) finishes. This routine pushes the second and latter packets into the endpoint, if the RX buffer still holds data more than the packet size.

As you see, most of the complicated USB details are hidden by the library. Your code focuses on just exchanging packets with endpoints.

I recommend you to read this short explanation, to get clear understanding on USB transfer.

Transfer - transaction - packet

http://www.cygnal.org/ubb/Forum9/HTML/001627.html

PICguy > At least you recognize you need assistance.  I recommend that if you plan to use USB and have the budget you should get a USB expert to assist.

I agree that USB beginner needs some assistance, to know the place where they should focus in the example source code. But I don't think paid consulting is required for startup on USB library. If it were, I could be a millionaire, now :)

Tsuneo

[tsuneo]

Posted on May 17, 2011 at 14:31

As PICguy pointed out,

USB HID can exchange 64 bytes transfer in every 1 ms USB frame on full-speed bus. But I recommend you bulk transfer, which carries more than 1K bytes / frame. Isoc also reaches to this transfer speed, but it's handling is troublesome on both side, host and device.

You are using the term ''real-time'' just as ''quickly''. But practically, ''real-time'' means ''in time''. If you wouldn't explicitly define deadline of process delay, including data transfer delay, ''real-time'' means nothing. For example, the air conditioner regulates the temperature of your room in ''real time''. It's response time is around 10s seconds order. The mouse in your hand moves the cursor on the PC display in ''real time''. It's response time is around 10s milli-seconds order. As you see, ''real time'' doesn't mean absolute time scale.

Either Ethernet or USB, these serial communications are based on packet transfer. When an optimal size of packet is exchanged, the transfer speed of packet transfer is maximized. That is, the sender has to hold incoming data stream on a buffer until it reaches to the optimal packet size. Here, buffering delay, corresponding to the packet size, is added to the transfer delay.

Tsuneo

[Andrew Neil]

Posted on May 17, 2011 at 14:31

''I can call the whole system a real-time system.''

 

Yes, you can call it that - but it is not helpful in this particular context.

The point is that calling it ''real-time'' conveys no information about your specific timing requirements & constraints - and it is the timing requirements & constraints that are key to your question!

[wfarid]

Posted on May 17, 2011 at 14:31

Hi Tsuneo,

 Thank you for your answers and links.

 1) Regarding ''real-time'', right now the 15 KB takes 167 milli-seconds on a UART running at 921,600. Let's say I want to constrain this data to take around 10-20 mSec so that the high end processor can capture this data and apply the algorithm and have an output ( 20 mSec ) after the data is received, so that I can have a response at most every 50 mSec. I think according to your examples, I can call the whole system a real-time system. Please correct me if I'm wrong.

 2) You recommended Bulk transfer which carries 1KB/Frame. How long does it take to send one frame on the USB 2.0 full speed peripheral ?

Thank you,

Walid

[wfarid]

Posted on May 17, 2011 at 14:31

Hi guys,

Andrew, thanks for the clarification ... I got what you mean.

Tsueno, I was looking for both functions that you mentioned, and after some search I found that the Handle_USBAsynchXfer() is in the USBLib_v3.3 and not USBLib_v2.2 which is installed with Keil. I'll look at the example and I might have some questions later. Just stating this if anybody else was searching for it.

1) I have one more comment regarding the data transfer rate using the Virtual COM Port example. From this link as well 

http://tinyurl.com/3llteo2 it seems that the maximum transfer using the bulk transfer mode with CDC is around 80KByte/sec ( on USB 2.0 full-speed ). This is also stated in an online microchip presentation (page15) 

http://tinyurl.com/3sqn9st. Can somebody explain why is that ? Using the 921600-UART, I can get a maximum transfer rate of 90KByte/sec, so I'm surprised how the bulk transfer mode using CDC can only reach 80KB/sec on a 1.5MB/sec USB 2.0 bus. I think the Virtual COM Port example is using the CDC.

Is this limitation because of the CDC ??

2) Does the host need to send the ''transfer'' size before the device sent any data ?

3) When using UART, we can just send data from the uController at any time without the host initiating it, can the bulk transfer mode on the STM32-USB be the same ?

4) Any idea what is the transfer rate will be using the Isochronous transfer mode ? Shall it reach the maximum 1.0-1.5 MB/sec ?

5) So now, if I have a USB-host with only one port connected to a USB-device which transmits the data using Bulk mode or Isochronous mode.

-> When using Bulk mode only , is the transfer still considered low priority ??

-> When using Isochronous mode only, can we still expect errors to occur compared to having more than one device connected to the USB ??

Thank you,

- Walid

[jpeacock23]

Posted on May 17, 2011 at 14:31

Given the size of your data and a requirement to send 15KB at better than 150ms time frame You mostl likely won't be able to use full speed USB.  If distance is short you might be able to use an SPI serial line at 15-20Mhz for a little better time (no USB protocol overhead either.

Otherwise you really want a 100Mbit Ethernet link.  Either embedded in a'F107 or an external controller using the FSMC bus and DMA.  You might look at the Micorchip ENC624J600 100Mbit etherent controller for this, it has a built-in PHY and a 16-bit parallel data bus, about as good a thruput as you can get with the FSMC bus.  Run a full duplex 100Mbit line point to point between the embedded device and the host, no collisions or network overhead, you get a deterministic response time.

  Jack Peacock

[wfarid]

Posted on May 17, 2011 at 14:31

Thank you Tsueno for your clear answers. Kudos !!

[tsuneo]

Posted on May 17, 2011 at 14:31

> 1) Is this limitation because of the CDC ??

Maybe, the Microchip author of this presentation still lives in Windows 98. Or, he doesn't realize on the basic endpoint handling of the device side, which I explained in this post,

http://www.cygnal.org/ubb/Forum9/HTML/001627.html

He should retire from USB world soon.

Microchip distributes a USB library in their Application Library

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784

Using this library as is, I can see transfer of 255 bytes / 1ms USB frame on CDC using PIC24F/32MX. Modifying the library function a little, so that it accepts unsigned short instead of unsigned char, I can see above top speed on these MCUs. PIC18F has core performance penalty. But even on this MCU family, I see more than 200 bytes/frame.

> 2) Does the host need to send the ''transfer'' size before the device sent any data ?

For CDC, host app doesn't need to notify transfer size to the device. Instead, device always has to terminate the bulk IN transfer in short packet (including ZLP - Zero-Length Packet).

PC CDC class driver repeats fixed-size transfer requests on bulk IN pipe. Usually, this size is 4K bytes (the paged memory size of PCI bus). Therefore, each transfer must be terminated by device using short packet.

> 3) When using UART, we can just send data from the uController at any time without the host initiating it, can the bulk transfer mode on the STM32-USB be the same ?

No. Not just on STM32.

USB is designed as host-centric.

Device prepares packet data on the bulk IN endpoint buffer, in advance.

When host initiates an IN transaction, the device USB engine (SIE) returns the data on the buffer in this IN transaction.

If the endpoint buffer is empty, SIE returns NAK (not ready) to the IN transaction. NAK is also a normal response, which consists USB hardware flow control. Receiving NAK, PC host controller repeats IN transaction after short interval. In this way, host controller repeatedly polls bulk IN endpoint, while the endpoint is NAKing. You'll see 30-40 IN-NAK transactions per frame.

> 4) Any idea what is the transfer rate will be using the Isochronous transfer mode ? Shall it reach the maximum 1.0-1.5 MB/sec ?

The top speed of full-speed isoc is 1023 bytes/frame.

> 5) So now, if I have a USB-host with only one port connected to a USB-device which transmits the data using Bulk mode or Isochronous mode.

Bulk is much easier than isoc on both side.

On host side, availability of PC class driver is the problem.

- For bulk, CDC and WinUSB is available as in-box driver.

- For isoc, in-box USB audio. But I believe you don't like your PC app as an audio app :)

On the device side, isoc requires tight timing to keep the transfer in ''isochronous''. Bulk timing is rough.

> -> When using Bulk mode only , is the transfer still considered low priority ??

Yes. As I wrote in other post, these setups ensure full bandwidth for bulk.

1) The device is directly plugged in to a PC USB port (ie. PC host controller), without any other device.

OR

2) The device connects to a PC over a multi-TT hub (*), with other full-/low-speed devices.

> -> When using Isochronous mode only, can we still expect errors to occur compared to having more than one device connected to the USB ??

In usual environment in office and home, you rarely see isoc error.

Tsuneo