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 need to write a number of drivers for both HID USB devices as well as some old serial devices. The drivers are to pull data off the device and then send the data over to an application that then consumes it. Since the Apple Docs mention that a lot of USB and HID communication can be done from the user space I had assumed that I would not need to write a kernel extension, at least not for the HID devices. Could some one tell me a more solid way to determine this?
Thanks!
If you're writing a single application that must talk to one or more USB HID devices you may well find you can just access the devices straight from the application using the application-level USB APIs.
A kernel driver would be more for something like a networking or mass storage device that needed to integrate with the kernel to be be available to multiple applications.
This Apple document Common QA and Roadmap for USB Software Development on Mac OS X goes into some detail on the matter and links to example code too.
I've been looking for a detailed description for how USB protocol and cabling works for a long time with no luck. I am looking for a detailed yet not overcomplicated explanation of how things work on the software and hardware side of USB. Links and explanations would be appreciated. I've really run out of ideas, so it would be great if you can help me out.
This is what I do know:
USB hardware carries 4 lines- 5V power, ground, and 2 full duplex lines.
When connecting, the device can ask for a specified amount of current.
The transfer speeds for USB are quite fast compared to traditional serial connections.
When connecting, a device will output descriptors to the host describing itself. These descriptors will also be used for data.
What I don't know:
How does a program in C/C++ write directly to a USB port? Does it write to an address in the port?
How do some devices describe themselves as HID?
How do drivers work?
Everything else...
Thank you!
Identification
Every device has a (unique) Vendor and Product ID. These are provided (sold) by usb.org to identify a device. You can use a library like libusbx to enumerate all connected devices and select the one with the Vendor and Product ID you are looking for.
HID Descriptors
The point of HID descriptors is actually to do away with drivers. HID descriptors are a universal way of describing your device so you don't need to waste time on a driver for every system/architecture/etc/. (Same concept as the JVM.)
Reports
You will use either the input, output, or feature reports to read or write to your device. You send a stream to your device on the input or feature report. This is typically 8 bytes I believe. Only one of which is a single character you wish to write. The HID descriptor contains all the information you need to put together a report. Although I'm struggling to find a related link to clarify this.
Potential Libraries
In an effort to be open-minded here are all the libraries I am familiar with and some info about them.
libusb-0.1
First off is libusb-0.1. This used to be the go to and was built in to many Linux kernels and Windows I believe. It is very easy to use and there is a lot of documentation. However, the owner never updated and it wasn't edited for many years. It supports only synchronous transfers. (If an error occurs, the program can wait infinitely while it expects a transfer.)
libusbx
Next is libusbx. This is what most people would suggest today and I agree. It was published by those frustrated by the owner of libusb-0.1. The code is much more lightweight, up-to-date, and importantly does not require root privileges like libusb-0.1 and libusb-1.0 (Discussed in a second). It supports synchronous or asynchronous transfers.
libusb-1.0
Then there is libusb-1.0. This was the first update to libusb-0.1 in some number of years. It is not compatible with libusb-0.1. This was published the same day as libusbx as a retaliation (I assume) and an attempt to rectify the lack of updated content and conserve a user-base. It supports synchronous or asynchronous transfers.
hid.h
Finally, there is the hid library. This was built on top of libusb as another layer of abstraction. But honestly, I think it's just really confusing and it just adds more overhead than necessary.
Some Good Resources
Understanding HID Descriptors
Control Message Transfer Documentation (Very Good Link IMO)
Rolling Your Own HID Descriptor
Good Visual of HID Reports for Transfers
Great List of bmRequestType constants (You will need this or similar)
A simple terminal app for speaking with DigiSpark using libusbx and libusb-0.1
I know this isn't exactly what you are looking for, but maybe it will get you started!
This website has a general overview of how USB devices work:
https://www.beyondlogic.org/usbnutshell/usb1.shtml
Particular sections give answers to things from the list of things you don't know yet about USB.
E.g. to find out how USB devices identify themselves, read about USB descriptors:
https://www.beyondlogic.org/usbnutshell/usb5.shtml#DeviceDescriptors
To learn how a C/C++ program can talk to a USB device, see examples on using the libusb library:
https://github.com/libusb/libusb/tree/master/examples
To learn how USB drivers work, see a tutorial from Bootlin:
https://bootlin.com/blog/usb-slides/
I wanted to monitor mouse status(connect/disconnect) in system wide on OS X. I checked the Apple developer library, but cannot find any clues.
My goal is to monitor both USB and Bluetooth mouse. Any API that I could use?
Thank you very much.
--N
You can use I/O Kit's HID manager API to find out when new HIDs (Human Interface Devices) appear in the system, or are disconnected from it. This is a complex topic in itself, so I won't throw random code at you - just go read Accessing a HID Device (in particular the Matching HID Devices and Registering for Unplug Notifications sections). Example code is included.
I have been tasked to write a device driver for an embedded device which will communicate with the micro controller via the SPI interface. Eventually, the USB interface will be used to download updated code externally and used during the verification phase.
My question is, does anyone know of a good reference design or documentation or online tutorial which covers the implementation/design of the USB protocol stack/device driver within an embedded system? I am just starting out and reading through the 650 page USB v2.0 spec is a little daunting at the moment.
Just as a FYI, the micro controller that I am using is a Freescale 9S12.
Mark
Based upon goldenmean's (-AD) comments I wanted to add the following info:
1) The embedded device uses a custom executive and makes no use of a COTS or RTOS.
2) The device will use interrupts to indicate data is ready to be retrieved from the device.
3) I have read through some of the docs regarding Linux, but since I am not at all familiar with Linux it isn't very helpful at the moment (though I am hoping it will be very quickly).
4) The design approach, for now at least, it to write a device driver for the USB device then a USB protocol layer (I/O) would reside on top of the device driver to interpret the data. I would assume this would be the best approach, though I could be wrong.
Edit - A year later
I just wanted to share a few items before they vanish from my mind in case I never work on a USB device again. I ran into a few obstacles when developing code and getting it up and running for the first.
The first problem I ran into was that when the USB device was connected to the Host (Windows in my case) was the host issues a Reset request. The USB device would reset and clear the interrupt enable flags. I didn't read the literature enough to know this was happening, thus I was never receiving the Set-Up Request Interrupt. It took me quite a while to figure this out.
The second problem I ran into was not handling the Set-Up Request for Set_Configuration properly. I was handling it, but I was not processing the request correctly in that the USB device was not sending an ACK when this Set-Up Request came in. I eventually found this out by using a hardware USB protocol analyzer.
There were other issues that I ran into, but these were the two biggest ones that took me quite a while to figure out. The other issue I had to worry about is big-endian and little-endian, Freescale 9S12 vs USB data format (Intel), respectively.
I ended up building the USB device driver similar to UART device drivers I had done in the past. I have posted the code to this at the following URL.
http://lordhog.wordpress.com/2010/12/13/usb-drive
I tend to use structures a lot, so people may not like them since they are not as portal as using #defines (e.g., MAX3420_SETUP_DATA_AVAIL_INT_REQR 0x20), but I like them since it makes the code more readable for me. If anyone has questions regarding it please feel free to e-mail and I can try to give some insight to it. The book "USB Complete: The Developer's Guide" was helpful, so long as you knew what areas to concentrate on. This was a simple application and only used low-speed USB.
While writing a device driver for any interface (USB, Parallel port, etc...) the code needed to be developed would depend upon whether there is any Operating System(OS), RTOS running on that Processor/Micro controller.
e.g. if thats going to run say WinCE - It will have its own Driver development Kit , and steps to be followed in the device driver development. Same for any other OS like Linux, symbian.
If its going to be a plain firmware code(No OS) which is going to control the processor/microcontroller, then it's a different situation altogether.
So based on either of the above situation u are in, one needs to read & understand:-
1.) The Hardware Specification of the processor/micro controller development board - Register files, ports, memory layout, etc.
2.) USB spec
3.) Couple of pointers i found quickly. Google shud be ur friend!
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ - Linux USB device driver
http://www.microsoft.com/technet/archive/wce/support/usbce.mspx
-AD
I've used an earlier edition of USB Complete by Jan Axelson. Indeed very complete.
From the editorial review:
Now in its fourth edition, this developer's guide to the Universal Serial Bus (USB) interface covers all aspects of project development, such as hardware design, device firmware, and host application software.
I'm curious, why did you pick the 9S12? I used it at a previous job, and was not pleased.
It had lousy gcc support so we used Metrowerks
which may have been okay for C, but often generated buggy C++
had a lousy IDE with binary project files!
The 9s12 was also slow, a lot of instructions executed in 5 cycles.
Not very power efficient, either.
no barrel shifter, made operations that are common in embedded code slow
not that cheap.
About the only thing I dislike more is an 8051. I'm using an ARM CortexM3 at my current job, it's better than a 9S12 in every way (faster clock, more work done per clock, less power consumption, cheaper, good gcc support, 32-bit vs. 16-bit).
I don't know which hardware you're planning to use but assuming that's flexible, STMicro offers a line of microcontrollers with USB/SPI support and a library of C-code that can be used with their parts. -- I've used their ARM7 series micros for years with great success.
Here is an excellent site maintained by Jonathan Valvano, a professor at the University of Texas. He teaches four courses over there (three undergraduate, one graduate), all are about using a 9S12 microcontroller. His site contains all the lecture notes, lab manuals, and more importantly, starter files, that he uses for all his classes.
The website looks like it's from the 90's, but just dig around a bit and you should find everything you need.
users.ece.utexas.edu/~valvano/
Consider AVR for your next MCU project because of it's wonderful LUFA and V-USB libraries.
I'm working on a project using the Atmel V71. The processor is very powerful and among lot's of high end connectivity offered on chip is a USB engine that will do device or host modes for 480 Mhz or 48Mhz (not USB 3.0). The tools are free and come with a number of host and device USB example projects with all the USB stack code right there. It supports 10 end points and all the transfers are done via DMA so you have most of the processor horsepower available for other tasks. The Atmel USB stack works without needing an RTOS