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?
Related
I am looking at implementing USB communication on a MCU which has a USB engine built into it. Basically you have access to the pipes/endpoints.
I am a little bit confused on the USB stack now. It appears that drivers operate on another level above the pipe/endpoint setup, so the pipe/endpoint is like a middle level layer that drivers are built on. Is this correct?
Secondly, I am interested in simulating serial communication over USB. It appears windows has a premade driver so on the computer side I do not need to program the pipe level.
How do I find out what I need to implement on the MCU to make it behave correctly with the generic serial driver?
This is an answer to your second question regarding the serial communication.
The USB standard defines a communication device class (CDC) for serial communication. The required drivers on the host side are implemented by Windows, macOS, Linux and many more operation systems.
The relevant CDC subclass is PSTN. The relevant documents are found in Class definition for Communication Devices 1.2.
The device basically implements four endpoints:
Control endpoint for configuration requests (baud rate, DTR state etc.). Have a look at SetLineCodeing, GetLineCoding and SetControlLineState.
Bulk endpoint for USB to serial transmission
Bulk endpoint for serial to USB transmission
Interrupt endpoint for notifications (DCD state, errors). See SerialState.
And of course you need to get the device descriptor right.
On top of that, you need to implement all the standard USB requests.
Chances are high that this has already been written for your MCU, both the standard requests and the serial communication. So why not use the existing code?
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 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?
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
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.