|
|
By Oleg Mazurov  Layout closeup
Release candidate 1 boards has been received, built, tested, and came out green wire free – at last! I placed an order for a small batch with board house and expect PCBs to be available in a couple of weeks. I am making second call for beta testers – if you write code and/or blog, drop me a line with a link to your blog and your voltage preference for the shield – 3.3V or 5V. I have more 3.3V boards left from prototyping so naturally people requesting 3.3V boards will have more chances to get one.
Updated Eagle and Gerbers are available in Downloads section. If you don’t have Eagle, here is the PDF of the schematic. Please make sure you are not using scematic posted in one of the previous articles – there are quite a few changes.
In this article I want to give an overview of the board and it’s features. I’d like to start with most complicated part, which is power configuration. First of all, the USB core part of the shield (MAX3421E) requires 3.3V to function. Second, bus-powered USB peripheral requires 5V on Vbus. However, to use self-powered USB peripheral we only need to connect 3.3V to Vbus to be able to see speed-setting pullup resistors. Consequently, for digital camera control applications, shield can be mated with 3.3V Arduino (like Sparkfun‘s Arduino Pro) with no additional power supplies.
Continue reading Arduino USB Host Shield build log. Part 4.
By Oleg Mazurov  USB Host Shield prototypes Making functional 5V version of a shield proved to be difficult. I was hoping to publish a release after building previous protos. However, it turned out that together with fixing old errors I managed to make several new ones and also missed a couple from previous prototyping cycle. So, in order to produce a proto containing less errors than a previous one, I spent a great amount of time checking everything I could think about, writing test code, running those tests against prototypes, and then repeating them on all possible mixes of available Arduinos and voltages.
Also, I found that USB-B connector on Duemilanove shorts GPIN contacts on a shield. Cover top of the connector with piece of Scotch tape, if you haven’t already.
Today I placed an order with BatchPCB to what I call “Release candidate 1”. I am hoping this is a design which will be released when I get it back in 3 weeks or earlier( BatchPCB is getting faster ). Also, I forked previous repo containing Arduino libraries, the current development is now contained in USB_Host_Shield. I removed Vbus power control support since it’s not implemented on a shield and added functions for GPIO pins read/write. I’m freezing previous repository to support old sketches.
While waiting for PCBs I will continue working on HID code for the shield and also write a library to control LCD/buttons via GPIO pins. Stay tuned.
Oleg.
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.
|
|
