Hi, gibt es evtl. sogar schon ein Byte, welches OOTB bei jedem Compiliervorgang erzeugt wird und auf dem Controller landet? Anderenfalls, wie würde man es am einfachsten anstellen, dass ein Timestamp automatisch beim compilieren erzeugt und mit auf den AVR geschrieben wird? Ich möchte am Ende des Tages ein Datumsstempel (egal in welchem Format) auf dem angeschlossenen Display ausgeben können, dass mir zusätzlich zur händisch gepflegten Versionsnummer (auf einen Blick!; hex-Files zweier unbekannter Chips auslesen und mit DIFF vergleichen ist ein Workarround aber keine zufriedenstellende Option;-) bestätigt, dass es sich um den gleichen Code handelt. Grüße Oekel PS: wir reden hier nicht von fälschungssicher. Es geht eher um die Bequemlichkeit mittels 1-2 Programmzeilen.
_DATE_ _TIME_
Also wirklich einfach:
1 | |
2 | |
3 | |
Hi, Naja der TO schrieb "auf" dem AVR ;) Da bleibt wohl nur Gravieren. BG, Tom
D a v i d K. schrieb: > char EEMEM compileTimestamp[11+1+8] Ich würde dem Ding ein Byte mehr spendieren, damit es auch mit einem Nullbyte terminiert wird. Und man kann die Angaben in den Klammern auch einfach weglassen, der Compiler kann nämlich selber zählen.
1 | |
Warum EEProm? Warum nicht Flash?
Gast
#5070230
D a v i d K. schrieb: > Anderenfalls, wie würde man es am einfachsten anstellen, dass ein > Timestamp automatisch beim compilieren erzeugt und mit auf den AVR > geschrieben wird? Mit einem Timestamp erkennst du nicht, ob der gleiche Code drauf ist. Damit siehst du nur, ob er aus dem selben Compilerlauf stammt. Ein Hash-Wert des Codes wäre zur Unterscheidung evtl. besser geeignet.
Beitrag #5070409 wurde von einem Moderator gelöscht.
Wolfgang schrieb: > D a v i d K. schrieb: > Ein Hash-Wert des Codes wäre zur Unterscheidung evtl. besser geeignet. In der Theorie hast du recht. In der Praxis compilieren ich ja nur, wenn ich auch Änderungen vorgenommen habe. Bzw. ich flashe nur Versionen, die ich mir zuvor gesichert habe (alos aus der IDE extrahiere). Daher ist der Anwendungsfall schon abgedeckt.
Carl D. schrieb: > Warum EEProm? Warum nicht Flash? Nur damit ich es nun nicht verwechsel: Flash wäre, wenn ich das EEEMEM aus der Deklaration streiche? (Also der ganz normale Speicher?) In dem Fall lautet meine Antwort: um Flash-Speicher zu sparen. Ansonsten: nutze ich den Flash noch gar nicht??? Wofür War dieser gleich noch geeignet/optimiert? Grüße Oekel
Gast
#5070532
D a v i d K. schrieb: > Ansonsten: nutze ich den Flash noch gar nicht??? > Wofür War dieser gleich noch geeignet/optimiert? ROFL. Das ist ein guter Witz.
D a v i d K. schrieb: > Carl D. schrieb: >> Warum EEProm? > In dem Fall lautet meine Antwort: um Flash-Speicher zu sparen. > Da war Dumpfbacke schneller, als ich editiert konnte. Vermutlich verbraucht mein Funktionsaufruf zum lesen der EPROM Stelle mehr als den Wert direkt in den Flash zu schreiben :( Also Denkfehler und ab in den Flash!
Beitrag #5070538 wurde von einem Moderator gelöscht.
Gast
#5070542
D a v i d K. schrieb: > als den Wert direkt in den Flash zu schreiben :( Du brauchst den String gar nicht explizit ins Flash schreiben. Der existiert ganz einfach schon wenn du einen Code compilierst (und ihn dann ins Flash schreibst) wo dieser String definiert ist.
Dumpfbacke schrieb: > D a v i d K. schrieb: > Der existiert ganz einfach schon wenn du einen Code compilierst > ... wo dieser String definiert ist. So meinte ich das auch.
D a v i d K. schrieb: > Dumpfbacke schrieb: >> D a v i d K. schrieb: > >> Der existiert ganz einfach schon wenn du einen Code compilierst >> ... wo dieser String definiert ist. > > So meinte ich das auch. Beim AVR muß man eine Stringkonstante schon in Flash zwingen, sonst landet sie im RAM. Vielleicht war das ja auch nur ein Schreibfehler und es war PROGMEN statt EEMEM gemeint.
1 | |
Falls dies dann per printf ausgegeben werden soll, muß %S (groß!) als Formatzeichen verwendet werden, um den String direkt aus dem Flash zu lesen. Entsprechendes gibt es für das EEprom nicht. Oder eben printf_P(), wobei der FormatString selbst aus dem Flash kommt und z.B.
1 | |
nach obigem Muster enthält.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Gast
#5071094
D a v i d K. schrieb: > Wolfgang schrieb: >> D a v i d K. schrieb: > >> Ein Hash-Wert des Codes wäre zur Unterscheidung evtl. besser geeignet. > > In der Theorie hast du recht. In der Praxis compilieren ich ja nur, > wenn ich auch Änderungen vorgenommen habe. Bzw. ich flashe nur > Versionen, die ich mir zuvor gesichert habe (alos aus der IDE > extrahiere). > > Daher ist der Anwendungsfall schon abgedeckt. Und Du -resp. dein buildtool , so es schlau ist- compiliert nur die Dateien die geändert wurden. Änderst Du immer nur die Datei mit der Zeile wo _DATE__ und __TIME_ irgendwohin zugewiesen werden? Auch wenn diese Datei zu einer (natürlich vorcompiliert abgelegten) Bibliothek gehört, welche man aus Gründen von Effizienz und Qualitätssicherung genau so dazu nur-linken will, wie man sie letzten Monat binär auf Herz und Nieren getestet hatte? In einer kleinen Welt mit Horizont nur auf 8-Bit-Distanz wir deine Praxis wohl schon zutreffen. In einer grösseren Welt, mit gut Architektierten und gut Strukturierten Projektorganisation (gerne auch mit mehreren, auf mehreren Standorte verteilten, Mitarbeiter) ist darauf zu achten dass die Zeilen welche solche Buildspezifische Information in die Buildartefakte einbringen sollen tatsächlich auch bei jedem Builddurchlauf compiliert werden. Meine bevorzugte Variante besteht u.A. darin dass solche Information ausserhalb des Quellcodes aufbereitet wird und allen am Build beteiligten Werkzeuge (konkret: nicht nur dem Compiler) per Kommandozeilenparameter forciert mitgegeben werden. Alternativ wird solche Information in eine für den Build *zwingend notwendige* (Quellcode-)Datei geschrieben, diese aber nicht in der Versionsverwaltung vorliegt. Der Buildablauf generiert diese; z.b. durch abändern einer Vorlagedatei in der Platzhalter zu ersetzen sind.
Programmiersprachentheaterintendant schrieb: > > In einer kleinen Welt mit Horizont nur auf 8-Bit-Distanz wir deine > Praxis wohl schon zutreffen. > > In einer grösseren Welt, mit gut Architektierten und gut Strukturierten > Projektorganisation (gerne auch mit mehreren, auf mehreren Standorte > verteilten, Mitarbeiter) ist darauf zu achten dass die Zeilen welche > solche Buildspezifische Information in die Buildartefakte einbringen > sollen tatsächlich auch bei jedem Builddurchlauf compiliert werden. > > Meine bevorzugte Variante besteht u.A. darin dass solche Information > ausserhalb des Quellcodes aufbereitet wird und allen am Build > beteiligten Werkzeuge (konkret: nicht nur dem Compiler) per > Kommandozeilenparameter forciert mitgegeben werden. > Alternativ wird solche Information in eine für den Build *zwingend > notwendige* (Quellcode-)Datei geschrieben, diese aber nicht in der > Versionsverwaltung vorliegt. Der Buildablauf generiert diese; z.b. durch > abändern einer Vorlagedatei in der Platzhalter zu ersetzen sind. Ich lebe zwar auch von Software (die weltweit verteilt entwickelt wird), aber meine μC (AVR) Projekte am Abend kommen mit einem Entwickler und 2m2 Fläche aus. Eventuell geht es David ähnlich. Und an gut architiktierten und professionellen Projektorganisationen glaubt man nur, wenn man sie nicht kennt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.