CompactFlash Identity - industry standard?

I have managed to access a Sandisk CompactFlash device using an 8051 micro, and am able to read its identity, and also read and write sectors in this device. Next task is to tackle FAT16...

My question relates to the Identify command (0xEC) with which one can check out the CF device's intrinsic parameters. Does one always have to use this command to electronically determine what the capacity (max number of sectors) of the CF device is? And is this same command also used to interrogate other storage devices' capacity, such as HDD's, diskettes, CDROM's(?)

Thanks Jack

Reply to
Jack
Loading thread data ...

Yes. How else were you planning to identify the card's characteristics?

HDDs - yes (though note that the situation is much more complicated with HDDs - for instance, only a very few very old "XT-IDE" drives support 8-bit mode, so you MUST use 16-bit data bus with those drives. Also, HDDs are not guaranteed to support LBA mode, and there are a host of other archaeological oddities that may or may not be important).

CD-ROM drives are not IDE, they are ATAPI. The command set is totally different (it is SCSI commands encapsulated in IDE transactions).

Floppy drives - it depends. I assume you're talking about IDE-interface drives, not 34-pin drives. Modern floppy drives that have a 40-pin interface are probably ATAPI, but some older flopticals behaved like a hard disk. IDE(ATAPI) floppy drives are not at all common. But why do you care about them anyway - the floppy disk is practically obsolete.

Reply to
Lewin A.R.W. Edwards

Thank you for the response & explanation Lewin. Since it is my first venture into the world of integration of mass storage devices into embedded devices, I was curious about determining the identity of e.g.

1.44" diskettes - not that I ever intended using diskettes!
Reply to
Jack

Floppy drives in the main use a 34-pin interface which is unrelated to IDE. They require a special controller IC. It's very hard to find suitable controllers these days, because the only mass-market application for them is PCs (so the easiest way to get a floppy controller is to buy a super I/O chip containing 2S 1P FDD etc - and these are HARD to find in easy-to-interface flavors now). While it's possible to have a dedicated micro doing the floppy control, it's a bit of a pain. Embedded applications these days tend to prefer removable flash media. The main reason for using floppy disks was data interchangeability with PCs. PCs are often not shipped with floppy drives any more.

There is no really hard-and-fast way to identify what kind of media is in the drive; part of the required information is user-supplied (CMOS settings). This is kind of a good thing, because it allows you to do hybrid disk formats, e.g. 19spt instead of 18 on a 1.44 disk.

Reply to
Lewin A.R.W. Edwards

SMSC is makeing a dedicated floppy controller. I used it in one of my last projects. Writing the low level IO routines was a bit of a pain cause these controllers leave quite some burden up to the processor controlling them.

I fully agree with you that if there is not a VERY strong requierement for floppy access, there are - as you mentioned - much better solutions possible these days.

Basically I just wanted to give a hint for a source of floppy controllers if one really absolutely must have one.

Markus

Reply to
Markus Zingg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.