Searching \ for 'PICs and IDE drives' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PICs and IDE drives'.

Truncated match.
PICList Thread
'PICs and IDE drives'
1998\10\10@231406 by Chris Corben

flavicon
face
Gooday Piclisters

Has anyone out there any clues to interfacing a PIC to an IDE hard-disk?

My application involves a sort of datalogging process (storing bat calls,
actually). Data comes in at a minimum of 250 bytes/second, with bursts of up
to 30K bytes/second (but only for a couple of milliseconds at a time). At
present, I use a PIC and a very simple FIFO buffer to drive that data into a
laptop via its parallel port. No problem with that, except that I would like
to build a stand-alone unit for field use which doesn't involve driving a
whole laptop from a battery.

What I envision is the data being input asynchronously into a FIFO, then
when the FIFO half-full flag goes active, using a PIC to dump the FIFO
contents into the sector buffer of a hard-drive and tell the drive to go
store it. That's the input stage. Later, the PIC will read data from the
hard-drive, and feed it into a laptop's parallel port for downloading.
Alternatively, the PIC might feed the drive data into another FIFO, with the
FIFO being interfaced to the parallel port by some very simple logic, which
might achieve downloading a lot faster than the PIC.

Advantages I can see from using a PIC would be low cost (I could imagine
about $50 plus the hard-drive), relatively low power consumption, and
especially, that I already understand PICs and have the means to program
them. A disadvantage would be the relatively high power consumption due to
having the drive running all the time. If I could put together an input FIFO
of about a megabyte, that would allow me to switch the drive off most of the
time, which would no doubt save a lot of power. On the other hand, I suspect
that developing a megabyte FIFO would be a bit of a pain and greatly add to
the cost, and anyway, even with the drive running all the time, it should
still be an easy matter to run the unit for a full night from a smallish gel
cell, which would meet my requirements.

On the face of it, the concept doesn't seem too difficult to me, but It may
be that I'm extremely naive about this. I could imagine several possible
scenarios:

1) Maybe there are already single board computers out there with built in
IDE interfaces, costing less than $100 and drawing only a few milliamps.

2) Maybe the IDE interface is just too damn fussy about timings. What I've
read so far has told me about how fast you can write to the IDE, but not how
slowly!

3) Maybe it's just a lot messier than I think, having to deal with bad
sectors and formatting and stuff.

I'm not the slightest bit interested in any kind of file structure: I just
want to treat the hard-drive as a dirty big FIFO buffer.

Any comments, disagreements, suggestions, insults etc would be very welcome!

Cheers, Chris.


Chris Corben
PO Box 2323
Rohnert Park, CA, 94927-2323
USA
707-584-8711
spam_OUTcorbenTakeThisOuTspamdelphi.com

1998\10\11@002645 by Erik Petersen

flavicon
face
I will start off by saying I know nothing about coding for
an IDE drive, but if you get this figured out, an alternitive
to driving a mechanical drive would be something called
"DiskOnChip". I don't know what they cost, or how many writes
you get on them but I wouldn't imagine it would draw too much
power.

Cheers and good luck,

-erik

> {Original Message removed}

1998\10\11@044359 by Peter L. Peres

picon face
On Sat, 10 Oct 1998, Chris Corben wrote:

> Has anyone out there any clues to interfacing a PIC to an IDE hard-disk?

I did that for a Conner 20,40,60,80 MB laptop drive(s) with a PIC 16C64
some time ago.

> My application involves a sort of datalogging process (storing bat calls,
> actually). Data comes in at a minimum of 250 bytes/second, with bursts of up
> to 30K bytes/second (but only for a couple of milliseconds at a time). At
>
> Advantages I can see from using a PIC would be low cost (I could imagine
> about $50 plus the hard-drive), relatively low power consumption, and
                                            ^^^^^^^^^
Last time I checked there was no hard disk that required less than 250 mA
spinning and twice as much to start up. Flash disks need much less, but
the price...

> having the drive running all the time. If I could put together an input FIFO
> of about a megabyte, that would allow me to switch the drive off most of the
> time, which would no doubt save a lot of power. On the other hand, I suspect
> that developing a megabyte FIFO would be a bit of a pain and greatly add to
> the cost, and anyway, even with the drive running all the time, it should
> still be an easy matter to run the unit for a full night from a smallish gel
> cell, which would meet my requirements.

250 mA * 10 hours ~= 2.5 Ah, probably more as it's 250 mA @ 5 V and a
switching psu would gain something by converting down from 12 V.

> On the face of it, the concept doesn't seem too difficult to me, but It may

The difficult part is, to get the ATA commands working with the PIC, which
involves a serious amount of debugging usually, and the drive power
control / switching sequences are not exactly intuitive.

> 1) Maybe there are already single board computers out there with built in
> IDE interfaces, costing less than $100 and drawing only a few milliamps.

Not likely, more like $299 in ones.

> 2) Maybe the IDE interface is just too damn fussy about timings. What I've
> read so far has told me about how fast you can write to the IDE, but not how
> slowly!

Slowest speed = 0 bytes / sec ;) There is a sector buffer in there, at
least.

> 3) Maybe it's just a lot messier than I think, having to deal with bad
> sectors and formatting and stuff.

The simplest format you can use is LFS, aka Linked File System. This is
simply made up of sectors chained with a link field present in ea. sector
that points to the next sector to be used. There is no directory, no FAT,
nothing. Bad sectors are 'jumped' over during formatting. A formatted
sector has a checksum in it. RAID 0 and 1 are easy to implement over this
(hint: double or multiple parallel chains of sectors, spaced by N/2
cylinders).

> I'm not the slightest bit interested in any kind of file structure: I just
> want to treat the hard-drive as a dirty big FIFO buffer.

Yup. Look above. You can even wrap over to the start when it's full and
make it a ring buffer. An extra sector(s) can store the H and T marks
between spin-downs.

hope this helps,

Peter

1998\10\11@150306 by shadedemon

picon face
Peter L. Peres wrote:

> The simplest format you can use is LFS, aka Linked File System. This is
> simply made up of sectors chained with a link field present in ea. sector
> that points to the next sector to be used. There is no directory, no

 Hmmm you seem to be forgetting NFS, or No File System.
Just put raw data into sectors in order.  No links at all..
Works well on IDE since bad sectors don't exist or at least
are remapped.
Alan

1998\10\11@200943 by James Cameron

flavicon
face
Peter L. Peres wrote:
> On Sat, 10 Oct 1998, Chris Corben wrote:
> > Has anyone out there any clues to interfacing a PIC to an IDE
> > hard-disk?
> I did that for a Conner 20,40,60,80 MB laptop drive(s) with a PIC 16C64
> some time ago.

How many I/O lines did you need to talk IDE?

Possible with an 'F84?

Pinout at ...

http://margo.student.utwente.nl/el/pc/hd-info/ide-tech.htm#IDETECH_004

Outputs: 6 (maybe less)
Inputs: 3 (one interrupt)
Bidirectional: 8 (or 16?)

>From a quick reading of that page, I can see it would be a tough job.
Where would I find 512 bytes of RAM?  I'd have to add an external RAM
chip.

--
James Cameron                                    (.....cameronKILLspamspam@spam@stl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\12@000302 by Rob Wentworth

flavicon
face
>On Sat, 10 Oct 1998, Chris Corben wrote:
>
> Has anyone out there any clues to interfacing a PIC to an IDE hard-disk?
>

The IDE specs (PDF format - need adobe acrobat reader) are at:

  ftp://fission.dt.wdc.com/x3t13/t13.htm

You can look the older (simpler) specs to get an idea of what is needed for
interfacing to one of these drives.
 ----------------------------------
 Rob Wentworth,  Software Developer
 612/757-5829      fax 612/757-4792
 What we attend to becomes reality.

1998\10\12@085750 by Peter L. Peres

picon face
On Mon, 12 Oct 1998, James Cameron wrote:

> Peter L. Peres wrote:
> > On Sat, 10 Oct 1998, Chris Corben wrote:
> > > Has anyone out there any clues to interfacing a PIC to an IDE
> > > hard-disk?
> > I did that for a Conner 20,40,60,80 MB laptop drive(s) with a PIC 16C64
> > some time ago.
>
> How many I/O lines did you need to talk IDE?
>
> Possible with an 'F84?

No, unless you like serial bus expanders very very much (4094/4021 etc) ;)
I SUPPOSE that by daisy-chaining 3 F84s one could get there. I would not
really really like to program such a thing, the C64 job was tough enough.

> http://margo.student.utwente.nl/el/pc/hd-info/ide-tech.htm#IDETECH_004

Leave that alone, get the ata IDE draft or full document off the web. I
don't remember where, I have mirrored copies here.

> Outputs: 6 (maybe less)
> Inputs: 3 (one interrupt)
> Bidirectional: 8 (or 16?)

Make that 16 IO, 7 control outputs, one input == 24 pins + 1 power
control. = 25 IO for this alone. You can economize one pin (RESET).

> >From a quick reading of that page, I can see it would be a tough job.
> Where would I find 512 bytes of RAM?  I'd have to add an external RAM
> chip.

The sector buffer(s) is(are) in the IDE drive... I did say something about
using streaming algorythms in the PIC before on this theme ;)

Peter

1998\10\12@102058 by Richard A. Smith

flavicon
face
On Sat, 10 Oct 1998 16:34:35 -0400, Chris Corben wrote:

>1) Maybe there are already single board computers out there with built in
>IDE interfaces, costing less than $100 and drawing only a few milliamps.
>

Use a sandisk instead of a hard drive.  My calcs show you only need about 22 Meg
s of storage for a 24 hour peroid.  I believe that
sandisk makes a 40 meg option.  Sandisk is a small flash card that looks just li
ke an IDE drive.  We use them for HD
replacements on our equipment.

Go see http://www.sandisk.com

--
Richard A. Smith                         Bitworks, Inc.
rsmithspamKILLspambitworks.com               501.521.3908
Sr. Design Engineer        http://www.bitworks.com

1998\10\12@112910 by Rob Wentworth

flavicon
face
At 03:24 PM 10/12/98 +0000, Peter L. Peres wrote:
>On Mon, 12 Oct 1998, James Cameron wrote:
>
>> Peter L. Peres wrote:
>> > On Sat, 10 Oct 1998, Chris Corben wrote:
>> > > Has anyone out there any clues to interfacing a PIC to an IDE
>> > > hard-disk?

---<snip>---

>
>     ... get the ata IDE draft or full document off the web. I
>don't remember where ...


The IDE/ATAPI (T13 committee) specs are stored at:

  ftp://fission.dt.wdc.com/x3t13/t13.htm#Project drafts

 ----------------------------------
 Rob Wentworth,  Software Developer
 612/757-5829      fax 612/757-4792
 What we attend to becomes reality.

1998\10\12@170358 by Mark Willis
flavicon
face
Peter L. Peres wrote:
{Quote hidden}

 One thought;  You could also, for slow data transfer rates at least,
look at the ValueStor type parallel port hard drive converters (Convert
an IDE or SCSI hard drive, or a CD-Rom Drive, to a Parallel port
interface.)  There's a Linux driver for both IDE models of these (I have
one old & one new version, ack!) - Fewer I/O lines would be necessary
for interfacing to a parallel port & so on - but, would too much speed
be required? (There's the rub <G>)

 I haven't really looked into this yet, but it's an interesting thought
at least!  (These units to require external power, usually an AC
adapter, I mean to hack that someday & make one mobile off a battery...)

 Parallel Port Linux drivers for this were off the Linux Parallel Port
Home Page at http://www.torque.net/parport/.

 Mark, .....mwillisKILLspamspam.....nwlink.com

1998\10\13@121424 by Peter L. Peres

picon face
On Mon, 12 Oct 1998, Mark Willis wrote:

>   One thought;  You could also, for slow data transfer rates at least,
> look at the ValueStor type parallel port hard drive converters (Convert
> an IDE or SCSI hard drive, or a CD-Rom Drive, to a Parallel port
> interface.)  There's a Linux driver for both IDE models of these (I have

That's right, but even the fastest PIC will have a hard time toggling data
into the IDE in a way that would make it even as little as notice it is
being used. Ok, there is an easy hardware way to fix that, but speed is
not the issue here. Parts count and cost are. Even the miserly Connors I
had used can do 500 kBytes/sec, and no PIC can keep up with that.

The C64 solution I came up with used 1 Xtal 1 resistor 1 capacitor 1 fuse
and 1 VFET power switch besides the C64. period. That's 6 parts, folks.
Ah, yes, the Connors need only +5V to run. There is some room left in the
C64 too. And yes, I did use the crystal in series mode w/o pi load
capacitors.  I always do, makes the circuit much more stable. Try R=1M5
in parallel with a usual crystal on ANY pic.

>   Parallel Port Linux drivers for this were off the Linux Parallel Port
> Home Page at http://www.torque.net/parport/.

(working hard to stay in the top)

Peter

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...