Hallo Leute,
Ich habe allerlei Software die ich für Kunden geschrieben habe und habe
nun nach einem OS Update das Problem das nach dem Update von
avr-gcc2.5.1 zu avr-gcc 4.8.3 plötzlich das Zeuch nicht mehr
funktioniert..
Beispiel:
Warum ist das so und wie werde ich das wieder los?
Der Kunde hantiert mit einem externen Editor (Exel Sheet) in dem Binary
des .eep files herum um dort Parameter anzupassen.
Wenn das so bleibt muß ich nicht nur die Software selbst ändern sondern
auch diese Tools abhängig von der gerade benutzen Compiler Version..was
soll das also? Habe ich was Wesentliches verpasst? Wird das irgendwo
beschrieben?
Gruß,
Holm
Holm T. schrieb:> Warum ist das so
Weil der C-Standard für globale Variablen keine bestimme Reihenfolge
garantiert.
> und wie werde ich das wieder los?
Alles in ein struct packen:
Dein eigentliches Problem besteht darin, dass das ursprüngliche
SW-Konzept mit der nachträglichen Parameteranpassung im *.eep File
schlecht ist.
Sauberer und sicherer wäre es gewesen, die Parameter via serieller
Kommunikation über den µC in das Eeprom zu übertragen, damit gelangen
die Parameter immer an die richtige Stelle unabhängig welche
Compilerversion benutzt wird.
Deine beschriebene Vorgehensweise kenne ich auch aus Produkten der
Vergangenheit, die einfach nicht abgekündigt werden. Letztlich stehst du
nun vor dem Problem: neues Konzept inkl. den Kunden davon zu überzeugen
(= Zeit + Geld) oder ein Workaround zu schaffen, welches in einiger Zeit
wieder zu einem Problem führt!
Hier solltest du im Vorfeld alle Für und Wieder prüfen und gut guten
Argumenten zusammen mit dem Kunden die für euch beste Lösung finden.
Frage:
War das Compilerupdate notwendig? Andernfalls arbeite doch mit dem alten
Compiler weiter, das würde das Problem zumindest verschieben!
visitor schrieb:> War das Compilerupdate notwendig? Andernfalls arbeite doch mit dem alten> Compiler weiter, das würde das Problem zumindest verschieben!
Und zwar genau so lange, bis du irgendeine neue Variable ins EEPROM
ablegst.
visitor schrieb:> Sauberer und sicherer wäre es gewesen, die Parameter via serieller> Kommunikation über den µC in das Eeprom zu übertragen, damit gelangen> die Parameter immer an die richtige Stelle unabhängig welche> Compilerversion benutzt wird.
Die Theorie ist fein.
Lustig wirds, wenn du ein Firmwareupdate des Controllers machst...
Clemens L. (c_l) schrubtete:
>Weil der C-Standard für globale Variablen keine bestimme Reihenfolge>garantiert.
..das der C-Standard das nicht garantiert bedeutet aber noch lange nicht
das eine Compiler-Sub-Release für eine Architektur das so mirnichts
dirnichts ändern sollte.. oder spinne ich?
Ich werde versuchen das in Structs zu verhäkeln.
visitor schrieb:> Dein eigentliches Problem besteht darin, dass das ursprüngliche> SW-Konzept mit der nachträglichen Parameteranpassung im *.eep File> schlecht ist.> Sauberer und sicherer wäre es gewesen, die Parameter via serieller> Kommunikation über den µC in das Eeprom zu übertragen, damit gelangen> die Parameter immer an die richtige Stelle unabhängig welche> Compilerversion benutzt wird.
Unsinn.
Es ist nicht der Endkunde der darin herumeändert, es ist der Produzent
von Geräten der den u.a. Schrittmotorantrieb seiner Geräte uf das
spezifische Modell paramerisiert und 1 Mal pro Gerät den Flash und den
EEPROM vor der Auslieferung programmiert.
Dazu hat er ein fertiges Hex File und konfiguriert den EEPROM Inhalt
vor dem bruzeln mit Seriennummer und den Motorparametern wie zu fahrende
Wege u.A.
Das macht der glaube ich seit Zeiten zu denen gcc-2.x noch aktuell war.
Nur weil es den Compilergurus plötzlich vom Arsch in den Kopf steigt das
innerhalb einer Mainrelease (4) des Compilers plötzlich anders herum zu
anzuordnen erfinde ich doch keinen Lader der Platz im Flash braucht um
das
andersherum da einzufädeln..
>> Deine beschriebene Vorgehensweise kenne ich auch aus Produkten der> Vergangenheit, die einfach nicht abgekündigt werden. Letztlich stehst du> nun vor dem Problem: neues Konzept inkl. den Kunden davon zu überzeugen> (= Zeit + Geld) oder ein Workaround zu schaffen, welches in einiger Zeit> wieder zu einem Problem führt!
Genau.
>> Hier solltest du im Vorfeld alle Für und Wieder prüfen und gut guten> Argumenten zusammen mit dem Kunden die für euch beste Lösung finden.>> Frage:> War das Compilerupdate notwendig? Andernfalls arbeite doch mit dem alten> Compiler weiter, das würde das Problem zumindest verschieben!
Das Compilerupdate hat sich aus der Neuinstallation des Betriebssystems
meines Rechners ergeben (FreeBSD10) auf einem Laptop habe ich noch die
ältere Release.
Gruß,
Holm
Holm T. schrieb:> Das Compilerupdate hat sich aus der Neuinstallation des Betriebssystems> meines Rechners ergeben (FreeBSD10) auf einem Laptop habe ich noch die> ältere Release.
und was sagt dir das.
Zu einem Projekt sichert man alles was zur Erzeugung notwendig ist. Man
darf sich nicht einfach darauf verlassen, das man ohne Probleme eine
neue Version einsetzen kann. Dafür müsste man die komplette QS machen.
Wenn Fehler in einer alten Version noch behoben werden soll, dann sollte
man das auch mit den alten Compiler machen.
Holm T. schrieb:> ... bedeutet aber noch lange nicht> das eine Compiler-Sub-Release für eine Architektur das so mirnichts> dirnichts ändern sollte.. oder spinne ich?
Bei gcc gibt es solche Garantien nur für Änderungen der dritten Stelle
der Versionsnummer.
Peter II schrieb:> Holm T. schrieb:>> Das Compilerupdate hat sich aus der Neuinstallation des Betriebssystems>> meines Rechners ergeben (FreeBSD10) auf einem Laptop habe ich noch die>> ältere Release.>> und was sagt dir das.>> Zu einem Projekt sichert man alles was zur Erzeugung notwendig ist. Man> darf sich nicht einfach darauf verlassen, das man ohne Probleme eine> neue Version einsetzen kann. Dafür müsste man die komplette QS machen.>> Wenn Fehler in einer alten Version noch behoben werden soll, dann sollte> man das auch mit den alten Compiler machen.
Mach Dir keinen Kopf darüber, ich bin problemlos in der Lage eine ältere
Version zu bauen.
Gruß,
Holm
Clemens L. schrieb:> Holm T. schrieb:>> ... bedeutet aber noch lange nicht>> das eine Compiler-Sub-Release für eine Architektur das so mirnichts>> dirnichts ändern sollte.. oder spinne ich?>> Bei gcc gibt es solche Garantien nur für Änderungen der dritten Stelle> der Versionsnummer.
..Garantieen? Du beliebst zu scherzen...
Gruß,
Holm
Holm T. schrieb:> Clemens L. schrieb:>> Bei gcc gibt es solche Garantien ...>> ..Garantieen? Du beliebst zu scherzen...
Das ist natürlich eine 200%-Geld-zurück-Garantie. :)
Aber konkret: solch eine Imkompatibilität in 4.5.x würde als ein Bug
behandelt werden. (Und in > 4.5 eben nicht.)
Holm T. schrieb:> Clemens L. (c_l) schrubtete:>>Weil der C-Standard für globale Variablen keine bestimme Reihenfolge>>garantiert.>> ..das der C-Standard das nicht garantiert bedeutet aber noch lange nicht> das eine Compiler-Sub-Release für eine Architektur das so mirnichts> dirnichts ändern sollte.. oder spinne ich?
Es hat sich nichts geändert:
Es war in der alten Version nicht spezifiziert, und es ist in der neuen
Version immer noch nicht spezifiziert.
Falls du unbedingt die Anordnung wie in der Quelle willst, dann mit
-fno-toplevel-reorder.
Alternativ kannst du auch eine eigenes Linker-Description File bemühen
und die Objekte händisch darin aufzählen.
Dritte lösung ist, die Objekte in entsprechende Sections zu legen (z.B.
per -fdata-sections oder per section_attribute) und per
Linker-Description File die Input-Section so in der gewünschten
Output-Section anordnen, dass die Reihenfolge ist wie gewünscht.
Vierte Lösung wurde bestimmt schon genannt: Alles in eine Struktur.
Fünfte Lösung: Suboptimaler Hack ist die Adressen von Hand anzugeben.
Generell ist es überaus schlechter Stil (und m.E. unprofessionell), sich
auf Undefined Behaviour oder Unspecified Behaviour zu verlassen!
Johann L. schrieb:> Holm T. schrieb:>> Clemens L. (c_l) schrubtete:>>>Weil der C-Standard für globale Variablen keine bestimme Reihenfolge>>>garantiert.>>>> ..das der C-Standard das nicht garantiert bedeutet aber noch lange nicht>> das eine Compiler-Sub-Release für eine Architektur das so mirnichts>> dirnichts ändern sollte.. oder spinne ich?>> Es hat sich nichts geändert:>> Es war in der alten Version nicht spezifiziert, und es ist in der neuen> Version immer noch nicht spezifiziert.
Nunja.. es gab bisher damit keine Sorgen von Version 2.7 bis jetzt.
>> Falls du unbedingt die Anordnung wie in der Quelle willst, dann mit> -fno-toplevel-reorder.
Genau nach Sowas hatte ich gesucht, es aber nicht gefunden. Danke!
>> Alternativ kannst du auch eine eigenes Linker-Description File bemühen> und die Objekte händisch darin aufzählen.>> Dritte lösung ist, die Objekte in entsprechende Sections zu legen (z.B.> per -fdata-sections oder per section_attribute) und per> Linker-Description File die Input-Section so in der gewünschten> Output-Section anordnen, dass die Reihenfolge ist wie gewünscht.>> Vierte Lösung wurde bestimmt schon genannt: Alles in eine Struktur.>> Fünfte Lösung: Suboptimaler Hack ist die Adressen von Hand anzugeben.>>> Generell ist es überaus schlechter Stil (und m.E. unprofessionell), sich> auf Undefined Behaviour oder Unspecified Behaviour zu verlassen!
Ich werde das überarbeiten aber es ist gut das ich das nicht alles auf
ein Mal machen muß.
Diese Art das EEPROM File zu bearbeien stammt nicht mal von mir, aber
ich mußte die halt weiter verwenden.
Gruß,
Holm
