I need some consultancy from someone with ATAPI design expertise

One data point: the inner loop of a PIC18 clocked at 40MHz (10MHz instruction cycle) can do PIO over directly connected ATA into internal RAM at approx 2 bytes/1us (2MB/sec), which is comfortably >8X but less than 16X. But that is fully utilising the MCU; seems to me you'd need a much faster MCU, or external RAM & DMA to handle realtime concurrent I/O and processing at 8X. (Doesn't matter for my application, which is non-realtime, PIO, and synchronous.)

--Toby

I don't like the idea of using DMA. I'd rather use a fast MCU. I'll only need to read data at 1x, since the CD's will only be played back. But if it's true that newer CD-ROM's can't read CD's at speeds below

8X...

I exaggerated a little. On further reflection, if all you're doing is spitting the data out again, the 40MHz PIC18 may manage 8X. Can you be more specific about what happens to the data?

The data will have to be played back. It will go to a DAC in I2S format, that's all I have to do. The only problem is that I'll have to send some data to a LCD display too, playback time, number of track, exactly as in a CD-player.

Why not try to get it working on an older stipped down PC under dos or linux, writing all the drivers to talk directly to the hardware (on an old board, the IDE interface is scarcely more than some buffer chips). This will give you a handle on the complexity of the task, in particular any 'gotchas' with regard to getting CD-DA working reliably. Then you can choose a suitable micocontroller, and either port your c code from the PC or implement all or part of it in the apporpriate assembly language.

My personal preference would be to use linux as a development platform will a full human interface and convince the IDE driver to ignore the second IDE interface so that you can do your experiments there. Just don't copy any of the linux IDE or ATAPI code unless you are willing to GPL your project too.

Chris

An alternative to keep in mind is that any modern CD drive (which are the only ones that can do CD-DA) also has a S/PDIF digital audio out on the back, which is by definition 1x (though I did see one accidentally play at 2x once... discovered that my project could do

96khz audio!). If you get a DAC that can handle S/PDIF rather than first decoding it to I2S, that would save the micro having to deal with the audio data at all - you'd just have to read enough of the disc to be able to navigate and display what you need to.

Or you could use the CD drive's DAC too, and not worry about digital audio at all. Or if it's a one-off project, you might be able to hack into the drive and get I2S signals before it's dac and break those out to drive a better one.

On reflection this is probably easier than we thought. Since the PIC reads at more than 8X, you can get one second's data (176KB or so) in less than 1/8 second - but you have the rest of the second's duration to process it. Which is much more time than should be required.

But I'm wondering about something else: if you are talking

*uncompressed* audio, can you just play CDDA directly via ATAPI commands?

--Toby

This is not a bad idea but would likely entail doing it twice - and I don't recommend debugging an IDE driver twice :). It's not really feasible to make the code portable between the two unless you already know your target MCU, the quirks of its compiler, and you're adept at making C portable under very difficult conditions.

I can confirm that the PIC18 can do it; I've just got direct-connected ATA and ATAPI working with a PIC18F6680 (40MHz external clock, but it could be much slower). Program size for my driver, including error checking, many text strings, a simple RS232 command monitor and utility routines such as ASCII formatting, is around 3Kb, with RAM use to GPL your project too.

It would be practically impossible to re-use even tiny fragments of O/S drivers on a PIC. If licensing is an issue, there is of course much BSD code available for reference, and I intend for my project to be released GPL in any case...

--

> 
> Chris

Agree. Building a test system from scratch might be easier.

OK, but please tell me 2 things:

1. what CD-ROM did you use?
2. what datarates did you read at?

Agree.

Tried 3 different drives, including a DVD-ROM. All fairly modern, I'd expect all faster than 8X, though I haven't checked what they report.

As mentioned above, data rate from drive buffer to PIC is 2MB/sec (peak). I haven't tried a sustained read, I can benchmark this if you like; from a data CD would be easiest since I have those handy, or I can burn a CDDA disc to test.

--Toby

If it's not too much an effort, that would be great, burning a CD-DA and benchmark the sustained datarate. I'd appreciate it ;)

OK, I made some timings with a CD-DA disc, reading 100 sequentially addressed sectors without stopping ("user data" of 2352 bytes/sector), near the start of the disc.

Lite-On LTN-301 took 0.287secs (for some reason this drive wanted to transfer a non-standard 2448 bytes per sector). One hundred standard CD-DA sectors transferred in that time is around 800KB/sec. In its Capabilities page, this drive states "5644 KB/sec", which I suppose means 32X.

The second drive I tried was slightly faster: Pan-International 480D, marked "48X MAX". It took 0.242secs, for a data rate of 949KB/sec. This drive's Capabilities page states "8800 KB/sec", or 50X.

So I was wrong, it is not up to 8X, only 4.5-5.5X, remembering this is just direct PIO with a PIC18F6680 @ 10MHz (40MHz ext clock).

For comparison, reading a comparable amount of data (230KB) from a QUANTUM FIREBALL_TM2550A takes 0.154sec, approx 1.46MB/sec. This would be entirely buffered in the drive, and are single sector reads. Multiple sector reads (four fit the CD's 2048+ byte buffer) would reduce overhead somewhat and raise throughput closer to the configuration's theoretical peak of 2MB/sec, worked out by counting cycles. This is still slower than the slowest Mode 0 PIO parameters.

The PIC doesn't have enough RAM to allow multiple CD sector reads, and if you use external RAM you could solve the throughput problem with DMA anyway.

--Toby

One more question regarding ATAPI. I settled on a non-DMA chip (C8-051F130 from Silicon Laboratories). What I want to know is: can the IORDY and INTRQ pins be used with PIO modes? I know that PIO modes can work without them, but what I'm not sure about is if they have any meaning in PIO modes at all or they're DMA-specific. I know, you'll tell me "go read the specs" but right now I'm in the stage of devising a schematc and want to be 100% sure before building the prototype PCB (it will be made in industrial conditions with soldermask, silkscreen etc) and it would be nice to get it right from the first time you know... :)

I had a look at the datasheet. Nice part, should be plenty fast. We didn't want to bother with QFP in our project; our PIC18 MCU is PLCC.

I do not use these signals (only DIOR_, DIOW_, DA, CS0_, CS1_, DD, and DASP_ & RESET_ during initialisation). The ATA-2 spec does say "The use of IORDY is required for PIO modes 3 and above."

A c.a.e poster recently used a form of this that is unusually polite by Usenet standards: "Go read the specs, you will need to eventually, so why not do it now?"

--Toby

snipped-for-privacy@telegraphics.com.au (Toby Thain) wrote in message news:...

Of course you're right but I think you can agree that standardisation documents are bloaaaaaated, and although experienced designers will recommend reading them from cover to cover, after doing so you usually end up convincing yourself that more than 50% is (excuse the word) bloat. The ATAPI spec I have is almost 500 pages long :( A spec should cover all the details, like designing an ATAPI device that supports all the features, but hey, how many of us did that? I'm not intending to design a 52x CD-ROM, if you get my point :) Of course one should read the spec thoroughly just to ensure that nothing crucial is missed but like any cumbersome process it is prone to error. Let me take an example. The electrical specs around page 11 (in my doc) says that a pull-down resitor for DMARQ is required at the host. There isn't a note that says that this is required for DMA modes only. But if you search on the internet for IDE projects you'll find that no-one puts that PD resistor and it works.

Thanks for the information, and excuse the rant :D