Hallo zusammen, für die Datensicherung habe ich in meinem Projekt einen SPI-EEPROM 25LC1024 vorgesehen. Die Zugriffsroutinen funktionen einwandfrei. Bisher liegen in diesem EEPROM 254 Datensätze zu je 128 Byte. Zugegriffen wird bei Bedarf immer auf den gesamten Satz, lesend und auch schreibend. Nun sollen dort aber auch noch einzelne Werte untergebracht werden und es wäre recht hilfreich, durch Definitionen diese Variablen in einem eigenen Bereich abzubilden. Leider weiß ich nicht, wie. In den Memory-Settings in den Project Options gibt es nur sram, eeprom und flash. Hier Beitrag "ARM-GCC: EEPROM abbilden?" wurde das Problem auch schon behandelt, aber irgendwie unbefriedigend für mich. Ist ja aber auch schon eine Weile her. Frage also: Wie macht man es geschickt und richtig? Thomas
>Hier Beitrag "ARM-GCC: EEPROM abbilden?" wurde das Problem >auch schon behandelt, aber irgendwie unbefriedigend für mich. Natürlich ist es unbefriedigend für dich wenn du etwas willst was gar nicht geht. Allerdings ist auch nicht erkennbar WAS du WIE willst.
Hmm, ist jetzt bischen putzig, nicht zu erkennen, WAS ich WIE will und trotzdem festzustellen, dass das garnicht geht. Ich dachte jetzt, ich habe das richtig herüber gebracht. Ich möchte Variablen definieren in der Art: uint8_t array1[1024] SPI_EEPROM; uint16_t array2[4096] SPI_EEPROM; und damit die Adressvergabe "automatisieren", aber weder im Flash, noch im internen EEPROM und auch nicht im RAM sondern in einem eigenen Bereich SPI_EEPROM. Den Zugriff darauf organisiere ich mit eigenen SPI-Routinen. Klar, man kann das mit #define erschlagen, aber das kann doch nicht der Weisheit letzter Schluss sein? Thomas
>Ich möchte Variablen definieren in der Art: >uint8_t array1[1024] SPI_EEPROM; >uint16_t array2[4096] SPI_EEPROM; Sowas dachte ich mir schon. Das geht nicht.
holger schrieb: > das geht nicht. naja, zumindest macht es meisten weniger Sinn als Verwirrung. Prinzipiell kannst Du natürlich mit entprechenden #pragma-Anweisungen dafür sorgen, dass Dein Linker Dir alle SPI-EEPROM-Objekte zusammenfasst und irgendwo hinlegt. Aber wozu? Beim Neucompilieren willst Du ja z.B. nicht, dass er sie auf einmal anders anordnet. Der einfachste Weg: Einen "Gott"-Struktur-Typ, in dem alle Objekte zusammegefasst sind. Dann kannst Du über "offsetof" auf beliebige Member zugreifen (erhälst dann die Offsetadresse im Flash).
Thomas P. schrieb: > Die Zugriffsroutinen funktionen einwandfrei. In C ist es nicht möglich, durch einfaches Lesen/Schreiben einer Variable eine Zugriffsroutine zu triggern. Darum geht das, was du willst, nicht. Nachtrag: Wenn der Zugriff hardwareseitig transparent ist (d.h. das SPI-EEPROM in den normalen Adressraum gemappt ist), dann kannst du ein passendes Linkerscript bauen. Ansonsten ist das ein Grund, zu C++ zu wechseln: Implementiere dir eine Klasse, die die Zugriffe für dich abstrahiert.
:
Bearbeitet durch User
er hat doch 256 Bytes je Page. Kann er nicht die Page adressieren und die Organisation innerhalb der Page .........shit ist ja "C" Definiere auf einem Blatt Papier Deine Page und welche Variablen da drin stehen. Dann Zugriff auf die Page und den oder die Werte holen. Notfalls die Werte in den RAM legen. Keine Ahnung ob C sowas kann. Ein ASM Programmierer denkt da nicht lange drüber nach :-)
Stephan schrieb: > Ein ASM Programmierer denkt da nicht lange drüber nach :-) Du hast das Problem nicht verstanden und faselst. Geh weg. Weder in C noch in Assembler kann man transparent auf ein Objekt zugreifen, wenn man eine Zugriffsfunktion benötigt. In C++ ginge das. Eine Datensatzstruktur mit read_dataset(index, &dataset) zu befüllen, ist kein Thema. Aber das ist eben nicht transparent.
S. R. schrieb: > Weder in C noch in Assembler kann man transparent auf ein Objekt > zugreifen, wenn man eine Zugriffsfunktion benötigt. Naja, man könnte schon, wenn's denn unbedingt sein muß. Mit ein bißchen Hardware-Nachhilfe (so es die denn auf dem Zielprozessor gibt). Ein "virtuelles" Array irgendwo hinlegen, wo ein Zugriff in jedem Fall einen Fault auslöst, dann im Fault-Handler Stack und Registerinhalte passend "hinfummeln" und zurückspringen, wie wenn nichts gewesen wäre. Ungefähr so, wie man das früher beispielsweise bei der "Software-FPU" gemacht hat. Ob das in diesem Fall den Aufwand rechtfertigt und irgendwas besser macht, sei dahingestellt.
Bitte nicht streiten. Dass man auf einem ATMega in Abhängigkeit von der Speichersektion nicht automatisch auf verschiedene Routinen zugreifen kann, weiß ich schon. Das ist ja auch beim internen EEPROM so. Aber hier kann man ja dann die Variablen unter Angabe der Sektion nacheinander definieren, muss aber dann mit den jeweils zuständigen Funktionen darauf zugreifen. Vertut man sich da, geht es halt in die Hose. Diesen Mechanismus hätte ich halt gerne auch für eine neue und von mir definierte Sektion (hier eben SPI_EEPROM). Ist zwar nur die halbe Miete, aber wesentlich besser als die Adressverwaltung zu Fuß. Gut, geht eben nicht, dann muss ich das per #define lösen, der Aufwand soll ja auch in Grenzen bleiben. Thomas
u.B. Habe mir auf dem Cortex dazu folgende Struktur + enum angelegt: // liegt im uC Flash const uint32[] = { 0, // mac addr 6, // irgendwas 6 byte später }; enum { EEPROM_S_MACADDR = 0, EEPROM_S_IRGENDWAS = 1, }; Aber eine Lookup-Table ist nun auch nicht die neuste Erfindung. Ein Dateisystem macht nichts anderes. Du kannst es auch viel cleverer schreiben, ist aber viel zu oversized für so einfache Aufgaben!
Thomas P. schrieb: > Gut, geht eben nicht, dann muss ich das per #define lösen, der Aufwand soll ja auch in Grenzen bleiben. Verstehe ich nicht, wieso soll das denn jetzt auf einmal nicht gehen? Du hast doch Lösungen bekommen.
Thomas P. schrieb: > Diesen Mechanismus hätte ich halt gerne auch für eine neue und von mir > definierte Sektion (hier eben SPI_EEPROM). Das ist in C nicht möglich. Nimm explizite Zugriffsfunktionen oder C++.
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.