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
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).
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.
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.
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
> 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
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.
> 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
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.
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.
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.
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
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.
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).
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
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.
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.
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
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?
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.
> 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
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.
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.
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.
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.
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.
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,
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?
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.
Herzlichen Dank euch allen für die interessanten Infos! LG Dennis
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..
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.