CF cards and changing PIO modes (to enable IORDY)

[TomS_]

Hi all.

Im trying to enable the IORDY signal on a CF card. The capabilities word obtained from an "identify" command states that it is supported (along with PIO modes 3 and 4 where this signal is mandatory).

It seems I should only need to use the "set features" command with feature 3 and supply the appropriate value, in this case 0xB (1011) to enable PIO mode 3 and IORDY.

I do this, and the drive does not report any errors in either the status or error registers suggesting that it accepted the command, but I never see the IORDY signal toggling when reading/writing after that.

Has anyone ever done anything like this before and knows the process? Ive been googling for hours looking at any and all documents about IDE, ATA, PIO, etc that I can find and they all seem to suggest about the same thing so Im not sure what Im doing wrong.

Thanks!

[Postal2]

As far I remember, IORDY reports about interface, not media. Will be set shortly when too big data sending. Small chunks will not affect him. When IORDY is active - computer is fully stopped (true for BIOS routines).

[TomS_]

Yes that is correct, and I want to use it on the interface side of things to time bus cycles according to the CF cards ability to complete them.

The specific use case is to tie IORDY into the generation of the DTACK signal in a Motorola 68000 system.

[Postal2]

IORDY as I know is fatal error indicator, it is not an irq request. It is signal of interface only, not bounded to busy of media. Of course, you can use it with your own low-level non-standard routines. To activate this signal you must overload data path (send too much data).

[TomS_]

I know its not an IRQ. But the datasheets do not mention anything about it being an error signal as such.

Do you mean to say that the IORDY signal might only be activated sometimes, if the CF card is too busy?

[Postal2]

Do you mean to say that the IORDY signal might only be activated sometimes, if the CF card is too busy?

Exactly yes. No flip-flop at normal mode.

[TomS_]

I guess that kind of matches what I am seeing. But it also sounds like I am going to have to ensure that I meet the minimum timing requirements on my own, rather than letting the CF card pace me, which is what I was ideally hoping for. 

Thanks!

[Postal2]

You must check IORDY (or via HAL), but not use it as data strobe. OK.

[TomS_]

I dont think it should be checked via any kind of software layer.

It is negated by the CF card when the bus cycle should be stretched, and asserted when it is ready to complete its bus cycle.

I could only check it in software if the read and write cycles were "bit banged", but my read/write cycles are move instructions executed by the CPU, therefore I could not check it in software.

This is why I want to integrate IORDY as a component of the DTACK signal - the CF card can negate IORDY and my logic will not assert DTACK until the CF card asserts IORDY. This is how the datasheet portratys this signal.

[Postal2]

It is negated by the CF card when the bus cycle should be stretched, and asserted when it is ready to complete its bus cycle.

Wrong. Chain is: busy media => buffer full => IORDY.

[TomS_]

Wrong. Chain is: busy media => buffer full => IORDY.

What is your reference for this, because this doesnt seem to be what the datasheets say about IORDY.

For example:



To me this says that the card will negate (pull low) the IORDY signal when it is busy during a bus cycle, and will release (it is open collector, so it floats back high by pull up resistor) once it is ready to complete the bus cycle.

[2N3055]

Just think of it as active LOW  /BUSY signal...

It is handshake signal to inform interface to insert wait states because buffer cannot receive data at the moment. Reason is irrelevant.

[Postal2]

What is your reference for this

Your picture is correct, use it. Exactly, you can see IORDY when device is selected, axiom.

[TomS_]

It is handshake signal to inform interface to insert wait states because buffer cannot receive data at the moment. Reason is irrelevant.

Yes, I am aware of this...

My original question is really whether I should be seeing it on every bus cycle because I do not, and the datasheets and spec documents are horrible and do not seem to explain its exact behaviour well enough for me to figure it out myself.

But answers from here and elsewhere seem to point towards it only be used occasionally if needed, and in particular for my host system, it may never be used at all (because its not fast enough to get close to overwhelming the card).

Postal2 does not seem to be a native English speaker so I am simply trying to work through the language barrier to come to a concrete understanding of what they are saying. 

[2N3055]

It is handshake signal to inform interface to insert wait states because buffer cannot receive data at the moment. Reason is irrelevant.

Yes, I am aware of this...

My original question is really whether I should be seeing it on every bus cycle because I do not, and the datasheets and spec documents are horrible and do not seem to explain its exact behaviour well enough for me to figure it out myself.

But answers from here and elsewhere seem to point towards it only be used occasionally if needed, and in particular for my host system, it may never be used at all (because its not fast enough to get close to overwhelming the card).

Postal2 does not seem to be a native English speaker so I am simply trying to work through the language barrier to come to a concrete understanding of what they are saying. 

You could or not see it asserted.  CF cards have buffer for  interface and  there is a process in background that lazy writes data in background. As long as your buffer does not reach high watermark (getting close to being full) it is ready to receive new data. It will depend on internal buffer size, how fast(slow) it actually commits data to storage layer (releasing buffer allocations by virtue of it), and how frequent are your writes and data size in every write.
For read, it is all the same, just in reverse: You ask for data and then have to wait for storage layer to get it from slow flash into buffer and then you can have it. Unless you just wrote it and it was not flushed from cache (buffer) so you can have it imediatelly.

This is disk interface, namely IDE disk interface. Literally. Handshake is a way of life and has to be pivotal part of transfer logic.

That is it.

[Postal2]

Postal2 does not seem to be a native English speaker ...

Postal2 has knowledge about interfaces however.

[TomS_]

This is disk interface, namely IDE disk interface. Literally. Handshake is a way of life and has to be pivotal part of transfer logic.

That is it.

I dont dispute that, I just want to understand it.