Hallo zusammen, ich habe auf meinem Board (Steuergerät für Forschung) einen STM32 verbaut, der allerhand Dinge wie USB, Ethernet, Peripherie per SPI und I2C, DAC usw. steuert. Die Schaltung hat sich mit der Zeit etwas weiterentwickelt im Bezug auf u.a. Pinbelegung, Schnittstellen usw. und wahrscheinlich wird sie das auch noch in der Zukunft. Leider kommt es nicht in Frage alle alten Boards gegen neue zu tauschen, dennoch würde ich die alten Boards aber gerne weiterhin mit Firmwareupdates bugfixen können. Wie geht ihr mit sowas um? Ich hatte mehrere Szenarien im Kopf, beispielsweise Abstraktionseben einzubauen, um die grundlegenden Schnittstellen wie USB, Ethernet, SPI so weit zu entkoppeln, dass ich je nach Hardware-Revisionsnummer dann die Schnittstellen inkl. Pinbelegung zur Laufzeit instanziieren und der Programmlogik übergeben kann. Das beißt sich dann zwar etwas mit den generierten CubeMX-Templates, aber einen Tod wird man vermutlich sterben müssen. Falls da jemand gute Literatur zu kennt oder einen Vorschlag hat, wäre ich sehr dankbar! Schöne Grüße, grtu
A. G. schrieb: > einen Vorschlag hat Bei der Firmwareentwicklung ist weniger oft mehr. Daher würde ich es einfach halten und nur mit #ifdef #endif arbeiten für die unterschiedlichen Codeblöcke und die entsprechende Boardrevision die damit abgefragt wird, dem Compiler mittels -D Option mitgeben. In der Entwicklungsumgebung kannst Du dann einfach verschiedene "Build Configurations" anlegen.
Ich hab da bis zu 8 Portpins mit 0Ω Widerständen nach GND vorgesehen, damit kann man bis zu 256 HW-Versionen codieren. Ohne Widerstand ziehen die internen Pullups auf High. Die SW fragt diese nach dem Reset ab und initialisiert sich entsprechend (swith/case).
Moin, Fuer eine (oder mehrere) Geraeteklasse(n) mit unterschiedlichen Eigenschaften laesst sich das Ganze im Unterhalt recht kompakt halten, wenn man Kernel (Programmcode) und Eigenschaften (HW-Elemente, Variablen) komplett trennt. Kann man dynamisch im System mit Konfig-Dateien erledigen, oder aus den Config-Dateien den entsprechenden Sourcecode generieren. Dabei braucht man ansich nur eine Zuordnung 'Eigenschaft' -> 'Register' etc. #ifdef-Konstrukte sind bei kleinen Projekten auch ok, sobald man aber mehrere Geraeteklassen mit einer Firmware abhaken muss, nimmt der Wartungsaufwand quadratisch zu. Deswegen tendiere ich grundsaetzlich zu einer homogenen Firmware, die jeweils eine Geraetefamilie abdeckt. Gibt es eine neue Revision mit weiteren/anderen Features, wird in der Geraetebeschreibung einfach die bisherige Klasse abgeleitet. Spaetestens wenn man die Geraete vernetzt und ein Front-End Daten abfragt oder Sachen steuert (testen muss man es ja auch noch) amortisiert sich das. Das Front-End sieht dann nur noch die abstrakten Eigenschaften, wie 'Motor.Enable'. Auf Firmware-Seite aendert man jeweils nur noch *genau ein* Beschreibungsfile per neue Revision und baut die Firmware neu. Nachteil ist halt durch Laufzeit-Rahmenwerk bedingter erhoehter Speicherplatzbedarf. Drum lagern wir die aus der Beschreibungsdatei erzeugten Feature-Tabellen ins SPI-Flash aus.
Peter D. schrieb: > Ich hab da bis zu 8 Portpins mit 0Ω Widerständen nach GND vorgesehen, > damit kann man bis zu 256 HW-Versionen codieren. Ohne Widerstand ziehen > die internen Pullups auf High. > Die SW fragt diese nach dem Reset ab und initialisiert sich entsprechend > (swith/case). Hallo Peter, wir würden so etwas auch machen, aber es gibt eine Firma in DE die diese Funktion patentiert hat und einen Kunden von uns deshalb erfolgreich abmahnte.
A. G. schrieb: > Wie geht ihr mit sowas um? Ganz einfach. Ich würde ein Strich ziehen. Neue Geräte neue Firmware = Code kopieren und dort weiter verwenden OHNE die älteren Teile zu berücksichtigen. Den Rest halt mit einen Bit-Array machen das ich fülle in der Ini-Routine. So nach den Motto If i2c = true then Bit_da(5) = true else Bit_da(5) = false Dann brauch man nur 1 Variable (was Speicher spart). Wenn es sehr eng im Speicher ist, schreibe ich den wert des Bit_arry als Feste Variable und spare mir die Test-Routine.
Und der Kunde hat tatsächlich gekuscht vor den Anwälten? Kaum zu glauben...
Falls die Hardware einen Bootloader drauf hat, kann man dem eine feste Hardware revision geben, und er meldet die dann. Ohne Bootloader koennte man einen Memory chip mitgeben, zB einen Serienummer Chip, zB einen 24AA02E48, mit 2kb EEPROM, welchen die Konfiguration enthaelt.
Markus schrieb: > Ernsthaft? ISt sowas Grundlegendes patentierbar? Klar. Nur dürfte das schwer durchzusetzen sein, daher auch die Anmerkung Wühlhase schrieb: > Und der Kunde hat tatsächlich gekuscht vor den Anwälten? Kaum zu > glauben...
Ich sollte mir endlich meinen Spannungsteiler zum Teilen von Spannungen patantieren lassen...
Markus schrieb: > Schmiddy schrieb: >> Funktion patentiert hat > > Ernsthaft? ISt sowas Grundlegendes patentierbar? Patentieren kannst du erstmal alles, was der Sachbearbeiter nicht direkt als unpatentierbar erkennt. Allerdings haben die Sachbearbeiter nicht das Detailwissen, um detailiert die Patentierfähigkeit zu Prüfen. Du musst ja nicht einmal beweisen, dass der Patentgegenstand überhaupt funktioniert. Wenn du ein solches Patent dann aber durchsetzen willst, kann dein Gegenüber eine Nichtigkeitsklage anstrengen, um dein Patent rückwirkend (-> von Anfang an) für ungültig zu erklären. Die Kosten für die Klage trägst dann du.
Markus schrieb: > Ernsthaft? ISt sowas Grundlegendes patentierbar? Naja, MS hat ein Patent auf den Doppel-klick und die Telekom auf eine Farbe. Ich denke mit genug Macht, patentierst du doch alles. ;)
Schmiddy schrieb: > Hallo Peter, > > wir würden so etwas auch machen, aber es gibt eine Firma in DE die diese > Funktion patentiert hat und einen Kunden von uns deshalb erfolgreich > abmahnte. 1) Halte ich fuer ein Maerchen 2) Falls es wirklich derart dreiste Patent-Trolle in Deutschland geben sollte: Gerne Firmennamen oder Patentnummer nennen 3) Patent duerfte ansonsten unwirksam sein, die 'prior art' diesbezueglich ist hier ueber 25 Jahre alt..
A. G. schrieb: > Ich hatte mehrere Szenarien im Kopf, beispielsweise Abstraktionseben > einzubauen, ... > ... Das beißt sich dann zwar etwas mit den > generierten CubeMX-Templates, Tja, was soll man dazu sagen, außer "wer die Fundamente falsch gelegt hat, den bestraft das Leben". Du hättest von Anfang an um sowas wie Cube&Co einen weiten Bogen machen sollen und dir einerseits deine Algorithmen so schreiben sollen, daß sie hardwareunabhängig sind und andererseits deine Lowlevel-Treiber mit solchen Interfaces versehen sollen, daß dieses ebenfalls hardwareunabhängig sind. Und wo es gar nicht anders geht, dann eben Zwischenschichten. Ich predige das hier den Leuten schon seit ewig, bis daß es denen zum Halse heraushängt - aber ganz offensichtlich nützt es nichts. Die Leute wollen mit dem Kopf durch die Wand und lassen sich auch nicht von den Beulen abhalten, die sie dabei am Kopf kriegen. Allenfalls wird über die Beulen geklagt, aber kein einziger Gedanke daran verwendet, sich einen anderen und besseren Weg zu suchen. W.S.
Da habe ich schon vor 18 Jahren ein Gerät gebaut, das aus drei Modulen besteht, die viel Gemeinsam haben, aber auch viele Unterschiede. Die Bestückung wird einfach mit einem Widerstandspaar am ADC unterschieden ud die Module unterhalten sich per Bus. Es gibt immer nur ein A, ein B und ein C, damit sind Lötfehler usw. erkennbar. Fehlt ein Teilnehmer oder gibt es einen doppelt, kann jeder Teil mit seinen Möglichkeiten Alarm schlagen. Die Firmware ist identisch und hat für die komplette Hardware "Treiber" dabei, nur das eben das HMI-Gerät den Text darstellt, die anderen beiden Geräte dagegen in der (ich nenn sie jetzt mal Print-)Funktion via während des Boots gelesenen ADC diesen Text dann eben zum HMI bussen. Es gab mehrere Revisionen, die durch andere ADC-Kombinationen erkannt wurden, die Firmware konnte dann eben A,B,C,D oder E sein, und dementsprechend wurden die Funktionen umgeschaltet. Ist ein Beutel voller Ifs, aber dafür für insgesamt 8 verschiedene Platinen nur eine Software (in ebenfalls mehrerern Versionen) über Jahre hinweg. Die alte Software konnte halt kein >=D und hat Fehler geworfen, neue Software hat Fehler der alten Revisionen beachtet. Ist quasi das gleiche wie mit Lizenzschlüsseln zur Freischaltung, auch da gibt's ein If das den Schlüssel abfragt und die Funktion entweder auf Fehler oder Normal schaltet. Muss ich jetzt Angst haben, das mir Patentanwälte auf den Leib rücken???
Schmiddy schrieb: > wir würden so etwas auch machen, aber es gibt eine Firma in DE die diese > Funktion patentiert hat und einen Kunden von uns deshalb erfolgreich > abmahnte. Anstatt der 0 Ohm einfach 1 Ohm Widerstände verwenden ;-) Bei meinen Gerätschaften habe ich auf vorhandene Hardware abgefragt. Da reicht es schon aus, ob irgendwo ein pullup/pulldown-Widerstand erkannt wird, um eine betreffende Funktion zu aktivieren. Irgendwo wird doch auch ein EEPROM verbaut sein, daß Aufschluß über die Version geben kann.
Wühlhase schrieb: > Und der Kunde hat tatsächlich gekuscht vor den Anwälten? Kaum zu > glauben... Wenn ich ein Produkt kaufe, will ich ein Problem lösen, und keinen Nebenkriegsschauplatz eröffnen. Es gibt Seriennummern-Bausteine per OneWire. Wie alle EEPROM/etc.-Lösungen haben sie den Nachteil, dass man irgendwo ein Verzeichnis über die Seriennummern führen muss. Falls es einen I2C-Baustein mit wenig Datentransfer auf der Baugruppe gibt, könnte man ihn an einen anderen µC-Pin hängen. Oder am gleichen Bus eine andere Adresse geben. (Ist irgendwie auch eine "Widerstands"-Kodierung, aber wahrscheinlich vom og. Patent nicht abgedeckt, da schon bei den allerersten I2C-Bausteinen vorhanden).
:
Bearbeitet durch User
A. G. schrieb: > oder einen Vorschlag hat, wäre Statt Abstraktionsebenen schlage ich eine Unit mit den I/O Funktionen vor. Die wird dann entsprechend eingebunden. Damit sind die Funktionen auch gekapselt, separat zu testen und können überall per ifdef Hardwareversion eingebunden werden. Mittels einer .h sind die Funktionensnamen gleich und der Compiler meckerst andernfalls. Die Funktionen müssen natürlich nach aussen das gleiche Verhalten haben.
W.S. schrieb: > Ich predige das hier den Leuten schon seit ewig, Das ist so hilfreich wie ein Kropf. Diese Probleme kann man auch erst lösen wenn man fit in der Sprache ist.
Cntaurus schrieb: > und können überall per ifdef > Hardwareversion eingebunden werden. Den Weg über bedingtes Kompilieren/Linken würde ich nicht gehen. In der Praxis sind eine einzige Programmversion und gerätespezifische Funktionen, die zur Laufzeit (beim Programmstart) aktiviert werden, einfacher zu handhaben. Danach wurde ja auch gefragt.
Schmiddy schrieb: > wir würden so etwas auch machen, aber es gibt eine Firma in DE die diese > Funktion patentiert hat und einen Kunden von uns deshalb erfolgreich > abmahnte. Und was ist daran patentwürdig? Das ist Stand der Technik und wird schon bei USB so gemacht, allerding nicht binär. Vielleicht könnt ihr an Stelle von 0Ω einen 100Ω Widerstand nehmen oder eine Analogsignalauswertung nutzen. All das setzt natürlich voraus, das so eine Möglichkeit zur HW-Versionserkennung von vornherein ins System halbwegs eindesigned ist. Die Alternative ist irgendeine Kennung in einem EEPROM, dass vor FW-Update geschützt ist.
m.n. schrieb: > Den Weg über bedingtes Kompilieren/Linken würde ich nicht gehen. In der > Praxis sind eine einzige Programmversion und gerätespezifische > Funktionen, die zur Laufzeit (beim Programmstart) aktiviert werden, > einfacher zu handhaben. Im Ergebnis schleppst du dann Code für alle möglichen Versionen mit dir rum. Muss auch kein ifdef sein. Unit austauschen, vorkompilieren ein Menüsystem zum Proggen geht auch. Oder man piepst das Board über nen Barcode ein und .... .Kommt auf die Anwendung an.
Wolfgang schrieb: > Die Alternative ist irgendeine Kennung in > einem EEPROM, dass vor FW-Update geschützt ist. Der Nachteil ist jedoch, daß es ein zusätzlicher Fertigungsschritt ist, der fehlerhaft sein kann. Auch ist die Bestückungsvariante nicht sofort erkennbar, man braucht also noch einen Aufkleber.
> Leider kommt es > nicht in Frage alle alten Boards gegen neue zu tauschen Daher nehme ich an dass er keine neue Hardware in die alten Boards einbauen will (EEPROM, 0Ω usw.) sondern nur eine Lösung für seinen Sourcecode-Tree sucht. Abstrahieren ist immer gut. So dass die #ifdef und #define an einigen wenigen Stellen gebündelt sind. Quasi einen "Hardware Abstraction Layer" einziehen, wie es viele Betriebssysteme machen.
Ist den eigentlich schon raus ob eine FW für alle varianten oder je eine eigne FW je variante? 1. HW erkennung ist hierfür sicher sinvoll. aber wenn die alten platinen das nicht haben ist das zu spät. Entweder digital wie oben beschrieben oder analog wie auch bereits erwähnt. Sowas sollte aber jde Paltine haben, ... 2. Wenn keine HW erkennung vorhanden dann zumindest im Bootloader (wenn vorhanden) eine Kennung die dieser beim update testet. Den bootloader kann man ja auch noch bei den bestehenden platinen nachträglich austauschen. Saubere trennung zwischen HW und Software. Hardware abstraction Layer (HWAL) Nicht den LED pin direkt steuern z.B. mit setGPIO(PORT2, PIN_15) sonder das ganze in eine funktion/macro auslagern. Je nach FW variante kann dann über #ifdef umgeschalten werden oder über if(variant == HW_1), ...
Walter T. schrieb: > Wühlhase schrieb: >> Und der Kunde hat tatsächlich gekuscht vor den Anwälten? Kaum zu >> glauben... > > Wenn ich ein Produkt kaufe, will ich ein Problem lösen, und keinen > Nebenkriegsschauplatz eröffnen. Das eine zu wollen schließt das andere ja nicht aus. Und eine solche Trollerei liegt dir, falls die Geschichte überhaupt wahr ist, noch für viele Jahre im Weg. I²C-EEPROMs sind nette Bausteine, aber oft doch mit Kanonen auf Spatzen geschossen. Und mich würde allein schon die Gegenreaktion genug interessieren um einer solchen Firma kurzerhand mitzuteilen, daß ich deren Patent anzufechten gedenke. Im Übrigen halte ich es allgemein für ein großes Problem in unserer Gesellschaft, daß jeder sein Maul hält und sich aus Angst vor Konflikten wegduckt. Es würde weitaus weniger unverschämt dreiste Menschen und auch weniger solcher Firmen geben, wenn die Richtigen an den richtigen Stellen öfter mal ein klein wenig streitfreudiger wären.
MosFeratu schrieb: > Im Ergebnis schleppst du dann Code für alle möglichen Versionen mit dir > rum. Es sind nicht alle möglichen, sondern nur die notwendigen Versionen. Und die dann auch nicht in meiner Hosentasche, sondern kommentiert im Code. Es müssen doch nur die Änderungen bei der Hardware berücksichtigt werden. Wenn beispielsweise andere ADCs eingesetzt werden, werden zwei oder mehr Funktionen zum Abfragen bereitgehalten und die jeweils passende aufgerufen. Dadurch wird das Programm nicht unüberschaubar aufgepustet. Bei unterschiedlichen Programmversionen läuft man Gefahr, daß (nach längerer Zeit) die unpassende aufgespielt wird und dies unter Umständen nicht sofort bemerkt wird.
m.n. schrieb: > Bei unterschiedlichen Programmversionen läuft man Gefahr, daß (nach > längerer Zeit) die unpassende aufgespielt wird und dies unter Umständen > nicht sofort bemerkt wird. Und vor allem muß man auch im VCS jede Version als eigenes Projekt verwalten. Werden Bugs gefunden, muß man in allen Projekten neue Bin-Files einchecken. Ich habe oft noch massig Flash frei, da ist das Mitschleppen von allen Codevarianten kein Problem.
Wühlhase schrieb: > I²C-EEPROMs sind nette Bausteine, aber oft doch mit Kanonen auf Spatzen > geschossen. Extra ein EEPROM für diese Anwendung vorsehen würde ich auch nicht. Aber wenn es schon da ist, könnte ich es in einer neueren Hardware-Version auf Adresse 0xA2 anstelle 0xA0 setzen. Mit den drei Bit kann man auch problemlos acht Hardware-Varianten durchkodieren. (Mit dem Nachteil, dass der Start dann bis zu 0,8 Sekunden länger dauern kann. Ob das im konkreten Fall hinnehmbar ist, ist eine andere Frage). Das geht natürlich mit fast jedem I2C-Baustein, von dem es nur einen gibt.
:
Bearbeitet durch User
m.n. schrieb: > Bei unterschiedlichen Programmversionen läuft man Gefahr, daß (nach > längerer Zeit) die unpassende aufgespielt wird und dies unter Umständen > nicht sofort bemerkt wird. Dafür gibt es z.B. HW versionen / Magic numbers die die FW oder der Booter abgleicht. Es ist auch die frage wie die FW eingespielt wird. über JTAB / SWD oder über z.B. RS232 und einen Bootloader. Manche MCUs haben ja auch ein paar beit OTP speicher den man ggf für so was misbrauchen könnte, ...
Peter D. schrieb: > m.n. schrieb: >> Bei unterschiedlichen Programmversionen läuft man Gefahr, daß (nach >> längerer Zeit) die unpassende aufgespielt wird und dies unter Umständen >> nicht sofort bemerkt wird. > > Und vor allem muß man auch im VCS jede Version als eigenes Projekt > verwalten. Werden Bugs gefunden, muß man in allen Projekten neue > Bin-Files einchecken. > Ich habe oft noch massig Flash frei, da ist das Mitschleppen von allen > Codevarianten kein Problem. Bei git z.B. ist das nicht notwendig. Da kannst du einfach für nebenläufige Programmversionen einen neuen Zweig aufmachen.
m.n. schrieb: > In der > Praxis sind eine einzige Programmversion und gerätespezifische > Funktionen, die zur Laufzeit (beim Programmstart) aktiviert werden, > einfacher zu handhaben. Danach wurde ja auch gefragt. Nein, genau DANACH wurde überhaupt nicht gefragt. Sondern nach dem Update und Bugfix bei älteren Baugruppen, die eben noch nicht die letzte Schaltungsrevision innehaben. Im Klartext: Wenn da früher ein Motor eingeschaltet werden sollte, ging das über Port X und Pin Y auf high und neuerdings geht es über einen anderen Port und nicht high sondern low. Das ist ne Frage ds Lowlevel-Treibers und nicht eine Angelegenheit der Algorithmen, die offenbar noch immer buggy sind. W.S.
A. G. schrieb: > kann. Das beißt sich dann zwar etwas mit den > generierten CubeMX-Templates, aber einen Tod wird man vermutlich sterben > müssen. CubeMX finde ich gut für die Planung, Taktkonfiguration, Doku und teilweise Codegenerierung für einige Komponenten. Für eine komplette Applikation mag ich das genau wegen dem 'Sterben' nicht. Der Umzug auf eine andere MCU ist mit viel fehlerhafter Handarbeit verbunden, in den Dateien ist generierter/User code gemischt und muss wieder neu zusammengeführt werden. Eine Abstraktion ist evtl. mögich wenn man das auf mehrere Projekte aufteilt, eines mit main() und den nötigen Systeminitialisierungen und dann eines oder mehrere mit Komponenten die dann Libraries (Archives) erstellen. In CubeMX kann man Funktionen abwählen um diese nicht in das Projekt zu übernehmen. Hört sich kompliziert an, ist es wahrscheinlich auch und deshalb mache ich es nicht so. Ich arbeite lieber mit einem (RT)OS das mir eine ordentliche Abstraktion liefert. Das Program fängt mit main() an und SystemInit und co. liefern OS + Buildsystem als Basis. Standardschnittstellen wie SPI, I2C, IO, USB und Ethernet bringt das OS ebenfalls mit und ein Umstieg von F4 zu F7 sind z.B. nur andere defines für Pinnames von SCL, SDA, oder sonstigen IO Pins. Durch ein cleveres Buildsystem braucht man auch keine ifdef Orgien, Konfigurationen oder Targetspezifischer Code können in eigenen Verzeichnissen gehalten werden. Libraries können damit mit Varianten in einem Codezweig und sauber mit git verwaltet werden. Das Ganze dazu noch in C++ weil das (Pseudo)dynamische Erzeugen der nötigen Instanzen schon von der Sprache unterstützt wird und den Aufbau universeller Libraries vereinfacht.
Walter T. schrieb: > Extra ein EEPROM für diese Anwendung vorsehen würde ich auch nicht. Wäre auch nicht unbedingt notwendig, da jeder STM32xyz seine eigene "Unique device ID" hat - OTP-Flash noch oben drauf. W.S. schrieb: >> Funktionen, die zur Laufzeit (beim Programmstart) aktiviert werden, >> einfacher zu handhaben. Danach wurde ja auch gefragt. > > Nein, genau DANACH wurde überhaupt nicht gefragt. Lies mal genau nach: Es wurde nach einer Versionserkennung zur Laufzeit gefragt. Ob es nur um lowlevel-Treiber geht oder auch zusätzlich Funktionen zur neuen Hardware dazugekommen sind (z.B. TFT anstatt zuvor LCD), das muß der TO wissen. Johannes S. schrieb: > Ich arbeite lieber mit einem (RT)OS das mir eine ordentliche Abstraktion > liefert. Ich denke, daß ist fernab von dem, was der TO macht bzw. braucht. Andernfalls würde er nicht fragen.
m.n. schrieb: > Ich denke, daß ist fernab von dem, was der TO macht bzw. braucht. > Andernfalls würde er nicht fragen. sehe ich anders: A. G. schrieb: > Ich hatte mehrere Szenarien im Kopf, beispielsweise Abstraktionseben > einzubauen, um die grundlegenden Schnittstellen wie USB, Ethernet, SPI > so weit zu entkoppeln, dass ich je nach Hardware-Revisionsnummer dann > die Schnittstellen inkl. Pinbelegung zur Laufzeit instanziieren und der > Programmlogik übergeben kann. Und genau das macht ein OS: es gibt ein API und die Hardware darunter ist austauschbar. Das ist schon richtig weitergedacht, wenn sich die Hardware derart ändert das IO auf anderen Pins liegt, dann liefert CubeMX entweder die Konfiguration für Variante A oder B. Wenn ich einen DigitalOut abhängig von einer Hardwarekennung von PA0 auf PB1 ändere, dann sind mehrere Zeilen Änderung mit HAL Konfiguration für GPIO und Clock nötig, beim C++ Objekt ändere ich 'DigitalOut led1(PA_0);' nach 'DigitalOut led1(PB_1);'. Und wenn es auf einem NXP laufen soll dann eben 'DigitalOut led1(P1_0);' Noch spassiger wird es natürlich bei komplexeren Komponenten die Interrupts verwenden oder USB oder Ethernet. Eine HW Rev per Codierjumper oder CPUID abzufragen ist doch wohl keine Herausforderung.
Johannes S. schrieb: > Eine HW Rev per Codierjumper oder CPUID abzufragen ist doch wohl keine > Herausforderung. Jede ID hat die nervige Eigenschaft, dass man eine Datenbank über alle Exemplare führen muss. Und mit Datenbank meine ich natürlich eine Excel-Tabelle :-).
Mein name ist Hase schrieb: > 1. HW erkennung ist hierfür sicher sinvoll. aber wenn die > alten platinen das nicht haben ist das zu spät. Es reicht, wenn man die zuverlässige Revisionserkennung nur in die neuen Platinen eindesignt. Wird die Revision dann nicht erkannt, ist es wohl noch die alte Platine, die bisher ja mit einer Firmwarevariante auskam. Eine "Unique Device ID" im SoC ist da eher ungeeignet, weil man die irgendwie auf die Bestückungsvariante mappen muss. Das heißt, dass man entweder sämtliche vergebenen IDs in die Firmware integrieren muss oder dass der Updateprozess in beide Richtungen kommunizieren muss. Wühlhase schrieb: > Bei git z.B. ist das nicht notwendig. Da kannst du einfach für > nebenläufige Programmversionen einen neuen Zweig aufmachen. Das führt dann irgendwann dazu, dass der Code für Variante A einen allgemeinen Bugfix enthält, den man in Variante B dann vergessen hat... Wenn man getrennte Quelltextbäume pflegen will, ist es egal, ob die in verschiedenen Repositories oder verschiedenen Branches liegen. Besser, man klebt das alles in einen Quelltextbaum und lässt entweder zur Laufzeit erkennen oder baut verschiedene Images per #ifdef. Die Laufzeiterkennung will man übrigens trotzdem haben, um ein unpassendes Image erkennen zu können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.