 |
 |
| View previous topic :: View next topic |
| Author |
Message |
CT_76leo
Guest
|
| USB Flash drive with PIC |
 Posted: Sun Jan 14, 2007 12:09 pm |
 |
|
| Can any one tell me how can i connect USB Flash Drive with PIC16F877A, How?if no why? |
|
 |
Ttelmah
Guest
|
|
| Posted: Sun Jan 14, 2007 2:06 pm |
|
|
Problem is that to connect to a USB slave device, requires implementing a USB master device. This is _complex_.
USB, is designed to make the slaves relatively simple, but at the cost of complexity in the master. When you talk to a flash device on a PC, you are using the internal USB master hardware, with a driver for this, then on top of this the USB stack, then the drivers for the flash device, then the drivers for the file system. Now in software terms, I doubt if you could actually fit all these (even a simple one device version), into a 16F877. The hardware also needs providing...
The simplest solutions are:
1) Use a SD/MMC memory instead (this allows SPI interfacing, which the PIC supports, and leaves only the file system drivers needed - versions of these are available).
2) Use an intermediate device that implements the hardware and low level drivers. Look at the FTDI Vinculum device. One of the demo versions of this, is built to provide exactly this interface.
Best Wishes |
|
|
tojape
Joined: 14 Jan 2007
Posts: 20
Location: Hungary
|
| PIC->USB Flash Drive |
| Posted: Sun Jan 14, 2007 2:58 pm |
|
|
You may probably benefit from this link:
http://www.vinculum.com/index.html
FTDI Vinculum is a lowcost (<$12 @ 1 pcs) USB host controller.
Hope I coluld help.
Best wishes
tojape
_________________
The computer helps solving the problems which would have never arised without computers |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Mon Jan 15, 2007 1:53 am |
|
|
| The VNC1L Vinculum chip is your best bet. It works well. Beware though the VDIF firmware documentation (Ver 1.06) is not entirely complete in places. |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Wed Jan 17, 2007 7:10 pm |
|
|
I have just received some free samples of the MAX3421E USB peripheral/host controller. According to their website they cost $3.47 when bought for money, so I think this will be the least expensive solution.
Does anybody have experience with this chip ? It has SPI interface. I am going to write some routines in CCS C into a PIC18F series to chip read/write USD flash drives. |
|
|
kamputty
Guest
|
|
| Posted: Wed Jan 17, 2007 9:28 pm |
|
|
Libor,
Please keep us informed (or at least me!  ). I'm about to do the same thing, so any lessons learned will help me too!
You're planning on writing to the USB drive, yes? (I hope so cuz that's what I want to do!)
Take care,
~Kam (^8* |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Thu Jan 18, 2007 1:10 am |
|
|
| libor wrote: | | I am going to write some routines in CCS C into a PIC18F series to chip read/write USD flash drives. |
So you are going to implement FAT12, FAT16 and FAT32 handling in the PIC - Will you have any space left for application code  |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Thu Jan 18, 2007 2:54 am |
|
|
| Quote: | | So you are going to implement FAT12, FAT16 and FAT32 handling in the PIC |
The application will be a vehicle based GPS-position datalogger* in trucks. So the data would go only one way.
As a beginning (and maybe i will stay by that) I am thinking about this (limited) solution to avoid implementing a real working FAT system, but in spite of this be able to read my data in any PC that will see the drive as a valid FAT (let it be FAT32:-) formatted media. The PIC would not really know what it does:
- The solution would require a kind of 'preformatting' the drives: a PC should write one continuous file of easily recognizable** dummy data (e.g. 0x55..., or I could also code in a file position pointer into the data if this helps me more) on the totally empty flash drive. As far as I know, in this case (empty drive, no other files involved) the file's data area will occupy continuos clusters (or some easily followable sequence of cluster positions) area on the drive).
- the PIC's thin solution's job will be only to progressively replace (rewrite) the file's dummy data with the valid data leaving all other things intact (the directory structure, the FAT table, etc)
- when the user plugs the drive into the PC, the PC will see this one same large file (with the dummy data in the end) but incrementally filled up with valid data from the beginning of the file onward.
(I could also presave a compressed version of this valid directory structure containing this one large dummy file references only in the FAT/directory of the drive into the PIC's program itself, - there are many repetitions, so it will take very small space when compressed - and so I will be able to 'preformat' the drives with the PIC itself, so no PC should be involved)
What do you think ?
* Storing the coordinates in a strong compressed form (long sequence of position deltas from the prev. pos. only and a timestamp data only when the truck is stopped) I will have a capacity of storing lifetime-length of the truck's voyage in a dynamic resolution up to 1sec on a 2Gbyte flash drive.
** In fact there's no real need for any dummy data in the file's data area at all, I can just leave the file's data area as is (dirty or factory programmed to FF, or I dont know what), it will be replaced by the PIC upon the known (continuous) sequence of the position only. The only thing the PIC would read from the drive (when booting, or a new flash drive is inserted) is a pointer to the end of the valid data in the file, so it can append new data after it.
I can even split the storage to several smaller files. The PIC will also be able to directly change the file names upon their know position of storage. The main thing is to avoid the hassle with the dynamic FAT table creation, directory structure modification, etc.
Last edited by libor on Thu Jan 18, 2007 3:47 am; edited 1 time in total |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Jan 18, 2007 3:46 am |
|
|
The approach sounds possible.
One 'caveat', if this is for a reasonably large production run, is availability of Maxim parts. They have a nasty habit, of having long lead times, so on their parts, I tend to hold at least six months stock, when using them in boards, to avoid availability problems. This makes them 'more expensive', than their actual 'price'...
You will need to setup INTLEVEL=0, and POSINT=0, to make the interrupt output work properly with the PIC INT input (assuming this is set to trigger on H_TO_L).
Provided the whole thing can be based on one design of memory card (so the same manufacturer ID, and FAT layout), this should be fairly 'do-able'.
Pre 'making' the file structure, is the approach used for the swap, and similar files, and simplifies things a lot. I'd suggest you pre-allocate the file to fill the drive, and use the first sector of the file to hold 'housekeeping' data. Try to avoid writing too often to this (device life....), so write the new data first, and only once al the sectors are in place, update the end-of_record pointer.
Good Luck  |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
