Gegrüßet seid ihr!
Entschuldigung schonmal für's gedankliche Chaos, das euch erwartet ;)
Einmal drei Dinge, die mich gerade beschäftigen:
1) Ich habe einige Zweifel, ob ich die Sache mit dem Memory Mapped I/O
gedanklich richtig umsetze.
Mein Verständnis ist derzeit folgendes: Man kann die CPU entsprechend
konfigurieren, dass sie entsprechend der Adressen, auf welche man
zugreift, unterschiedliches Verhalten zeigt. Also abhängig von der
Adresse wird eine konfigurierte Chip-Select-Leitung ausgewählt und dann
über den Datenbus und die Steuerleitungen, welche normalerweise für's
RAM vorgesehen sind, Datenübertragung mit einem externen Baustein
durchgeführt, der sich ansonsten eigentlich so verhält wie ein Speicher,
nur eben ohne Adressleitungen. Ist das soweit gedanklich korrekt? Wobei
ich mich gerade frage, wie das ohne die Adressleitungen überhaupt gehen
kann, wenn man sich mit Geräten unterhält, die "größer" sind, als die
Systemwortbreite. Also werden die Adressleitungen vielleicht auch
genutzt? Das würde mir auch erklären, warum im Sheet zum AM186er vor
Speicher und IO-Bausteinen Latches für Adressbus und Datenbus
eingezeichnet sind, damit die Geräte nicht das ganze für andere
bestimmte Gedöns mitlauschen müssen.
2) Mein Problem ist, dass ich zwar 1a die Kommunikation mit einem FPGA
und dem Sheet der Bausteine hinbekomme, aber die "Blackbox"
Mikrocontroller+DOS-Bibliothek ist für mich im Moment noch etwas ein
Buch mit sieben Siegeln. Wo es nur den Mikrocontroller betrifft, kann
ich ja in dessen Handbuch schauen, aber was genau nun inport und outport
aus der DOS-Bibliothek, die ich hier verwenden "muss", tun, konnte ich
auch mit einer Google-Suche nicht herausfinden. Dort tauchen irgendwie
nur Labview und Mathlab-Probleme auf, bzw. der Zugriff unter NT. Die
Beispielsourcen, die ich hier habe (weitgehend undokumentiert), gehen
von vorhandenem Verständnis aus und mixen wüst den Zugriff auf einzelne
Konfigurationsregisterbits mit Highlevel-Aufrufen aus der
DOS-Bibliothek.
3) Generell muss man während der Kommunikation mit der Außenwelt bei
entsprechender Taktung doch ein paar Wartezyklen einplanen, bis
Antworten kommen, oder nicht? Ich frage mich, ob inport und outport
diese Wartezyklen per Software einbauen, oder ob diese vom
Mikrocontroller vorgeschrieben werden. Für mich wäre es zB. interessant,
ob man während der Wartezyklen nicht vielleicht noch ein paar
Berechnungen für bereits gelesene Daten in Registern durchführen kann
(Der Speicherzugriff dürfte ja wohl blockiert sein).
Danke an jeden, der schonmal bis hier kam und viele Grüße!
Michael
Ich nehme an, der AM186 ist vergleichbar mit Intel '186.
1) Ob hinter einer Adresse nun ROM, RAM oder irgendwelche I/O-Bausteine
stehen ist der CPU schnuppe. Es werden aber sehr wohl die
Adressleitungen dabei verwendet, um (a) den Baustein auszuwählen und (b)
seine Register zu adressieren. Weshalb I/O Bausteine üblicherweise ein
paar Adressleitungen haben.
Da der Adressbus mindestens teilweise mit dem Datenbus gemultiplext ist
findet man üblicherweise Adresslatches in den Systemen. Strukturell
gehören die aber nicht sehr zum Speicher, als vielmehr zur
CPU-Baugruppe, die damit einen leicht nutzbaren nicht gemultiplexten
externen Bus bekommt.
3) Notwendige Wartezyklen sind vom Prinzip her Sache des adressierten
Bausteins. Der kann ggf. die WAIT-Leitung aktivieren bis er soweit ist.
Inwieweit die erwähnten vordekodierten CS-Signale auch programmierte
Waitstates enthalten weiss ich nicht, das weiss das Datasheet aber
bestimmt.
186er sind keine out-of-order Prozessoren. Wenn gewartet wird, dann wird
gewartet. Es ist nicht der Sinn des WAIT-Signals, die CPU für lange Zeit
ausser Gefecht zu setzen, sondern nur für wenige Takte bei langsamen
Bausteinen. Für Signalisierung, wann beispielsweise eine serielle
Schnittstelle wieder ein Byte parat hat, ist nicht WAIT zuständig,
sondern ein Interrupt oder DMA.
Memory mapped I/O ist im Zusammenhang mit einem x86 etwas ungewöhnlich,
da dieser einen eigenen Adressraum nur für I/O-Bausteine hat, der dann
auch mit den dafür vorgesehenen I/O-Befehlen inp/outp angesprochen wird.
Anstelle von MEMRD/MEMWR werden dann die Leitungen IORD/IOWR verwendet.
Okay, vielen Dank Dir erst einmal. Ich wühle mich hier gerade durch die
Sheets der Bausteine (AD7606 und DAC8544) und sehe eigentlich nichts,
das für mich wie ein klassisches Wait-Signal von einem parallelen
Interface aussähe. Das passt auch dazu, dass hier in den Beispielen
scheinbar 12 Waitstates eingestellt werden (wobei dort auch allerhand
falsche Beispiele zu finden sind, daher gebe ich da nicht mehr so viel
drauf). Und in 12 Zyklen könnte man ja wahrscheinlich schon einmal einen
Mittelwert bilden oder soetwas, anstatt zu warten. Muss ich anhand der
Sheet-Timingdiagramme wohl einmal ausrechnen, ob bei 50MHz wirklich 12
Zyklen nötig sind...
Aber wie es so aussieht, kann ich also direkt schadlos inport/outport
als Highlevel-Interface zum MMIO benutzen, statt da selber kryptisch
rumzuhantieren, ja? Wobei ich mich natürlich frage, wozu man die
braucht, wenn man doch auch einfach die Addresse zB. in C hartkodiert in
einen Zeiger packen könnte und dann den Zeiger zum lesen oder schreiben
dereferenziert. Sollte das nicht gerade die Idee sein, dass externe
Komponenten sich nach außen hin wie echter Speicher verhalten?
Das Schaltbild des Mikrocontroller-Boards enthält leider den
Mikrocontroller selber nicht, aber die Signale an die MCU sind nicht
nach AMD-Dokumentation benannt, sondern applikationsspezifisch, sodass
ich die Signale in einer weitere Tabelle wieder übersetzen muss und für
3 Bausteine mit 4 Dokumenten hantiere... Das wird alles noch ein
steiniger Weg hier :) Auf jeden Fall versuche ich gerade herauszufinden,
was alles am WAIT-Pin der MCU angeschlossen ist. Aber das finde ich noch
heraus, Tjiakka!
Viele Grüße,
Michael
Rufus Τ. Firefly schrieb:> Memory mapped I/O ist im Zusammenhang mit einem x86 etwas ungewöhnlich,> da dieser einen eigenen Adressraum nur für I/O-Bausteine hat, der dann> auch mit den dafür vorgesehenen I/O-Befehlen inp/outp angesprochen wird.> Anstelle von MEMRD/MEMWR werden dann die Leitungen IORD/IOWR verwendet.
Ich denke Du hast vollkommen Recht. In der Doku wird auch exakt von
I/O-Raum gesprochen, ich hatte jetzt angenommen, das wäre dasselbe O.O
Nomenklatur wichtig! merk Grummel. Das werde ich dann wohl auch gleich
sehen, wenn ich das Schaltbild entschlüsselt habe.
Michael S. schrieb:> Aber wie es so aussieht, kann ich also direkt schadlos inport/outport> als Highlevel-Interface zum MMIO benutzen, statt da selber kryptisch> rumzuhantieren, ja?
Falls du darauf eine Antwort erhoffst: meinerseits Bahnhof.
Danke Dir, kein Problem, ich gehe nach euren freundlichen Erläuterungen
jetzt davon aus, dass inport und outport nur Makros oder Funktionen
sind, die einem den Inline-Assembler für die Instruktionen "inp" und
"outp" abnehmen. Ist aber nur so in's blaue hinein vermutet ersteinmal.
Eine eigene Frage?
Dieser Thread ist über 13 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
