Moin, meine AlarmSau nimmt jetzt so langsam Formen an. Das (Assembler)Programm entwickelt sich prächtig, 164kB Quelltext in 6200 Zeilen, 13.5kB Futter für den Controller, etwa 5500 Befehle. Code-Eingabe funktioniert, Alarmauslösung funktioniert, SMS bei Alarmauslösung funktioniert. Der Rest ist die langweilige Benutzerverwaltung. Und da bin ich auf ein Problem gestoßen, wo ich keine Antwort für gefunden habe: Die Konfiguration soll in den EEPROM rein, so weit kein Problem. Aber kann man irgendwie verhindern, daß der AVR beim Flashen jedes Mal den EEPROM-Inhalt vergisst? Im Moment stehen da noch keine Nutzerdaten drin, nur die Kalibrationswerte für die Alarmschleifen. Daher muß man im Moment zum Testen nur die Kalibration nach dem Flashen neu ausführen, aber das wird noch komplexer wenn Benutzerdaten dazukommen. Spätestens dann nervts. Muß ich dem AVR-Studio beim Flashen einen Inhalt für den EEPROM bereitstellen, der mit hineingeschrieben wird oder wie geht das? Danke!
EESAVE Fuse setzen, dann bleibts beim Chip Erase erhalten.
Hi, vor dem Flashen des Programms, dem ja ein Chip Erase vorangeht, musst Du die EESAVE Fuse setzen. Die verhindert, dass beim Chip Erase das EEPROM ebenfalls gelöscht wird.
Ben B. schrieb: > Moin, meine AlarmSau nimmt jetzt so langsam Formen an. > > Das (Assembler)Programm entwickelt sich prächtig, 164kB Quelltext in > 6200 Zeilen, 13.5kB Futter für den Controller, etwa 5500 Befehle. > Code-Eingabe funktioniert, Alarmauslösung funktioniert, SMS bei > Alarmauslösung funktioniert. Der Rest ist die langweilige > Benutzerverwaltung. > > Und da bin ich auf ein Problem gestoßen, wo ich keine Antwort für > gefunden habe: Die Konfiguration soll in den EEPROM rein, so weit kein > Problem. Aber kann man irgendwie verhindern, daß der AVR beim Flashen > jedes Mal den EEPROM-Inhalt vergisst? Im Moment stehen da noch keine > Nutzerdaten drin, nur die Kalibrationswerte für die Alarmschleifen. > Daher muß man im Moment zum Testen nur die Kalibration nach dem Flashen > neu ausführen, aber das wird noch komplexer wenn Benutzerdaten > dazukommen. Spätestens dann nervts. Muß ich dem AVR-Studio beim Flashen > einen Inhalt für den EEPROM bereitstellen, der mit hineingeschrieben > wird oder wie geht das? > > Danke! Hi, gab es dafür nicht sowas wie EESAVE als Fuse? Micha
Drei mal? Dann wirds wohl stimmen. Und wohl auch im Datenblatt stehen.
Wobei schon erstaunlich ist, dass jemand, der sich derart intensiv mit dem Controller befasst - Assemblerprogramm mit fünfeinhalbtausend Befehlen - nie an dieser Stelle im Datenblatt vorbeikam.
Arduino Fanboy D. schrieb: > Drei mal? > Dann wirds wohl stimmen. > Und wohl auch im Datenblatt stehen. dummerweise nicht in der Arduino Defaulteinstellung. Ich könnte ja.... Aber was solls, kopiere ich halt nach dem flashen im Setup aus dem Progmem ins EEPROM. Noch ein Grund warum ich das EEPROM der RTC bevorzuge!
:
Bearbeitet durch User
Joachim B. schrieb: > dummerweise nicht in der Arduino Defaulteinstellung. Du überrascht mich! Beim Arduino Bootloader brennen, wird auch die EESAVE Fuse gesetzt. Soweit mir bekannt, bei allen AVR Arduinos. Also ja, das ist der Arduino Default.
Beitrag #5682670 wurde von einem Moderator gelöscht.
> EESAVE Fuse setzen, dann bleibts beim Chip Erase erhalten.
Hm sorry für die dumme Frage, das war zu einfach um selbst drauf zu
kommen.
Ich danke euch, funktioniert prima!
Edit: Die Größe des Quelltextes ist einfach die komplette Datei, mit
allen Kommentaren, Labeln usw. Das ganze Getippsel halt.
Und ja, ich hab die Stelle im Datenblatt wohl überlesen, habe ich
bislang nicht gebraucht bzw. wenn ich mal was mit dem EEPROM gemacht
habe, hat es nicht gestört, wenn der beim Flashen gelöscht wurde.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Du überrascht mich! > > Beim Arduino Bootloader brennen, wird auch die EESAVE Fuse gesetzt. vielleicht irrte ich mich? bestimmt wenn du das sagst, da ich ab Arduino nur umständlich ein eep erzeugen kann, da steckte ich nie so tief drin wie im AVR Studio habe ich mir das interne EEPROM am Arduino abgewöhnt. Ich weiss zwar nun das man das irgendwie hinbekommt, aber ich brauche es nicht, entweder sehe ich ein I2C EEPROM 8pinner im DIL Sockel vor zum kaputtbrennen oder das in dem billigen RTC-Modul, bevor ich den Arduino schrotte. Externe EEPROMs lassen sich durchs AVR flashen eh nicht stören.
:
Bearbeitet durch User
Joachim B. schrieb: > bestimmt wenn du das sagst, da ich ab Arduino nur umständlich ein eep > erzeugen kann, Was ist ein eep? Vielleicht geht das ja doch einfacher, als du glaubst.
Hi
>Was ist ein eep?
Diese dümmliche Frage konnte nur von dir kommen.
MfG Spess
So schau bist du? Dann sage es mir doch bitte, was der Joachim damit meint. Wenn damit die *.eep Datei gemeint ist, die erzeugt Arduino selber, da muss man nichts "umständlich erzeugen". Die wird bei der Kompilierung für AVRs gleich mit erzeugt. Automatisch und immer. Da kann man sich kaum gegen wehren. Also nochmal die Frage: @Joachim Was ist für dich ein eep? Was meinst du mit eep?
Arduino Fanboy D. schrieb: > Wenn damit die *.eep Datei gemeint ist, Die ist wohl gemeint. > die erzeugt Arduino selber, da > muss man nichts "umständlich erzeugen". Dann bleibt ja nur noch die Frage, ob 1. Die Arduino-IDE den eep-Inhalt automatisch ins EEPROM schickt 2. Wenn ja, ob man das abschalten kann, um die aktuellen EEPROM-Daten zu erhalten
Arduino Fanboy D. schrieb: > Dann sage es mir doch bitte, was der Joachim damit meint. [Mod: gekürzt] Ein eep ist eine Eingabedatei für avrdude, die den Inhalt des EEproms vorgibt. So wie eine hex Datei den Inhalt des Programmspeichers vorgibt. Avrdude wird von Arduino verwendet, wenn du auf den "Hochladen" Knopf klickst. Soweit ich weiss unterstützt die IDE jedoch nicht das Hochladen von eep Dateien ins EEprom.
:
Bearbeitet durch Moderator
Beitrag #5683119 wurde von einem Moderator gelöscht.
Beitrag #5683120 wurde von einem Moderator gelöscht.
Beitrag #5683121 wurde vom Autor gelöscht.
Beitrag #5683124 wurde von einem Moderator gelöscht.
Beitrag #5683127 wurde von einem Moderator gelöscht.
Ich bitte, beim Thema zu bleiben. Beiträge mit persönlichen Angriffen werden gelöscht.
c-hater schrieb im Beitrag #5682670:
> ernsthafter Asm-Programmierer
Das ist ein Oxymoron.
Frank M. schrieb: > Dann bleibt ja nur noch die Frage, ob > > 1. Die Arduino-IDE den eep-Inhalt automatisch ins EEPROM schickt > > 2. Wenn ja, ob man das abschalten kann, um die aktuellen > EEPROM-Daten zu erhalten 1. Nein, aus 2 Gründen: 1a. Die vorgefertigten Upload Wege der IDE sehen das nicht vor 2b. Die Bootloader können das nicht. 2. Da man das in der Hand hat, stellt das wenig Problem dar. --------- Wie geh es? Benötigt wird ein ISP Programmer, da der Weg über den Arduino Bootloader versperrt ist. Der für mich am leichtesten gangbare Weg ist, den Menuepunkt "Hochladen mit Programmer" zu verändern. Denn, aus meiner Sicht ist der sowieso defekt. OK, er funktioniert, läd aber nur das Programm hoch, nicht den Bootloader, der geht dabei verloren. Das macht dann den nächsten Upload über USB unmöglich. Man kann den Menuepunkt so erweitern, dass: 1. Programm 2. EEPROM Daten 3. Bootloader In einem Schub hoch geladen werden. Vorgehen: Man sucht den Ordner mit der betreffenden Boarddefinition. Dort liegt eine platform.txt. Daneben legt man eine Datei namens platform.local.txt. In dieser kann man alle Einträge der originalen platform.txt überschreiben. Und auch noch eigene Dinge unterbringen. Damit man per ISP unter dem Menuepunkt "Hochladen mit Programmer" sowohl Programm, EEPROM DAten, asl auch Bootloader auf den AVR speilsen kann, bracuht es nur eine Zeile in der platform.local.txt:
1 | tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.with_bootloader.hex:i" "-Ueeprom:w:{build.path}/{build.project_name}.eep:i" |
c-hater schrieb im Beitrag #5682670:
> mit 5,5k Befehlen auf satte 164k Quelltext zu kommen
Ist einfach hervorragend kommentiert! Da kann man sich eine Scheibe
abschneiden!
Gruss Chregu
> 2. Wenn ja, ob man das abschalten kann, um die aktuellen > EEPROM-Daten zu erhalten Nach der Veränderung des Menuepunktes: Der normale Upload, über USB, erhält die EEPROM Daten Der Upload mit Programmer überschreibt die EEPROM Daten.
Christian M. schrieb: > c-hater schrieb im Beitrag #5682670: >> mit 5,5k Befehlen auf satte 164k Quelltext zu kommen > > Ist einfach hervorragend kommentiert! Da kann man sich eine Scheibe > abschneiden! > > Gruss Chregu Wahre Assemblerprogrammierer beißen die Befehle binär ins Papierband. Redundanzfrei!
> Wahre Assemblerprogrammierer beißen die Befehle binär > ins Papierband. Redundanzfrei! Das würde ich ja glatt machen, aber leider ist das mit dem AVR und einem Lochstreifen so eine Sache...
Also "beißen" nun nicht gerade, aber von Hand jedes Loch einzeln stanzen, dafür ist sich manchmal selbst ein Professor nicht zu schade - in einen Datenträger für eine Drehorgel nämlich, Notenrolle oder -karton.
Angehängte Dateien:
Stefanus F. schrieb: > Ein eep ist eine Eingabedatei für avrdude, die den Inhalt des EEproms > vorgibt. So wie eine hex Datei den Inhalt des Programmspeichers vorgibt. Hmm, ich kapier's nicht. Bei mir ist eep.hex beim EEPROM Brenn-Untermenü drin. Nur als Offline-Beispiel Arbeite ohne Bootloader und ohne "USB". ciao gustav
Karl B. schrieb: > Bei mir ist eep.hex beim EEPROM Brenn-Untermenü drin. Ja! Der Umweg ist für die Arduino IDE nötig. Nicht fürs Atmel Studio. Das Problem vom Ben B. (Firma: Funkenflug Industries) (stromkraft) ist schon längst erledigt, wenn ich das richtig verstanden habe.
Yep meine Frage ist beantwortet, aber ich gebe den Thread gerne für andere Probleme frei wenn jemand anders welche hat... Ich selbst hatte das mit der EEPROM-Datei nur als Workaround angedacht falls es nicht sowas tolles wie diese EESAVE Fuse gegeben hätte. Ich nutze auch keine Arduino-IDE.
Ja, dann ist ja alles Fein (bis jetzt). Für die Liebhaber der Arduino IDE packe ich mal 2 Beispiele in den Anhang, wie man mit dem AVR EEPROM umgehen kann.
Bin zwar BASCOM-Programmierer, muss jedoch auf ein Problem, welches hochsprachenunabhängig ist, hinweisen; Nie den ersten EEPROM-Speicherplatz des AVR nutzen, der geht nach jedem Neustart auf FFFFFFFF. Entweder ein erstes EEPROM-Dummy festlegen oder direkt adressieren. VG Micha
Michael B. schrieb: > Nie den ersten EEPROM-Speicherplatz > des AVR nutzen, der geht nach jedem Neustart > auf FFFFFFFF. Davon lese ich jetzt zum ersten mal. Und ich bin schon lange dabei.
Michael B. schrieb: > Nie den ersten EEPROM-Speicherplatz > des AVR nutzen, der geht nach jedem Neustart > auf FFFFFFFF. Soviel ich im Laufe der Jahre hier im Forum darüber gelesen habe, war das vor vielen Jahren bei den AVRs mal ein Bug, der längst behoben wurde. Von daher gilt das wohl nicht mehr. Viel wichtiger ist beim Schreiben des EEPROMs eine stabile Spannung. Deshalb sollte man, wenn man das EEPROM verwendet, auch die Brownout-Fuses entsprechend konfigurieren.
Stefanus F. schrieb: > Ein eep ist eine Eingabedatei für avrdude, die den Inhalt des EEproms > vorgibt. So wie eine hex Datei den Inhalt des Programmspeichers vorgibt. Letztlich sind beides Intel Hex Dateien. Die entsprechenden Suffixe haben sich nur mal so eingebürgert. Eigentlich bräuchte man die schon jahrelang nicht mehr, man könnte die entsprechenden Passagen auch direkt aus der ELF-Datei dem AVRDUDE hinlegen. Hat sich aber offenbar bis in die Arduino-IDE noch nicht rumgesprochen. Arduino Fanboy D. schrieb: > Man kann den Menuepunkt so erweitern, dass: > 1. Programm > 2. EEPROM Daten > 3. Bootloader > In einem Schub hoch geladen werden. Das mag für Produktionscode interessant sein *), für die laufende Entwicklung eher nicht. Entweder arbeite ich mit einem Bootloader, dann programmiere ich den einmal, danach benutze ich ihn. Oder ich programmiere direkt, dann kann ich mir (während der Entwicklungszyklen) den Bootloader auch klemmen. Durch den chip erase wird er bei üblichen AVRs ja ohnehin jedesmal wieder gelöscht. EEPROM-Daten wiederum will ich während der Entwicklung vielleicht ja auch nicht jedesmal wieder auf ihren Ursprung zurücksetzen. *) Den wiederum würde ich zumindest nicht über eine IDE flashen, sondern über einen Script oder eine kleine App oder etwas Ähnliches.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Das mag für Produktionscode interessant sein *), für die laufende > Entwicklung eher nicht. Entweder arbeite ich mit einem Bootloader, > dann programmiere ich den einmal, danach benutze ich ihn. Oder ich > programmiere direkt, dann kann ich mir (während der Entwicklungszyklen) > den Bootloader auch klemmen. Durch den chip erase wird er bei üblichen > AVRs ja ohnehin jedesmal wieder gelöscht. > Natürlich kannst du dir die Welt so zurecht malen/basteln, wie sie dir am liebsten ist. Die Frage ob oder nicht Bootloader stellt sich in der Arduino Welt kaum, da wohl alle Arduinos einen haben. Und die EESAVE Fuse ist auch bei allen gesetzt. Jörg W. schrieb: > EEPROM-Daten wiederum will ich während der Entwicklung vielleicht ja > auch nicht jedesmal wieder auf ihren Ursprung zurücksetzen. Sach ich doch! Passiert ja auch nicht über den Bootloader Nur mit ISP möglich. Auch wenn dir mein vorgeschlagener Weg nicht schmeckt, ist es doch eine gangbare Möglichkeit, die *.eep Datei aus der Arduino IDE auf den AVR spielen zu können. Eine einfache Möglichkeit. Das was du vorschlägst: Eine extra Anwendung auf dem AVR und eine auf dem PC, um die Daten hoch zu spielen hört sich nicht gerade so an, als ob das flotter von der Hand geht. Auch die Bootloader von allen Arduinos zu entfernen, naja, wenn nötig ok, aber warum, wenn es nicht muss? Ich rate dir: Spiel mit der Arduino IDE und probiere meinen und deine Wege aus. Und dann komm wieder, und sage, was leichter von der Hand geht. Jörg W. schrieb: > Eigentlich bräuchte man die schon jahrelang nicht mehr, man könnte die > entsprechenden Passagen auch direkt aus der ELF-Datei dem AVRDUDE > hinlegen. Hat sich aber offenbar bis in die Arduino-IDE noch nicht > rumgesprochen. Für mich erstmal nicht zu ändern.
Arduino Fanboy D. schrieb: > Spiel mit der Arduino IDE und probiere meinen und deine Wege aus. Nö. Warum sollte ich? Ich programmiere seit mittlerweile fast 20 Jahren AVRs, pflege seit wahrscheinlich 15 Jahren AVRDUDE, warum sollte ich mir deshalb nun deinen Weg unbedingt aufdrängeln lassen? Die Arduino IDE habe ich schon mal gesehen, aber keinen Drang, sie nun deshalb zu meiner täglichen Umgebung zu machen. Die IDEs kommen und gehen, meine Umgebung ist im Vergleich dazu ziemlich stabil (und nahezu unabhängig vom eigentlichen Target, PC vs. AVR vs. ARM). :) > Die Frage ob oder nicht Bootloader stellt sich in der Arduino Welt kaum, > da wohl alle Arduinos einen haben. Dann braucht man aber auch keine Verrenkungen, um ihn irgendwie neu zu programmieren, denn er ist schon da und wird sich selbst sowieso nicht antasten wollen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > warum sollte ich mir deshalb nun > deinen Weg unbedingt aufdrängeln lassen? Wieso "drängeln"..? Mir ist es doch völlig egal, mit welchen Systemen du arbeitest. Du hast deinen Vorschlag gemacht, ohne die Arduino IDE zu kennen, ohne das Problem je in dieser Form gehabt zu haben. Ohne die Arduino IDE dafür nutzen zu wollen. OK, kannst du machen.... Aber du wirst so nicht feststellen können, ob deine Vorschläge überhaupt taugen. Jörg W. schrieb: > Dann braucht man aber auch keine Verrenkungen, um ihn irgendwie neu zu > programmieren, denn er ist schon da und wird sich selbst sowieso nicht > antasten wollen. Hach... Zum hochladen der EEPROM Datei benötigt man einen ISP, da der Bootloader das nicht kann. Beim Hochladen der Anwendung über ISP, wird der Bootloader beim Chip Erase gelöscht. Also finden wir manchmal folgende Situation vor: Ok, nicht "wir", sondern ICH, und evtl. noch ein paar andere Arduino User. Es muss Bootloader + Anwendung + EEPROM hochgeladen werden. Und genau das erledigt mein Vorschlag. Ich denke mal, "Verrenkungen", würdest du spüren, wenn du versuchen würdest DEINE Vorschläge mit der Arduino IDE umzusetzen. Aber das willst du ja nicht. Und ich möchte dich nicht bekehren.
Arduino Fanboy D. schrieb: > Zum hochladen der EEPROM Datei benötigt man einen ISP, da der Bootloader > das nicht kann. Das ist allerdings ein meiner Meinung nach ziemlich ernsthafter Schwachpunkt. Ist ja nicht so, dass man das grundsätzlich nicht implementieren könnte …
Die Idee mit dem Bootloader kam mir schon immer fragwürdig vor. Die ursprünglichen Arduino Boards enthalten alle einen programmierbaren Chip als USB-UART, da hätte man auch gleich einen STK500 kompatiblen ISP Programmer mit unterbringen können. Dann müsste man hier nicht jeden Monat erneut erklären, wie man den ISP Sketch verwendet. Ausserdem wären die Arduino Boards dann ohne zusätzliche Hardware AVR/Atmel Studio kompatibel. Aber was erwartet man von Leuten, die sogar die I/O Pins neu durch nummerieren...das war auch eine Schnapsidee. Also ob die Bezeichnung D0 verständlicher wäre als PD0 und A0 oder 14 besser wäre als PC0. Dank der "einfachen" Nummerierung fragen jetzt Leute alle Nase lang, ob man die analogen Eingänge auch digital verwenden kann und was dabei zu beachten wäre. Und dann auch noch 70 CPU Takte um einen Pin auf High zu setzen, ... echt geil. Ich würde sagen: Ziel verfehlt.
Stefanus F. schrieb: > Aber was erwartet man von Leuten, die sogar die I/O Pins neu durch > nummerieren...das war auch eine Schnapsidee. Nein, ist es nicht. Es bietet die Möglichkeit, über verschiedene Hardwareimplementierungen übergreifend eine einheitliche Nummerierung der Pins zu verwenden, sodass die "Sketches" so lange hardwareunabhängig aufgebaut werden können, wie sie nicht selbst direkt auf die Hardware zugreifen. (Dass man damit nicht die maximale Performance erreichen kann, die die Hardware eigentlich gestattet, ist aufgrund der Architektur der IN/OUT/SBI/CBI-Befehle des AVR sonnenklar, aber das war sicher auch kein Designziel.) Es ging hier nicht um allgemeines Arduino-Bashing, sondern um EEPROM-Inhalte.
Das gleiche Problem habe ich beim Flashen vom PIC. Beim löschen vom PIC wird sowohl Flash und auch Eeprom gelöscht. Ich benutze den Brenner vom Sprut.Wenn die Option im Sprut Programm „Eeprom Inhalt behalten“, wird Eeprom Inhalt vor dem Löschen gesichert und am Ende von Programmierung wieder geschrieben.
B. P. schrieb: > Wenn die Option im Sprut Programm „Eeprom Inhalt behalten“, wird > Eeprom Inhalt vor dem Löschen gesichert und am Ende von Programmierung > wieder geschrieben. Offenbar unterstützt (dein) PIC sowas nicht direkt in der Hardware. AVRs dagegen unterstützen das halt schon, es muss ihnen nur per EESAVE-Fuse vorher mitgeteilt worden sein.
Das mit der nicht sicheren Nutzung des ersten EEPROM-Byte beim AVR geht zwar ein wenig am eigentlichen Thema vorbei, ich habe mir bei meinem letzten grösseren Projekt fast einen angebrochen. Dort sollte lediglich ein sich selbst einlernbarer Wert netztausfallsicher gespeichert werden. Da ich dies übern Compiler gemacht habe, wurde natürlich die erste Speicherzelle genutzt. War fast am Verzweifeln, bis ich von irgendwo her mal Wind bekam von diesem Problem. Hab dann die 2. Speicherzelle genutzt, dann liefs. VG Micha
Jörg W. schrieb: > Es ging hier nicht um allgemeines Arduino-Bashing, sondern um > EEPROM-Inhalte. Es ging hier - wenn man sich den ersten Beitrag anschaut - noch nicht einmal um Arduino ;-)
Jörg W. schrieb: > Es ging hier nicht um allgemeines Arduino-Bashing, Vielleicht für dich und mich nicht. Wenn man genügend Hass und Wut im Herzen trägt, kann das Arduino Bashing schon ein Ventil sein, um etwas Druck abzulassen. Immer bedenken: Was einem bei (AVR) Arduinos fehlt, kann man sich ja bauen... Aber wenn die Kompetenz dafür nicht langt, dann kann man schon sauer auf alle Arduinos sein. Stefanus F. schrieb: > Und dann auch noch 70 CPU Takte um Auf die 70 Takte für Digital Out ist man nicht angenagelt. Auch die Durchnummerierung der Pins tut nicht weh, wenn man den Compiler das herauswürfeln lässt. Mit ein bisschen OOP, bekommt man das so schlank und schnell, dass selbst Assembler Fans da kaum einen Takt mehr rausholen, oder Speicherplätzchen einsparen, können. Jörg W. schrieb: > sondern um EEPROM-Inhalte. Auch das lässt sich gestalten. An der Stelle würde es mich erfreuen, wenn jemand man die Arduino Doku so auf Vordermann bringt, dass sie zeigt, wie man die EEPROM Adressen automatisch vom Compiler berechnen lässt. Denn in der Doku werden nur absolute/konstante Adressen verwendet. Die Adressberechnung bleibt beim Programmierer hängen, und ist damit recht offen für Flüchtigkeitsfehler/Irrtümer. Die beiden Beispiele von mir, ein paar Beiträge vorher, vermeiden das. Das erzeugen der eep Datei mit den Vorbesetzungen ist nur eine weitere nützliche Kleinigkeit dabei. ..naja, vielleicht mache ich das mal..
Arduino Fanboy D. schrieb: > An der Stelle würde es mich erfreuen, wenn jemand man die Arduino Doku > so auf Vordermann bringt, dass sie zeigt, wie man die EEPROM Adressen > automatisch vom Compiler berechnen lässt. Am einfachsten, alle EEPROM-Daten in eine einzelne struct packen. Die beginnt dann logischerweise auf EEPROM-Adresse 0. Wenn man (wegen der potenziellen Probleme bei brownout oder reset während des EEPROM-Schreibens) Adresse 0 auslassen will, legt man halt ein Dummy-Byte als erstes in die struct.
Jörg W. schrieb: > Am einfachsten, alle EEPROM-Daten in eine einzelne struct packen. Kann man tun. Ich stufe das mal als Empfehlenswert ein. Aber auch einzelne Variablen mit dem EEMEM Attribut stellen kein Problem dar. Zumindest solange nicht, bis man die Eeprom Daten erhalten möchte, und der Linker die Variablen durcheinander wirbelt. Dann hätte man besser eine Struktur verwenden sollen.
Arduino Fanboy D. schrieb: > Aber auch einzelne Variablen mit dem EEMEM Attribut stellen kein Problem > dar. Du hast nur keinen Einfluss darauf, wie der Linker sie anordnet.
Jörg W. schrieb: > Du hast nur keinen Einfluss darauf, wie der Linker sie anordnet. Danke für die Bestätigung! Schön, dass wir uns in dem Punkt so einig sind.
Würde das Problem mit der ersten Speicherzelle des EEPROM nicht im Errata stehen wenn es da Probleme gäbe?
Das Problem war zumindest irgendwo dokumentiert, weiß nicht, ob das in den Appnotes war, oder ob es nur Errata einzelner (älterer) Devices waren. So aus der Erinnerung: wenn man eine EEPROM-Zelle beschreiben will, aber während des Schreibens ein Reset ausgeführt wird, dann konnte es passieren, dass statt an der gewünschten Adresse die Zelle 0 beschrieben wird.
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.