Atmelstudio 7 Version als Variable

[Steffen (Gast)]

Hallo,

ich hab mal ne Frage. Ich nutze Atmelstudio 7 und div. Matmegas. Kann 
man die Build Version als Variable nutzen? Das man diese dann in einer 
Art Konfig im Programm verwenden kann? Um z.B. beim Updaten diese zuerst 
zu ermitten.

Vielen Dank

[Mate Rigo (Gast)]

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:

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.

[Adam P. (adamap)]

Steffen schrieb:
> Kann man die Build Version als Variable nutzen?

Meinst du die Build-Ver. vom AtmelStudio oder die deiner Firmware?

Build-Ver. AtmelStudio:
Ich hab die Version 7.0.2389, mit den vordefinierten Makros (Pre-build 
event command line) kannst du dir zumindest die 7.0 in eine 
"Versionsdatei" schreiben lassen:

echo #define AS_VERSION $(ProjectVersion) > "$(SolutionDir)\version.h

und die dann bei dir im Projekt einbinden.

Falls du die Firmware-Ver. meinst, da hab ich mir ein kleines 
konsolen-prog. geschrieben, welches ebenfalls über die "Pre-build event 
command line" aufgerufen wird, das liest die aktuelle version.h und 
erhöht bei jedem build die version.

Sieht dann so aus:

#ifndef _VERSION_
#define _VERSION_

#define VERSION_MAJOR  10
#define VERSION_MINOR  5
#define VERSION_BUILD  31

#endif /* _VERSION_ */

Ich lade es einfach mal als Bsp.-Projekt hoch.
Im VCTRL Ordner ist noch eine kleine readme und auch der Source...

und JA mir ist bewusst, dass es evtl. nicht super programmiert ist,
aber es funktioniert :-P

Vllt. kann es ja jmnd gebrauchen.

Gruß

[Mate Rigo (Gast)]

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

//Automatically generated file 
#define GITSHA "5e873fb0438d8d69e45e7bad0bc14af6dee866e4"
#define GITISCLEAN (true)
#define BUILDTARGET "Release"

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

#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.

[Adam P. (adamap)]

Mate Rigo schrieb:
> da der Build nicht reproduzierbar ist.

Es handelt sich um kein "Release", es ist grad nur in der Entwicklung.

Mate Rigo schrieb:
> Ich habe ja später keine Ahnung wann ich das genau gebaut habe, und welchem
> Repo Stand das entspricht.

Die Build kann auch weggelassen werden, es war nur eine Möglichkeit, 
nicht das was auf alle Fälle zutrifft.

Wenn das Datum wichtig ist, kannst auch dies einbauen:

dbg(" FW-Rev.: %d.%d-%d [%s %s]\n", VERSION_MAJOR, VERSION_MINOR, VERSION_BUILD, __DATE__, __TIME__);

Aber vllt. mag nicht jeder GIT verwenden? ...

[Mate Rigo (Gast)]

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.