IDE-Schnittstelle 2

[PauleFoul]

@ tomster

Also ich hätte schon interesse die Dinger fux und fertig zu kaufen.

Würdest du denn eine "Kleinserie" auflegen??


Gruß
____Paule

[eule]

...(vor allem wenn sich da eine Brücke bilden sollte wo sie nicht hingehört.) Habe nun mal keinen Heisluft lötkolben.
Gruß Gorcon

Dazu brauch ich keinen Heißluft-Lötkolben. Das macht auch noch meine alte Weller WECP.... Alles sauber verzinnen (eine Lötzinnperle über alle Pins einer Seite) und Zinn wieder durch geschickte Bewegungen der Spitze unter Ausnutzung der Oberflächenspannung und Beigabe von Flußmittel abziehen. Danach Kontrolle mit einer Lupe ob alle Pins angelötet und keine Brücken zwischen den Pins sind. Das geht ruck zuck...

[Gorcon]

Danke für die Tipps.

Gruß Gorcon

[tomster]

Hallo PauleFoul

Kleinserie würde sicher gehen. Dafür finden sich schon ein paar Leute hier, die die Lötarbeit übernehmen denke ich. Nur nochmal:
Ich denke es ist einfach noch zu früh um die Platinenbestellung aufzugeben. Es macht einfach nur Sinn, wenn man mal gute 100 Stück bestellt. Und ich will da auch nicht unbedingt in Vorlage gehen.
Lass uns doch warten, bis das Interface wirklich 100% funktioniert, soll meinen inkl. der Treiber und sämtlicher anderen notwendigen Files. Erst dann wird die Bestellung Sinn machen. Es kann ja sein, dass sich bis dahin noch etwas am Layout ändert (Stichwort Netzwerkinterface und andere Gimmicks). Dann wären die "alten" Platinen sicher nicht mehr sonderlich gefragt...

Ich hab auch noch keine Infos wie und wo man die benötigten Memory connectors bekommt. Da gab es meines Wissens bislang keine Möglichkeit die Dinger zu bestellen. DBoxBaer hat aber wohl was aufgetan. Erst wenn man da Mal anfragt, wieviel die Stecker und die anderen passiven Bauteile kosten kann man auch eine Angabe über den Gesamtpreis machen.

Ich selbst kann höchstens bei der Lötarbeit/ Organisation behilflich sein. Von der Software habe ich keinen Plan. Da muss ich mich, wie du, auf Andere verlassen. Aber ich denke, bei den derzeitigen Aussichten auf Erfolg werden sich schon ein paar schlaue Köpfe finden, die mit DBoxBaer zusammen den "ist ja dann nur Software"-Teil übernehmen.

[PauleFoul]

@ tomster

Kein Problem. Ich wollte eigentlich nur zu Ausdruck bringen, dass es
schön wäre wenn sich jemand (DU?) um die Hardware kümmern könnte
um die Sache etwas zu vereinfachen. Ist halt net jedermanns Sache
IC es, Widerstände bei Reichelt zu bestellen, Platinen zu ätzen und das
dann auch noch vernünftig zusammen zu löten...

Natürlich sollte erst die Funktion gegeben sein und das Stück Software
auch richtig laufen...

Gruß
____Paule

[gurgel]

Ist halt net jedermanns Sache ...
Platinen zu ätzen ...

diese hier kriegt man als Hobbybastler auch nicht mehr hin, selbst ich würde sie bestellen...

[tomster]

Wie angeboten:
Ich bin gern behilflich. Aber allein werd ich das nicht schaffen. Das geht mit ein paar Platinen, aber nicht mit 20, 50 oder 100.
Und gurgel hat da Recht. Selber ätzen tut heut keiner mehr. Erstens sind die Ergebnisse meist eher bescheiden und 2. warum sich die Hütte dreckig machen, wenn man eben für ein paar Euro fuffzig je Platine die Dinger in's Haus geschickt bekommt.

Evtl. kann man sogar noch ein bissl sparen, wenn man bei DBoxBaers Hersteller anfragt. Dann würden die Einrichtungskosten wohl wegfallen und man zahlt nur noch die reine Platine. Aber wie gesagt, alles Zukunftsmusik. Deine und meine Euphorie dabei natürlich in allen Ehren. Ich kann's ehrlich auch nimma dawarten; aber wie heisst's so schön Neudeutsch: "the show ain't over till the fat lady sings".
Und ich hab bislang nur das Einsingen vernommen...

[Gorcon]

Ist halt net jedermanns Sache ...
Platinen zu ätzen ...

diese hier kriegt man als Hobbybastler auch nicht mehr hin, selbst ich würde sie bestellen...

Sehe ich auch so, vor allem wegen der vielen durchkontaktierungen.
Der Aufwand wäre auf jedenfall um einiges höher.

Lötstoplack habe ich bis jetzt auch nie irgendwo in kleinen Mengen kaufen können.

Gruß Gorcon

Ab und zu ätze ich auch noch Platinen, aber bei zweiseitigen mache ich das nur ungern.

[bROAdWAY]

Super Sache.
Ich habe schon den ersten IDE-Beitrag mit großem Interresse verfolgt.

SMD-Löten sowie Teilebeschaffung ist für mich kein Problem.
Wenn Ihr also noch Hilfe in der Richting benötigt meldet euch einfach ...

[Tommy]

dann tu doch als erstes quellen für die Stecker (Sagem, Nokia, Philips) auf - das ist sicher die schwerste Aufgabe von allen

[gurgel]

dann tu doch als erstes quellen für die Stecker (Sagem, Nokia, Philips) auf - das ist sicher die schwerste Aufgabe von allen

für Sagem ist das kein Problem, da kann man gleich die Paltine entsprechend designen.

[Tommy]

für Sagem ist das kein Problem.

na da fällt mir ja ein Stein vom Herzen mit meinen drei getreuen Sagems

[bROAdWAY]

Da war Gurgel schneller als ich

[MPC823]

Ich hatte mal Ersatzstecker für Connector der Speichererweiterung gefunden. Das Problem an der Sache das die Sauteuer sind und man die Dinger nur in Grossmengen bekommt. 20 Stk bestellen ist da nicht

Für die Testboards ist es wohl am besten man findet eine alte Speichererweiterungsplatine und lötet den Stecker da runter.


Greets Martin

[bROAdWAY]

@MPC823

Hast du evtl. noch den Preis den Du für den Connector gefunden hast im Kopf?

[MPC823]

Die VPE war 1000 Stk und der Preis lag wenn ich mich recht erinnerere bei ca 5 Euro. Ich kann da aber nochmal nachfragen wegen dem Preis und der Mindestabnahme, wenn intresse besteht kann ich da nochmal nachforschen.


Gruss Martin

[chkbox]

Kennt irgendwer die Spezifikationen für einen DIMM 100 Slot? Übers Pinout gibts was in einigen Datenblättern und irgendwo hier im Forum. Für ein Layout sind aber auch die mechanischen Daten nicht ganz unwichtig
Ich habe zwar ein Modul hier, aber irgendwie habe ich wenig Lust das auszumessen...

Wie werden die Signale eigentich genutzt? Ist es möglich RAM Erweiterung und IDE gleichzeitig zu nutzen? Wäre für alte Nokias wichtig und ich habe meine 64 MB auch für Puffer schätzen gelernt...

[Tommy]

ich habe meine 64 MB auch für Puffer schätzen gelernt...

Speicheraufrüstung wird ja oft belächelt - Meinst Du mit Puffer eine Verbesserung beim streamen? Könnte man so den Ringbuffer weiter aufbohren?

[DBoxBaer]

Speicher und CPLD parallel zu benutzen ist im Moment nicht vorgesehen:
Einmal verwende ich relativ viele Adressleitungen um damit "Daten" (besser "Information"...) zu übertragen (damit der CPLD weiss, was er eigentlich machen soll). Der Adressraum wird dadurch recht grossflächig missbraucht.
Zweitens kollidieren die Zugriffe natürlich einfach, da ein RAM recht dumm ist...
Drittens ist es Leitungstechnisch für den CPU Bus evtl. nicht ganz trivial, in einem entsprechenden Layout der Platine muss man dann sehr gut aufpassen.

Lösbar wäre es trotzdem, hat allerdings einige Konsequenzen:
Hintergrund:
Zwischen CPU und SDRAM werden Kommandos ausgestauscht. Diese Sequenzen sind in der UPM der CPU gespeichert und sind im Prinzip so Dinge wie "Select Row", "Write", "Read", "Refresh", etc.
Es gibt auch das Kommando "NOP", und da macht ein RAM nix: Der CPLD könnte nun dieses Kommando verwenden um Daten zu transportieren. In dem Fall müsste eine solche Sequenz in der UPM abgelegt werden. Man kann so eine Sequenz auch selbst basteln: Es gibt dafür ein Tool von Motorola/Freescale, habe ich auch verwendet um das Timing, das die DBox verwendet, wieder lesbar abzubilden. (Diese Timing Diagramme daraus lege ich demnächst dann wohl auch mal irgendwo hin: Ich glaube, das passt vielleicht gut ins Wiki?!).

Etwas doof ist aber evtl. der Zugriff um diese Sequenzen zu verwenden, man muss über irgendwelche Register des Memory Controllers der CPU diese Sequenzen anstossen, es ist dann kein normaler Memory Zugriff mehr.
Auf der anderen Seite ist das vielleicht gar nicht schlecht, da ich die Zugriffe ja sowieso etwas ungewöhnlich benutze. (I)DMA fällt dann aber sicher flach, denke ich.

Wenn jetzt jemand meint, irgendeine Logik in die CS Leitung von der CPU zum RAM einzuhängen wäre eine Möglichkeit: Wird schwierig werden, da diese SDRAM Kommandos nur 15ns lang sind (es sind um ein Wort zu lesen ja gleich mehrere notwendig). Eine Logik in dieser Leitung würde aber sicher einige ns Verzögerung kosten, und das kann bei einem SDRAM schon zuviel sein. Mit dem CPLD schafft man das evtl. in 5ns, und da wird es ganz sicher schon sehr eng.

Für alte Nokias empfehle ich daher eher, das man den Speicher auf dem Mainboard aufrüstet. Ein Freund von mir hat auch genau dieses Problem, das gehen wir demnächst mal an, ich habe nur noch keine Speicherchips für ihn.

Ich hoffe allerdings das fürs Puffern keine grossen Speichermengen mehr notwendig sein werden: Eine Platte sollte die Daten doch eigentlich immer recht gut wegschaffen können?!

Ansonsten: Ich sehe nicht wirklich einen Grund, warum man den Speicher wenigstens einer Nokia nicht auch auf mehr als 32MB onboard aufrüsten könnte: Ich würde das jedenfalls mal so probieren:
1. Der Speicher muss so angeschlossen werden, das es den BR Boot Teil nicht stört.
2. Im U-Boot programmiert man den Memory Controller dann entsprechend um: Die Zuordnung der Adressleitungen kann man recht einfach ändern. Vielleicht benötigt man dann ein oder zwei Adressleitungen von der CPU dazu, aufgrund der gemultiplexten RAS/CAS Aufteilung gehts vielleicht auch so?!

Wenn ich schon beim "rumspinnen" sind, was man noch so umbauen könnte: Mehr Flash ginge so wahrscheinlich auch recht einfach...

Ciao,

DboxBaer

PS:
Ein Modul im Kernel habe ich nun endlich hinbekommen und darin auch schon mit dem CPLD gesprochen. Leider ist die Doku bezüglich IDE im Kernel unter aller Kanone, aber ich habe langsam eine Ahnung wie ich es machen muss. Wenn jemand hier ist, der ein schönes Beispiel kennt, wo jemand die INB & Co Routinen der ide_hwif_t (oder so) Struktur mit eigenen Routinen bestückt: Her damit! Für welche Plattform auch immer, jedes Beispiel hilft.

[saruman]

Sorry für OT, aber das muss mal gesagt werden:

Alter Schwede, ich versteh nur Bahnhof.

[chkbox]

Wenn ich mir das mal so überlege ist das mit dem Ram eigentlich auch egal... Es lebe swapon

Ansonsten habe mich mal hingesetzt und den DIMM100 Connector der Sagem für Eagle gebastelt. Bin dabei aber auf Probleme gestoßen:

1.) Kann jemand mir sicher sagen, dass http://forum.tuxbox-cvs.sourceforge.net ... 4230#85475 richtig ist? Ich habe z.B. http://download.micron.com/pdf/datashee ... x32UDG.pdf gefunden, dort ist die Nummerierung der Daten- und Adressleitungen anders (Ich weiß, dass bei der dbox nicht bei 0 angefangen wird! Die Wertigkeiten scheinen aber völlig durcheinander zu sein oder ist das irgendeine big/little endian Geschichte?).

2.) Mechanik: Das Micron sheet liefert ein paar Daten dazu. http://www.ddknet.co.jp/English/product ... dmm100.pdf liefert weitere Details. Leider widerspricht sich dieses Datenblatt bei der Positionierung der linken Kodierungs-Aussparung (Oder ich verstehe es einfach nicht ). Vielleicht kann mich ja jemand aufklären, wo genau die Aussparungen und die Kontakflächen hin müssen.

Vielleicht kanns ja auch einfach wer verbessern oder kontrollieren... http://rapidshare.de/files/8785362/dimm.lbr.html Ist bisher leider nur das Package und ein angefangenes Symbol...

@DBoxBaer: Aus welcher Lib sind eigentlich der CPLD und IDE Connector?

Hätte noch eine Idee: Wie wäre es wenn man eine USB-IDE-Bridge hinzufügt. Beim CPLD kann man die Pins sicher auf Z bringen. Bei der Bridge vielleicht auch oder man fügt einen Puffer ein. Ich kenne aber keinen der in beide Richtungen funktioniert und erstrecht nicht für UDMA133 takt.

[SchaSche]

Sorry für OT, aber das muss mal gesagt werden:

Alter Schwede, ich versteh nur Bahnhof.

Geht mir genau so, aber es klingt gut!

[PauleFoul]

Wie geht es eigentlich weiter?? Gibt es denn was neues??


Gruß
____Paule

[DBoxBaer]

Wie geht es eigentlich weiter?? Gibt es denn was neues??


Gruß
____Paule

Leider bin ich die letzten Tage gar nicht dazu gekommen, an der DBOX Software zu basteln: Weihnachtsvorbereitungen...

Aber damit das Verständnis etwas breiter wird, erkläre ich hier mal ein paar Grundlagen nochmal etwas genauer:

Wie funktioniert ein Speicherzugriff bei den 8xx CPUs?

Grundsätzlich stehen der CPU dafür verschiedene Anschlüsse (Pins) zur Verfügung:

Datenbus
Adressleitungen
diverse Steuerleitungen

Über die Steuerleitungen teilt die CPU der Hardware (Flash-Rom, RAM, ...) mit, was sie gerade machen will. Lesezugriffe funktionieren im Prinzip so, das die CPU der Hardware sagt, das sie nun eine bestimmte Information lesen will: Dazu legt sie die Adresse auf die Adressleitungen und teilt der Hardware über die Steuerleitungen mit, das sie etwas lesen will. Diese Hardware legt nun die Daten auf den Datenbus und die CPU liest die Daten von dort.
Schreibzugriffe funktionieren ähnlich, da legt die CPU die Daten auf den Datenbus.
Damit CPU und Hardware wissen, wann Daten auf dem Datenbus zur Verfügung stehen müssen sich beide Seiten über die Nuzung der Steuerleitungen einig sein. Im Prinzip gibt es zwei verschiedene Verfahren:
Mit "Handshaking" und ohne. Handshaking bedeutet, das die Hardware über eine Steuerleitung der CPU sagt: "ja, ich hab gemacht was Du willst".
Ohne Handshaking wird einfach ein "Timing" verwendet: Im Prinzip heisst das, die Hardware muss die Aufgabe (Daten lesen/ schreiben) einfach zu einem bestimmten Zeitpunkt erledigen, nachdem die CPU den Anfangszeitpunkt über die Steuerleitungen mitgeteilt hat.

Grundsätzlich unterscheidet die CPU Zugriffe über die Adresse und die Wort-Breite: Da die CPU einen 32-Bit Bus besitzt, kann sie der Hardware zum Beispiel mitteilen, das sie nur ein Byte transportieren will:
In dem Fall wird nur ein Teil des Datenbus verwendet. Welchen Teil sie verwendet wird über vier Leitungen festgelegt, für jedes Byte eine.

Damit nun verschiedene Hardware angesprochen werden kann, wählt die CPU für bestimmte Adressbereiche unterschiedliche Hardware aus: Dafür verwendet sie die "CS" Leitungen (Chip Select).

In der 8xx Hardware funktioniert das so:
Der PowerPC Kern generiert eine Adresse mit 32 Bit. Der Memory Controller (neben dem Kern ein weitere Teil der 8xx CPUs) vergleicht nun diese Adresse mit acht (programmierbaren) Werten, im Prinzip ungefähr so:

if ((addr & MASK0)==VALUE0) then CS0
if ((addr & MASK1)==VALUE1) then CS1
...
if ((addr & MASK7)==VALUE7) then CS7

Diese Masken und Values sind dabei frei programmierbar (ORx und BRx Register). Wie man hier sieht, legt die Maske auch die Größe des Speicherbereichs fest, der für eine CS Leitung gilt.

Nachdem sich nun der Memory Controller für eine CS Leitung entschieden hat, führt der Controller diesen Zugriff aus, und wie das abläuft ist wiederum sehr fein programmierbar. (Programmierbar heisst nur, es gibt dafür eine Menge Einstellmöglichkeiten, nicht das "wirkliche" Programme ablaufen können)

Für jede CS Leitung kann primär gewählt werden, welcher Ablauf für den Zugriff gewählt wird:
- General-purpose chip-select machine
- User-programmable machine A
- User-programmable machine B

Die "General-purpose chip-select machine" wird üblicherweise für Hardware-Zugriffe verwendet, aber auch das Flash wird darüber angesprochen. Programmiert werden können hier zum Beispiel die Anzahl der "Wait-States", das heisst wie lange ein Zugriff dauert, oder genauer: wann, nachdem die CPU der Hardware ihr Anliegen (Zugriff) mitgeteilt hat, sind die Daten auf dem Bus.

(Ich denke diese Maschine wurde für das alte IDE Projekt verwendet, leider sind hierfür aber nicht alle dafür notwendigen Leitungen auf dem Memory-Connector, daher muss man dann diverse Leitungen vom Mainboard zusammensuchen/anlöten)

SD-RAM kann über diese Maschine aber nicht angesprochen werden, dynamisches RAM hat nämlich ein paar besondere Eigenschaften, die die Ansteuerung komplizierter machen:
- Refresh
- gemultiplexte Adressen

Da die Speicherzellen nach kurzer Zeit ihren Inhalt verlieren, benötigen sie einen Refresh: Im Prinzip reicht es bei modernen RAMs aus, das man dem Chip regelmässig mitteilt: Jetzt ist ein guter Zeitpunkt einen Teil Deiner Daten mal zu refreshen. Multiplexing ist hier das Verwenden einer Leitung für verschiedene Aufgaben, beim RAM werden über jeweils eine Adress-Leitung zwei Adress-Bits übertragen. (Ein Vorteil ist dabei auch, das Leitungen gespart werden können)
Zu diesem Zweck werden einige der Adress Bits als "Row" bezeichnet, andere als "Column", und das RAM wird als 2D-Tabelle angesprochen:
Zuerst werden die Row-Bits der Adresse angelegt, und das RAM wählt eine Zeile in seiner "Speicher-Tabelle" aus. Danach werden die Column Bits der Adresse ans RAM gelegt und es wird der

entsprechende Eintrag (Spalte) in der Zeile angesprochen, also gelesen oder geschrieben.
Traditionell gab es zwei Leitungen bei DRAMs für diesen Zweck: Die RAS (Row Adress Strobe) und CAS (Column Address Strobe), die jeweils aktiv sind, wenn der entsprechende Teil der Adresse am
RAM angelegt ist.
Eine weitere Leitung war die WE Leitung (Write Enable), mit der mitgeteilt wird, ob geschrieben oder gelesen wird.
Bei SD-RAMs gibt es noch immer Leitungen mit diesen Namen, allerdings werden sie nun etwas anders verwendet, denn mit drei Leitungen (RAS,CAS und WE), also drei Bits, können acht verschiedene

Zustände übertragen werden.
SD-RAMS interpretieren diese Zustände nun als Kommandos, und ein Speicherzugriff ist eine bestimmte Abfolge dieser Kommandos.

Zurück zur 8xx CPU:
In der "User programmable machine" (UPM) des Memory Controller können nun verschiedene solche Sequenzen abgelegt werden, die dann von der UPM abgespielt werden: Im Detail gibt es dabei eigene Sequenzen für Read, Write, Read-Burst, Write-Burst und Refresh. Aber man kann auch eine eigene Sequenz in der UPM ablegen, und diese "per Hand" anstossen (spezieller Zugriff auf die Register des Memory-Controller).

Wie schon erklärt werden die Adressen gemultiplext. Tatsächlich ist auch dies programmierbar, d.h. welche Adressleitungen werden beim RAS Kommando am RAM angelegt. So ist es möglich, das über die gleichen Leitungen unterschiedlich viel RAM angesprochen werden kann, je nachdem wie der Adressmultiplexer programmiert ist. Auf diese Art ist es auch möglich, an die CPU mehr als 64MB Speicher anzuschliessen, und das im Prinzip auch auf dem Mainboard, wenn man den entsprechende Speicherchips auflötet und den Memory-Controller passend umprogrammiert.

Nun zum IDE Interface:
Da für General Purpose CS Machine die Leitungen nicht am Connector nicht zur Verfügung stehen, und die DBOX wenigstens kurzfristig beim Booten Zugriffe auf SD-RAM durchführt, um festzustellen, ob überhaupt RAM vorhanden ist, blieb nur die Möglichkeit, die UPM zu verwenden. Leider hat die CPU nur zwei UPMs und beide sind schon in Benutzung, daher konnte ich auch hier an den Sequenzen nichts drehen.
Die oben erklärten Kommandos zum RAM werden nun allerdings von der CPU auch noch mit BUS Takt durchgeführt, und das sind 66MHz. Das heisst, jedes dieser Kommandos dauert nur 15ns. Mit diesen Randbedingungen wurde die Wahl der Möglichkeiten schon stark beschränkt, ein CPLD ist so gut wie die einzige Möglichkeit, diese Eigenschaften zu erfüllen.
Danach ist es aber relativ einfach: Der CPLD muss die Kommandos erkennen und die Sequenzen "verstehen": So beginnen Lese und Schreibzugriff immer mit einem "Row Select" Kommando, dabei liegt der "Row"-Teil der Adresse am Chip an. Danach folgt ein Takt Pause, dann kommt das Write bzw. Read Kommando, bei diesen liegt nun der Column-Teil der Adresse am Chip an. Die genauen
Sequenzen, die die CPU ausführt habe ich einfach aus der programmierten UPM der CPU zur Laufzeit ausgelesen und in ein lesbares Timing umgewandelt.

Wie funktioniert ein IDE Zugriff:

Das IDE Interface stammt noch aus uralten Zeiten der PC Technik. Technisch handelt es sich um eine Handvoll 8 Bit breiter Register, einem 8 Bit Kommando Register und einem 16-Bit breitem Datenregister. Um einen Sektor von der Festplatte zu lesen passiert nun zum Beispiel das folgende:
Zuerst wird in die verschiedenen 8-Bit Register die Nummer des Sektors geschrieben. Danach wird in das Kommando Register der Wert 0x20 (oder so) geschrieben, das bedeutet "Read Sector".
Danach wird ein wenig gewartet (z.B. auf einen Interupt, oder es wird per Polling ein Status-Bit in den Registern überprüft) und zum Schluss werden aus dem Datenregister die Daten geholt.

Was macht nun der CPLD:

Denkbar wäre es natürlich, das der CPLD gleich die ganze Sequenz der Zugriffe der IDE Register übernimmt. Das ist aber nicht sinnvoll, denn diese Sequenzen sind im IDE-Treiber des Linux Kernel bereits programmiert. Daher ist es "nur" notwendig der CPU den Zugriff auf diese IDE Register zu ermöglichen.
Nun werden für einen solchen IDE Register Zugriff verschiedene Informationen benötigt, unter anderem die Register Nummer, aber auch die Wort-Breite usw. Da bei jedem Zugriff von der CPU (also auch beim Lesen) die Adresse (in zwei Hälften) "übertragen" wird, verwende ich diese um diese Informationen in den Chip zu bekommen.

Nun ist es aber so, das ich an dem Ablauf "Read Word" von der CPU beim Lesen nichts ändern kann, die CPU erwartet zu einem bestimmten Zeitpunkt die Daten auf dem Bus, ein IDE Zugriff dauert aber viel länger.

Deshalb verwende ich eine ähnliche Idee wie die UPM, und transportiere Kommandos, ebenfalls in der Adresse: Diese Kommandos sind "Lese Wort", "Schreibe Wort", "Lese 2 Worte" und "Schreibe 2 Worte". (evtl. noch ein paar weitere).
Diese Kommandos können sowohl bei Lesezugriffen als auch bei Schreibzugriffen der CPU ausgeführt werden, denn sie sind ja Teil der Adresse, und die gibt es immer.
So funktioniert dann das Lesen eines IDE Registers: Zuerst schreibt (oder liest) man von einer bestimmten Adresse, die CPU führt mit Hilfe der UPM diesen Zugriff aus, der CPLD erkennt diesen und sieht das Kommando "read word". Nun führt der CPLD diesen IDE Zugriff aus und merkt sich das Ergebnis.
Einen Augenblick später greift die CPU erneut auf den CPLD zu und liest nun diese Daten. Bei diesem Zugriff kann aber bereits das nächste Kommando beim CPLD ausgelöst werden, und so weiter.

Da 16 Bit Zugriffe aus CPU Sicht nicht sehr effektiv sind, kann der CPLD auch gleich zwei IDE Zugriffe durchführen und die CPU bekommt so gleich 32 Bit übertragen. Das macht natürlich nur Sinn beim Zugriff auf das Datenregister.

Problematisch ist daher nur das Detail "einen Augenblick später". Die CPU darf den zweiten Zugriff erst dann ausführen, wenn der IDE Zugriff fertig ist. Bei langsamen Devices kann dies möglicherweise zu schnell sein. Allerdings kann der CPLD dies feststellen und so dem Treiber im Prinzip auch mitteilen, das er das nocheinmal machen muss, diesmal aber bitte langsamer.

Ansonsten schonmal fröhliche Weihnachten,

DboxBaer

[Npq]

Coole Sache, danke für die Erklärung, mit den Busprotokollen hab ich mich bisher nur am Rande beschäftigt, die UPMs werden ja normalerweise direkt vom BMon programmiert bis auf die Nokia, wo dort ein Fehler drin war und das vom U-Boot aus korrigiert wird.

Schon ne interessante Idee mit der Kodierung der Kommandos über die Adresse.

Dir auch ein frohes Fest.