- LiTime Speicher und Akkus         
Ergebnis 1 bis 8 von 8

Thema: Frage: Software Code ohne Version/Revision dokumentieren

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076

    Frage: Software Code ohne Version/Revision dokumentieren

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Mir ist eben bei der Dokumentation meiner Microchip PIC Software aufgefallen,
    dass es etliche von Source Code Dateien von Microchip gibt, die keine Version / Revisionsnr haben, nichts...

    Beispiel: Die Datei

    pic.h oder auch die xc.h

    Da sie unterschiedliche Dateigrößen in unterschiedlichen Versionen haben, werden sie sich vermutlich auch unterscheiden
    ich hab den Code aber nicht komplett verglichen.

    Es befindet sich in den Dateien leider kein Hinweis auf eine Version Revision oder Zugehörigkeit, leider garnichts.

    Da ich ALLE benötigten Dateinen meines Projekt mit einer Versionsnummer/Revisionsnr grade aufliste,
    fällt das jetzt etwas schwer mit der Dokumentation.

    Idee: Ich werde nun die benötigten Dateien in meinen Projektordner kopieren müssen
    und mit einem Editor eine Version/Revisionsnr vergeben müssen.

    Wie macht man das denn am Besten ?
    Ich wollte jetzt eigentlich nicht in der ohnehin schon als "SOUP" deklarierten Software auch noch Änderungen vornehmen müssen.

    Oder ich schreibe die Dateien komplett neu, bzw. specke sie ab für mein Projekt. Dann ist es auch keine SOUP mehr.

    Bei den eigentlichen Include Files der PICs z.B. Pic12F1840.inc
    hat man es aber gemacht:
    // Version 2.05
    // Generated 20/12/2018 GMT
    warum nicht bei den anderen Dateien ?

    Ohne jeglichen Texthinweis in einer Datei find ich schon etwas "armselig" Bild hier  

    Siro
    Geändert von Siro (06.03.2019 um 14:51 Uhr)

  2. #2
    shedepe
    Gast
    Anstatt von Hand Versionsnummer zu vergeben verwendet man heutzutage Versionsverwaltungssystem wie GIT oder SVN (Das nur mal als Hinweis zu deiner Idee von Hand Versionsnummern in deine Files zu schreiben - das würde ich echt nicht machen).

    Zu deinem eigentlichen Problem: Das ist kein direktes Versionierungsproblem im Sinne einer klassischen Versionsverwaltung sondern eher eine Versionsverwaltung hinsichtlich der benötigten Umgebung.
    Auch die PIC Toolchain wird eine bestimmte Versionsnummer haben. Unter den meisten Linux Distros wäre es z.B. sinnvoll die Version des installierten Pakets anzugeben, unter Windows eben die runtergeladene und installierte Version.
    Bsp: Unter Python kann man ein requirements file für die Setuptools mit angeben, bei dem man die benötigte Version von Abhängigkeiten angeben kann.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Ersteinmal Danke für dein Info shedepe.

    Da hast Du natürlich recht,
    die besagten Dateien stammen aus einer "bestimmten" Version der Entwicklungstools.
    In meinem Falle ist dies der Compiler XC8 in der Version 2.00 oder folgende.
    Diese Dateien sind bei mir in den Ordnern:

    C:\Programm\Microchip\XC8\V2.00
    C:\Programm\Microchip\XC8\V2.05

    dann in den Unterordnern:
    ...\PIC\include

    Diese Zugehörigkeit lässt sich jedoch im Nachhinein, lediglich aus der Datei, nicht mehr erkennen,
    das finde "ich" halt etwas schade, oder problematisch.
    Hier würde ich mir schon wenigstens eine Zeile mit Info wünschen.
    // XC8 Version 2.0 das reicht doch schon...

    Die gesamte Archivierung von Projekten ist leider bei mir eine riesen Baustelle, wenn man das so nennen darf.
    SVN und/oder GIT sind für mich böhmische Dörfer.
    Ich hab da zwar schon Einiges drüber gelesen, aber ehrlich gesagt. "in meinem Falle" viel zu aufwendig.
    Unsere Entwicklungsabteilung ist recht übersichtlich, denn das bin nur ich selbst.
    Code sowie die Verwaltung dafür liegt also nur in meinen Händen.
    Für größere Projekte an verteilten Orten usw, ist die Versionsverwaltung sicherlich unumgänglich,
    brauchen wir nicht drüber zu diskutieren. Ja, ein MUSS auf jeden Fall.


    Meine Versionsverwaltung sind lediglich die Software(Firmware) Versionen selbst.
    V1.00 V1.12 usw.
    entsprechend sieht auch meine Ordnerstruktur aus.
    In den Ordnern findet man dann "ALLE" Dateien um ein erneutes, theoretisch identisches, Compilat wieder zu erzeugen.
    Inzwischen weis ich aber, dass selbst das, kaum möglich ist aufgrund tonnenweiser Einstellungen
    in den Compilern / IDEs Registryverwaltungen usw.
    In meinen Augen ein fast aussichtsloses Unterfangen ohne Festplattenbackup.

    Deshalb mein Anliegen, wenigstesn eine Kommenartzeile in "jeder" Datei für die Zugehörgkeit wäre schön.

    Siro
    Geändert von Siro (07.03.2019 um 15:15 Uhr)

  4. #4
    shedepe
    Gast
    Wie gesagt: Würde ich davon abraten. Dazu hat man eine Versionsverwaltung die Tags kann. In jedem File einzeln Versionen reinzuschreiben dauert lange und ist fehleranfällig. Außerdem ist es aufwendig z.B. einzelne Files zurückzusetzen.
    Mein Tipp für deine eigene Software: Schau dir Git an: Kann man sogar ohne Server lokal verwenden und ist in den Basis funktionen jetzt wirklich nicht so schwierig zu verwenden:
    Hauptsächlicher Ablauf: git add git commit git push

    Mit git log und git blame kann man dann bis auf Zeilenebene Änderungen im Code nachvollziehen.
    Aufwendig ist das halt nicht, sondern benötigt nur mal einen Tag Einarbeitungszeit. Danach hat man ein viel mächtigeres Werkzeug bei der Hand. (Wobei ich durchaus nachvollziehen kann, dass man sich manchmal sträubt doch was neues anzuschauen, wenn das bisherige Verfahren ja funktioniert)

    Ansonsten bewegst du dich damit in den Bereich Continous Integration bzw. verifiable builds. Mein Tipp ist es außerdem darauf zu verzichten den Build durch eine IDE zu erzeugen sondern lieber durch ein Buildsystem wie Make oder CMake oder irgendwas anderes. Da kann man dann nämlich auf Versionen der Toolchains usw. prüfen und weiß defintiv mit welchen Einstellungen man kompiliert. Einen Schritt weiter könnte man gehen in dem man seine Entwicklungsumgebung in einem Container (z.B. Docker oder Systemd) aufsetzt und eben diesen Container versioniert. So wird das dann in großen Umgebungen gemacht: Leerer Container mit definierten Versionen von Tools, Code wird frisch aus dem Repo gecloned, Build wird gestartet, Build Ergebnisse eingesammelt.

    So jetzt hab ich dir ganz schön viel an den Kopf geworfen:
    Wenn du sagst: Das ist mir zu viel: Mein Vorschlag: Kopier die dir PIC library und schreib dir ein Skript was automatisch die Versionen von deinem Code in den Header der Files reinschreibt. Schön ist das zwar nicht und über Probleme dieses Vorgehens bist du dir vermutlich selbst bewusst, aber wäre denke ich eine schnelle Lösung.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Mahlzeit und vielen Dank nochmal an shedepe für deine Informationen und Mühe.
    Mit dem Git muss ich mir wohl doch nochmal genauer anschauen.
    Ich arbeite ja generell nur Lokal auf einem Rechner, das scheint mit Git auch möglich zu sein.

    Ich müste mal versuchen ein Compilat ohne die IDE zu erzeugen, mittesl Makefiles
    Linkerscript, das sollte ja auch irgendwie möglich sein.
    Zumindest für die "Release" Version, dann brauche ich auch keine IDE archivieren, lediglich die Compiler.

    In unserer Verfahrensanweisung steht:

    SOUP Elemente einschließlich Standard-Bibliotheken müssen erfasst und entsprechende Informationen
    zum Titel, Hersteller und SOUP-Kennung aufgezeichnet werden.

    Die freigegebene Version der Software muss in der Liste der Konfigurationselemente aufgezeichnet werden.
    Das Verfahren und die Umgebung, die verwendet wurden, um die freigegebene Software zu erzeugen,
    muss dokumentiert werden.
    .....
    Der Papierkrieg überrolt mich grade und die Entwicklung steht, für eine Person wird das echt zu viel.
    Lehrgang IEC62304 hab ich auch hinter mir....

    Und dann noch ackern, wo andere den Frauentag genießen
    Ich wünsche euch allen ein schönes Wochenende.

    Siro
    Geändert von Siro (08.03.2019 um 15:48 Uhr)

  6. #6
    Erfahrener Benutzer Roboter Genie Avatar von White_Fox
    Registriert seit
    04.10.2011
    Beiträge
    1.473
    Zitat Zitat von Siro Beitrag anzeigen
    Und dann noch ackern, wo andere den Frauentag genießen
    Andere schämen sich da durchaus für.

    Dir auch ein schönes Wochenende.

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Siro Beitrag anzeigen
    ....
    pic.h oder auch die xc.h

    Da sie unterschiedliche Dateigrößen in unterschiedlichen Versionen haben, werden sie sich vermutlich auch unterscheiden
    ich hab den Code aber nicht komplett verglichen.

    Es befindet sich in den Dateien leider kein Hinweis auf eine Version Revision oder Zugehörigkeit, leider garnichts.

    Da ich ALLE benötigten Dateinen meines Projekt mit einer Versionsnummer/Revisionsnr grade aufliste,
    fällt das jetzt etwas schwer mit der Dokumentation.

    Idee: Ich werde nun die benötigten Dateien in meinen Projektordner kopieren müssen
    und mit einem Editor eine Version/Revisionsnr vergeben müssen.
    ....
    Das halte ich für keine gute Idee. xc.h z.B. wird in jedem File bei MPLABX angezogen. Dahinter verbirgt sich heftige Macro-Magie. Zusammen mit dem Prossortyp, der in den Projekteinstellungen festgehalten ist, werden die unterschiedlichsten weiteren Headerfiles angezogen. Ob das noch funktioniert, wenn diese Files nicht mehr an der alten Stelle im System liegen, bezweifle ich.

    Und ob diese neu vergebene Versionsnummer reicht, müsste man auch klären. Sie ist von dir vergeben worden, niemand kann sie überprüfen, das Original hat ja keine. Jetzt hast du die ganze Verantwortung für die Toolchain mit all ihren Files an der Backe, da du ja was dran geändert hast.

    Ich würde das anders angehen. In einer virtuellen Maschine (z.B. VMware oder Qemu) würde ich mir ein Minimalsystem einrichten, nur Betriebssystem, IDE, Compiler und andere benutzte Tools. In diesem wird gearbeitet. Und wenn man einen Stand abspeichern will, sichert man das Image. Das sollte selbst dann noch laufen, wenn eine neue Version des Host-Betriebssystems gängig ist. Heutzutage würde man dafür wohl Docker statt einer virtuellen Maschine verwenden. Ich muß aber zugeben, daß ich damit keine Erfahrung habe.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  8. #8
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    72
    Beiträge
    11.077
    Hallo!
    Zitat Zitat von Klebwax Beitrag anzeigen
    Das halte ich für keine gute Idee. xc.h z.B. wird in jedem File bei MPLABX angezogen. Dahinter verbirgt sich heftige Macro-Magie. Zusammen mit dem Prossortyp, der in den Projekteinstellungen festgehalten ist, werden die unterschiedlichsten weiteren Headerfiles angezogen. Ob das noch funktioniert, wenn diese Files nicht mehr an der alten Stelle im System liegen, bezweifle ich.
    Ich kann das nur bestätigen. Wozu braucht man sinnlose Versionsnummern ? Ich habe das bisher nie gebraucht.
    MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!

Ähnliche Themen

  1. Software Version 9: Tesla lässt Atari-Games ins Auto und wichtigste Funktion weg
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 0
    Letzter Beitrag: 08.10.2018, 09:20
  2. Frage zum MINGW gcc Version 4.5.0
    Von Hero_123 im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 07.06.2012, 19:13
  3. Suche CNC Software DXF -> G-Code
    Von BastelWastel im Forum Konstruktion/CAD/3D-Druck/Sketchup und Platinenlayout Eagle & Fritzing u.a.
    Antworten: 5
    Letzter Beitrag: 11.08.2011, 22:30
  4. Antworten: 13
    Letzter Beitrag: 05.11.2007, 00:29
  5. externen RC5 decodiert Code ... von Bascom AVR Version
    Von spatz2222 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 2
    Letzter Beitrag: 03.11.2005, 17:53

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test