pendrives

hi! as a part of our academic project we have to make a pendrive.can anyone help me with the components required and the cost etc.? thank you

.

------- k..this is not much help but it's funny...

Email the pendrive company and request a schematic. :) Say you're a pendrive repair specialist..

D

YOU might think its funny.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

I'll pay that one!

Dave :)

Many ways to skin this cat.

Easiest way might be to take apart a USB stick, desolder all the components, trace out the circuit, design your own PCB, rebuild and present as your own project. Good chance of failing though ;-)

Next option might be to get a proper controller chip like this one:

$250US Should be easy to get "example designs" and copy that. You probably don't learn learn much this way though.

Third option would be a complete do-it-yourself design using some sort of USB interfaced microcontroller and a flash chip. The hard part would be writing your own driver if you wanted it to appear as a Windows drive with all the automatic plug'n'pray detection etc.

You probably need to be more specific on what the actual requirements are and what restrictions you have.

Dave :)

What is it with students these days. When I was at uni, and school, I was expected to research the topic and find a solution. We had to use books and libraries. Now they have google and they still cant look it up.....

Atmel has code showing how to use their AT91SAM7X parts as mass storage devices. So you could couple a SAM7X with a flash chip/flash card and have your pen drive.

I suspect pen drives that you find in stores will use specialized controllers though that do pretty much everything for you.

-Mike

Microchip has an Appnote doing this using a PIC18F4550. It implements a USB SD card reader but it should be easy enough to replace the SD card with a serial flash chip (in fact, a serial flash is much easier since you don't need to init it like an SD card). Or use a micro-SD (transflash) and superglue it to your pendrive circuit.

Google for "Microchip AN1003"

They are lazy.

They want instant gratification.

Got that one and thought it sucked. uses the pic18f4550 for examples no hardware designs at all in the book, just some programming examples. Though Jan's other books aren't bad, but this only could of been better IMHO.

On that note, could you recommend a USB interface chip (similar to what the MAX232 does for the serial port) that one can use with non-USB-enabled micros?

I was looking at the PIC18F2455 and PIC18F4455, but was wondering if I could stick with Atmel (and use something that would work with a breadboard - restricting me to DIP for the moment).

Michael

FT232R from FTDI

And if you want the other end, look at their new Vinculum host chip.

Thanks.

- Michael

Adding your bad review to the average 4.5 (on 3 reviews) at the above link still gives a pretty good overall rating. It's definitely worth a look.

Silicon Labs has a USB to UART Bridge chip.

Anybody know how one designs a file structure that doesn't wear out a couple of key blocks? "Wear leveling" is pretty obvious for data, less so for directory structures.

I just managed to wear out a 512M SanDisk flash doobie. It's hard to imagine that I did 100K writes, a typical flash endurance, but each file write might involve a lot of flash-bash activity if the design is dumb.

And why do they stick out the front of computers, just begging to get whacked and broken off? Why isn't at least one USB slot recessed? And why does Dell mount all their USB connectors upside down? Grrrrrr.

John

On a sunny day (Tue, 02 Jan 2007 10:44:58 -0800) it happened John Larkin wrote in :

Only use the flash for storage, work from harddisk, it is faster too.

Insert flash read only, Copy the lot to harddisk. Work all day on harddisk. End of day [after encrypting the lot] copy the lot back to flash. Remove flash from PC.

Encryption will protect you if you lose the flash with sensitive data.

You can xor the whole flash image with a file on the PC of greater length. Cannot be broken without access to the PC. Only one write per day to flash, good for 100000 days.

# First make a 512 MB ransom mask file for encrytion: dd if=/dev/urandom bs=1000000 count=512 of=random_file

# End of day, compress all files in tree on harddisk # (one should use a script to make a tree if it is not in one place) # Compress all dirs to one big file. tar -zcvf x.tgz dir/*

# Encrypt xor x.tgz random_file x

# Copy to flash (flash is known as /dev/sda1 to the PC in this case). cp x /dev/sda1

# remove flash.

# flash cannot be decrypted without PC. # Take flash home.

# Next day: # Insert flash

# Decrypt xor /dev/sda1 random_file x.tgz

# Decompress, this re-creates all files and the directory structure on harddisk. tar -zxvf x.tgz

# Work with these files.

# So you have also saved space.

// xor source code:

#include #include

int main(int argc, char **argv) { int c,m; FILE *fptri, *fptrx, *fptro;

if(argc != 4) { fprintf(stderr, "Usage: xor sourcefile maskfile outfile\\n"); exit(1); }

fptri = fopen(argv[1], "r"); if(! fptri) { fprintf(stderr, "could not open %s for read\\n", argv[1]); exit(1); }

fptrx = fopen(argv[2], "r"); if(! fptrx) { fprintf(stderr, "could not open %s for read\\n", argv[2]); exit(1); }

fptro = fopen(argv[3], "w"); if(! fptro) { fprintf(stderr, "could not open %s for write\\n", argv[3]); exit(1); }

fprintf(stdout, "XORing file %s with %s to produce %s\\n", argv[1], argv[2], argv[3]);

while(1) { c = fgetc(fptri); if(c == EOF) break;

m = fgetc(fptrx); if(m == EOF) { fprintf(stderr, "WARNING mask file too short! File not encrypted\\n"); exit(1); } fputc(c ^ m, fptro); }

fclose(fptri); fclose(fptrx); fclose(fptro);

fprintf(stdout, "Ready");

exit(0); }

Lookup jffs2 for an example. Although I ended up implementing a much simpler one for our stuff. It is quite useful since we can now dispense with battery-backed RAM on many products. And it's not just wear levelling, you also have to consider the effect of power-failures at any point in the erase & programming process. Blocks can end up partially erased or partially programmed, such that their subsequent contents are untrustworthy.

I thought they had special hardware to avoid that - could be wrong there though!

Are you sure wearing out is the problem? Perhaps it got zapped by ESD, or the afore-mentioned unexpected power down, or something.

--

John Devereux

Agreed. Variation on the above:

Maintain critical files on one directory on the harddisk (e.g., C:\\Critical) Zip these files up into a single archive (tar + gzip for Linux folks) Encrypt, if contents are sensitive Copy the *one* zipfile to the flash drive at the end of the day Remove flash drive

This should minimize filesystem writes... any comments?

Michael