Shopping Cart

Posts

A library to interface Arduino with XKeys USB keyboards

XKeys backlight control

XKeys backlight control


Thomas Strausbaugh contacted me a while back with a project involving XKeys – a series of HID keyboards with extended functionality. Tom also offered to lend me XK-16 Stick; after receiving it I made a small addition to the USB Host Shield library and soon after Tom e-mailed me back asking to test his code. The picture on the left shows one of the example sketches, a “blinky” of sorts, where all backlights are sequentially turned on and off.

Xkeys can be controlled by sending proprietary (but well documented) output report which doesn’t follow standard HID report format. By sending this report it is possible to turn LED integrated into each key on or off, change light intensity, as well as switch the keyboard on the fly between mouse, joystick, and keyboard emulation modes. Larger keyboards have some additional features. In addition to that, products are very maker-friendly; for example, a manual for XK-16 Stick contains this:

Customization
The electronic design of the X-keys Stick is such that the stick may be cut off to any length after the second key. P.I. Engineering will perform this service in our lab for a fee including testing to maintain the warranty, or you may contact us for specific instructions if you wish to do it yourself.

The big disadvantage of Xkeys is price. However, if you want you project to look professional but don’t have much time to refine it, a good looking user interface can be produced very quickly with Xkeys.

Tom’s library implements programmer’s interface to extended keyboard features (sans cutting). Easy to use functions are provided enabling direct access to programmable features of each key or LED. Thank you very much, Tom!

Running USB Host code on Digilent chipKIT board

chipKIT Uno32 with USB Host Shield

ChipKIT Uno32 with USB Host Shield


Andrew Kroll and I were talking a lot about running USB Host Shield at higher SPI speeds. We were discussing one peculiar case of seemingly defective SPI master module and were needed full sized shield-compatible host board with fast SPI to check our theories when I realized that I have two Digilent ChipKIT Uno32 boards sitting in my ever expanding “to-do” pile of projects. I sent one to Andrew and soon he made a port which compiles under Digilent’s IDE and runs on chipKIT boards, although we only tested on Uno32 (rev.B).

It should be noted that another good candidate for the host board capable of high-speed SPI would be Arduino DUE. It is supported by the library and presumably runs at up to 24 MHz SPI speed with full-size shield. Incidentally, none of us have a DUE so we can’t test. Donations are gladly accepted.

The chipKIT support is currently in beta. At the moment, the only code example I have verified is Board QC routine – a program I’m using to test the shields before selling them to people. The port lives in xxxajk branch. Making other examples work should be a simple matter of (quoting Andrew) “including the right SPI.h”. Indeed, nothing in the library relies on SPI speed so increasing it would simply allow data to be sent faster.

In this article I will show how I modified a standard full size USB Host shield rev.2.0 to run on chipKIT Uno32 board at high SPI speed. I was able to run up to 20 MHz; unfortunately, the next available SPI rate on Uno32 is 40 MHz which is too high for the MAX3421E chip. The modded shield can be seen on a title picture (click on it to make it larger). Uno32 is 3.3V board; even though the inputs on PIC32 on-board MCU are 5V tolerant and it is likely possible to run the shield as-is I removed the level shifting ICs, which are unnecessary when interfacing the shield with 3.3V boards and could decrease error margin. Also, the RESET line on the ICSP connector on Uno32 has been replaced with CS by Uno32 designer, perhaps to make it look more like SPI, so I also needed to disconnect and reroute it. Here is the implementation, step-by-step.

Continue reading Running USB Host code on Digilent chipKIT board

PS4 controller support for the USB Host library

The PS4 controller is now also supported via Bluetooth. It uses the same API as the other libraries I have written, so if you have used them before, then you should be quite familiar with it.

The example code is available at Github: https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/Bluetooth/PS4BT/PS4BT.ino.

For more information take a look at my blog post: http://blog.tkjelectronics.dk/2014/01/ps4-controller-now-supported-by-the-usb-host-library/. This explains how to pair with the controller and have some background information as well.

You should also check out the readme which will always have the newest information available.

That is all for now. Hopefully this will be useful to anybody out there that wants to use the PS4 controller with the library.

Update 18. January 2014
A USB version of the library is now also available.

Bluetooth HID devices now supported by the USB Host library

PS3 keyboard

PS3 keyboard

I am glad to announce that Bluetooth HID devices are now supported by the USB Host library. The library already supports PS3 and Wiimote controllers, but now you are also able to use Bluetooth mice and keyboards with the library.

An example is available at the following link: https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/Bluetooth/BTHID/BTHID.ino.

I have personally tested it with a PS3 keyboard (see image), an Apple Wireless Keyboard and an old Bluetooh mouse from Microsoft and all of them works fine.

For more specific instructions on how to use the library I recommend taking a look at the blog post at my own blog: http://blog.tkjelectronics.dk/2013/12/bluetooth-hid-devices-now-supported-by-the-usb-host-library/.

Feel free to post a comment below if you got questions or got problem with a specific device and I will answer as fast as possible.

Teensy 3.0 now supported by the USB Host library

Layout of the Teensy 3.0

Layout of the Teensy 3.0

I am pleased to announce that the first ARM processor is now supported by the USB Host library. It is the Teensy 3.0 which features an 32 bit Cortex-M4 ARM processor running at up to 96MHz. This is a huge increase in speed if you are used to the Arduino Uno running at 16MHz.
The Teensy 3.0 is created by the Paul Stoffregen which is also a dedicated contributor to the Arduino IDE. If you are looking for a ARM based board for your next project, I recommend taking a look at the Teensy 3.0. A more detailed overview can be found at the official page.

To use the Teensy 3.0 with the library I recommend using the Mini variant of the USB Host Shield as it is much more compact and a bit cheaper too. Since the Teensy 3.0 is running at 3.3V no logic conversion is needed.
Note it is very important than you do not connect a 5V microcontroller to the Mini variant of the USB Host Shield, as this might damage the board. If you are planning to use a 5V microcontroller like the Arduino Uno I recommend getting the full sized version of the shield.

In order to use the Teensy 3.0 you will need to connect the Teensy 3.0 to the USB Host shield like so:

USB Host Shield Teensy 3.0
RESET 3.3V
GND GND
INT 9
SS 10
MOSI 11
MISO 12
SCK 13
3.3V 3.3V
GND GND

The images to the right shows both the pinout for the Teensy 3.0 as well as the Mini USB Host Shield.

Layout of the USB Host Shield Mini variant

Layout of the USB Host Shield Mini variant

Furthermore I recommend cutting the VBUS jumper and then soldering a wire from the provided pad on the USB Host shield. This wire can then be connected to the VIN on the Teensy 3.0. The USB Host shield will then get powered directly from the same USB port as the Teensy 3.0 and the VBUS will be 5V as required by most devices – note that you might need a separate 5V regulator depending on which device you are using with the shield, as it might draw too much current.
More information about how to modify the shield can be found at the hardware manual.

Also take a look at the guide for the other Teensy boards, as the wiring is almost the identical.

Hopefully this is just the first of many ARM based boards that is going to be supported by the USB Host shield library.
If you got any questions or comments, then feel free to write a comment below and I will answer as fast as possible.

Update
Both the Teensy 3.1 and Arduino Due is now also supported by the library.

Adding a display to a digital scale using Arduino and USB Host shield

Arduino reading digital scale

Arduino reading digital scale


I am the proud owner of Stamps.com Model 510 5lb digital scale. It is a nice little scale which works very well (much better than Stamps.com service itself) while attached to my workstation. The scale doesn’t have a display making any kind of standalone use difficult. However, since the scale is a USB HID device reading data from it should be as easy as from a joystick and Arduino board should be adequate to provide a display function for it. To test this theory I made a simple setup consisting of Arduino UNO, USB Host shield and HD44780-compatible LCD display. I also wrote a small sketch which polls the scale and outputs the weight. The secondary objective of this project was to demonstrate LCD support in USB Host shield library.

For this project I used the following:

  1. An Arduino board. Standard size board, such as UNO, Duemilanove or Leonardo, will work
  2. USB Host Shield
  3. Toshiba HD44780-compatible LCD display, in 16×1 or 16×2 configuration. If you’re planning to use this sketch for something else, like data logging, the display is optional – all output from the scale is repeated to the serial port
  4. Stamps.com 5lb digital scale. Scales are standard HID devices with usage table 0x8d, therefore, scales from other brands may work as well with no or minimal modifications to the code
  5. USB Host library

The example code is also hosted at github, as well as in ‘examples’ section of the library under ‘HID’. It has been tested with Arduino IDE version 1.0.5.

In this project, the LCD is connected to the shield’s GPOUT pins, as documented in max_LCD.h header file. In addition to data lines, 5V and ground must also be connected to the shield’s 5V and GND terminals; the RW pin must be grounded – I do it on the LCD itself. In order to see the characters, the display must be biased – a 5K-10K pot with wiper on Vo and other two pins on 5V and ground will provide contrast adjustment.

Continue reading Adding a display to a digital scale using Arduino and USB Host shield

VBUS power control on USB Host shield

Power switch populated

Power switch populated

About a month ago I started shipping USB host shields built on PCB bearing revision number 2.0.1. On this PCB I added a new feature, suggested by Andrew Kroll – a VBUS power switch. The board comes with power switch unpopulated and if you don’t care about this feature it can simply be ignored. However, if you do care about power control, read on.

The ability to turn VBUS on and off at will can be very beneficial. In battery-powered projects the run time can be significantly increased by powering on USB device only when needed. Some other devices can’t even be initialized reliably without a powercycle. Also, many power switches incorporate current limiting circuitry allowing VBUS overload detection and prevention.

An example of populated power switch is shown in the title picture (click on it to make it larger). A is a power switch IC (in this case, Micrel MIC2004). B is 0.1uF ceramic capacitor in 0603 package. C is a wire from MAX3421E GPX pin to the ENABLE pin of the power switch. Finally, D is VBUS Power jumper which needs to be opened, as pictured. Current revision of USB Host 2.0 library is needed to support power control.

Board Layout

Board Layout


Next picture will be used to explain the details of the power control circuitry.

  • Arrow A points to the jumper which needs to be cut open
  • Arrow B shows the position where 0603 0.1uF ceramic capacitor needs to be placed
  • C and D show the places for the power switches (only one switch is needed). Many switches packaged in SOT23-5 and SOT23-6 use this footprint, use On Semiconductor NCP380 as a reference. Also, some other 5 pin switches, such as Maxim MAX4793 and Micrel MIC20xx, will work while placed on SOT23-6 footprint, as shown on the title picture.
  • Certain switches, such as 6 pin NCP380, allow for adjustable current limit. The position for current setting 0603 resistor is marked ILIM – for the value of this resistor consult the datasheet for the part you’re planning on using
  • Many switches provide FAULT pin to signal various fault conditions, like output overload, reverse votage, or over-temperature. The pin is typically active low open drain type. It is broken out to a pad labelled VBUS OVL. The signal can be used in several different ways. A LED with a series resistor can be connected across VBUS OVL and a power rail. Also, it can be connected to a MCU input. In this case, a position labelled 10K should be populated with 0603 resistor, typical value is 10K. The other (upper) end of the resistor is connected to 5V rail with a trace which is placed under the letter K; if 3.3V level signal is desired, cut the trace and solder the upper end of the resistor to the 3.3V rail.
  • The power control signal is labelled VBUS EN. The library uses GPX pin for vbusPower() and Init() functions. There is also a variant of Init() function which will hold the VBUS off for the number of milliseconds passed to it as a parameter. See usbhost.h file for details. Also, testusbhostFAT.ino demonstrates usage of powercycling Init().


Continue reading VBUS power control on USB Host shield

GitHub repository for USB protocol traces

Beagle Analyzer USB hub  trace

Beagle Analyzer USB hub trace


I’m the proud owner of Totalphase Beagle USB 480 protocol analyzer. It helps tremendously in debugging USB code and the software which translates binary traces into human-readable form is free allowing sharing the trace files. Some time ago I needed to capture and share analyzer traces of certain Bluetooth dongles with developers of USB Host Shield 2.0 library. Instead of sharing the traces privately I decided instead to put them into another GitHub repo for everyone to see and learn.

At the moment, the repository contains just a handful of Bluetooth traces, captured on Windows and Linux machines. I will be expanding the repo with other interesting traces generated during my development. Also, if anyone wants a trace from a device not already in the repo – just ask.

Enjoy,
Oleg.

Mass Storage Support for USB Host Library 2.0 released!

Mass Storage

Mass Storage

The code supporting USB Mass Storage Class of devices has been added to USB Host Shield 2.0 library and is available to download on GitHub. Mass storage devices include USB Flash drives, memory card readers, external hard drives/CD-ROMs, smartphones/tablets, and some others – almost anything that shows as a drive while connected to a PC (exceptions are digital cameras as well as some phones pretending to be digital cameras). Andrew Kroll (who made this release possible) – thank you very much!

At present, the code example, also featuring Andrew’s FAT and extended memory implementation, can only be run on “big” Arduinos such as Mega and Mega 2560. Another FAT implementation, developed by Alex Glushchenko, is being tested – there is a slight possibility that at least some functionality can be demonstrated on a regular UNO board. On the other hand, the mass storage component can be used without a file system by simply reading/writing physical sectors; this approach can save a lot of memory. The documentation for the mass storage class code is available here.

Many hours has been spent testing the code; it should work with any device which claims to support “mass storage bulk only” transport. While newer (less than 5 years old) won’t cause any problems, older ones could be finicky. If your device shows odd behaviour with this code, please let me know – I will trade it for the good working one.

Enjoy!

Oleg.

Running multiple slave devices on Arduino SPI bus – data formats

Bit reversal code

Bit reversal code

This is Part 3 of 3-part series of articles. Part 1 talks about ways of tweaking SPI code while Part 2 talks about hardware modifications.

After finishing hardware modifications for my three-SPI-device setup I started coding and hit a snag. Any device would happily work by its own, WiFi and SD were also happy together, however, adding NFC Shield to the mix would disable other two. If I moved NFC initialization to the beginnig, other two devices would work but NFC would not. At the same time, if a device was just present on a bus and not initialized, other two devices were not affected. It became clear that initialization itself was the source of error.

Seeedstudio NFC Shield uses NXP PN532 transmission module. This module supports several communication interfaces, namely SPI, I2C, and HSU. In SPI mode the data format is ‘LSB first’, i.e., transmission starts from bit 0. Such format is uncommon; all other SPI shields I’m aware of – Ethernet, WiFi, USB Host, etc., are using ‘MSB first’ format – the transmission starts with bit 7.

A quick look into NFC library source code revealed the following line in PN532::begin() function:

pn532_SPI.setBitOrder(LSBFIRST);

This line sets the data format. In Atmega microcontrollers the default SPI data format is ‘MSB first’ – all other SPI devices don’t have to set it during initalization. Initial revision of PN532 code ( written by Adafruit ) was using software SPI and awkward bit order was dealt with in write() and read() functions. When Seeedstudio modified the code to work with hardware SPI, they just switched SPI to ‘LSB first’ format without much thinking, breaking compatibility with the rest of the world. Surely, when I commented out this line, NFC initialization stopped breaking WiFi. Predictably, NFC also stopped working.

Luckily for me, the SPI is pretty basic protocol and bit order setting in SPI controller doesn’t mean much. It really doesn’t matter how the bit order is set; if we need ‘MSB first’ for the majority of the devices we can initialize SPI in a normal way and then modify write() and read() functions for ‘LSB first’ device to serve it reversed bytes. This is exactly what I did. Below is modified version of Seeedstudio PN532 library (also presented on a title screenshot) – lines 6 and 16 perform bit reversing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/************** low level SPI ********/
/*Function:Transmit a byte to PN532 through the SPI interface. */
inline void PN532::write(uint8_t _data) 
{
  /* bit reversing code copied vetbatim from http://graphics.stanford.edu/~seander/bithacks.html#BitReverseObvious */
  _data  = ((_data * 0x0802LU & 0x22110LU) | (_data * 0x8020LU & 0x88440LU)) * 0x10101LU >> 16;
 
  pn532_SPI.transfer(_data);
}
 
/*Function:Receive a byte from PN532 through the SPI interface */
inline uint8_t PN532::read(void) 
{
  uint8_t data_ = pn532_SPI.transfer(0);
  /* bit reversing code copied vetbatim from http://graphics.stanford.edu/~seander/bithacks.html#BitReverseObvious */
  data_  = ((data_ * 0x0802LU & 0x22110LU) | (data_ * 0x8020LU & 0x88440LU)) * 0x10101LU >> 16;
 
  return data_;
}

After making these modifications, commenting out the ‘LSB first’ setting in the PN532:begin() and also modifying WiFi code to stay away from pin 9 (see this article for discussion) all three devices are happily working together without conflicts. The library mod for PN532 can be left there permanently – the chip will never know that it is communicating with “misconfigured” SPI host. I’m hoping Seeedstudio will fix their code eventually; in the mean time, if you have SPI compatibility issues, simply make code modifications presented in this article.

Enjoy,
Oleg.