Konfiguration Eingebetteter Systeme, wie wirds heute gemacht?

[Jan K. (jan_k)]

Hallo zusammen,

Ich stehe gerade vor der Frage, wie ich mein nächstes Projekt 
konfiguriere. Mikrocontroller wird ein STM32 Cortex M3, aber eher ein 
kleinerer mit wenig Ram. Sprache ist momentan C. C++ bis 14 wäre 
theoretisch möglich, aber der Vorteil muss schon groß sein.

Es müssen verschiedene Sensoren über SPI ausgelesen werden, es gibt auch 
nen ADC für Analogwerte und CAN oder UART zur Kommunikation. Es wird 
verschiedene Hardware Revisionen geben mit unterschiedlich vielen 
Sensoren und Features, für die die FW, und zwar möglichst immer die 
gleiche, konfiguriert werden muss.

Zur Konfiguration stehen Dinge wie clock, Ports, Parameter der 
Berechnungsvorschriften, Anzahl und Adresse der angeschlossenen 
Sensoren, sample raten, Filterlevel etc PP.

Momentan stehen volatile Parameter mit Default in einem globalen Eeprom 
Modul, wo sich per define die einzelnen Module ihre settings holen. Das 
muss in die einzelnen Module gekapselt werden. Diese Parameter werden 
teilweise bei einem kalibrierschritt aktualisiert.

Dann gibt es auch noch build options, die z.B. bestimmte Berechnungs 
Module ein oder ausschalten, oder spezielle Kundenoptionen darstellen.

Dann gibt es momentan ein config Modul, das const structs zur 
Konfiguration der statischen Dinge wie clock und Ports definiert. Die 
config steht da also im Code (und damit in Git).

Ich möchte möglichst viel vereinheitlichen, um eine zentrale config zu 
haben, damit ich genau weiß, was welche fw kann, anstatt das an mehreren 
Stellen nachschauen zu müssen.

Wie wird das momentan in der Industrie gemacht?

Im Prinzip kommen da imo zwei gegensätzliche Konzepte in Frage:

1. Wird die FW möglichst dynamisch gehalten, und dann erst zur Laufzeit 
konfiguriert, z.B. mit typabhängiger Konfiguration, die aus ner 
Datenbank oder einer json oder woher auch immer kommt? Nachteil: 
massiver flash und RAM Verbrauch für Funktionalität, die möglicherweise 
nicht gebraucht wird.

2. wird der Code komplett statisch generiert durch irgendwelche Code 
Generatoren? Cube MX geht ja so in die Richtung, aber umfasst ja eher 
nur Hardware config/Hal. Vorteil: config in generator config Datei und 
damit versioniert, viel weniger Ressourcenverbrauch. Nachteil: ggf zu 
wenig Flexibilität.

2.1. nicht der gesamte Code wird generiert, aber z.B. ein (einzelner) 
config Header, mit einer Art namespace Schema für jedes Modul. Hat den 
"Charm" von alten C header define Orgien.

2.2. man schreibt gegnerischen Code mit Platzhaltern, der z.B. durch ein 
Python Skript geparst und modifiziert wird.

Was macht ihr und warum?

Danke :)

[PittyJ (Gast)]

Ich habe eine zentrale Konfiguration im Eeprom. Die wird am Anfang 
gelesen.
Und ja nach Konfiguration werden einzelne Objekte mit new und den 
Parametern generiert, oder der Pointer auf NULL gelassen.
In einem zweiten Schritt schaue ich z.B. bei I2C, was dort wirklich 
angeschlossen ist. Meldet sich der Chip nicht, dann wird der Konstruktor 
auch nicht aufgerufen, bzw abgebaut.
Da das new/delete einmalig bei Hochfahren stattfindet, bekomme ich wenig 
Probleme mit fragmentiertem Speicher.

Bei der Inbetriebnahme der Platine muss das Eeprom einmal richtig 
gesetzt werden.

[Jens R. (tmaniac)]

Jan K. schrieb:
> 2. wird der Code komplett statisch generiert durch irgendwelche Code
> Generatoren? Cube MX geht ja so in die Richtung, aber umfasst ja eher
> nur Hardware config/Hal. Vorteil: config in generator config Datei und
> damit versioniert, viel weniger Ressourcenverbrauch. Nachteil: ggf zu
> wenig Flexibilität.

So in der Richtung habe ich jetzt angefangen.
Aktuell bastel ich an einen CAN Stack mit diversen (automitive) 
Protokollen. Inklusive der Konfigurierbarkeit im CubeMX/CubeIDE.

Gerade wenn man mehrere Konfigurationen realisieren möchte, lohnt sich 
der Weg über die Codegeneration.

Ob der generierte Code nun statisch als Konstante im ROM oder 
veränderbar im EPROM liegt, ist vom Ansatz egal.

[Heinz (Gast)]

Zum Thema Eeprom:
Meine Eeprom Daten sind in einem großen union/struct definiert. Das 
erste Element gibt immer die Eeprom-Version an. Dadurch kann ich in 
späteren Software-Versionen das Eeprom-Layout beliebig ändern oder 
erweitern. Die späteren Software-Versionen müssen lediglich alle älteren 
Eeprom-Layouts kennen.
Dadurch kann eine neuere Software nach dem Update die Eeprom Daten 
nutzen, die eine älteren Softwareversion zuletzt hinterlassen hat.

typedef union Eeprom
{
  struct
  {
    unsigned long version;
    byte param 1;
  } EepromLayout_V1;

  struct
  {
    unsigned long version;
    byte param 1;
    byte param 2;
  } EepromLayout_V2;
};