[EDIT]This article covers revision 1 of the shield. Current revision (2.0.x) is slightly different and works under different software. The following test routine shall be used to test the board and generate test signals.[/EDIT]
Making electronic devices requires close interaction with parts – reversing supply polarity, overloading inputs, and inadvertently shorting pins with test leads. Consequently, occasional destroying of parts is natural and shall be anticipated. I have been in correspondence with several electronics enthusiasts helping them getting their shields fixed and since their problems look similar to what I see when doing post-manufacturing quality control I decided to share my testing procedure along with some pictures.
In the past, it was customary to include schematic with every electronic device documentation. Complex devices, such as oscilloscopes, spectrum analyzers and other test instruments used to have service manuals containing detailed calibration and repair procedures. At some point, service manuals and schematics disappeared from the documentation for various reasons – equipment users were left to deal with manufacturer’s support or rely on their own reverse engineering skills. With open source movement and general understanding that sharing information is beneficial, manufacturers resumed publishing schematic diagrams of their creations. This article presents next logical step – a service manual for Arduino USB Host Shield, sort of.
Much of the testing is performed using board test sketch, available from examples section on github. Two files are necessary – board_test.pde and board_test.h containing diagnostic messages. The sketch tests 4 major parts of the circuit – SPI interface, general purpose input/output pins (GPIO), quartz crystal oscillator, and finally USB SIE. The main loop is written so that any test can be turned off if necessary by commenting out a single line. GPIO lines are checked using a loopback adapter – a thing that connects GPIN0 to GPOUT0, GPIN1 to GPOUT1, and so on. This test is made optional – if you don’t connect GPIO lines as described, the test will print an error message and continue with the next test. Also, GPIO test is placed between short and long SPI tests. The reason for this is that due to MAX3421E internal organization both short SPI test (reading REVISION register) and GPIO read/write doesn’t require working crystal oscillator, whereas long SPI test (reading/writing any other register) will fail and stop if crystal is defective. Therefore, when I see short SPI and GPIO tests passed and long SPI test fail I know that it’s actually a crystal which is dead, not SPI.
In addition to board test program, you will need a multimeter with thin sharp test leads to measure voltage and resistance between board elements. Some of them are quite small so a magnifier is also handy. Certain steps of the test procedure call for time-base instrument. Modern digital mixed-signal oscilloscope is the best choice, however, since very few people can afford one, a method of visualizing SPI traffic with plain analog oscilloscope will also be demonstrated. Logic analyzer is handy, but optional. For testing USB transactions you will also need some sort of device connected to shield’s USB connector. I usually use USB flash drive as a test device.
The article as well as board test program is written for worst-case scenario, i.e., shield which was built from scratch or came from major rework like MAX3421E replacement due to applying 5 volts to 3.3V pin. The test program works the same way with all four configurations, however, manual tests are shown only for “Simple” configuration, i.e. one with level translators and receiving both 3.3V and 5V from Arduino Duemilanove or similar (no DC-DC converters). Testing other configurations is slightly different and will be noted in the text. Also, “Minimal” configuration calls for specific type of test device – I use digital camera.
I’ve been working lately on improving manufacturability of my products. As a first result, I’m changing board revision of USB Host Shield to 1.21. The main difference between revisions 1.0 and 1.21 is level converters and jumpers in SMT packages. Picture on the right shows the very first panel of rev.1.21 board fresh from the oven.
Functionally, the board is the same. However, schematic has changed a little in part where control signals go through level converters. Therefore, it is important to use the right schematic when troubleshooting or hacking the shield. Downloads section has been rearranged and documentation for both variants added and labeled. I also posted closeup pictures of new board in store listings for the shield and bare PCB. I still have several rev1.0 boards available, they should be all gone by the end of the week so when you buy a board this week, you may get an old version. If you have a preference, let me know.
Lastly, from now on USB Host Shields comes bundled with stackable headers, the famous 4uconn part numbers 18688 and 18689. “Bundled” here means that by default they come in a bag, un-soldered. However, if you prefer, I can solder them for you – send me an e-mail after the purchase stating that you’d like your headers soldered and indicate the direction, female or male side up.
This is the third part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:
Part 3. Develop the Bluetooth USB and HCI interface used in the support of the Wiimote and PS3 game controller, and also some utilities needed to analyse and configure these devices.
1. USB Interface
As before, we first look at the descriptors for the USB dongle using the USB_Desc sketch. The result is:
This is the second part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:
Part 2: Develop the USB interface to the PS3 controller
1. USB Reduced Hosts
Full USB hosts such as Windows and Linux based computers can manage a large variety of different USB devices and load appropriate USB drivers for each device. There is an enumeration or discovery phase where the host gathers information on the attached USB device and uses this information for the driver selection and configuration. In small embedded applications this is not possible or required to support this variety, so the application usually only supports a few devices, often only one. This means the discovery process can be much reduced since the results are already known. This will reduce the memory required for the application by hard coding the device configuration into the application.
Though the configuration will be hard coded, we still need to initially gather the information from the device itself and other sources.
The existing device drivers mentioned above for Windows and Linux are important in our development process. The Windows drivers are usually complete, but not available in source form. Linux drivers are available in source form, though not always as complete. Device manufacturers are usually very reluctant to provide information required to build a driver or embedded application. So we rely on copying Linux code or “sniffing” Windows code to give us guidance.
1. Background
These articles describe how to interface PS3 and Wiimote game controllers directly onto the Arduino using the USB Host Shield. These controllers have not previously been directly connected to an Arduino due to the USB and Bluetooth interfaces and protocols used, and their relative complexity. The game controllers are a good match to the capabilities of the Arduino, and to the imagination of Arduino users, they have not only buttons and joysticks, but also motion sensing, and other goodies which deserve to be in the hands and ideas of Arduino users. Also I hope these articles provide some guidance for people to develop other USB host and Bluetooth applications for small embedded processors.
Arduino already comes in versions which have USB and Bluetooth interfaces, but these are not suitable for our chosen game controllers. When used in USB mode, the PS3 controller is a USB device and needs to talk to a USB host. The normal Arduino USB interface is also a device, so not compatible. When in Bluetooth mode, both of these game controllers use the Bluetooth HID protocol and this is not compatible with the commonly used Bluetooth modules which support only the RFCOMM Serial Port Protocol. Arduino users have successfully used a PC as an intermediary between the game controllers and the Arduino, so the PC is host to both devices.
These articles were written by Richard who is new to the Arduino, blogs, github, libraries, etc, so please give me any help and feedback on how I might improve or correct these articles and software.
PS3 controller connected to Arduino USB Host Shield
Another HID example has been added to Github repository of USB Host Shield for Arduino (which you can purchase in my store) . Richard Ibbotson sent me this nice piece of code along with some pictures. He also posted a short description of his sketch in comments section:
I wrote a sketch for the interface of the PS3 controller over USB. I have two controllers, one Sony and one Madcatz wireless with a USB dongle. Both of these work fine to the USB host shield. I only made one minor change to the library to increase the NAK count. The sketch tests all the function, buttons, joysticks, accelerometer/gyro, leds and rumble. This is not yet under bluetooth just USB. I can set the host bluetooth adddress on the controller though which is needed for bluetooth pairing.
Did not make much attempt to reduce code or data size, so only have about 4K of program space and 240 bytes of data space left, but sketch is pretty long. The actual PS3 part is very small and could be made to a small library.
Next is to move to the bluetooth part, from what I have found on the direct USB, I am pretty confident this will fit even on the 168.
PS3 controller support opens some very interesting possibilities. Not only can it be used as a normal “joystick plus buttons” type of control, but you can also utilize it’s accelerometer/gyro. With wireless variant of the controller all kinds of very powerful radio control are possible. Who is going to be the first to make a mechanical dog, which follows you around and brings back the controller when you throw it away?
If you want to try the sketch, make sure you have the latest library code as well – there are some small but important changes made recently in NAK handling.
MadCatz wireless controller to USB Host Shield
Wireless mini keyboard connected to USB Host Shield
Here is an interesting project which uses MAX3421E breakout board to connect XBox360 wireless controller to old Nintendo Entertainment System. Francois Gervais used Cortex-M3 as an interface between Nintendo and a game controller. There are two other videos showing the details of the setup – check them out as well.
I am continuing on topic of using USB Host shield to drive USB peripherals started in the previous article. The code presented here performs keyboard polls, character translation and management of “LOCK” keys – NumLock, CAPSlock and ScrollLock.
A keyboard is hard to use if results of typing can’t bee seen, so my first step was to add an output device. Even though HD44780-compatible character LCD can be driven with Arduino pins, I wrote a little library which uses GPOUT port of MAX3421E for LCD control. This library is now a part of USB Host Shield repo on github. I used LCD high-level routines from official Arduino distro and developed low-level functions specific to MAX3421E hardware, as well as LCD initialization. Since function syntax and behaviour (and source code ) is identical to official LCD functions, the user manual is already written and can be found in the library reference by title LiquidCrystal. The only difference is in the constructor; since only 4-bit mode is possible and only one pinout is supported, Max_LCD constructor is not accepting any parameters. The pinout of LCD connections to GPOUT is given in the Max_LCD.h file; see also title image of this article.
[EDIT] This post is about legacy product which is no longer supported. Visit USB Host Shield project page for up-to-date information[/EDIT]
Arduino USB Host Shields are in the store. If you are not yet familiar with the project, please browse “USB Shield” category of the site and read the articles. In short, the purpose of this shield is to add USB Host interface capability to Arduino. The software libraries for this shield currently support control and bulk-in transfers, while bulk-out transfer is in the works. Access to GPIO pins of MAX3421E is also supported. Sketch examples, demonstrating USB device control queries and polling USB keyboard, are published. More code will be developed in the future.
At present, four configurations of the shield are available. The first one, called “Minimal”, contains USB core components only. It is compatible with 3.3V Arduinos, such as Arduino Pro from Sparkfun. Also, since no 5V is available, only communication with self-powered devices is possible. Moreover, not every self-powered device would work in this configuration. For unknown reasons, some external hard drives refused to answer until VBUS voltage was raised to 5V. On the other hand, all printers and digital cameras that I and several beta-testers tried worked fine as well as other people’s external hard drives. “Minimal” configuration is the best one for battery-powered projects since 3.3V Arduinos consume less electricity.
The time has come to start using the code to communicate to peripheral devices. There are many devices which work well with microcontrollers. HID devices, such as keyboards, joysticks, and Radio Controller look-a-likes are useful and not too difficult to implement. Another good application of embedded USB host is digital camera control. Communication using Bluetooth and WiFi peripherals are also a possibility.
Today I’m going to show how to communicate with USB keyboard. Standard USB keyboard belongs to a class of devices, called HID (Human Interface Device). The format of data generated by HID device is quite flexible and each device stores it’s data definitions in structures called Report descriptor and Physical descriptor. Generally, to work with the device, report descriptor has to be retrieved and parsed. Because of HID flexibility, a universal HID driver will take many many lines of code. Luckily for us, if all we need is to talk to the keyboard, there is an easier way.
