I develop the driver in Embedded Device that communicates via USB with Host (PC). Device implements CDC class on USB FS.
When I send data from Host to Device with the size more than MaxPacketSize I have never get any Zero Length Packet to terminate transaction in any case.
I have checked it with data size equal or not equal to MaxPacketSize multiply.
According to USB specification (USB 2.0 standard 5.8.3) Zero Length Packet should be send in this case.
I suppose that this is a matter of Windows driver - usbser.sys, but I have not found confirmation of this behaviour.
What I am asking is there any way to detect the last packet in Bulk OUT transfer from Host to Device or any way to setup the Host to send these ZLP packets in Bulk OUT transfer?
Related
Will USB communication in Windows 10 be done in Bulk mode?
I'm in the process of selecting a PC and would like to know how to transfer Windows 10 to other devices for USB communication.
There are four transfer methods for USB communication, Control, Interrupt, Bulk, and Isochronous, and which one is used depends on the host.
I'm hoping to use the Bulk method of communication because I don't want USB communication without retransmission.
Thank you!
and which one is used depends on the host
Yes and no. The host must use the method appropriate for a device, and the device has endpoint descriptors which define whether an endpoint is bulk,interrupt or isochronous.
Note that common devices have specific endpoint type requirements: Mass storage use bulk while HID devices (e.g. mice or keyboards) use interrupt ep.
I am using a Zebra DS457 Scanner to read bar and qr codes via COM-Port (RS232). In my test evironment I used a MSI terminal with Win10 and it worked on the real COM-Port without any problems. But on other devices (Win10 and Win7) there are some issues that the software trigger does not come through and the read information do not get sent back to the computer. When I am using a USB to RS232 FTDI adapter I have no issues at all. But why? First I thought it is Win10 and the legacy support could be better, but the adapter is on all devices better and faster. How is this possible? Maybe a driver specific thing? I am using this adapter link to conrad.de.
An FTDI serial port will impose a minimum latency between the time a character arrives over the wire and when an application can see it, and between the time an application wants to send something and the time it goes over a wire. On older devices, these latencies were a minimum of 1ms each, but I think some newer high speed devices have reduced them to 125us. Further, data which arrives at just the wrong speed sometimes ends up with hundreds of milliseconds of additional latency, for reasons I don't quite understand.
On the other hand, an FTDI device can buffer 256 bytes of data from the wire, or 128 bytes of data from the USB port to be sent over the wire, and process RTS/CTS handshaking, without any software intervention--abilities which are lacking in the UART chips used by PC serial ports. If software gives 128 bytes to an FTDI device, it will start sending it until the remote device deasserts its handshake line, whereupon the FTDI device will stop sending as soon as the current byte is complete; it will then resume transmission as soon as the remote device reasserts handshake. If an FTDI device receives enough data over the wire that its UART would be in danger of overflowing, it will automatically deassert its handshake output without requiring any software intervention. The UART used in PC serial port, by contrast, requires a fast interrupt handler to control or respond to the handshake wires. If an interrupt handler maintains a 4096-byte buffer, it may deassert the handshake wire once that buffer is 75% full, but nothing would deassert the handshake wire if the buffer is less than 75% full and 17 bytes arrive over the wire in quick succession before the UART interrupt handler. Worse, if transmit buffering is enabled, and the PC has fed 16 bytes to the UART for transmission when the remote device deasserts its handshake line, those 16 bytes will be sent out whether or not the remote device is ready to receive them (and based upon the handshake wire, it very well might not be).
Thus, some applications can work much better with an FTDI UART, and some much better with an actual serial port.
I have probably a very simple question.
When I initialize the port in Windows 10 the control message sent to USB device is incomplete. Windows sends the speed, but all other parameters are zeros (ie parity, nbits etc). I have checked the raw data received by the endpoint, I have also sniffed the communication on the cable - and Windows does not send this data.
Is this the standard virtual serial windows driver issue?
I have problem with communication via USB CDC with Windows. On Linux or Mac everything work good.
So, when I try to connect to my COM port I get notification from PUTTY "Unable to open communication to COM2. Unable to configure port.
It is my own device based on Rx63n uC, I transmit in FullSpeed standard, packet in size less than 64 bytes. I'm used 2 endpoints for bulk transfer IN/OUT.
In USBLyzer I got information thatSTALL packet is received from my device after error (USBD_STATUS_CANCELED).
I used driver from Windows 10 usbser.sys.
Any ideas what is wrong?
I forgot to add that in USBLyzer I see a lot of my packets, and after transferred some data it generate error as above.
I'm working on an Ethercat master written Go. The underlying library is at http://github.com/distributed/ecat and contains one link level driver, using UDP and multicast. I'm having trouble to get this link level driver to work consistently across multiple platforms (OS X, Windows, Linux) and different networking configurations.
For those not familiar with Ethercat, here's how it works. Ethercat is an industrial bus system based on Ethernet. There's one bus master and potentially many slaves, which are connected into a logical ring. The master can be built from off-the-shelf hardware, i.e. with normal Ethernet interface cards. The master sends a packet on its Ethernet interface, the slaves modify the packet on the fly and after passing through all the slaves, the master receives the packet on the same network interface that sent it. Depending on the number of slaves, the network interface might start to receive the packet while it is still transmitting the very same packet. There are two possible formats for Ethercat frames. The first is an Ethernet packet with a special ethertype. The second is a UDP packet destined for port 0x88a4.
Depending on the commands contained in an Ethernet packet, the slaves may or may not modify the packet's Ethercat data. Apart from changing Ethercat data, the only thing about the packet that is changed is that bit 1 of the Ethernet destination address is set to 1. The IP header of the packet is not touched by the Ethercat slaves.
My code works as follows. I join a multicast group, say 239.255.65.10 on interface xyz, where I connected my Ethercat slaves. To exchange data with the bus, I send a packet, let's call it pA on this interface to 239.255.65.10. The OS fills in the source address, say the IP address 192.168.5.2 of interface xyz. After the packet passed through the bus and was possibly altered, it's now packet pB. The IP header still has a source of 192.168.5.2 and a destination of 239.255.65.10. Depending on the host's networking settings, this packet might or might not reach my application. In the cases where it does not reach my application, say when rp_filter is set, on Linux, packet pB is rejected because it looks like it originated from my machine, but we shouldn't be receiving our own packets over the network.
What steps can I take to reliably receive the processed packet pB? Please note that I'm not speaking about loopback - loopback is about receiving packet pA, my question is about receiving pB.