Using Linux and Flash Drive for Robot

[Builder1]

Hi All,
I'm using a Mini-ATX motherboard for my robot and I'm also planning to use Linux for the OS. One nagging question I have is can I use a flash drive to store my OS instead of using a hard drive, this would save on cost and weight. I've read somewhere that one can actually fit the entire OS on a flash drive and simply plug it into the USB port and it should work. If anyone has ever done this before or has comments on this idea, I welcome all that you have to share. Thanks in advance for your response.


Builder1

[z.s.tar.gz]

Yes, linux can be installed and run entirely from a usb flash drive.

[mlucia]

Yes, it's not too bad to do either. Look at syslinux for putting a bootloader on the USB stick -

The other option which works better, easier and faster is to get a IDE=> CompactFlash adapter and use a CF card - the newer ones are pretty fast - when you are done, the CF looks and acts like a HDD.

One word of caution... you will want to minimize the writes to ANY flash device. That includes NOT creating a swap partition. Even with wear leveling, you can chew up a flash device in short order. What some folks do is to create a RAM disk and mount that for logs etc, and copy them to flash every so often.

Hope this helps

-Mark

[Builder1]

Hi All,
Thank you for your prompt response, you very were helpful. Mlucia what do you mean by not writing to the flash drive and creating swap partition? Are you saying I can not update my robot program, not even updating the robot with constantly changing info gathered by the different sensors that is used for navigation? Please elaborate and thanks again everyone for your time.

Builder1

[z.s.tar.gz]

You shouldn't use a swap partition on a flash drive, due to increased wear on the flash drive.
Otherwise, it will work exactly like on a hard drive.

[Admin]

One word of caution... you will want to minimize the writes to ANY flash device. That includes NOT creating a swap partition. Even with wear leveling, you can chew up a flash device in short order. What some folks do is to create a RAM disk and mount that for logs etc, and copy them to flash every so often.

He means that all USB drives have an X number of writes until failure problem. So do your best to minimize all writes to the drive.

[dunk]

hey guys, haven't posted here in a while...
i think i can explain this one clearly.

by default most Linux installs will partition some of your disk off as a swap file.
this way memory in use by sleeping processes is copied (cached) to the swapfile on the disk so more of your expensive memory is free for use by active processes.

the down side of this is that although flash memory is getting better all the time but it is still limited to a few million writes before it starts to die.

it is quite possible if you are using flash memory instead of a hard disk all that writing backwards and forwards will exceed your flash memory's write limit.

the solution is to not have a swap partion at all. it's fairly easy to select none at install time when you are asked about disk partitioning.
memory hungry applications will not run as quickly but they will still work. (i'm writing this on a flash based machine at the moment.)

Are you saying I can not update my robot program, not even updating the robot with constantly changing info gathered by the different sensors that is used for navigation?

you don't have to worry about that unless your program will write to the same disk location thousands of times per second.


dunk.

[mlucia]

Yup - depends on how much writing you do to the flash drive - here is a link that does a far job of explaining

http://www.acscontrol.com/knowledgebase/article.asp?CatID=2&ID=7

The article said that the write endurance of any single cell is on the order of 300,000 erase/write cycles. That can be misleading, as flash is erased and written in blocks.... Sooo, if you want to write a *single* character, an entire block of flash is erased and written. The block size is determined by the actual flash chips used. CF cards employ "wear-leveling" - transparent to the OS or user, the CF card will *move* data around in the flash chips so that all blocks of flash have about the same erase/write cycles.

The whole idea of a limited number of erase/write cycles in not unique to CF cards - the datasheet for the atmega168 indicates a limit of 10,000. Some of the newer PIC devices are on the order of 1000.

The specific issue with linux (at least a full blown install - one not tweeked for flash) is that out-of-the-box, it writes a LOT of logs... the logs are appened one line at a time. There are TONS of commercial examples of flash based devices running linux that manage all of this very very nicely. LinkSys routers are a good example... most have 4M of flash.

There are some linux projects that targeted at flash based storage:

http://www.damnsmalllinux.org/  - designed to run from USB stick and includes complete GUI etc
http://www.openwrt.org/         - targeted at the LinkSys WRT54G routers
http://buildroot.uclibc.org/         - a -generic- linux build system that supports dozens of architectures like ARM, PPC and of course x86

In my opinion, buildroot is your best place to start - you can create a complete linux OS with development tools etc, in < 100mb without breaking a sweat.

[Admin]

the datasheet for the atmega168 indicates a limit of 10,000. Some of the newer PIC devices are on the order of 1000.

That value is only the average number of writes before failure . . . meaning there is a bell curve. Your drive could potentially fail after just 3000 writes.

Flash drives are designed for manual file writes. Meaning you'd probably not overwrite data on it more than once or twice a day. So it'll take many years to even reach the low end of the bell curve.

For an OS on a USB stick, automated rewrites are much more intensive.

The CMU team that is planning to put a robot on the moon, they tried to use a USB stick for RAM. They were burning through several sticks a week until finally deciding it was a bad idea.