Da ich mich erst seit kurzem intensiv mit µC und der Programmiersprache C beschäftige ist es durchaus mögliche, dass folgende Frage völlig trivial und sinnlos ist. Ich stelle sie aber trotzdem. Der AVR besitzt ja eine Harvard-Struktur. Beim Programmieren in C drückt sich das durch einer extra Handhabung aus, wenn man z.B. auf Strings im Flash-Speicher zugreifen will. Also würde ich auch eine extra Handhabung erwarten wenn ich Zeiger auf Funktionen verwende, dies funktioniert aber offensichtlich ganz ohne spezielle Funktionen. Warum ist das so ?
Ein indirekter Funktionsaufruf ist ja schon allein syntaktisch erkennbar. Und vom Typ her auch. Also was bitte soll er da falsch machen? Eine andere Sache ist es, abhängig von einem Attribut des Zeigers unterschiedlichen Code zu generieren. Der Datentyp ist ja der gleiche. Dazu ist GCC erkennbar nicht in der Lage. Interssant wird's mit künftigen AVRs mit mehr als 64KW Flash. Denn dann unterscheiden sich die Zeiger nicht nur im Typ und Attribut, sondern auch in der Grösse (Data: 16bit, Function: >=24bit). Keine Ahnung ob dass mit GCC zu machen ist, kann gut sein das AVR-GCC dann am Ende ist.
Da Zeiger auf Funktionen immer nur Zeiger auf Funktionen sind -also immer nur auf den Codespeicher verweisen-, geht der Compiler folgerichtig immer von Codezugriffen aus. Die Bestimmung der Adresse einer Funktion liefert einen Zeiger auf Codespeicher, das Dereferenzieren eines solchen Zeigers (sprich: Aufrufen einer Funktion) wird auch im Codespeicher ausgeführt. Da sehe ich keine Probleme mit der Harvard-Architektur. Selbst eine Erweiterung des Adressraumes auf 24 Bit dürfte eigentlich keine Probleme bereiten; der Compiler müsste dann "nur" darauf vorbereitet werden, Codezeiger als 24- oder 32-Bit-Variablen zu behandeln. Wie einfach das ist und ob man gcc überhaupt dergestalt verbiegen kann, das steht auf einem ganz anderen Blatt. Wer weiß, vielleicht wird Atmel ja bei AVRs mit mehr als 128 KByte Flash-ROM auch einen Banking-Mechanismus implementieren. Mittlerweile gibt es ja sogar AVR-Varianten, die Code im RAM ablegen können (mit einem Mapping-Mechanismus kann die Aufgabe von Speicherblöcken umdefiniert werden) - AT76C712 ist so ein Kandidat. Das ist überhaupt ein hochgradig interessanter Prozessor - einerseits, weil er mit einem USB-Device-Controller ausgestattet ist, andererseits, weil er vollständig ohne Flash- oder sonstiges ROM auskommt. Ein fest eingebauter Bootloader lädt Firmware aus einem externen seriellen EEPROM oder wahlweise auch per USB - genauso, wie es die Ez-USB-Controller von Cypress machen. Aufgrund dieser RAM-Architektur kann der (interne) Prozessortakt auf 48 MHz erhöht werden, etwas, was bei Flash-ROMs aufgrund deren relativ langsamen Zugriffen nicht möglich war. Bevor ich weiter ins Schwärmen komme - seht Euch einfach selbst das Datenblatt an: http://www.atmel.com/dyn/products/product_card.asp?part_id=3579
Wie Atmel mit >128KB umgeht ist doch schon längst definiert. Direkten JMP/CALLs geht erst jenseits von 8MB die Luft aus, und indirekte belegen auf dem Stack 3 Bytes. Soviel zu den Zeigern auf Funktionen. Die werden halt grösser. Und Daten im ROM werden heute schon in Banks adressiert, wenn's 128KB ROM sind und man dusselig genug ist, in die oberen 64KB Daten reinzupacken. Nichts neues also. Neues ist also nur seitens der Compiler zu erwarten.
Das Problem ist, dass GCC wohl derzeit noch keine Variante hat, mit 24-bit-Zeigern umzugehen. Ein Aufblähen auf 32-bit-Zeiger wäre nicht so toll...
@ Rufus T. Firefly: Zum Thema AT76C712: Du schwärmst zwar von diesem Prozessor, aber der Programmspeicher, auch wenn es RAM ist, wird ja immernoch anders adressiert als das Daten-RAM, oder?
Sicher, an der Harvard-Architektur selbst ändert sich nichts. Das ist halt eine der Kerneigenschaften der AVRs. Ein Prozessor mit ähnlichem Aufbau, aber einem ARM7-Kern, dafür könnte ich mich erst recht erwärmen.
Bitte 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.