Adding OTG and embedded host to 16U firmware

Is it possible to add USB Host and Host Negotiation Protocol ability to U16 firmware?

At least a minimalistic interface to mass storage devices would be a great advantage for Uno etc. since this would add the possibility of non volatile storage without burning out the internal flash by abusing code space as data space.

It would also mean extensive data logging volume would be possible on cheap ubiquitous USB flash devices would be readily available to stock Arduinos.

If there was some host functionality in the firmware, a USB flash device could be written to as a single block device without the need for file system support in the arduino sketch thus adding little overhead. Such an unformatted device could then be read by tools like dd command on Linux and OSX. etc.

Has someone written a mass-storage class driver?

No, it's not possible. It would need significantly different hardware support.

Extract from the 16U spec sheet

USB 2.0 Full-speed/Low Speed Device Module with Interrupt on Transfer Completion
– Complies fully with Universal Serial Bus Specification Rev 2.0
– Supports data transfer rates up to 12 Mbit/s and 1.5 Mbit/s
– Endpoint 0 for Control Transfers: up to 64-bytes
– 6 Programmable Endpoints with IN or Out Directions and with Bulk, Interrupt or
Isochronous Transfers
– Configurable Endpoints size up to 256 bytes in double bank mode
– Fully independent 832 bytes USB DPRAM for endpoint memory allocation
– Suspend/Resume Interrupts
– CPU Reset possible on USB Bus Reset detection
– 48 MHz from PLL for Full-speed Bus Operation
– USB Bus Connection/Disconnection on Microcontroller Request

The obvious difference between a slave device and host is supplying the power on 5V.

I just checked one of my USB flash memory devices and it says its max requirement is 98mA. It should be easy enough to provide that.

What other fundamental hardware issues are there?


JoystickHostWithParser - Joystick host demo with HID Descriptor parser, using the library USB HID Class driver framework
KeyboardHost - USB Keyboard host demo, using the library USB HID Class driver framework
KeyboardHostWithParser - USB Keyboard host demo with HID Descriptor parser, using the library USB HID Class driver framework
MassStorageHost - Mass Storage host demo, using the library USB Mass Storage Class driver framework

Doesn't this suggest the LUFA library could be used to provide USB host?

Doesn't this suggest the LUFA library could be used to provide USB host?

Yes, but only if the chip being used has a USB-host capable peripheral.

As I understand it, a usb device peripheral will allow the user to set up buffers of data, which it will then transmit in a timely fashion when it receives a poll from the host. A host has to initiate polls to all the devices (and then "immediately" accept responses, plus handling a lot of possible error conditions, which would require at least a somewhat different engine.

Now, I've never been clear on why something like a USB memory stick needs a fully conformant USB host to talk to it; if that's all you want to do. It seems to me like faking host messages well enough that the relatively dumb peripheral controllers would respond shouldn't be THAT hard. But I haven't heard of anyone doing it, including the (amazing) people who are capable of pre-calculating the USB bitstream so that it can be bit-banged out a generic IO pin. So I assume that at least it is very, very, hard...

Now, I've never been clear on why something like a USB memory stick needs a fully conformant USB host to talk to it; if that's all you want to do.

I doubt that Arduino would want to add something officially that was not spec compliant but a minimalistic subset that would allow a relatively slow mass storage device like a flash stick is all I'm interested in.

For my needs if it only refused all but mass storage and only implemented the slower write operations it mean I could make a data logger without adding a sheild and doubling the basic hardware cost.

Well, SD cards have similar capacity to flash drives, and are much easier to interface.
Assorted serial (spi, iic) EEPROM and data flash chips are still easier to talk to, though much lower in capacity (4 MByte for about $2)

Indeed. USB is probably an unnecessary complication. It just seemed like a good idea at first.

There is a cheap ($9.50+4 ++SDcard) SD shield but I can't find any reports of it actually being used , good or bad :?

I need some external buffering anyway for the ADC so it maybe best to add a memory chip as well though cheap expendable media like flash keys are appealing.

Looks like the easiest thing is to add an SD socket and use SDlib in arduino

Not sure what your project is and what components you already have
but there is a nice very compact solution using a Teensy board.
You can get the Teensy and the SD adapter for under $25.

--- bill

yes, I was looking at Tweensy earlier, it would fit the bill but his postal charges to Europe are a killer. USPS "upto 3 weeks, no tracking" $10 or something like $60-80 for UPS.

Since he's fixed all the memory leaks that affects strings and SD, for Tweensy, I'd like to support his boards but for the delivery problem.

You can buy Teensy from European distributors, for quicker (and hopefully cheaper) shipping.




Regarding USB, for background information to speak meaningfully, you really must read chapter 4 and part of chapter 5 of the USB specification. Many important concepts are explained. Here is the direct link:

This enormous zip file contains 35 documents. The one you want to "usb_20.pdf". There's no need to read all 650 pages! Skip chapters 1-3 (they're useless fluff). Chapter 4 is short, and chapter 5 gets into more detail. If you read only that small portion, you'll learn quite a lot about USB, and you'll become familiar with the USB specific lingo that's necessary to have a meaningful conversation about USB implementations.

Once you have a basic understand of USB device/host roles, endpoints, transfer types and other key concepts, you're ready to read the USB mass storage spec. There are many, but this is the one that matters:

Of course, this only explains how the commands are transported. The actual commands are a subset of SCSI, which sadly is not a free download. There are draft copies floating around, and Jan's USB Complete book(s) contain basically rephrased copies of the specs, at a far lower price than paying for a legal copy of the SCSI specs.

If you read all that, you should have a pretty good idea of the technical issues involved.

Regarding bit-banged USB implementations, they're only 1.5 Mbit/sec. USB flash drives connect their pullup resistor to the D+ line, so communication must begin at 12 Mbit/sec. Of course the host can switch to 480 Mbit/sec after reading the alternate settings descriptor. But the host can not choose to communicate at 1.5 Mbit/sec to such a device.

Thanks for all the links on USB. Good to have some background, but I already said I'd dropped that as being unnecessarily complicated. SD seems a much more appropriate way to get mass storage.

I was looking at the floris site earlier , the delivery is a lot more sensible