mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Professionelle Entwicklung für AVR-Controller (Linux)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Dennis V. (schwebo)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die letzten 12 Jahre ging es bei mir beruflich meistens um serverseitige 
Entwicklung mit Java. Embedded-Entwicklung war nur ein Hobby.
Das ändert sich jetzt: ich möchte auch professionell an 
Microcontroller-basierten Projekten arbeiten.

Deshalb möchte ich gerne wissen, welche Methodiken und Werkzeuge im 
professionellen Umfeld üblich sind. Speziell interessiert mich 
Entwicklung unter Linux/Unix für AVR-Microcontroller. Genauer:

- welche Rolle spielen Simulatoren bei der Entwicklung?
- welche Tools werden eingesetzt? (Ich arbeite aktuell mit avr-gcc, 
PlatformIO, Git)
- wie sieht es aus mit In-Circuit-Debugging?
- welche Tests sind üblich und welche Tools werden dafür eingesetzt? 
Wird hauptsächlich mit Unit-Tests gearbeitet oder gibt es auch 
automatische Tests, die gegen die fertig programmierte Hardware laufen?
- wird nach wie vor hauptsächlich mit C oder C++ und Makefiles 
gearbeitet?

Ich bin gespannt!
Viele Grüße,
Dennis

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dennis V. schrieb:

> - welche Rolle spielen Simulatoren bei der Entwicklung?

Kann man für Algorithmen benutzen, einschließlich für Unit testing.

Die reale (Außen-)Welt eines Mikrocontrollers kann man in aller Regel 
viel zu schlecht abbilden, als dass man da noch irgendwas simulieren 
könnte.

> - welche Tools werden eingesetzt? (Ich arbeite aktuell mit avr-gcc,
> PlatformIO, Git)

Irgendwas in der Art.

Auch mit einem simplen "make" oder dem ältlichen SVN kommst du zum Ziel. 
git ist Hype, keine Frage, aber vieles dessen, was er eingebaut hat, ist 
in der Praxis nicht so ganz einfach zu beherrschen, sodass man oft dann 
trial&error arbeitet … in der Firma sind wir vor allem deshalb auf git 
gegangen, weil wir die komplette Integration eines Systems wie gitlab 
benutzen möchten.

> - wie sieht es aus mit In-Circuit-Debugging?

Allemal nützlich, wenngleich beim AVR mit AVaRICE nicht so gut, wie man 
es sich wünschen würde. (Auf ARM mit OpenOCD deutlich besser.)

Debuggen von Mikrocontrollern braucht aber Tricks & Kniffe & Erfahrung. 
Widerstehe der Versuchung, die Optimierung auszuschalten, nur weil dein 
single stepping im Debugger nicht geht: du debuggst sonst einen komplett 
anderen Code. Ohne Optimierung ändert sich das Timing, manchmal so sehr, 
dass es keinen Sinn mehr hat, damit überhaupt was zu machen. Außerdem 
treten viele Fehler, die man im praktischen Leben macht (bspw. ein 
vergessenes "volatile") erst durch aggressive Optimierung zutage. Sowie 
du in deinen Fähigkeiten die Programmiersprache gut genug beherrschst, 
dass du praktisch aus dem Stegreif syntaktisch fehlerfreien Code 
schreibst, solltest du auch gleich den optimierten Code debuggen.

Potenzielle Hilfsmittel: einzelne Werte für den Debugger temporär in 
"volatile"-Variablen ablegen, Breakpoints auf Anweisungen setzen, die 
nicht weiter optimierbar sind (bspw. Setzen von IO-Pins), ggf. halt 
einen "nop" einbauen, auf den man einen Breakpoint setzen kann. 
Generierten Assemblercode reviewen. Immer ein paar freie IO-Pins bereit 
halten zum Debuggen, da kommt ein Logic Analyzer dran während der 
Inbetriebnahme.

> - wird nach wie vor hauptsächlich mit C oder C++ und Makefiles
> gearbeitet?

Makefile werden sicher noch einen großen Teil der Entwicklungsumgebungen 
dominieren, denn sie sind praktisch universell benutzbar. Wir sind in 
der Firma inzwischen auch auf PlatformIO umgestiegen, ist halt 'ne 
andere Philosophie.

Ob du nun in C oder C++ programmierst, hängt von deinen Fähigkeiten ab, 
von dem, was deine Kunden wollen und ggf. von externer Software (wobei 
sich ordentliche C-Teile ja in ein C++-Projekt integrieren können 
sollten).

von Dres (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Professionell und AVR war mal, aber mittlerweile eher mit 32-bittern, 
d.h. in meinem Falle STM32-Familie. In anderen Firmen ganz ähnlich. AVR 
wird nur noch dort verwendet, wo es auch Sinn macht bzw. wo die 
Entwickler darauf bestehen. Preislich schlagen die 32-bitter die 
8-bitter so ziemlich in allen Fällen.
Beispiel: STM32F030C8T6TR (48 MHz, 64kB Flash) bei mouser schon ab 1-er 
Stückzahl unter einem Euro...

Thema Simulatoren: oft Zeitverschwendung. Nimm lieber reale HW und dort 
kannst du auch mal ein Oszi oder Speki dranhalten...

Tools: was einem Zusagt bzw. was preislich im Budget liegt. Ich 
favorisiere Keil-MDK, aber auch mit anderen tools kann man genauso gut 
arbeiten.

In-Circuit-Debugging: grundsätzlich ja. SWD bei den kleinen, JTAG bei 
größeren. Verstehe bis heute nicht, weshalb die ganzen Bastler es auf 
die harte Tour machen. Selbst die ollen AVR haben JTAG und der ebenfalls 
olle Dragon kann die auch bedienen...

Tests: stark Projekt und kundenabhängig. Macht man den Job aber 
ordentlich und schreibt grundsätzlich alles(!) selber, dann ist die SW 
bei Freigabe schon recht brauchbar. Wie es mit HAL und LL-Treibern 
aussieht, keine Ahnung. Habe ich nie genutzt.

C ist immer noch Mittel der Wahl, zumindest bei mir. Reicht für alle 
bisher aufgetretenen Aufgabenstellungen völlig aus wenn man es sauber 
beherrscht.

von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
Dennis V. schrieb:
> für AVR-Microcontroller.

Schau Dir unbedingt auch ARM-Cortex basierte Controller an. Denn es gibt 
zwar noch eine Nische für AVRs auf dem Markt, die wird aber immer 
kleiner.

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
Für "Einsteiger" die µC beruflich nutzen wollen kann ich ebenfalls nur 
zu einem ARM µC mit 32 Bit raten.

Als Einstige ist ein STM32 Discovery Board nicht schlecht, dazu die 
"STM32CubeIDE" als Entwicklungsumgebung.
Auf dem Board ist ein Debugger gliech mit drauf und mit Kosten von ca. 
20€ kann man hier schon einsteigen.
Ob es diese IDE auch für Linux gibt weiß ich jetzt nicht, jedoch ist 
diese recht Professionell und funktioniert sehr gut.

Natürlich gibt es auch von NXP und anderen Herstellern ARM µC und 
passende SW dazu.

: Bearbeitet durch User
von Stefan F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Markus M. schrieb:
> Ob es diese IDE auch für Linux gibt weiß ich jetzt nicht

Ja, gibt es

von Olaf (Gast)


Bewertung
-12 lesenswert
nicht lesenswert
> Deshalb möchte ich gerne wissen, welche Methodiken und Werkzeuge im
> professionellen Umfeld üblich sind. Speziell interessiert mich
> Entwicklung unter Linux/Unix für AVR-Microcontroller.

Nichts davon.

In der professionellen Entwicklung setzt man Linux nur ein wenn fuer 
Linux entwickelt wird oder auf Servern. Bedenke das der 
durchschnittliche Anwender, Programmierer und Admin nur wenig bis keine 
Ahnung von Linux hat.

Man setzt keine AVRs mehr ein sondern derzeit irgendwas mit ARM/Cortex. 
Als Debugger nimmt man einen Jlink. Also Compiler nimmt man in der Regel 
auch keinen gcc sondern was kommerzielles. Einfach weil man jemanden 
braucht den man anrufen kann oder vor das Schienenbein treten kann wenn 
etwas nicht geht.

Natuerlich gibt es fuer alles Ausnahmen, aber das sind dann auch 
Ausnahmen. Und ich will auch nicht sagen das ich das alles gut finde, es 
beschreibt nur die Realitaet.

Olaf

von Joggel E. (jetztnicht)


Bewertung
-2 lesenswert
nicht lesenswert
Nun, ja. JTAG ... kann man machen fuer triviale Probleme. Sobald es 
Probleme mit dem Ablauf beinhaltet kann man's vergessen, weil ein 
Breakpoint the Ablaufkontext zerstoert, denn der externe Prozess laeuft 
weiter, der Controller nicht.

von Olaf (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
> Nun, ja. JTAG ... kann man machen fuer triviale Probleme.

Nein, man kann es auch fuer eine Reihe aeusserst komplexer Probleme 
verwenden und es verkuerzt die Entwicklungszeit ERHEBLICH. Aber 
selbstverstaenlich gibt es auch Probleme die man damit nicht finden 
kann, wo dann andere Strategien gefragt sind.

> Breakpoint the Ablaufkontext zerstoert, denn der externe Prozess laeuft
> weiter, der Controller nicht.

Und warum nutzt du dann den Debugger nicht um im laufenden Betrieb 
Variablen oder Speicherstellen auszulesen?

Zur Zeit sehe ich nur zwei Dinge wo ein Debugger im professionellen 
Betrieb doof ist.

1. Manchmal hat man Teilschaltungen die potentialfrei sein muessen und 
da erdet man die wenn man einen Debugger ansteckt. Das kann man zwar 
auch loesen, aber ist etwas Aufwand.

2. Bei Anwendungen die extrem auf Stromsparen optimiert sind und wo auch 
die Versorgung nur wenig Energie bereitstellen kann wird es kritisch 
weil der Verbrauch der Controller steigt wenn die Debugmacrozelle im 
Controller aktiviert wird. Auch da kann man Loesungen finden, aber auch 
die sind aufwendiger.

Olaf

von Stefan F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> In der professionellen Entwicklung setzt man Linux nur ein wenn fuer
> Linux entwickelt wird oder auf Servern.

Ich arbeite jetzt in der dritten Firma in Folge, wo das so nicht 
zutrifft. Dort arbeiten die Entwickler gemischt mit Windows, Linux und 
Mac OS. Windows hat noch die Mehrheit.

von Blechbieger (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Das hängt stark vom Anwendungsgebiet ab. Für ein Gadget werden andere 
Methoden und Tools eingesetzt als für sicherheitskritische, streng 
regulierten Bereiche wie die Medizintechnik.

Jörg W. schrieb:
> Dennis V. schrieb:
>
>> - welche Rolle spielen Simulatoren bei der Entwicklung?
>
> Kann man für Algorithmen benutzen, einschließlich für Unit testing.
>
> Die reale (Außen-)Welt eines Mikrocontrollers kann man in aller Regel
> viel zu schlecht abbilden, als dass man da noch irgendwas simulieren
> könnte.

Da werden dann Hardware-in-the-Loop (HIL) Teststände eingesetzt die die 
Umgebung in Echtzeit simulieren oder echte Lasten enthalten. Problem 
sind die Kosten. Ein HIL für ein einzelnes einfaches Steuergerät kostet 
ca. 50 k€, für ein komplettes Auto 1 M€ aufwärts.

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
Stefan F. schrieb:
> Olaf schrieb:
>> In der professionellen Entwicklung setzt man Linux nur ein wenn fuer
>> Linux entwickelt wird oder auf Servern.

LOL

> Ich arbeite jetzt in der dritten Firma in Folge, wo das so nicht
> zutrifft. Dort arbeiten die Entwickler gemischt mit Windows, Linux und
> Mac OS.

Dito.

> Windows hat noch die Mehrheit.

Hier nicht. Hier haben wir das Problem, daß nur einer unserer Entwickler 
freiwillig Windows benutzt. Wenn der mal im Urlaub ist, bleiben Windows- 
spezifische Bugs liegen. Die am meisten verwendete Hardware ist von 
Apple, meistgenutztes OS dürfte knapp Linux sein.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Olaf schrieb:

> In der professionellen Entwicklung setzt man Linux nur ein wenn fuer
> Linux entwickelt wird oder auf Servern.

Mit Verlaub, das ist Quark.

Gerade bei der Mikrocontroller-Entwicklung spielt das Host-OS sowieso 
nur eine außerordentlich untergeordnete Rolle, denn die Software muss 
hinterher weder auf Linux noch auf *BSD noch auf Windows noch auf MacOS 
laufen, sondern auf dem Controller.

> Bedenke das der
> durchschnittliche Anwender,

Interessiert hier nicht.

> Programmierer

Kann sein, muss nicht sein.

> und Admin nur wenig bis keine
> Ahnung von Linux hat.

Dann ist es eher ein unterdurchschnittlicher Admin.

> Man setzt keine AVRs mehr ein sondern derzeit irgendwas mit ARM/Cortex.

Kann man so pauschal auch nicht sagen, wenngleich der Trend ganz sicher 
da ist.

> Als Debugger nimmt man einen Jlink.

Auch keineswegs zwingend. Wir haben stattdessen mittlerweile einen 
FT2232 als Debugger¹ und einen USB-Hub gleich mit auf die Boards gebaut: 
das spart die ganze Stripperei: ein USB-Kabel für den Debugger, eins für 
die Debug-UART, eins für den Target-Controller. Jetzt nur noch ein 
Kabel, und dem OpenOCD ist es sowieso wurscht, ob es ein JLINK, ein 
STlink, ein AtmelICE oder einen FT2232 ansteuert, das funktioniert mit 
allen. Entsprechend unabhängig bin ich in dem, was ich dann obendrauf 
setze.

¹) 1. Kanal SWD, 2. Kanal Debug-UART

> Also Compiler nimmt man in der Regel
> auch keinen gcc sondern was kommerzielles.

Auch das ist Quatsch. Mittlerweile benutzen alle unsere Kunden 
ausschließlich GCC, egal ob "bare metal" oder irgendwo zusammen mit 
irgendwelchen Hersteller-Tools geliefert.

> Einfach weil man jemanden
> braucht den man anrufen kann oder vor das Schienenbein treten kann wenn
> etwas nicht geht.

Das funktioniert sowieso nicht, die Schienbeine sind viel zu weit weg, 
und für den Tritt vors virtuelle Schienbein bekommst du bestenfalls eine 
Ticket-Nummer, aber keine Garantie, bis wann das Ticket auch behoben 
ist. Für eine solche Garantie bezahlt man nochmal deutlich drauf, 
entsprechend macht man das nur dort, wo man das unbedingt braucht (und 
der Preis auf das Endprodukt umlegbar ist).

> Natuerlich gibt es fuer alles Ausnahmen, aber das sind dann auch
> Ausnahmen.

In unserem Laden sind dann 80 % von deinen Aussagen „Ausnahmen“ (die 
verbleibenden 20 % sind, dass ein Teil der Entwickler wirklich mit 
Windows arbeitet, aber eben auch nicht alle).

: Bearbeitet durch Moderator
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joggel E. schrieb:
> Sobald es Probleme mit dem Ablauf beinhaltet kann man's vergessen, weil
> ein Breakpoint the Ablaufkontext zerstoert, denn der externe Prozess
> laeuft weiter, der Controller nicht.

Das ist das, wo ich oben schrieb, dass es eben auch ganz viel Erfahrung 
braucht.

Einerseits passiert es während der Entwicklung trotzdem ganz oft, dass 
man dann eben einfach an irgendeiner Stelle das Verhalten der Software 
jetzt „abschreibt“: dann ist ab dem Moment, wo der Debugger stoppt, das 
Timing im Eimer, aber man kann so eine Art „post mortem debugging“ 
machen, d.h. den auf diese Weise eingefrorenen Zustand analysieren. 
Ggf., s.o., Hilfsvariablen zwischendurch anlegen (das können auch ganze 
Ringbuffer etc. sein, heutige Controller haben in aller Regel genug 
RAM-Reserven), und in diesen interessante Trace-Informationen 
abspeichern, die man dann mit dem Debugger analysiert.

Ansonsten kann man sich auch Hilfsbefehle einbauen, um bspw. an 
irgendeiner Stelle im Fehlerfall einen NOP zu haben, auf den man einen 
Breakpoint setzen kann. Solange die Software durchläuft, dann mit 
Volldampf, wenn der Fehler auftritt, rennt sie in den NOP, auf dem der 
Breakpoint sitzt, und man schaut sich den Salat mit dem Debugger an.

Ja, das ist nicht so geradlinig wie 08/15-Debugging auf einem 
Hostcomputer.

Aber ohne Online-Debugging-Möglichkeit würde alles noch viel 
langwieriger werden.

JTAG isses heute bei den kleinen ARMs meistens nicht mehr, sondern SWD. 
Spart zwei Leitungen ein.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Blechbieger schrieb:
> Ein HIL für ein einzelnes einfaches Steuergerät kostet ca. 50 k€, für
> ein komplettes Auto 1 M€ aufwärts.

Richtig. Wir reden hier von jemandem, der sich mit sowas gerade mal 
selbstständig machen will. Für den sind solche Geschichten sehr 
wahrscheinlich noch in ferner Zukunft (sofern ihm nicht gerade sein 
Auftraggeber für ein Projekt sowas hinstellt).

von Andreas H. (ahz)


Bewertung
0 lesenswert
nicht lesenswert
Dennis V. schrieb:
> Deshalb möchte ich gerne wissen, welche Methodiken und Werkzeuge im
> professionellen Umfeld üblich sind. Speziell interessiert mich
> Entwicklung unter Linux/Unix für AVR-Microcontroller.

Alles was die Leute hier geschrieben haben war richtig (wenn man von dem 
Blödsinn SWD vs JTAG oder Linux vs Windows mal absieht).

Ich würde aber vermuten, dass sich Dein zukünftiges "Handwerkszeug" 
simpel nach den Anforderungen Deines Arbeitgebers richtet.

Ja, sicher sind 32-Bit ARM heute sehr beliebt. Aber wenn Dein AG schon 
x-Systeme mit PIC/PIC32 oder RL78 im Feld hat, alle anderen Entwickler 
darauf eingearbeitet sind (und oft auch keine Lust auf Wechsel haben), 
alle Entwicklungstools für diese Prozessorfamilie vorhanden sind und Du 
keine wirklich überzeugenden Gründe (und das heisst wirschaftliche 
Gründe) für einen Wechsel hast, dann wird es vermutlich schwierig.
Das Gleiche gilt aber auch für einen Wechsel zu AVRs ;)

/regards

von Blechbieger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Blechbieger schrieb:
>> Ein HIL für ein einzelnes einfaches Steuergerät kostet ca. 50 k€, für
>> ein komplettes Auto 1 M€ aufwärts.
>
> Richtig. Wir reden hier von jemandem, der sich mit sowas gerade mal
> selbstständig machen will.

Ich sehe im Ursprungsbeitrag nichts von Selbstständigkeit. Und in einen 
Bewerbungsgespräch ist es kein Fehler wenn man zumindest schon mal davon 
gehört hat falls das Thema zur Sprache kommt.

von Stefan F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Nur mal so nebenbei bemerkt:

Die GNU Compiler Collection wurde von Linux nach Windows portiert. Die 
gcc läuft unter Windows nur mit Stützrädern (mingw, msys, cygwin). Lange 
Zeit gab es keine offizielle 64bit Version.

Auch der OpenOCD Debugger wurde von Linux nach Windows portiert.

Oracle Java (auf dem viele IDE's laufen) wurde von Solaris nach Windows 
portiert. Merkt man unter anderem daran, dass "/" als Pfad-Trenner 
benutzt wird und praktisch keine Windows spezifischen Funktionen 
unterstützt werden.

Folglich fühlen sich diese Tools unter Unix artigen Betriebssystemen 
wohler, als unter Windows. Wenn ich professionell für µC entwickeln 
würde, wäre das für mich ein Grund, andere Entwicklungs-Tools zumindest 
zu probieren.

Andererseits ist das alles kostenlos und durchaus brauchbar, tadellose 
Ergebnisse zu produzieren.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Stefan F. schrieb:

> Die GNU Compiler Collection wurde von Linux nach Windows portiert.

Nein, die ist viel älter als Linux.

> Die
> gcc läuft unter Windows nur mit Stützrädern (mingw, msys, cygwin).

MinGW ist kein „Stützrad“, sondern das Win32-API als „glue layer“. Das 
sind also waschechte Windows-Binaries (wie wir ja neulich anhand der 
Lahmheit von sscanf() erfahren durften hier).

> Lange
> Zeit gab es keine offizielle 64bit Version.

Das ist doch nur das Problem, dass das mal wer compilieren muss. Spielt 
aber höchstens beim Compilieren riesiger C++-Dateien eine Rolle, alles 
andere sollte locker in 1 oder 2 GB Adressraum passen.

> Oracle Java (auf dem viele IDE's laufen) wurde von Solaris nach Windows
> portiert.

Wobei Sun damals so viel Aufwand investiert hat, dass die 
Windows-Version schneller war als die meisten Unix-Implementierungen 
(von Solaris selbst abgesehen).

> Merkt man unter anderem daran, dass "/" als Pfad-Trenner
> benutzt wird

Das funktioniert bereits seit MS-DOS 3.x in den Syscalls, folglich auch 
unter allen Windows-Versionen.

Nur command.com und cmd.exe machen den Backslash als Pfadnamentrenner 
zur Pflicht, da sie den Vorwärtsstrich von CP/M als Options-Trennzeichen 
geerbt haben. Das wiederum hatte sein Vorbild bei RSX-11 und RSTS.

> und praktisch keine Windows spezifischen Funktionen
> unterstützt werden.

Wofür bräuchte man diese bei einer Softwareentwicklung für 
Mikrocontroller?

: Bearbeitet durch Moderator
von Dennis V. (schwebo)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die spannenden Beiträge! Sehr aufschlussreich.

Wie sieht es mit automatischen Tests aus? In der 
ECommerce-Software-Entwicklung arbeiten wir mit einem bunten Zoo aus 
Unit-, Komponenten-, Integrations- und UI-Tests, die bei jedem Commit 
innerhalb einer Build-Pipeline ausgeführt werden.
Gibt es etwas ähnliches für Embedded-Entwicklung?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Tests gibt es auch in der embedded Welt. Ich benutze mbed-os noch in 
privaten Projekten, die testen so gigantisch viel das ich keine Bedenken 
habe sowas auch im beruflichen Umfeld einzusetzen:
https://os.mbed.com/docs/mbed-os/v5.14/tools/testing.html
Und in auch im professionellen Umfeld arbeiten nur Menschen die auch 
alle nur mit Wasser kochen. Es gibt grosse Unterschiede, ich habe genug 
Code der Marke 'geht schon, funktioniert doch' gesehen. Es sind nicht 
alles Informatiker die da Code schreiben. Und wenn jemand frisch von der 
Ausbildung kommt muss er erstmal lernen. Was im Labor so toll 
funktioniert sieht draussen ganz anders aus.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Wie sieht es mit automatischen Tests aus?

Wie in der PC-Welt nur noch komplexer weil man umfangreiche 
Zusatzhardware entwickeln muss mit dem man bestimmte Eigenschaften der 
Hardware oder ihrer Umgebung simulieren kann oder auch Fehler der 
Hardware erzeugen kann die zu keinem unerkannten Fehlverhalten fuehren 
darf. Compiler muessen auch diverse Zertifikate mitbringen.

Zum Beispiel sowas hier:
https://www.iar.com/iar-embedded-workbench/certified-tools-for-functional-safety/

Deshalb auch kein gcc.

Olaf

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Olaf schrieb:
> Compiler muessen

Das ist halt nur ein kleiner Teil von "Embedded Programming". Der 
überaus größte Teil braucht sowas nicht, weil es eben nichts 
sicherheitskritisches ist.

Aber auch dort wird getestet, wobei es halt Aufwand ist, Tests 
einzurichten. Die Möglichkeit, automatisierte Tests anzubinden, war für 
uns die Motivation, auf gitlab zu gehen. Tests sind aber halt (zumindest 
in unserem Umfeld) nichts, wofür einem ein Kunde massiv Geld bezahlen 
würde, insofern muss man immer sehen, wie man das im Budget mit 
unterbringt.

von Dennis V. (schwebo)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Tests sind aber halt (zumindest
> in unserem Umfeld) nichts, wofür einem ein Kunde massiv Geld bezahlen
> würde, insofern muss man immer sehen, wie man das im Budget mit
> unterbringt.

Für mich sind automatische Regressionstests (auch ohne dass der Kunde 
das beauftragt) in erster Linie hilfreich, um Sicherheit beim 
Refactoring und bei funktionalen Erweiterungen/Änderungen zu bekommen. 
Falls ich nur manuell teste, müsste ich ja potenziell bei jeder Änderung 
alle bisherigen manuellen Tests wiederholen.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Aber auch dort wird getestet, wobei es halt Aufwand ist, Tests
> einzurichten. Die Möglichkeit, automatisierte Tests anzubinden, war für
> uns die Motivation, auf gitlab zu gehen.

gitlab etc. ist aber alles rein softwarebasiert. Du musst also für Deine 
Firmware eine virtuelle Umgebung bauen in der sie ablaufen kann. Wenn 
man das mal gemacht hat ist es schön, hat aber das Problem daß die 
Aussage der Tests sehr stark von der Qualität dieser virtuellen Umgebung 
abhängt. Komplexe reale Objekte zu simulieren um z.B. Regelungstechnik 
zu testen, ist gar nicht so einfach.

Was ich daher normalerweise versuche:

Für die Produktion der Embedded-Geräte wird ja normalerweise sowieso 
immer ein Test-Jig benötigt, mit dem ein großer Teil der Funktionalität 
des Geräts stark automatisiert getestet werden kann. Da wird dann das 
frisch produzierte Gerät in einem der letzten Schritte der Produktion 
reingesetzt und ein Testlauf gestartet.

Wenn so ein Test-Jig einmal entwickelt wurde, sind die Kosten für ein 
weiteres Exemplar meist überschaubar. So ein Test-Jig kann man dann mit 
einem Muster in ein Rack stellen und dort Tests als Teil des CI-Zyklus 
automatisiert ausführen.

Wenn man diese Anwendung schon von Anfang an mit im Blick hat, ist das 
meist ohne große Mehrkosten umsetzbar.

> Tests sind aber halt (zumindest
> in unserem Umfeld) nichts, wofür einem ein Kunde massiv Geld bezahlen
> würde, insofern muss man immer sehen, wie man das im Budget mit
> unterbringt.

Das hängt aber dann vielleicht auch ein bisschen an Euren Vertrieblern. 
Dem Kunden Qualitätsvorteile durch umfangreiche Testsuites zu verkaufen 
ist eigentliche deren Job.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> gitlab etc. ist aber alles rein softwarebasiert.

Wir nutzen auf Arbeit eine Jenkins-Umgebung, die die Testsuites auf der 
realen Hardware laufen lässt. Das heißt, die Test-Rigs sind als 
Jenkins-Slaves konfiguriert, die Entwickler selbst sitzen woanders.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> gitlab etc. ist aber alles rein softwarebasiert.

Nö, wir binden da reale Hardware an.

Aber wie ich schrieb, es ist aufwändig, das einzurichten.

von Chris94 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
AVRs kommen einfach aus der Mode. ARM basierte Prozessoren sind einfach 
effizienter, performanter, vielseitiger und mittlerweile sogar oftmals 
günstiger. Natürlich darf man den Anwendungsfall nicht vergessen. Aber 
ich erlebe es oft, dass selbst in kleinsten Produkten auf ARM gesetzt 
wird, auch wenn die Leistung bei weitem nicht benötigt wird. Eben, weil 
die Hauptexpertise dort angesiedelt ist.
Zur Toolchain kann ich dir folgendes erzählen:
Codeverwaltung mit Git. Insbesondere komplette Integration von 
Bitbucket, Jira, Jenkins Buildserver.
Programmiert wird bei uns ausschließlich nach C++14. Die Features, die 
dynamische Allokation verwenden, werden komplett durch Alternativen wie 
die ETL ersetzt.
Als Buildtool verwenden wir aus Performancegründen nicht mehr make 
sondern Ninja in Verbindung mit CMake.
Compiler hauptsächlich GCC. Manchmal auch Clang.
Zusätzlich verwenden wir statische Codeanlysen mit Clang Tidy, Code 
Coverage mit gcovr und Google Test & Mock für Unit Tests. Seit neuestem 
verwalten wir diese Abhängigkeiten mit Conan.

Das von mir beschriebene, stellt für mich und mein Unternehmen den 
State-of-the-Art dar. Ich bin mir aber sicher, dass es hier auch wieder 
viele andere Ansätze gibt, die für den speziellen Anwendungsfall 
optimaler geeignet sind.

Viele Grüße,

von Dennis V. (schwebo)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Für die Produktion der Embedded-Geräte wird ja normalerweise sowieso
> immer ein Test-Jig benötigt, mit dem ein großer Teil der Funktionalität
> des Geräts stark automatisiert getestet werden kann.

Sind Test-Jigs das gleiche wie die von Blechbieger erwähnten 
HIL-Teststände?

von Blechbieger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dennis V. schrieb:
> Sind Test-Jigs das gleiche wie die von Blechbieger erwähnten
> HIL-Teststände?

Die meisten Test-Jigs sind wesentlich simpler aber ja, ein Jig für 
voll-automatischen Test in der Massenfertigung hat schon Ähnlichkeit zu 
einem HIL. Z.B. National Instruments liefert Komponenten für beides. Der 
Schwerpunkt ist aber ein anderer. Automated test equipment (ATE) dient 
dazu möglichst schnell eine Baugruppe auf elektrische Funktion zu 
testen, die Firmware wird als funktionierend angenommen. Beim HIL geht 
es darum eine Firmware möglichst komplett zu testen, die Hardware wird 
dabei als funktionierend angenommen.

von Dennis V. (schwebo)


Bewertung
0 lesenswert
nicht lesenswert
Herzlichen Dank euch allen für die interessanten Infos!
LG Dennis

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> gitlab etc. ist aber alles rein softwarebasiert. Du musst also für Deine
> Firmware eine virtuelle Umgebung bauen in der sie ablaufen kann. Wenn
> man das mal gemacht hat ist es schön, hat aber das Problem daß die
> Aussage der Tests sehr stark von der Qualität dieser virtuellen Umgebung
> abhängt. Komplexe reale Objekte zu simulieren um z.B. Regelungstechnik
> zu testen, ist gar nicht so einfach.

Man kann durchaus auch einen Runner triggern, der nach dem durchspulen 
der Simulation (und Synthese) ein Bit-File auf den angeschlossenen 
Target jagt und die Testvektoren in echt stimuliert. Kostet jetzt auch 
nicht mehr so die Welt wie ein teurer ICT..

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.