In the section 5.12.6 of usb spec 2.0, it mentions that "because SOF packets can be damaged in transmission, devices that support isochronous transfers need to be able to synthesize the existence of an SOF that they may not see due to a bus error". But how to comprehends that synthesize the existence, it refers to usb devices will remain the sof number or increase the sof number when sof packet damaged in transmission.
Related
While researching the HID specification for a current project, I stumbled across the following phrase:
Using USB terminology, a device may send or receive a transaction every USB frame (1 millisecond). A transaction may be made up of multiple packets (token, data, handshake) but is limited in size to 8 bytes for low-speed devices and 64 bytes for high-speed devices.
This leads me to believe that the maximum size for a HID packet is 64 bytes.
However, examining the report descriptors for some other devices I see that packets of more than 500 bytes are being used. How is this possible? Are these devices violating the USB spec? If so, what might that imply in terms of compatibility across different platforms?
As far as I know, the last HID specification is much older than the recent USB specs; IIRC the latest version is 1.11 which dates back to 2001.
There is low-speed, full-speed, and high-speed USB these days, and I think the HID spec was never changed to reflect this.
The maximum packet size for high-speed is 64 bytes for control transfers, 1024 bytes for interrupt transfers and isochronous transfers, and 512 bytes for bulk transfers.
See USB in a NutShell, which I think is more up-to-date. There are other sources, of course.
I am not entirely sure if all this applies to HID devices as well these days, what with the HID spec not having changed, but I assume high-speed HID devices exist now that use larger packets as described in the newer USB specs.
I have a custom ps2 keyboard(8x8 matrix) interfaced with AT89C51ED2 microcontroller, now I need to change it to USB interface. I have been studying about the basics of USB HID class communication(USB HID class specs, USB complete, Beyond logic) and have come to know little bit about the theory behind it.
But I am not able to understand the firmware part, I read a demo keypad application by Microchip which had given a sample source code, but I am not able to understand in the code how data(key pressed) is sent to the IN endpoint and how the host reads that through polling. I know that endpoint is a buffer from which data is sent to host, but Is it one of the registers of the micro-controller and how do I use it in my code?.
And I have been searching the suitable micro-controller with USB support, but no supported demo's are available, any suggestions will be helpful
The AT89C51ED2 datasheet does not mention hardware support for USB, so the answer is no: an endpoint does not correspond to a hardware register. Instead, an endpoint would refer to some software buffers in the RAM of the chip, and some data to keep track of the endpoint's state. Every bit of every USB packet must be handled by the firmware of the device, and endpoints are an abstraction that live entirely in the firmware of your device.
Note: I am assuming that the keyboard doesn't have some kind of USB interface chip, and that the data lines of the USB cable connect more-or-less directly to the microcontroller.
If you can't find the source code for the keyboard, you might look into using an open-source AVR software USB implementation. Here are some useful links:
https://www.obdev.at/products/vusb/
http://www.fischl.de/usbasp/
Please note that you are undertaking an advanced project, and if you are not familiar with AVRs, USB, microcontrollers, reverse engineering, and embedded development/debugging, it might be useful to start with something simpler first.
I am looking into ways to stream a usb camera over long distances. The plan is to plug the USB into a raspberry pi2, then send it over wifi via TCP. Is this a viable plan?
I have found a few approaches like this:
https://www.virtualhere.com/
But They seem to be for printers and other 'static' devices. Will a streaming data connection work with this type of approach?
Thanks.
Yes, a USB camera uses the "isochronous" transfer mode of the USB protocol.
VirtualHere and most other usb/ip software support this mode.
The main issue is network latency. The lower the webcam resolution, the less latency will be a problem. Also, the pi2 has a fast CPU however the USB bus is shared with the Ethernet so by definition throughput is cut in half, perhaps looking at a embedded board that doesn't share the USB bus like a beaglebone or odroid-c1 or other board would provide better performance for the same price.
(I am the author of VirtualHere)
The mikroC compiler has a library for HID (Human Interface Device) USB communication. In the supplied samples, they specify that the buffers below should be in USB RAMand use a PIC18F4550 as the target microcontroller.
unsigned char readbuff[64] absolute 0x500; // Buffers should be in USB RAM, please consult datasheet
unsigned char writebuff[64] absolute 0x540;
But the PIC18F4550's datasheet says USB RAM ranges from 400h to 4FFh.
So why does their example work, when their buffers appear not to be between 400h to 4FFh?
Link to full source.
The datasheet actually says:
Bank 4 (400h through 4FFh) is used specifically for
endpoint buffer control, while Banks 5 through 7 are
available for USB data. Depending on the type of
buffering being used, all but 8 bytes of Bank 4 may also
be available for use as USB buffer space.
So, it would appear the code you're quoting is defining buffers used for USB data, not "endpoing buffer control" since they are in bank 5 instead of bank 4.
When USB HID mode is activated, USB RAM Memory ranges from 400h to 4FFh is assigned for buffer descriptors. Range between 500h and 7ffh is assigned for USB and user data. Important thing is all descriptor buffer and data buffer will be in ram memory range of bank 4-7.
Thank you
Does anybody know if it's possible to emulate UART (simple serial transmit and receive) over USB? How would this be accomplished?
I found this link on the Microchip website, but it's not very forthcoming.
http://www.microchip.com/forums/m522571-print.aspx
Any ideas? Thanks.
You need to implement the device stack as a CDC ACM device (also known as Virtual COM port or VCP). Most vendors of microcontrollers with USB support have example code or app notes.
Given that, your device will look like a COM port as far as Windows is concerned. At the device end, you will get raw blocks of data transferred. An appropriate abstraction layer can be implemented for both UART and USB interfaces to give then the same interface if necessary.
One gotcha is that USB devices require a Vendor ID allocated by the USB Implementer's Forum, at a $5000 fee(correct 23 JUly 2016). If you are going to release your device in the wild, you really will need one if your device is to be recognised and behave correctly with other devices. Some microcontroller vendors will allow you to use their vendor ID for a subset of product IDs for free or a smaller fee, but they might only do that if you were purchasing significant quantities of devices from them.
Another issue is that while on OSX or Linux a CDC/ACM is recognised without any additional drivers, Windows is more fussy and required an INF file to associate the specific USB Vendor and Product ID to the usbser.sys driver. Then you get into the whole world of driver signing, which is essential if using Windows Vista 64, or any version of Windows 7. A code-signing signature will also cost you money. If your vendor has provided example VCP code, they will also probably provide a signed driver. STMicroelectronios's STM32 VCP example is even WHQL certified so can be acquired automatically via Windows Update.
So the upshot is that for experimentation you can do it if your vendor already provides code and a signed driver (or you are not using Windows), but to deploy a product you will need an Vendor ID and a code-signing certificate. It is a bit of a minefield to be honest.
A simpler approach is to use an FTDI USB<->Serial chip. This is especially useful for a microcontroller without a USB controller of its own, but the data transfer rate will be limited by the micro's and/or the FTDI's UART interface rather than USB speed. An FTDI chip can be used as-is using FTDI's VID/PID or you can customise it with your own VID/PID. Customising puts you back into needing to acquire a VID and a signing certificate, but allows your device to be identified uniquely rather than as a generic serial port.
Basically you have two options to emulate UART over USB:
Use an existing product. The company FTDI provides well known and solid UART-USB bridge chips, e.g. FT230X. Pro: You don't need any detailed knowledge about USB. Cons: Expensive if used in mass production. Additional hardware, needs additional power.
Implement the USB device class "Communication Device Class" (CDC). The specification of CDC is available from the USB.org, see here. Pro: Cheap in mass production (if your Microcontroller has USB on board). Con: You need detailed knowledge about USB.