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.
Aha, es ist also von C die Rede. Ja, x86 Compiler oder deren Libs haben solche Funktionen, ob nun als Aufruf oder implizit in die Befehle umgesetzt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.