|
|
By Oleg Mazurov  USB Isolator [ Update ] I now have bare PCBs and parts kits of this design for sale in store, as well as assembled and tested boards.
We all love USB. It is well supported across many platforms, easy to work with, and even able to provide a little power to the peripheral. However, the quirk of USB is that peripheral must share ground line with the host. The host is usually a PC and very often a desktop, which means it’s USB ground is electrically connected to earth ground in the wall outlet. With PC-based test instruments, like oscilloscopes, logic analyzers and such, It works fine most of the time, but not always.
There are situations when we prefer our ground separate. It happens when PC/earth ground is too “dirty” and we don’t want our circuit to pick up this dirt. Sometimes our device’s ground is not too good or even dangerous if connected to earth ground. Sometimes we are trying to overcome ground loops. Sometimes, we want our oscilloscope to behave like a multimeter, i.e. being able to show voltage drop between any two arbitrary points of the circuit. In any of this cases we want our USB data and ground isolated from the host.
Isolation improves common-mode voltage, enhances noise rejection, and permits two circuits to operate at different voltage levels. It also tends to save test equipment, as well as PC itself. It is also very useful in industrial setting, that probably why industrial USB isolator devices cost between $200 and $400. While looking for a solution for my lab, I found interesting USB isolator part, recently released by Analog Devices, and decided to give it a try.
Continue reading USB Isolator.
By Oleg Mazurov  USB Host Shield prototypes I finished building Arduino USB Host Shield prototypes. Functionality has been tested, errors found, fixed, and 1.0rc boards ordered. Title picture shows two prototypes, 3.3V sitting on top of Arduino Pro from Sparkfun and 5V on top of Duemilanove (bought at Sparkfun also).
As you can see, the biggest amount of errors has been made in 5V part of the circuit. To be honest, I’m not quite sure all of them are fixed. At some point I decided to stop messing with temporary fixes and order a board – if anything is still not right, I will find out later.
One of the goals of this build was to test 3.3V to 5V DC-DC converter (schematic). You can see it populated on 3.3V shield. It can be used on 3.3V-only systems to provide power to Vbus. This converter is designed around LTC3426, delivers ~700mA (slightly more than needed for powering Vbus) and runs cold with 90-94% efficiency. Output ripple was measured at 25mV. Note of caution: you should expect stability issues when powering such setup from USB (for example, during development) – in one of my tests Arduino was regularly rebooting during USB drive connect.
Continue reading Arduino USB Host Shield build log. Part 2.
By Oleg Mazurov  5V to 3.3V converter
Parts has arrived yesterday and I started test-building my USB Host Shield prototype PCB to check functionality and buildability. Since design is not final, I’m not publishing Eagle files yet – they will be online as soon as I get all errors fixed. In the meantime, the PDF of the schematic diagram is available.
One of the goals of this design is to make it compatible with both 5V and 3.3V Arduinos. Since MAX3421E is 3.3V part, I added some extra circuitry to provide 5V compatibility.
I started my testing by building 5V to 3.3V converter piece to check parts values and circuit layout. The circuit is located in the upper-left corner of the schematic and in the lower-right corner of the board. Please also take a look at the title picture if you haven’t already to see the layout. This converter comes in handy if, for example, you are using 5V Arduino and/or need to provide Vbus power for bus-powered peripheral and want to use this supply to power the shield/Arduino also. Converter is rated for 600ma, enough to power both MAX3421E and Arduino, if necessary.
Continue reading Arduino USB Host Shield build log. Part 1.
By Oleg Mazurov  Arduino USB Host Shield PCB
While developing Arduino code for MAX3421E USB Host controller I was thinking about making a shield for it. Sure, breakout board riding on top of protoshield works just fine, however, some people don’t like the wire clutter. Additionally, since many Arduinos are 5V devices, level translation may be necessary. I was playing with different configurations, and routed a draft prototype to build and see how it would look like. I received PCBs today from BatchPCB – just in time before the weekend.
In addition to MAX3421E with accompanying parts, the shield contains level translating logic for all signals and GPIN/GPOUT ports, and 3.3V to 5V step-up and 5V to 3.3V step-down converters. I decided to use DIP packages for level translators – this way if translation is not necessary, the PCB can be simply modified with jumper wires.
I’m going to start building/debugging this board today and produce final version in 2-3 weeks. After that, the plan is to order a batch of boards, build them and send to beta testers. If you want to participate in testing, leave a comment and I’ll put you on a list.
Oleg.
By Oleg Mazurov  Get device descriptor trace I finished porting USB transfers from PIC C to Arduino C++. There is now a USB class in the repository. Two main types of USB transfers – control and bulk, are implemented. If you want to know more about USB transfer mechanics, take a look at this article. The code was written to work on Microchip PIC, however, the Arduino code is almost identical.
Since we now have tools to talk to USB device, let’s start using them by looking at USB descriptors. In order for sketches from this article to work you need to copy current repository contents ( *.cpp and *.h files ) to a sub directory in your Arduino hardware libraries directory. In addition, don’t forget to supply 5V to Vbus and connect a USB device, such as flash drive or mouse to USB connector of a breakout board.
First sketch demonstrates access to device descriptor. Device descriptor is the first descriptor that the host retrieves from the device during enumeration. The information which host needs is device endpoint zero maximum packet size. In this example, maximum packet size is already set by a function in USB class, called “Task”. In addition to maximum packet size device descriptor contains other information, used during device configuration.
Continue reading Arduino USB Host – USB Descriptors.
By Oleg Mazurov  MAX3421E on a protoshield I started porting my PIC USB host code to Arduino platform. There is now a repository on GitHub. Right now it contains a single class of functions talking to MAX3421E. This is not enough to support full USB host functionality, but enough to get started. To follow examples given in this article, create a sub-directory in your Arduino hardware libraries directory and copy MAX3421E*.* files from the repository into it.
MAX3421E talks to Arduino via SPI, so you will need Arduino SPI library. SPI uses pin13 – a pin also used to blink LEDs. Some Arduinos even have this LED hard-wired to pin13. My Arduino has it, and it co-exists peacefully with MAX3421E, however, there is no guarantee it will work on others. It would depend on current drawn by the LED. If you have problems communicating with MAX3421E and/or you can’t see SPI clock on this pin with your oscilloscope or protocol analyzer, try to disconnect the LED and see if it changes anything.
Picture on the right shows the final arrangement. The breakout board sitting on top of protoshield is a 3.3V part. Since I’m using 3.3V Arduino Pro from Sparkfun, no level converters are necessary. Look at the previous article for the closeout picture and schematic. The breakout receives power from Arduino.
Continue reading Arduino USB host – First programs.
By Oleg Mazurov  MAX3421E on a tray
I just took delivery on a batch of MAX3421Es from Maxim. They are available for sale in the store for $8.00.
The MAX3421E makes the vast collection of USB peripherals available to any microprocessor, ASIC, or DSP when it operates as a USB host. For point-to-point solutions, for example, a USB keyboard or mouse interfaced to an embedded system, the firmware that operates the MAX3421E can be simple since only a targeted device is supported.
This controller is supported by open source firmware that I’m developing for 8-bit microcontrollers, including PIC18s and Arduino.
By Oleg Mazurov  MAX3421E on a keyboard Human interface device AKA HID is likely the most simple class for USB host to interact with. Reports are easy to parse and timing is not critical. In addition to that, HID standard defines simplified variety of the protocol, called “boot protocol”.
Modern USB keyboards, as well as mice, support boot protocol. It was designed to be used by PC BIOS during POST setup. No report parsing is necessary; as soon as device is put into configured state, it’s interrupt IN endpoint starts generating fixed-format 8-byte packet. This packet contains basic information about peripheral events. For keyboard, such packet contains information about modifier keys (control, shift, alt ) plus keys pressed. Mouse would give state of up to three buttons, plus amount of travel in X and Y direction since last poll.
Look at the code, function HIDMprobe or HIDKprobe. This function is called during enumeration to configure device which was just attached. By default, HID peripheral is configured to talk report protocol. In order to change it to boot protocol, host has to send “Set protocol” request with single data byte set to 0. After this is done, device starts generating interrupts( i.e., host can start periodically polling interrupt endpoint for new data.
It is worth mentioning that not all HID devices support boot protocol. Interface subclass set to 1 indicates that boot protocol is supported for this interface.
The first byte in 8-byte packet from a keyboard contains states of modifier keys – Control, Shift, Alt, and Windows. The next byte is reserved, it’s state means nothing to us. Last 6 bytes is a keyboard buffer – it contains so-called HID codes of keys being pressed since last poll.
Continue reading Lightweight USB host. Part 6 – introduction to HID.
By Oleg Mazurov  MAX3421E and mouse All data on USB bus is transferred under host control. Even though some transfers are called IN and some other OUT, they all start at the host. There are four types of transfers, the most interesting of which is control transfer. This type of transfer is used all the time in communication with every class of devices. In this article, I give a short description on programming control transfers.
Control transfer consists of three steps( or stages ): setup, data, and status. Some of them carry necessary data in setup packet itself and don’t have data stage at all. Good example of such short request is “Set address” – the information to transfer is just one byte and is sent by filling a certain setup packet field.
Even though USB specification defines several different destinations for the transfer, such as device, interface and endpoint, on the lowest level each packet address consists of two parts – device and endpoint. Some endpoints are IN or OUT only. Other, such as “default control pipe” AKA endpoint 0, are bi-directional. Before each transfer can be sent out, peripheral address must be loaded into MAX3421E PERADDR register.
Continue reading Lightweight USB Host. Part 5 – control transfers.
By Oleg Mazurov  Arduino USB Host Shield prototype
I have been thinking about expanding ways to use my recently conceived USB Host controller based on MAX3421E. Nice and very popular AVR development platform called Arduino looked like logical target. After quick Internet search, I went to SparkFun to pick up an 3.3V 8 MHz Atmega168 Arduino Pro, a protoshield, and USB to serial cable. After checking that everything works fine together, I populated a MAX3421E breakout and soldered it on the top of protoshield ( see schematic ).
I wanted to make a quick prototype and not worry about level translation for now. Arduino Pro is 3.3V and is able to talk to MAX3421E directly. The circuitry to adapt this shield for 5V Arduinos will be added later. This is going to be interesting since MAX3421E is not only a USB controller but also a port expander. It provides 8 general purpose outputs and 8 inputs, which can be configured as interrupt sources, all accessible via SPI. I’m using 1 input and 1 output for Vbus tracking, the rest is available for general use.
In order to use Atmega’s SPI peripheral I imported SPI library from Arduino playground. The default initialization will work. Below is the quick sketch that I wrote to make sure that MAX3421E is talking. Here I’m defining pins, setting initial state, and configuring MAX3421E SPI to full-duplex mode. This is not the right way to initialize MAX3421E, however, the beauty of this controller is that its SPI subsystem is separate from the rest of the chip and will work in any state as long as power is applied. No fancy resets are necessary.
Continue reading Arduino USB host – Pre-prototyping.
|
|
