Atmelstudio 7 Version als Variable

Nein, Atmel Studio ruft nur den avr-gcc auf, sofern es den avr-gcc 
angeht, hat der keine Ahnung wer ihn aufruft, also kann er auch nicht 
die Atmel Studio Version weitergeben.
Du kannst dieses Befehl ausführen um zu sehen was der compiler für 
defines beim kompilieren benutzt:

1

echo | "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-g++.exe" -dM -E -

Das sind die einzigen "Variablen" die du in deine Binary reinbauen 
könntest.

Natürlich könntest du selbst was einspeisen.
Es gibt diverse Atmel Studio Umgebungsvariablen, welche du als Defined 
Symbol an den compiler weitergeben kannst. Also quasi als -D switch.

Siehe Bilder.

Ich benutze bei Atmel Studio ein Pre-build Event das immer die folgenden 
3 Infos in ein Header File schreibt:

1

//Automatically generated file 

2

#define GITSHA "5e873fb0438d8d69e45e7bad0bc14af6dee866e4"

3

#define GITISCLEAN (true)

4

#define BUILDTARGET "Release"

Damit kann ich Später genau den Stand reproduzieren was auf einer HW 
drauf ist. Sofern ich auf einer HW

1

#define GITISCLEAN (false)

habe, dann weiß ich, dass ich das überhaupt nicht anfangen soll zu 
testen, da der Build nicht reproduzierbar ist.

Als Idee nehme ich von dem TO mit, dass ich in Zukunft vielleicht auch 
die Toolchain Version mit reinbaue. Im anderen Projekten habe ich 
üblicherweise auch den Toolchain mit im repo, als conan package zb. 
damit das auch automatisch mit getrackt wird.

Nichts zu ungut, aber eine Build Inkrementierung hilft mir nichts. Ich 
habe ja später keine Ahnung wann ich das genau gebaut habe, und welchem 
Repo Stand das entspricht.

Ach so, und das ganze wird immer über Uart beim booten ausgegeben, weil 
ein gelocktes AVR kann man ja nicht auslesen.

Klar mag nicht jeder git verwenden. Statt git sha kann man auch die SVN 
Nummer, oder die mercurial sha verwenden. Meinetwegen auch die MKS 
Revision Nummer.
Aber ich glaube dem TO war es wichtig ein Build reproduzieren zu können.

Und dafür brauche ich eigentliche folgendes:
1.gleicher source code
2.gleiche toolchain
3.gleiche toolchain flags

Wenn ich alles im Binary abspeichere dann weiß ich später was ich 
jemanden in die Hand gedrückt habe. Ich muss nicht explizit eine Build 
machen, das eine Versionsnummer hat.

1. wird gewährleistet mit dem commit das gebaut wurde.
2. wird gewährleistet mit Abspeicherung des compiler versions (mit Atmel 
ist das _VERSION_)
3. wird gewährleistet bei Atmel Studio durch die Build Konfiguration, 
weil die beinhaltet ja die flags. (also Release oder Debug)

Was genau Release oder Debug bedeutet wird ja im Projekt File 
gespeichert, was wiederum versioniert ist mit irgendeiner CVS, sei es 
git oder was anderes.

Das alles wird in die Binary abgespeichert beim bauen.

Ohne CVS kann man die ganze Reproduzierbarkeit vergessen.

Ich habe es all zu oft erlebt, das Tester irgendwas testen, wo die keine 
Ahnung haben was eigentlich drauf ist. Es werden Binaries in Emails 
herumgeschickt, wo man vielleicht aus dem Email selbst mit ein bisschen 
Glück rauslesen kann, welcher Stand denn gebaut wurde. Aber ein 
Fehlklick reicht ja schon um was falsches zu schicken.

Das einzige was Abhilfe schafft ist in dem Build System eine 
automatische Versionierung einzubauen, mit dessen Hilfe man genau weiß 
welcher Stand im CVS genau wie gebaut wurde.