Alles für den Sourcecode Nerd
Auch was spannendes: Wenn Software in Hardware getestet werden will und man die Programmierung mit programmierter Spannung unter oder über die Grenzen treibt.
Nach auch nur einem kurzen Moment hat man ein buntes Tagwerk an Kabeln auf dem Tisch verteilt.
Wichtig dabei: Formelsammlung für Spannungsteiler sollte parat liegen!
Es gibt Eclipse IDEs für Embedded Entwicklung welche ihre SDK Pfade über Umgebungsvariablen im Projekt definieren. Erst mal eine prinzipiell gute Idee, denn nicht jeder Arbeitsplatz eines Entwicklers hat die gleichen Pfade.
Wenn diese Variable aber nun Punkte im Namen hat, fangen die Probleme an. Unter Windows ist das ja noch OK, aber das gleiche unter Linux ist nicht erlaubt. In einer bash Shell klappt das zum Beispiel nicht mehr.
Also die Empfehlung an die Hersteller: Wenn man schon die eigene IDE auch unter Linux anbietet, dann bitte mit vollständig portablen Eigenschaften.
Ein weiteres NoGo Beispiel aus C-Land:
Man will in einem Modul eine bestehende header Datei einbinden und fügt das passende #include hinzu. Schon hagelt es aus der eingebetteten Datei unbekannte Identifier und mehr. Was ist passiert?
Die neue header Datei nimmt stillschweigend an bestimmte weitere header files schon im aufrufenden Code eingebettet zu haben. Besser ist es aber, wenn jede header Datei alles selber einbettet was sie zu nutzen gedenkt. Dann sind die Einbindungen zwar vielfach vorhanden, aber das abzufangen ist ja schon lange ein Must Have, dank #ifdef in jeder header Datei.
Viele Methoden liefern auch einen Rückgabewert, ob alles geklappt hat. Den kann man prüfen, macht man aber nicht. Beispiele?
Gegeben sei folgender Funktions Prototyp (wir nehmen mal C als Sprache):
int myMethod(void);
Also wird das im Programm dann mal so aufgerufen: „Rückgabewerte von Funktionen prüfen“ weiterlesen
Bei den ganzen Tools und CI Ketten braucht es eine Plattform sie alle zu knechten und zu kommentieren. Also geht es hier nun los.