CF cards and changing PIO modes (to enable IORDY) - Page 1
Forum section: electronics / general

author: TomS_
author_rank: Frequent Contributor
timestamp: January 17, 2024, 06:41:22 pm
content: 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!

author: Postal2
author_rank: Frequent Contributor
timestamp: January 18, 2024, 02:37:09 am
content: 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).

author: TomS_
author_rank: Frequent Contributor
timestamp: January 18, 2024, 07:37:26 am
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 18, 2024, 08:54:42 am
content: 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).

author: TomS_
author_rank: Frequent Contributor
timestamp: January 18, 2024, 11:37:40 am
content: 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 activatedsometimes, if the CF card is too busy?

author: Postal2
author_rank: Frequent Contributor
timestamp: January 18, 2024, 12:06:10 pm
content: Quote from: TomS_ on January 18, 2024, 11:37:40 amExactly yes. No flip-flop at normal mode.

author: TomS_
author_rank: Frequent Contributor
timestamp: January 18, 2024, 12:14:27 pm
content: I guess that kind of matches what I am seeing. But it also sounds like I am going to have to ensure thatImeet the minimum timing requirements on my own, rather than letting the CF card pace me, which is what I was ideally hoping for.Thanks!

author: Postal2
author_rank: Frequent Contributor
timestamp: January 18, 2024, 12:20:20 pm
content: You must check IORDY (or via HAL), but not use it as data strobe. OK.

author: TomS_
author_rank: Frequent Contributor
timestamp: January 18, 2024, 03:01:23 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 19, 2024, 02:38:02 am
content: Quote from: TomS_ on January 18, 2024, 03:01:23 pmWrong. Chain is: busy media => buffer full => IORDY.

author: TomS_
author_rank: Frequent Contributor
timestamp: January 19, 2024, 08:15:05 am
content: Quote from: Postal2 on January 19, 2024, 02:38:02 amWhat 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.

author: 2N3055
author_rank: Super Contributor
timestamp: January 19, 2024, 08:21:35 am
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 19, 2024, 09:57:21 am
content: Quote from: TomS_ on January 19, 2024, 08:15:05 amYour picture is correct, use it. Exactly, you can see IORDY when device is selected, axiom.

author: TomS_
author_rank: Frequent Contributor
timestamp: January 19, 2024, 10:09:30 am
content: Quote from: 2N3055 on January 19, 2024, 08:21:35 amYes, 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.

author: 2N3055
author_rank: Super Contributor
timestamp: January 19, 2024, 11:15:03 am
content: Quote from: TomS_ on January 19, 2024, 10:09:30 amYou 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 19, 2024, 11:50:19 am
content: Quote from: TomS_ on January 19, 2024, 10:09:30 amPostal2 has knowledge about interfaces however.

author: TomS_
author_rank: Frequent Contributor
timestamp: January 19, 2024, 01:48:26 pm
content: Quote from: 2N3055 on January 19, 2024, 11:15:03 amI dont dispute that, I just want to understand it.