Saving data to a real Harddrive

Hello Arduino ppl.

First i would like to know if it’s posible to save data (fx. temperature data, distance data and so on), on a real harddrive from arduino?

The reason im asking this, is because, if i wanted to make a robot some day, it would help me a lot to save the data the sensors recive for both statistic use and for helping the robot to “learn”.

Anyone that can tell me if thats posible?

Regards from Denmark (DK)

Interfacing with a hard drive probably isn't worth the effort required.

It is much easier to use a SD Card for logging data.

http://www.arduino.cc/playground/Learning/SDMMC

Sparkfun has a USB Host card, need that to control a hard drive as a starting point.
SD cards seem much easier to use, lots of stuff exists, and they have quite large storage size these days.

Basically no, you haven’t got enough memory to hold the filling system and you would have to interface a hard disc controller or hard drive interface. These really on parallel I/O which is not available on the arduino. Well not a whole byte at a time.

Mike,
How about the external hard drives that are only connected to vias USB (2).
Like a 1 TB drive.

Can the arduino plus the sparkfun USB host shield plus a decent battery be made to access one of these?
Add an MP3 card from MDFLY for audio playback. Maybe an SD card to hold the drive index to speed things up?
Need a display too.
And play back selection controls.

Can the arduino plus the sparkfun USB host shield plus a decent battery be made to access one of these?

It is USB2 and the sparkfun is only USB1, it might not like the slow transfer speeds achievable. Also you still have to have the filling system, I think it is a bit much for the poor processor.

Real hard drives are also rather delicate to put on an experimental robot rig - when active they must be protected from vibration and knocks (this is why many laptops have an accelerometer to detect free-fall and park the disk heads). An SDcard is practically bulletproof.

Large disks need a better filesystem than FAT32 anyway to prevent gross wastage(*), so having a terabyte means using a far far more complex filesystem on the drive which definitely won’t be accessible to the Arduino. All modern filesystems are far far more complex than FAT32 (We’re talking code/cache footprints of megabytes).

(*) A terabyte drive with FAT32 would take a minimum of 15MB per file and directory (the cluster size).

Saw the Rev2's, that got me thinking it was USB2.

Looking more & more like duct taping a portable USB Passport-type drive to a $200 Netbook computer running WinAmp might be the way to go!
Or replacing the 80GB drive in my Neurosw Audio player with a higher density internal drive.

We so abuse our poor little 8 bit arduino boards with such high expectations and desires. :wink:

To make a direct hard-drive interface based on SATA or IDE from an Arduino is likely to be more than a stretch for the Arduino both in terms of software and hardware requirements. So the general answer to interfacing hard-drives would be no – not possible/practical.

There is the possibility however to interface with other more capable hardware than can act as a bridge between Arduino and a hard-drive. Some candidates are:

USB host shield
The Maxim IC used on the shield will only handle low level USB signaling requirements and the USB protocol must be implemented in Arduino code. It seems like the lead developer working on a library for this shield has ambitions just short of world dominance, but mass storage (as would be required for hard-drives) is still not supported. I would also expect that when/if such support is ever written there is not likely to be any resources (RAM/Flash) left for a decent application. Not practical for USB hard drives (or flash drives) unless a microcontroller is dedicated for this purpose.

Vinculum VDRIVE2
This is different from the USB host shield in that the USB protocols are implemented in on-chip firmware. Support for USB mass storage devices (including FAT32) is available.
This approach removes most of the complexity and memory requirements from the Arduino. Interface is SPI or TTL serial. Hard drive size is limited by a cluster size of 512 (restricted in Vinculum firmware) to a maximum of 137GB (FAT32 will support up to 2.2 terabytes with 8kB clusters, not 15MB as Mark suggests). This would be within reach of an Arduino.

Wireless
Another approach could be a wireless bridge (Bluetooth serial or even low cost wireless modules could be used) between a PC and an Arduino. There are obvious practical limitations in terms of speed/distance/PC required, but still possible and would open the full mass storage capacity of a PC. This would require developing a PC side application interface to implement a protocol for data storage / logging.

Vinculum VDRIVE2
This is different from the USB host shield in that the USB protocols are implemented in on-chip firmware. Support for USB mass storage devices (including FAT32) is available.
This approach removes most of the complexity and memory requirements from the Arduino. Interface is SPI or TTL serial. Hard drive size is limited by a cluster size of 512 (restricted in Vinculum firmware) to a maximum of 137GB (FAT32 will support up to 2.2 terabytes with 8kB clusters, not 15MB as Mark suggests). This would be within reach of an Arduino.

The 137GB limit would be the holdback here. Might be more straightforward to have a card (shield) with multiple SD cards instead.
The “Bobuino” I am waiting for PCB delivery of right now has a seperately addressable SD and microSD cards (the upper surface SD and the lower surface uSD are separately addressable - I think what I should have made the upper surface cards the same SS, and given the bottom cards its own SS - next rev …
I think I can fit 6 uSD sockets on board! Use the JTAG IO pins to drive them all.

@crossroads
any idea what sort of (sustainable) write speed you're expecting?

Whoops, I totally messed up on the cluster size, confusing FAT16 and FAT32 for some reason... Sorry about that. I think my concern was from having seen 1GB microSD cards with FAT16 preformatted on them - which is less than ideal.

@mmcp42,
No idea! Have never used an SD card in a design before. Don't know why it would be any different than writing to any other card, there's just more of them. All are accessed via SPI calls. Figure start with @fat16lib's SPI library.
I was thinking for personal use to load them up with music using a PC, then plop them into the board and go.

Skyjumper has a similar design working now with a regular SD card, I'll ask him what he see's for write speeds, he has a datalogger thing going on.

mmcp42:
@crossroads
any idea what sort of (sustainable) write speed you're expecting?

It is heavily, heavily dependant upon the SD card itself. The "high speed" data cards are not necesserally high speed when using the SPI interface. I have a few different cards and the speed is very different. IIRC, one is about 170 KB/s while the other is much lower, around 90 KB/s (kily bytes per second). Read speeds are more like 360 KB/s.

There has been quite a lot of discussion of this on the storage forum on this board. If you need higher sustained write speeds, and you have a good idea how big the file is going to be, you can allocate all the space ahead of time and then go fill in the data. The latest SDFat library beta (just about a week old now I think) has example code that does this. Thats a very well done library. You'll need the latest Arduino cores to make it work though.

thanks guys! :slight_smile:

Well, in time I may be able to answer this.. I have one of those CH375B USB host modules, but haven't used it yet.

As I understand, it does buffer for itself and uses FAT32.. so maybe not a terabyte, but a good number of gigs anyway.. it's designed for hosting USB pen drives, not raw SD card. Since it's that kind of interface, I figure that an external HDD uaing the same interface "ought" to work..

If you really need to talk to an actual hard drive, you're better off with an ARM card running Linux.

I don't know, seems a little overkill.
My little Neuros Audio has an 80GB hard drive, and it doesn't use that.
For downloading from PC there is a USB2 connection.
For MP3 playback, it controls the drive directly.
http://open.neurosaudio.com/extra/NeurosSchematics.zip

Wow, that's a lot of parts!

I see it more as a software issue. If you need to build a production device and keep each unit cheap, then maybe its overkill because you can write the code and then ship it with each device. But implementing a file system and other support code to talk to a hard drive is going to be a lot of work. Linux has it all there for you, and its free. I have seen Linux ARM dev boards for $80.