Timestamp des Compilers auf den AVR schreiben

[D a v i d K. (oekel)]

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.

[Max D. (max_d)]

_DATE_
_TIME_

[D a v i d K. (oekel)]

Also wirklich einfach:

__DATE__//The string constant contains eleven characters and looks like "Feb 12 1996".
__TIME__//The string constant contains eight characters and looks like "23:59:01"
char EEMEM compileTimestamp[11+1+8] = __DATE__ +"|"+ __TIME__;

[Thomas H. (flaretom)]

Hi,
Naja der TO schrieb "auf" dem AVR ;) Da bleibt wohl nur Gravieren.

BG, Tom

[Rufus Τ. F. (rufus)]

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.

char EEMEM compileTimestamp[] = __DATE__ + "|" + __TIME__;

[Carl D. (jcw2)]

Warum EEProm? Warum nicht Flash?

[Wolfgang (Gast)]

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.

[D a v i d K. (oekel)]

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.

[D a v i d K. (oekel)]

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

[Dumpfbacke (Gast)]

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. (oekel)]

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!

[Dumpfbacke (Gast)]

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.

[D a v i d K. (oekel)]

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.

[Carl D. (jcw2)]

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.

char PROGMEM compileTimestamp[] = __DATE__ +"|"+ __TIME__;

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.

__DATE__ und __TIME__

 nach obigem Muster enthält.

[Peter D. (peda)]

#include <avr/pgmspace.h>

prog_char Version[] __attribute__((used));
prog_char Version[] = PROJECT_STRING ", "
                      "V:" REVISION_STRING ", "
                      __DATE__ "\n";

[Programmiersprachentheaterintendant (Gast)]

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.

[Carl D. (jcw2)]

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.