Test und Dokumentation von Embedded Systems?

[Julian S. (julianschubert99)]

Hallo liebe Leser,

ich habe vor 3,5 Jahren meinen BA in technische Informatik absolviert. 
In den 3,5 Jahren habe ich versucht meinen Traum zu verwirklichen, woran 
ich jedoch gescheitert bin. Nun möchte ich wieder als Entwickler 
arbeiten und bewerbe mich für eine Stelle als 'Berufseinsteiger'.

Dort ist unter anderem folgende Voraussetzung aufgelistet:
-> Erste Erfahrung in Test und Dokumentation von Embedded Systems

Leider habe ich komplett vergessen wie man im Embedded Bereich richtig 
Testen und Dokumentierten kann/muss. Bei Java sind es ja 
Klassendiagramme, Flussdiagramme etc, JUNIT-Test und JavaDoc. Welche 
Hilfsmittel gibt es da im Embedded Bereich?

Google hat mir nich so wirklich weiter geholfen.

Lg

[Cyblord -. (cyblord)]

Julian S. schrieb:
> Bei Java sind es ja
> Klassendiagramme, Flussdiagramme etc, JUNIT-Test und JavaDoc. Welche
> Hilfsmittel gibt es da im Embedded Bereich?

Wenn du dein Embedded System in Java schreibst, dann bleibt alles 
gleich.
Als ob das vom Einsatzbereich abhängen würde. Eher von der Sprache.

Aber was du da aufzählst ist mir zu sehr mit der Programmiersprache 
verknüpft. Auf dieser Ebene dokumentiert man ein SW-Modul, aber kein 
Embedded SYSTEM.
Embedded bezieht sich, IMO mehr auf die Hardware. Welcher Controller, 
welche Schnittstellen/Busse, welche HW-Module, wie verschaltet. 
Natürlich dann auch die Arbeitsweise der Software. Aber bei Embedded 
kannst du HW und SW nicht einfach trennen.

Warum willst du, als offensichtlich bisher reiner JAVA Entwickler, 
unbedingt in den Embedded Bereich? Kannst du Spannung von Strom 
unterscheiden? Kannst du spontan ein Oszi, Signalgenerator und 
LogicAnalyzer benutzen?
Kannst du Schaltpläne und Datenblätter lesen?

[Pandur S. (jetztnicht)]

Nun ja. Embedded bedeutet eigentlich Echtzeitsysteme. Also 
Zustandsdiagramme, Taskablaufsdiagramme,..

Meist geht Testen per singlestep ja nicht, resp nur bei trivialem Zeugs, 
weil der Kontext kaputt geht. Bedeutet man muss waehrend des Ablaufs, in 
Echtzeit debuggen und auch simulieren. Man schreibt sich Tracebuffer und 
Tracevariablen welche per Command auslesbar sind. Oder wewendet 
Hilfshardware. zB Ein Pin, oder ein DAC, welcher irgendwelche Werte 
ausgeben kann, welche dann mit dem Oszilloskop angeschaut werden 
koennen. Ich hab zB einen (aufsteckbaren) QuadDAC, welcher es erlaubt 4 
dynamische Werte gleichzeitig anzuschauen.

[Michael F. (Gast)]

Joggel E. schrieb:
> Man schreibt sich Tracebuffer und
> Tracevariablen welche per Command auslesbar sind.

:-/

Und warum nimmt man nicht die in vielen MCUs bereits vorhandene Trace 
Hardware (Stichwort: Arm CoreSight) mit passender Debug-Probe, um dann 
ohne Umwege eine komplette Liste aller ausgeführten Instruktionen zu 
bekommen?

[Pandur S. (jetztnicht)]

Ja, wenn's den hat, nimmt man den. Allenfalls reicht das eben nicht.

[A. S. (Gast)]

Julian S. schrieb:
> bewerbe mich für eine Stelle als 'Berufseinsteiger'.
>
> Dort ist unter anderem folgende Voraussetzung aufgelistet:
> -> Erste Erfahrung in Test und Dokumentation von Embedded Systems

Was ist das für eine Stelle? SW-Entwickker? Programmierer? 
Projekt/Produkt-irgendwas? Entwickler? Testbereich? Q? Doku?

Je nach Aufgabe ist "Test und Doku" etwas völlig anderes. Auch reicht 
"embedded" vom uP im Rasierer über DSP-Motoren bis zu vernetzten 
Linuxsystemen.