Daten vom Compiler in EEprom schreiben lassen

International Deutsch
1

Hi

Ich bin auf der Suche, wie ich zur Compilerzeit Werte im EEprom verewigen kann.
Unterm Strich sollen Das Grenzwerte werden, Die ich ganz gerne 'von Außen' anpassen möchte und Die bei Spannungswiederkehr nicht verloren sind.
In Assembler kann ich im E-Segment Daten hinterlegen, Die in einem separatem File landen und gebrannt werden.
Meine Frage ist nicht, ob Das geht (kann mir ehrlich gesagt nicht vorstellen, daß Das bei C++ nicht geht), sondern Wie Das geht.

Auf

werden Werte wie MAC-Adresse, DS18B20-Adressen und so Kram per Programm selber ins EEprom geschrieben - kann mir nicht vorstellen, daß Das der ideale Weg ist.
Diese Werte in 'initiale_EEPROM' werden NIE WIEDER benötigt, meiner Meinung eine Verschwendung von Speicher.
Deshalb meine Frage: Wie bekommt Ihr schon vorher feststehende Daten ins EEprom, möglichst ohne Eigenleistung des Arduino selber.
Bei mir soll Dieser damit beschäftigt werden, diese Werte auszulesen und mit Messwerten zu vergleichen.

Im Klartext: Per US-Sensor wird die Füllhöhe eines Tank überwacht.
Wenn die Füllhöhe einen gewissen Stand unterschreitet, soll eine Aktion ausgelöst werden, wenn die Füllhöhe einen gewissen Stand überschreitet, eine Andere.
Da akut die Aufhanghöhe über dem oben offenem Wasser-Tank nicht vorherbestimmt werden kann, wollte ich zumindest Werte dort eintragen, Die die Funktion nicht stören, also außerhalb der abzutastenden Grenzen liegen.
Klar kann ich auch im Programm darauf prüfen, ob der Wert 'Standard' ist und erst dann verzweigen - Das kann Es aber auch nicht sein, bei meinen zwei/drei Variablen ein überschaubarer Aufwand, wenn's Mal mehr werden, eher nicht so toll.
Auch will die Prüfung, ob die Speicherstelle relevante Daten enthält jedes Mal Laufzeit haben und Programmplatz geht dabei auch drauf.

Also: Wie mache ich Es nun richtig?

MfG

2 
#include <EEPROM.h>

struct Configuration
{
  char name[20];
  float  temperature;
};

const Configuration eepconfig  EEMEM {"Gast",47.11}; // Arduino legt eine *.eep Datei an

Configuration buffer;

void setup() 
{
  Serial.begin(9600);
  Serial.println("Start"); 
  
  EEPROM.get(reinterpret_cast<int>(&eepconfig),buffer);
  Serial.println(buffer.name);
}

void loop() 
{
}

Nunja...
Das ist die Hälfte der Arbeit.

3

Schritt 2:
Per Hand die *.eep Datei übertragen.

Alternativ:
Den Eintrag tools.avrdude.program.pattern=
In der Boardefinition anpassen.

Der Upload funktioniert über einen ISP Adapter.

Ob er auch über den Bootloader funktioniert, habe ich noch nicht getestet.

4

Naja..

Ich finde das schon ok, das EEPROM mit den richtigen Werten vorzubesetzen.
Und es geht ja auch.

Vertrauen kann man der Geschichte ebenfalls.
Was soll da schief gehen?

Habe es gerade nochmal getestet...
Und in meine Dateien geschaut, was genau zu ändern ist.

Per Bootloader kann man das EEPROM nicht beschreiben.

Es geht also nur mit einem ISP Programmer.
Dabei ist darauf zu achten, dass man den Bootloader auch mit schreibt, damit später ein Upload per Bootloader möglich ist, ohne das EEPROM zu überschreiben.

Dazu muss eine Zeile in der plattform.txt geändert werden.
(die mit # Kommentar Zeichen, ist die alte original Zeile)

#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}.hex:i"
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"
5

combie:
Per Bootloader kann man das EEPROM nicht beschreiben.

Es geht also nur mit einem ISP Programmer.
Dabei ist darauf zu achten, dass man den Bootloader auch mit schreibt, damit später ein Upload per Bootloader möglich ist, ohne das EEPROM zu überschreiben.

Wäre es da nicht einfacher, einen kleinen Sketch zu schreiben, der die gewünschten Daten ins EEPROM schreibt, den runterzuladen, einmal auszuführen und dann den 'richtigen' Sketch hinterherzuschieben?

6

Ich mache mir für solche Fälle eine Funktion "SystemparameterSchreiben()", die alle relevanten Daten ins EEProm schreibt. Da ich auch eine "SystemparameterLaden()" habe, die mir im Setup die entsprechenden Variablen mit Daten aus dem EEProm beschreibt, ist die "Umkehrfunktion" recht schnell erstellt.

die Funktion "SystemparameterSchreiben()" ist normalerweise auskommentiert. Nur bei Bedarf wird die Funktion einmal von Hand aktiviert um das EEProm zu setzen.

Da Code selten auf Anhieb funktionieren (zumindest bei mir) muss man sowieso mehrmals compilieren und flashen, da geht das recht einfach, einmal die Funktion zu aktivieren. Ich mach sowieso immer noch einen letzen Upload, im dem die Serielle Ausgabe deaktiviert ist, um unnötigen Traffic zu sparen.

7

Euer Einsatz in Ehren...
Aber dem Eingangsposting ist zu entnehmen, dass unser postmaster-ino genau das nicht will.

(soweit ich das verstanden habe)

8

combie:
Es geht also nur mit einem ISP Programmer.

Und es erfordert eine Änderung der avr\platform.txt

Da das ja unabhängig von Flash-Update via IDE passieren soll, und auch eigentlich nichts mit "Bootloader brennen" zu tun haben muss, könnte man sich auch ein separates Tool vorstellen/schreiben, mit der Funktion EEPROM kompilieren, dann per avrdude / ISP Programmer nur den EEPROM neu schreiben.

Statt avr-gcc zum Kompilieren zu verwenden, wäre für diese begrenzte Aufgabe auch eine direkte Erzeugung der .hex Datei denkbar?

9

combie:
Euer Einsatz in Ehren...
Aber dem Eingangsposting ist zu entnehmen, dass unser postmaster-ino genau das nicht will.

(soweit ich das verstanden habe)

Ich hatte das zumindest so verstanden, dass ihn der 'tote' Code stört, der dann im Flash steht und nie mehr genutzt wird. Das wäre dann ja auch nicht gegeben, wenn der im endgültigen Sketch nicht mehr vorhanden ist - sei es das EEPROM-Schreiben als eigener Sketch oder hinterher auskommentiert.
Aber da wird er sich sicher zu äußern. Ist ja auch immer eine Frage wie einfach oder umständlich man die jeweilgen Varianten empfindet.

10

Und es erfordert eine Änderung der avr\platform.txt

Nicht unbedingt.
Die *.eep Datei zu schreiben geht auch händisch per avrdude, oder mit einem seiner grafischen Frontends.

Statt avr-gcc zum Kompilieren zu verwenden, wäre für diese begrenzte Aufgabe auch eine direkte Erzeugung der .hex Datei denkbar?

Denkbar, sicher.
Aber praktikabel, eher nicht.

Wenn man den Job dem Compiler überlässt, kann man sich sicher sein, dass er alle Adressen der EEP Daten korrekt auf dem Schirm hat.
Das halte ich für einen fast unschlagbaren Vorteil.

Andererseits:
Vielleicht erbarmt sich ja mal ein Java Spezi, welcher für das Werkzeuge Menue ein Tool baut, um *.eep Dateien hochzuladen.
Das würde mich erfreuen!

Aber da wird er sich sicher zu äußern.

Ja...!

11

Hi

Jupp, Da ist Er wieder und jupp, Dem geht Es in erster Linie um den toten Code.

Danke für die vielen Antworten und Überlegungen, wie man die Daten ins EEprom bekommt.
Favorisieren würde ich derzeit die Funktionen Lesen/Schreiben, wobei die Schreiben beim 'letzten Weg' auskommentiert wird, oder einen separaten Sketch, Dem die EEprom-Daten seriell zugefüttert werden - müsste da dann aber die Daten wohl aufbereiten, daß Die auch Da hin kommen, wo ich Diese dann brauchen - hier haben die Lesen/Schrieben Funktionen klar die Nase vorne.
Muß mir Mal den Aufbau der .eep Datei anschauen, die Hoffnung stirb zuletzt ... vll. ist Die ja halbwegs sinnig aufgebaut :wink:
Dann müsste ich 'nur noch' die .eep Datei seriell ausgeben (sollte sich mit Bordmitteln machen lassen) und im Arduino einen Interpreter, Der die Daten annimmt und 'weg brennt'.
Aufgrund der Geschwindigkeit des EEprom - ist hier ein Handshake nötig?
Wobei ich ja auch mit den FRams spiele - Da wäre Platz genug, um den Inhalt zwischenzuspeichern ... dann werde ich doch noch Millionär ... mit dem Arduino-EEprom-FRam-Shield.

Da gibt es Doch was, was der Compiler so nicht unterstützt - hätte doch fast auf das Gegenteil gewettet!

Befürchte, daß 'der endgültige Sketch' noch etwas auf Sich warten lassen wird :confused:
Wenn mir hier was halbwegs brauchbares gelingt, kommt Das aber hier rein.
(wir haben gerade Anfang 2018, wenn hier 2030 noch Nichts weiter kam, gab's wohl Keinen)

MfG

12

postmaster-ino:
Favorisieren würde ich derzeit die Funktionen Lesen/Schreiben, wobei die Schreiben beim 'letzten Weg' auskommentiert wird, oder einen separaten Sketch, Dem die EEprom-Daten seriell zugefüttert werden - müsste da dann aber die Daten wohl aufbereiten, daß Die auch Da hin kommen, wo ich Diese dann bra

Wo kommen denn die Daten her, die Du ins EEPROM schreiben willst? Ich hatte das so verstanden, dass Du diese Werte vorgibst. Dann kannst Du die doch einfach in dem 'EEPROM-Schreibe-Sketch' als const definieren, und dann im Setup des Sketches ins EEPROM schreiben - fertig. Da brauchst Du doch gar keine eep-Datei.

postmaster-ino:
Da gibt es Doch was, was der Compiler so nicht unterstützt - hätte doch fast auf das Gegenteil gewettet!

Der Compiler kann das schon. Das Problem liegt hier eher bei der Arduino IDE, die das bisher nicht so ohne weiteres ins EEPROM schreiben kann.

13

Der Compiler kann das schon. Das Problem liegt hier eher bei der Arduino IDE, die das bisher nicht so ohne weiteres ins EEPROM schreiben kann.

Ich befürchte mittlerweile, dass er nicht über das interne, sondern über externe Fram/Eeprom spricht(und vergessen hat das zu sagen).
Und dann war mein ganzes Geposte hier für die Katz.

Beispiel:
Ich ZEIGE ihm wie es mit dem Compiler geht, aber er sagt draufhin, dass es nicht geht.
Da gehen bei mir alle Lampen an.

14

Hi

Es geht weiter um das Arduino-interne EEprom, dort möchte ich akut je zwei/drei Werte für zwei Sensoren als Grenze anlegen.
Klar kann ich Das mit einem separatem Sketch, Der nur diese sechs Werte enthält - wird wohl auch genau so gemacht werden, da ich für 'elegantere Lösungen' wohl etwas (viel) mehr Zeit benötige.
Mittlerweile habe ich auch 'gefressen', daß der Compiler eine .eep Datei anlegt, ich Diese also, bei umfangreicheren Sachen, ggf. benutzen kann.

Entweder:

  • EEprom-Sketch aufspielen
  • .eep Datei seriell an den Arduino verfüttern
  • Nutz-Sketch aufspielen
    Oder:
  • EEprom per ISP brennen
  • Bootloader per ISP aufspielen (so wie ich Das verstanden habe, bleibt das EEprom davon unbehelligt)
  • Nutz-Sketch aufspielen

Bei der 'Entweder'-Version verbliebe der Bootloader auf dem Arduino - denke, damit bleibe ich flexibler, weiter geht Das dann komplett über USB.

Die Idee mit dem FRam geht in die Richtung, daß ich dort die kompletten Daten zwischenspeicher, da der FRam verflixt schnell ist und die serielle Schnittstelle nicht auf den µC warten muß.
Der 2.te Schritt, die Daten vom FRam ins EEprom zu bekommen - Da habe ich 'Alle Zeit der Welt'.
Wobei hier dann wohl wesentlich mehr Zeit bei drauf geht, als wenn ich die Übertragung der .eep Datei einbremse, daß ich Diese direkt ins EEprom bekomme.

@combie
Nicht Jeder denkt so verzwickt, wie ich bzw. ich verzettelt mich ruck zuck in neue Ideen - Deine Äußerungen 'für die Katz' dürften spätestens zukünftig Suchenden eine Hilfe darstellen.
(wobei ich bei der Erst-Lösung, nur die 6 Werte ins EEprom zu bekommen, diese Info wohl auch verwenden kann)

Das Umschreiben der Befehlsaufrufe möchte ich ganz gerne vorerst sein lassen.
Es schadet Nicht, wenn man mit der Standard-Installation ans Ziel kommen kann, befürchte beim 'Umbau', daß spätestens bei einer Neu-Installation irgend was nicht mehr klappt und das große Suchen beginnt.
Da sehe ich einen Vorteil, wenn mit einem unverspieltem System Alles 'ganz normal' funktioniert.
Ein .eep Dateien fressender Arduino-Sketch gefällt mir Da am Besten, wenn's aber wohl die Premium-Lösung darstellt und somit noch lange Zeit brauchen wird, bis Das 'spruchreif' ist.

Besten Dank

Wenn trotzdem noch was unklar ist: Fragen ... bin öfter hier :wink:

MfG

15

Oder:

Werte in den Quelltest des EEPROM-Schreib-Sketches schreiben, diesen hochladen und im Setup die Werte schreiben. Spart die serielle Übertragung und das eep-File.
Du hast die Daten sowieso irgendwo in einem Quelltext liegen.

Gruß Tommy

16

Hi

Du verdirbst mir auch jeden Spaß ... aber Recht hast Du.
Geht dann wieder in die Richtung 'später auskommentierte Schreib-Routine'.

Heute aber wohl nicht mehr, muß gleich noch Mal weg und kam bis jetzt noch nicht zu wirklich viel :confused:

MfG

17

postmaster-ino:
Entweder:

  • EEprom-Sketch ...
    Oder:
  • EEprom per ISP brennen
  • Bootloader per ISP aufspielen (so wie ich Das verstanden habe, bleibt das EEprom davon unbehelligt)
  • Nutz-Sketch aufspielen

Bei der "oder" Variante könnten wahlweise Bootloader und Sketch auf dem Arduino bleiben. Das geht allerdings nicht mit der IDE, sondern einer eigenen Funktion die avrdude und einen ISP-Programmer verwendet.

Da ist die Variante mit dem EEPROM-Brennsketch via USB wohl doch bequemer.