[electrick]

Tach,
ich baue zur Zeit einen ATAPI Controller (standalone CD-ROM Controller um Audio Tracks auszulesen).
Dabei hab ich ein Problem mit dem Verständnis des ATA Protokolls, genauer gesagt habe ich wohl die die Timing-Diagramme für PIO-Transfer (Registertransfer) nicht so richtig verstanden, denn mein Controller funktioniert mit einigen Laufwerken, mit anderen jedoch nicht (Verhältnis 1:2 ).
Kann mir jemand erklären wie ein Register-Lese/Schreib Zugriff auszusehen hat? Das was dazu im ATA-Standard steht, ist für mich nicht so eindeutig verständlich...
Danke schonmal.

[Jørd]

Du solltest Dir vermutlich mal die Timingdiagramme des ISA-Busses ansehen - die IDE-Schnittstelle hängt nämlich i.d.R. mehr oder weniger direkt dadran.
Vor etlichen Jahren war mal ein sehr ausführlicher Artikel darüber in der c't (11/91), der leider in der elektronischen Version auf CD auf übelste entstellt wurde (die Timingdiagramme fehlen).

Mit was für einem Controller steuerst Du Dein CD-Laufwerk an und wie hast Du den 16-Bit-I/O-Zugriff gelöst?

[electrick]

Hello,
Mit dem ISA-Bus hab ich nichts am Hut, da ich nur ein ATA bzw ATAPI Device benutze und meinen Controller direkt daran hänge, ohne PC.
Der Controller ist ein fpga und mit dem 16 Bit Zugriff hab ich eigentlich keine Probleme, der Datenbus ist ja auch 16 Bit breit... Oder hab ich dich jetzt irgendwie missverstanden?
Das eigentliche Problem für mich ist, die PIO-Timings korrekt zu implementieren, da das Ganze zur Zeit nicht zuverlässig mit verschiedenen Devices funktioniert.
Danke für deine Hilfe

[Jørd]

Mit dem ISA-Bus hast Du insofern was am Hut, als daß das Port-I/O-Timing dessen Gepflogenheiten entsprechen sollte.
Ein 16-Bit-I/O-Zyklus ist etwa 400 nsec lang - vielleicht bist Du zu ungeduldig resp. zu schnell?

Könntest Du mal ein Timingdiagramm Deiner Zugriffe irgendwo ablegen, auf daß ich mir das mal ansehen kann?

[electrick]

Original geschrieben von Jørd
Mit dem ISA-Bus hast Du insofern was am Hut, als daß das Port-I/O-Timing dessen Gepflogenheiten entsprechen sollte.

Warum das? Es geht ja um das ATA-Protokoll, und das hat ja für die verschiedenen PIO-Modes die Timings definiert.

Könntest Du mal ein Timingdiagramm Deiner Zugriffe irgendwo ablegen, auf daß ich mir das mal ansehen kann?

Ich probiers mal hierhin zu malen, für einen Lesezugriff auf ein Register:

     _______    350ns    _____________      _______
DIOR-       \___________/    350ns    \____/


ADDR             ___________________
valid___________/                   \______________


laut referenz sollten die Daten   ________
dann ungefähr hier stabil sein:__/        \______

Wie gesagt klappt es so leider nicht. Die Daten sind zu keinem Zeitpunkt wirklich stabil...

[Jørd]

Das kann so nicht stimmen.

DIOR- ist ein Signal, das für einen Lesezugriff low sein muss - daß die zu lesenden Daten fast 300 nsec nach einer steigenden Flanke davon anstehen, das kann so nicht sein.
Wenn in Deinem Timingdiagramm DIOR- invertiert wäre, dann sähe das sinnvoller aus.
Wertest Du das vom Laufwerk generierte IOCS16- -Signal aus?

[electrick]

Original geschrieben von Jørd
Wenn in Deinem Timingdiagramm DIOR- invertiert wäre, dann sähe das sinnvoller aus.

Ja, das hatte ich auch schonmal probiert, hat aber nicht funktioniert.
Ich glaube schon, dass das vom Prinzip so richtig ist, also DIOR- als "active low signal".
Es wäre nett wenn du einmal in diese pdf schauen könntest, auf Seite 138, und mir sagen, könntest wie du das verstehst...

Wertest Du das vom Laufwerk generierte IOCS16- -Signal aus?

Das iocs16 ist seit ATA2 nicht mehr Teil des Standards. Deshalb mache ich da auch gar nichts mit...

Danke für Deine Hilfe.

[Jørd]

Eben. DIOR- ist ein active-Low-Signal.

Dieses Timingdiagramm ist mit Vorsicht zu genießen - sieh' Dir mal die Defintionen in Abschnitt 9.3 auf Seite 122 (136) an - Active-Low-Signale werden invertiert dargestellt!
Das ist ja hirnkrank!

Damit ist das Timingdiagramm auf Seite 124 (138) besser zu verstehen.
Der Lesezugriff wird also durch Anlegen von Adressen (und CS) eingeleitet.
Diese Signale müssen t1 lang stabil sein, bevor mit einer fallenden Flanke von DIOR- (Invertiert!) der eigentliche Lesezugriff beginnt.
Das ist die senkrechte Linie zwischen t1 und t2.

Ab wann gültige Daten zum Lesen zur Verfügung stehen, ist im Diagramm nicht direkt dargestellt - die eigentlich naheliegende Rechnung t2 - t5 ist so nicht wirklich zulässig. Dabei ist die einzige Flanke, auf die man sich hier beziehen kann, eben jene fallende von DIOR- zwischen t1 und t2.

Je nach PIO-Modus muss also DIOR- lange genug aktiv (low) sein, damit t5 davor stabile Daten anliegen.

Das ist ein Gurkendiagramm, von vorne bis hinten. Noch praxisferner kann man sowas kaum noch darstellen. Idiotenbande.

Wie auch immer:
1. Adressen (und CS-) anlegen, t1 warten
2. DIOR- auf low setzen, t2 warten
3. Daten übernehmen
4. DIOR- auf high setzen, t2i warten

Lass' Dich nicht von der ersten Flanke von DIOR- im Timingdiagramm verwirren (die, bei der t0 anfängt).

[electrick]

Danke für deine Erklärungen!
Du wie Du es beschrieben hast, hatte ich es auch zu allererst gemacht. Das hatte auch funktioniert, jedoch nicht mit allen Laufwerken, die ich getestet hatte. Deshalb war ich dann davon ausgegangen, dass es dann wohl so sein müsste wie oben dargestellt... Egal, ich probiers nochmal aus, und probiere etwas mit den timings rum.
Melde mich dann nochmal.

[electrick]

hallo nochmal,
sieht so aus als hättest du recht gehabt. Ich hab nochmal einiges getestet so wie du es vorgeschagen hast und die Quote funktionierende Devices zu nicht funktionierende liegt jetzt bei 5 zu 2. Das reicht mir
Die spezifikation ist echt der letzte Dreck.