4 prototype boards arrived today. After going over them carefully, I found 4 lines that crossed each other. After some quick surgery with a knife and some solder and wire, the IDE project is now semi portable. The power supply is still out of a PC, so it's tied to an AC outlet. I'd like to make it battery powered or at least get a smaller power source on it so it's more easily moved. There's mounting holes for standoffs so it can piggyback with a hard drive. Right now, I've got the compact flash adaptor mounted on it. |
I've been spending every waking moment for the last 3 weeks working on this project. The low level assembly routines have been done for a while. I've just been delaying putting them here. My main focus right now is finishing this project in Optama C. I'm working on something I'm going to call PICDOS. So far, I have about 14 commands defined and am working on writing the code behind those commands. For testing purposes, the user interface is a VT100 serial terminal using the built-in USART. Eventually that interface will be replaced with an I2C interface so a microcontroller (such as the BS2) can easily access a FAT partition with minimal hassle. Here's the low-level routines wrapped in a C function call: low.c Also, here's an updated schematic. I've switched to an 8-bit LCD interface and moved A5 to C2 to keep all the LCD lines together. |
The assembly code is working and allows for an amazing 430kb/s transfers from drive to RAM! It will read my entire 8MB CF card in less than 19 seconds. That's 134 times faster than the basic code. As soon as I get the rest of the routines converted, I'll post the code in its entirety. Until then, here's what I have done. |
Here's the all basic routines and the schematic. The speed is confirmed at 3.2kb/s when writing to RAM, either from a fixed value or from the drive. I haven't done speed tests for drive write times, but I assume they would be comparable. The assembly routines are partially written. There's some issue with timing (the PIC is faster than the CF card!) so I've had to pull out my o-scope to try to resolve the problem. I think it's just a matter of inserting a few NOPs. |
The PIC version is now programmed with all low level routines. It's programmed in PICmicro Basic Pro. I figure it's got a 3.2kb/s throughput on the RAM side (40 seconds to write '0' to all 128kb of ram). That's pretty low considering it's running at 20Mhz. Later, I'll convert each routine to assembler. Anyway, right now, it's reading each sector from the hard drive and displaying the first 10 bytes in HEX to the first line on the LCD followed by the sector number. I'll post photos and a schematic when I get a chance. |
I've finally taken some time to wire up the new PIC version. Other things have taken priority...It took over 3 hours to wire up the PIC, IDE header, 2-74LS373s & 2-64kx8bit cache ram chips pulled from an old 486 motherboard. Basically, I've got 128kb of ram arranged so I latch the whole 16bit address, then read/write a whole word of data at a time. This allows for 16bit transfers to/from the hard drive directly to/from RAM. The PIC doesn't have to intercept or handle the data in any way during a transfer between the hard drive and RAM. So far, I'm using 24 pins out of the 33 available on the PIC. I still have to wire up the LCD before any programming starts. |
I've received several e-mails suggesting that people are confusing these 2 versions. The above version is based on a PIC16F877, 2 latch chips and 2 SRAM chips. Below, is the Basic Stamp version. It's based on a BS2, 2 8255's and a SRAM chip. The BS2 version was a proof-of-concept and the PIC version is the first prototype. Not necessarily the final design, but it works well. |
I just finished the FAT16 code! This little BS2 is logging a single value every minute to a CSV file. There's about 122 bytes of code space free and more should be available after optimizing. The low-level routines are smaller in this version, too. (850 bytes) Here's the code. There's 2 problems: The order I store the bytes in ram is backwards. Also, right now the maximum filesize is 512 bytes. There is a problem with the end-of-sector detection. I don't have time to debug it right now. Once that bug is squashed, the filesize limit will be 16k (one cluster). Once I implement end-of-cluster detection, the filesize limit will be 4MB (one sector of FAT entries). When the end-of-sector detection for the FAT is implemented, the max filesize will be 128MB (one cluster of FAT entries). And, finally, when the end-of cluster detection for the FAT is implemented, the max filesize will be the full 2GB that a FAT16 partition can access. Have fun! I'll be back Sept 9th. |