Arduino USB Storage

Well, I've bought a Uno, I've got code working, and the right lights flashing at the right time. The only thing which now stands between me and a product is storage. USB storage.

I need a solution where a user can insert a USB stick into the device, and trigger processing of the file/s it contains. It HAS to be a USB stick, my application will run in a workshop full of gnarled and greasy fingers, and fiddly little SD cards (especially micro-SD) just won't be usable.

Are there any Arduino solutions, or am I condemned to Fez and C#?

Probably you are looking for something like this &&


Try to read this:

It might be a simpler solution than the USB host shield

Also look at and


Thank you for the suggestions.

I've looked at both options, but I can't find good example code or stories of success in their use. The forums, for example, show only questions and problems.

Should these be considered "experimental", or are they production-ready?

If it’s simply the size of the media that’s the problem, why not make some custom enclosures for standard SD cards to use instead? You can then have the best of both worlds - SD card use is simple enough for the arduino, and you can tailor the size of the media device for those gnarly fingers to whatever you want.

Hi Crook,

Let me be a bit more open. This design is for something I'd like to sell. I'd rather not go into the exact purpose, but basic workflow is that the user prepares a file on a computer, copies it to media, then plugs that media into the device.

The intended audience isn't known for its currency of technology, and I expect that the majority of users won't have an SD card reader.

Further, the intended audience is mainly retired men. They'll manage a large USB key, but their fingers are losing their dexterity and SD cards are too hard to handle.

I like your suggestion of a carrier for the SD card, but this would push up the cost and complexity of the solution. No matter how I look at it, USB drives are the best all-round solution.

I just wish I could find a proven USB strategy for Arduino ... so far, I'm just not getting the warm fuzzies that I need to proceed.

Oh, also, I'm principally a software guy. I'm amazed at how Arduino has let me bring software and hardware together, but I'm not confident in my ability to do anything too electronic in building/prototyping a solution. That's why I'm looking for something proven in both hardware and software.


Hi Ron,

I have one FEZ board at home and these work well with USB stick. See chapter 23.2 of for example code. I tried it and it works (but that does not make it proven tech).

FEZ claims to be Arduino compatible wrt the I/O pins and as far as I know it is. Drawback for me is that they only recently support the [u]ethernetshield/u. Still have to try it. Recently there was an update for my FEZ that took me two evenings to get all things working again. This means FEZ is maybe more experimental and difficult than Arduino in some aspects imho. So in terms of [u]proven tech[/u] in HW & SW I think you will always jump on a moving train no matter what board you will use. It's up to the developer (you) to make it proven. Sharing your needs & problems on a forum like this does often help in such project.

The USB host shield I mentioned earlier is on my wishlist so I can't share experiences about that shield.

If you want to go for [u]commercial[/u] usage I would just walk both the Arduino (with USBHOST shield) and the FEZ way. The costs won't kill you and from experience I know that developing on multiple platforms in parallel speeds up the insight of how things could be done, finding bugs, better architecture etc. NB the behavior of the application should be the same, independent from the platform used.

Hopes this helps in your decission. Rob

Sometimes one can't see the forest for the trees :)

Rob, you are quite right. The incremental cost of TRYING both solutions is minimal. I've just ordered a Fez and a USB shield, I'll report back on my results.

The biggest issue I see with parallel development on two platforms is language. Fez (and Netduino) use .NET Micro Framework, which only supports C# in its current incarnation. C# is a great language for desktop development and data processing, but I'd rather have C/C++ for the elegance and brevity that pointers can bring to the algorithm, not to mention the non-issue of Garbage Collection.

At least I'll get a decent IDE and debugger!

Time to report back.

I tried the Fez and didn't like it. Nothing technically wrong, but I just didn't like doing my project in managed C#. Having a debugger and emulator was great, but having to think my way out of pointer-based code wasn't. Also, Fez didn't offer a USB host storage solution on the board I was using.

My other option was a VDRIVE2 device. I've got mixed emotions about this one. It works, but it is slow, and the command-based interface is quite clunky. I had expectations of getting a file-system experience like I'd get on a PC. Stupid me, in the absence of an operating system that experience lives only in my imagination :)

I'm not sure that the VDRIVE2 is a rugged, production-ready device. A couple of times it has failed to recognise a USB key when plugged in, and I've had to wriggle the key around to get the indicator to light up. If I'm careful when I insert the key I have no problems, but I can't design a product for a workshop environment that relies on "careful" users.

A few hints if you ever use a VDRIVE2:

  1. Get the datasheet and the firmware instructions (the command language) from

  2. Make sure you reflash the drive using what is referred to as the "Reflash (FTD)" version of the "VDAP Disk And Peripheral Firmware V3.68", or a later version. The firmware shipped with the device is hopelessly out of date, and you'll waste your time trying to get it to work unless you upgrade to a later version.

  3. NewSoftSerial is your friend. It was simple to set up a command interface using this library.

  4. Ignore any advice you see about wiring CTS and RTS together. In reading files I lost great chunks of data until I went back to basics and implemented these pins. Here's a little bit of code that shows how I used it:

      // Send the command to the USB key. Wait a few ms for the
      // USB interface to respond.
      usb.print (cmd);
      delay (10);

      // Write any response to the monitor
      while (usb.available()) {

            // Don't allow the USB interface internal buffer to overflow.
            if (usb.available() > 8) {
                  digitalWrite(usbcts, HIGH);
            else {
                  digitalWrite(usbcts, LOW);

            // Read a character from the USB device
            ch = ();

            // Echo character to the serial monitor
            Serial.write (ch);

To summarise work to date, VDRIVE2 works, but slowly, and with possible physical/reliability issues.

It looks like I'll have to revisit my basic design principles.

I'll look at SD cards, but I don't think they'll be much better than the USB key. Certainly, they're not as user-friendly.

I'll also look at the possibility of plugging the Arduino into the PC and downloading some files onto an embedded (hidden) SD card. The user might bring the device to the PC, load it, then take it back to the workshop.

Back to the code-bench!

I have lost my sanity and my hair but I do have a VDRIVE2 logging time,date & 2 temperatures every 10 seconds. Eventually this will be every hour so speed is not a problem. I will know how robust the VDRIVE2 is after it has been in the field for a couple of years. But, in the mean time it does work.

Quick question to you guys - did anybody find or write their own library code for interfacing with the VDRIVE2, or just hack it?

Stupid question.. why not use an Arduino?

Use a mini, and have your PC-side "programmer" simply be AVRdude in a pretty dress? (okay, let's not EVER use that slang in relation to AVRdude again. It's just...not right.)

Your PC side app downloads your executable directly to the arduino, which is then carried over and plugged into the remaining hardware. On both sides, you have power, so your "key" needs no internal battery or whatever. This is a lot simpler (and therefore cheaper as well as more likely to work) than trying to implement on hacked-together SD card interfaces. All your user sees on one side is the PC-side USB, and you can purchase pretty much any type of connector for the "other end" which plugs into your device. Instead of moving just the data, move the whole computer (the Arduino, that is), and it becomes easier.

Seems that you are trying to bring the mountain to Mohammed, so to speak. Arduino minis are just about the right size to be made into a keyfob sized device.. so what you really need is a connector, and some creative code. Don't take the data to the arduino, take the arduino to the data. Just my take on one way to approach the problem.. with mini's being in the $20 range even in single units, it makes sense. It also allows you to completely update the firmware of your device at any time, adding features or fixing problems.

Good luck :)

I've probably had a little too much coffee this morning, but I'm a little confused as to what your suggesting.

Instead, let me describe my particular application - not sure about what other people are doing.

I'm designing an embedded device around an atmega1280. I still have my training wheels on, so I'm doing a lot of the programming inside the Arduino IDE.

This device will be an isolated datalogger, logging to attached SD card memory. When the time comes, I want to be able to stick a flash drive into the device, and copy the contents of the sd card to the flash drive.

The data needs to stay with the device, so just logging to usb and removing it isn't an option.

What would you suggest here?

G'Day vanquish. If you are not needing vast amounts of storage you might consider I2C memory. If you are using a DS1307 RTC that has some or there are devices like 24LC256 which hold 256 kb (32 kB) of data.


Thanks for your reply :)

Not to be pedantic, but the memory available on the DS1307 is actually battery backed RAM, not EEPROM. And there is only a few (about 56 IIRC) bytes available.

My SD Card will be about 1-2GB.