Thursday, October 04, 2007
PICs Reading USB Drives
We've kicked around the idea of a RepRap being able to store parts on a USB drive so that no PC is actually needed to print things out. It's a little esoteric and not a near-future priority, but for those into such things this article describes how a PIC can be interfaced to a USB Flash drive using a VNC1L Vinculum controller IC:
http://dataweek.co.za/news.aspx?pklNewsId=26407&pklCategoryID=34
Vik :v)
http://dataweek.co.za/news.aspx?pklNewsId=26407&pklCategoryID=34
Vik :v)
Comments:
<< Home
I like the idea of autonomous operation very much, as pc´s eat a lot of electricity and get bsod´s every so often (mine does, anyway).
But i think adding an usb host-controller is way more complicated than necessary. A mm-card can be controlled directly by a microcontroller, perhaps directly on the power-comms-card.
But i think adding an usb host-controller is way more complicated than necessary. A mm-card can be controlled directly by a microcontroller, perhaps directly on the power-comms-card.
My thoughts too. SD cards are everywhere, even in a lot of phones, so you're not sacrificing that much flexibility.
And SD cards are compatible with MMC cards, and MMC cards can be read with a simple bit-banging interface.
Right you are. So here goes:
Midi-Recorder, not PIC but AVR:
http://www.lehmayr.de/e_mrmidi.htm
As i understand, the MMC just needs clock,ground, and two IO-lines. The rest is Firmware, library functions for FAT16 are available on AVR, should be easy to port, if necessary.
Another Link, for FAT32:
http://www.pjrc.com/tech/8051/ide/fat32.html
Midi-Recorder, not PIC but AVR:
http://www.lehmayr.de/e_mrmidi.htm
As i understand, the MMC just needs clock,ground, and two IO-lines. The rest is Firmware, library functions for FAT16 are available on AVR, should be easy to port, if necessary.
Another Link, for FAT32:
http://www.pjrc.com/tech/8051/ide/fat32.html
The communication with the card is the easy part. There are a bunch of sites of sites that give you example circuits and practical info on how to talk to them. If you want the actual specification, google "SanDisk Secure Digital (SD) Card Product Manual" for a PDF with all the gory details.
The FAT filesystem is the harder bit, it takes a good chunk of memory to read -- 1k or so. Here's a few more links for you:
http://elm-chan.org/fsw/ff/00index_e.html
http://www.larwe.com/zws/products/dosfs/index.html
http://efsl.be/
(pdf) http://foros.solocodigo.com/index.php?act=Attach&type=post&id=78757
The FAT filesystem is the harder bit, it takes a good chunk of memory to read -- 1k or so. Here's a few more links for you:
http://elm-chan.org/fsw/ff/00index_e.html
http://www.larwe.com/zws/products/dosfs/index.html
http://efsl.be/
(pdf) http://foros.solocodigo.com/index.php?act=Attach&type=post&id=78757
The msp430 family has some beefier processors with sufficient ram to handle a FAT filesystem. Plus there's gcc support for the msp430 processor, so you can program it in C.
For the FAT filesystem, there's a bunch of open source code which reads it. For example, the handhelds.org bootldr reads FAT12 and FAT16 filesystems, and it's BSD-licensed.
For the FAT filesystem, there's a bunch of open source code which reads it. For example, the handhelds.org bootldr reads FAT12 and FAT16 filesystems, and it's BSD-licensed.
GCC isn't so good for micros. Can you tell offhand if the available code is going to fit on a PIC and use SDCC?
Vik :v)
Vik :v)
GCC is fine for micros with a reasonable instruction set. MSP430 has a nice simple, clean, 16 bit instruction set with just the right instructions and addressing modes to run C. I haven't use GCC with it but the IAR compiler produces very good code.
PIC on the other hand is terrible at running C and the SDCC compiler seems to not be able to produce working code without some manual intervention. No compiler is every going to produce efficient code on a PIC, especially not the 16 series.
PIC on the other hand is terrible at running C and the SDCC compiler seems to not be able to produce working code without some manual intervention. No compiler is every going to produce efficient code on a PIC, especially not the 16 series.
I've examined the code that gcc produces for the msp430 series. It is EXTREMELY clean. I haven't found any instance where I felt "damn but I'd code that better myself".
/me hugs his msp430s.
I don't know if the blog tells you about new comments on old posts, but I found some christmas bead garland which is 8mm balls moulded on a string. Might make a nice drive belt.
Post a Comment
/me hugs his msp430s.
I don't know if the blog tells you about new comments on old posts, but I found some christmas bead garland which is 8mm balls moulded on a string. Might make a nice drive belt.
<< Home