mmIO in Software

Da stellen sich folgende Fragen: Was soll das denn bringen? Ein Interrupt macht doch nur Sinn, wenn er von der Peripherie (also dem was du per I/O ansprichst) ausgeloest wird. Auf den Speicherbereich (bzw. den I/O Port) auf den die Peripherie gemapped ist greift ja die CPU zu - wozu soll sie sich jetzt selbst mitteilen, dass sie zugegriffen hat?

Oder meinst du von aussen per DMA in den Speicher der CPU schreiben? Das waere dann aber nicht was ich unter "memory-mapped-IO" verstehen wuerde.

Und was ist bitte "Software-memory-mapped-IO"? Entweder die CPU hat ein Speicherinterface und man haengt die Peripherie da dran (dann ist sie "memory mapped") oder sie hat keins, dann eben nicht. Willst du einen Speicherzugriff per Software emulieren?

Micha

Jo genau das ;)

Ich kenne deine CPU nicht, aber es wuerde mich wundern wenn da Support fuer sowas drin vorhanden waere. Wenn du kein Speicherinterface hast, musst du das Zeug ja wohl oder uebel an die I/O Ports anschliessen. Manche CPUs mappen die I/Os automatisch zusaetzlich in den Speicher - wenn deine das nicht tut wirst du wohl per I/O zugreifen muessen. Was gefaellt dir daran nicht?

Micha

Nur, was soll der INT bringen? Deine Software weiss ja, wann sie auf den Speicher zugreift, also kannst du dort einen einfachen Unterprogrammaufruf einbauen.

INTs als Unterprogrammaufruf gab/gibt es allerdings beim PC/80x86. Dort kann man einen INT per Komando auslösen. Bei DOS wurde das als bequeme Möglichkeit verwendet, um Routinen des Betriebssystems aufzurufen.

Das ist aber eher ungewöhnlich.

Gruß

Stefan DF9BI

Das Problem ist, daß dem Kunden der Code mir Unterprogramm-Aufrufen nicht gefällt. Er möchte Zeiger haben ;) Und da hab ich gedacht, ich definiere eine Speicherseit für IO und sag dem uC : wenn auf die Seite zugegriffen wird, löse einen Interrupt aus. Und in dem Interrupt würde ich dann das Unterprogramm aufrufen.

Thorsten

Anzunehmen eher: er will kein Polling der CAN-Schnittstelle, sondern diese möge Interrupts auslösen.

MfG JRD

... was aber unabhaengig davon ist ob I/O "memory mapped" gemacht wird oder nicht.

Im uebrigen: Warum soll man fuer I/O ein Unterprogramm aufrufen muessen? Der I/O Zugriff kann doch genauso inline gemacht werden wie der Speicherzugriff:

wert = *(base + reg);

vs.

PORT_X = reg; wert = PORT_Y;

Micha

Ich kenne die betreffende CPU jetzt nicht, würde aber mal im Kapitel zur Testunterstützung nachlesen, ob man Watchpoints setzen kann. Da bekommst du dann ein irgendwie geartetes Ereignis, wenn die Speicherstelle gelesen oder geschrieben wird. Wenn du Glück hast als Interrupt, wenn du Pech hast nur außenrum über JTAG.

Stefan

Warum nicht? Ein solches Unterprogramm könnte den Zugriff so kapseln, dass bei einem späteren Wechsel des Prozessors und Memory-Mapped-IO nur dieses Unterprogramm geändert werden muss.

Ist simpel, klar. Das seh ich im Prinzip genauso, aber es wird wohl doch auf folgendes hinauslaufen:

char lese_canreg(char adresse) { char wert; Port_Y = enable_aus; // Steuerleitungen RD*, WR*, CS* aus Port_X = adresse; // gewünschte Adresse setzen Port_Y = enable_an | read; // CS* und RD* aktivieren wert = Port_Z; // Wert auslesen Port_Y = enable_aus; // RD*, WR*, CS* aus result = wert; }

Ist nicht wesentlich aufwendiger, wie die zwei Befehle, die du angegeben hast, aber wenn an verschiedenen Stellen gelesen werden soll, ist die Kapselung in eine Funktion einfach lesbarer.

Gruß

Stefan DF9BI

Dein CAN Controller hat 15 Message Objects, und was du brauchst ist ein Interrupt von deinem CAN Controller an dein MC, wenn einer der 14 TX Buffer leer oder einer der 15 RX Buffer voll ist. Dann kannst du anfangen, mit oder ohne mem mapped io, mit oder ohne Zeiger/ Unterprogramme oder was dir sonst noch einfällt, den CAN Controller zu adressieren und das Message Object, welches den Interrupt ausgelöst hat zu identifizieren und zu bedienen.

Gruß

Hans-Georg

Ich wollte darauf hinaus, dass man es auch inline machen kann. Im Sinne von: Es ist kein Argument, dass das Anspringen der Routine Zeit und Stack verbrauchen muss (falls das den Kunden stoeren sollte).

Da spricht ja auch nichts dagegen. Wenn man genug Programmspeicher hat, kann man diese Routine dann ja als "inline char lese_canreg(char adresse)" definieren oder als Macro.

Micha

Stimmt. Das ist ein Argument. Dazu müsste man aber mal den benötigten Datendurchsatz bzw. die Prozessorbelastung berechnen. Ich kann nicht beurteilen, ob es durch den Zugriff über Ports sowie die Unterprogrammaufrufe zu einer nennenswerten Mehrbelastung des Prozessors oder gar zu Problemen mit dem Datendurchsatz auf der CAN Schnittstelle gibt.

Gruß

Stefan DF9BI