Hallo,
ich bin unlangs zu einer anderen Firma gewechselt und werde dort nun
verstärkt im embedded C Bereich eingesetzt, obwohl ich mehr aus der VHDL
Ecke komme. Ich bin direkt in ein gerade gestartetes Projekt gesetzt,
soll heißen dass die Vorüberlegungen zum Thema "welcher Controller" etc.
schon beschlossen sind.
Im Kern geht es darum dass die Hardware die wir für den Kunden machen
eine Reihe von digitalen Filtern und anderen Algorithmen beinhaltet.
Diese sind allesamt schon in Octave designed, inklusive Stimuli und
erwarteten Ausgangsdaten. Nun hat mein Projektleiter mir aufgetragen,
genau diese schon bestehende Information zum Aufsetzen eines mehr oder
weniger automatischen Test-Systems zu verwenden.
In der VHDL Ecke habe ich sowas ziemlich häufig gemacht (Matlab Modell,
VHDL Simulation und Ausgangsdaten vergleichen). Da ich nicht so
bewandert bin in der Test-Ecke von Embedded C wollte ich mal fragen ob
mir jemand etwas Starthilfe geben könnte in dieser Sache um mich etwas
einzulesen oder mich mit Prozeduren vertraut zu machen?!?
Unterm Strich wird dies ein Pilot-Projekt für 'Design by Test' in
unserer Firma. Das bedeutet dass ich auch einen Continious Integration
Server mit diesen automatischen Tests laufen lassen will/soll.
Soweit ich weiß (das Projekt ist mir gerade erst zugeteilt, ich hatte
noch keine Gelegenheit die Details zu beschauen) sind die Matlab/Octave
Modelle nicht wahnsinnig kompliziert, allerdings sind sie ziemlich
zahlreich. Vorerst sollen die Test nur funktionell den zu erstellenden
C-Code verifizieren. Erst im zweiten Schritt soll das ganze dann auch
auf der Zielhardware getestet werden.
Im Vorraus vielen Dank
Matthias
Die Frage in Kurzfassung wäre, wie die Kopplung zwischen den schon
bestehenden matlab/octave modellen inkl der stimuli und dem dann
ersteltem quellcode (der dann auf der zielhardware laufen soll) aussehen
soll. Irgendiwe sehe ich das noch nicht so richtig vor mir wie octave
mit einer hand voll C Funktionen umgeht. Gut möglich dass das alles ganz
einfach ist, aber mangels Erfahrung kann ich mir nunmal noch keinen Reim
drauf machen.
Ich hoffe dass das die Situation etwas deutlicher macht?!?
Schade das immer gleich die Trolle bemüht werden müssen nur wenn man mal
die Frage nicht versteht.
Was willst du überhaupt testen ? Wenn ihr eh schon verifizierte Modelle
habt und mit Codegenerierung arbeitet bringt es nichts da irgendetwas
gegen zu testen...das einzig sinnvolle ist das ganze mit der echten
Hardware zu verifizieren
Moin Moin!
Verstehe ich Dich richtig, dass Du zum einen Simulationsmodelle auf dem
PC hast die dann manuell in C-Code übertragen wurden und nun auf einem
uC laufen? Diese Handcodierten Funktionen sollen nun auf dem uC getestet
werden, oder? D.h. der Code soll auf dem uC Laufen und dann mit diversen
Testdaten gefüttert werden und dann das Ergebnis mit den Ergebnissen aus
den Simulationsmodellen verglichen werden?
Wenn ja, könntest Du das ganze über einen Debugger testen. D.h. manche
Debugumgebungen unterstützen auch Skripsprachen um Tests zu
automatisieren. Hier könnte man die Ergebnisse aus den Simulationen
einlesen und dann mit den Ergebnissen aus dem Target vergleichen. Wie
das ganze dann mit einem CI-Server zusammenläuft weiß ich nicht.
Ein anderer Ansatz wäre z.B. eine Erweiterung von Octave. Soweit ich
weiß kann Octave mittels C-Funktionen erweitert werden. Hier Könntest Du
eine Erweiterung schreiben die eine Verbindung zu deinem Target uC
herstellt (z.B. per UART oder so). Dann känntest Du direkt von Octave
aus Die Daten aus dem uC auslesen und direkt mit den Daten aus der
Simulation vergleichen.
Viele Grüße...
Ralf schrieb:> Moin Moin!> Verstehe ich Dich richtig, dass Du zum einen Simulationsmodelle auf dem> PC hast die dann manuell in C-Code übertragen wurden und nun auf einem> uC laufen? Diese Handcodierten Funktionen sollen nun auf dem uC getestet> werden, oder? D.h. der Code soll auf dem uC Laufen und dann mit diversen> Testdaten gefüttert werden und dann das Ergebnis mit den Ergebnissen aus> den Simulationsmodellen verglichen werden?
Das wäre der zweite Schritt, das stimmt.
Der erste Schritt, so wurde mir aufgetragen, ist die reine funktionale
Kontrolle. Soll heißen, die Eigenschaften eines bestimmten Algorithmus
werden in C-Code übertragen, und genau dieser Code soll nun vom schon
bestehenden Matlab Modell wieder verifiziert werden.
Soweit ich das bisher verstanden habe, besteht schon ein System dass so
aussieht in Matlab:
Stimuli --> Filter --> Resultat
Diese 3 Dinge bestehen bereits. Was man jetzt scheinbar möchte ist den
in Matlab erstellten Code durch den C-Code der auf dem uC laufen soll zu
ersetzen. Die Stimuli füttern den Code, das resultat sollte, wenn man
alles richtig gemacht hat, dann gleich dem theoretischen Modell sein
(rundungsfehler ausgenommen vielleicht).
Im ersten Schritt läuft das ganze noch PC basiert, später dann auf dem
uC. Wenn ich nur erstmal matlab/Octave soweit kriege den von mir
erstellen sourcecode zu verwenden dann bin ich schon ziemlich weit
gekommen.
Die Kunst liegt darin Stimulifiles zu erstellen
die die Filter bin an den Rand der Aussteuergrenze bringen.
Wenn man wirklich was falsch gemacht hat dann sieht man das oft nicht
weil bestimmte Frequenzen interne Register nur wenig aussteuern, andere
Frequenzen dafür umso mehr.
Also: waveform auf uC übertragen, uC Filter filtern lassen, gefilterte
Waveform auf PC übertragen und vergleichen. Wenn die Waveform nicht
voll in den uC Speicherpasst : oops.
Hallo,
wenn du Matlab hast dann solltest du vielleicht in einem Matlab-Forum
fragen. In gomatlab.de wurde mir schon oft geholfen.
Wenn euer Code schön modular ist und die eigentlichen Funktionen keine
mikrocontrollerspezifischen Zugriffe (interne Peripherie) haben, sollte
es möglich sein C Code in Matlab einzubinden.
Eine automatisierte Auswertung auf dem Mikrocontroller wird da wohl
schon schwieriger, da du dann möglicherweise die eigentliche
Funktionskette von Sensor zur Verarbeitung zu Ausgabe/Steuerung/... mit
dem Stimuli unterbrechen müsstest. Dabei änderst du aber schon wieder
die Gesamtbedingungen und stellst damit die Frage nach der Wirksamkeit
dieser Tests.
Du kannst in matlab "normalen", microcontroller_un_spezifischen C und
C++ Code mit coder.ceval('') einbinden und daraus eine MEX file (doc
mex, doc coder) erzeugen lassen, oder du erzeugst nur aus dem reinen C
Code eine MEX file.
Der C code könnte auch automatisch erzeugt werden (embedded coder), aber
das scheint hier nicht wichtig zu sein.
Du kannst mit der MEX file genau so arbeiten, wie mit einem normalen
matlab Skript file, du kannst nur nicht mehr "reingucken", da es sich
dann um eine Binärdatei handelt.
Schöne Grüße,
Jan
Zuerst ist mal zu klären: Hast du Matlab oder Octave?
Octave lehnt sich zwar an die Syntax und Funktion von Matlab an, aber
für Matlab bekommt man ganz andere Toolboxen (schönes Denglish ...),
z.B. für Tests mit HIL.
Daher ist es ein wichtiger Unterschied ob Octave oder Matlab. Nehmen wir
an es ist Octave. Dann darfst du eigentlich alles selber bauen.
ICh habe sowas schon ein paar mal gemacht und die Realität ist, dass man
das nicht mal eben Schnell in einem Forum-Posting erklären kann.
Anfangen kannst du damit, dass du dir folgende Fragen beantwortest:
- C Implementierung
Auf der Zielhardware ausführen?
Oder auf einem PC simuliert?
Oder auf einem PC emuliert?
- Stimuli vorhanden
Injection der Daten in die Zielhardware?
Oder nur in die Software auf der Zielhardware?
Oder in die simulierter / emulierte PC Software?
Entweder auf simulierter / emulierter Hardwareebene?
Oder auf simulierter / emulierter Softwareebene?
- Erwartete Ergebnisse
Mit welcher Genauigkeit sollen die getroffen werden?
Sind die Testfälle bekannt? Besonders die Grenzfälle?
Wie aus der Zielhardware bekommen?
Oder aus der Simulation/Emulation?
- Steuerung und Ablauf
Steuerung des ganzen durch Octave? Dann ev. eigene Octave-Erweiterungen
programmieren.
Steuerung z.B. durch eine Skriptsprache? Dann sorgfältige Auswahl (nicht
einfach so einen Modedreck wie Python)
Wer kann / muss das Ganze warten? Spezialpersonal oder soll muss
kann jeder Entwickler neue Tests einbringen?
Steuerung durch ein Continuous Integration System? Welches?
Compilierung der C-Implementierungen durch wen und wann? Build-System,
CI-System?
Loader / Test-Programm um die jeweiligen Algorithmen-Implementierungen?
Laden der Kompilate in die Hardware Simulation Emulation?
Kontrolle der Ausführung in der Hardware Simulation Emulation?
An jeder der Antworten hängt ein Rattenschwanz von Details dran, z.B.
wenn es um Timing geht oder tolerierbare Abweichungen vom vorgegebenen
Ergebnis.
Vielen Dank für die vielen sinnvollen Antworten.
Das was ich suchte war das generieren von MEX. Ich hab da jetzt ein
bisschen mit rumexperimentiert und es leistet auf jeden Fall genau was
ich gesucht habe. Zugegeben ist das octave nicht gerade eine tolle
Sprache um vernünftig automatisiert zu kompilieren, aber mit ein
bisschen Krampf hat auch das hingehauen.
Ich finde die Dokumentation von MEX in Octave (vor allem die Funktion
mkoctfile) und der Verwendung von mexFunction ein bisschen
undurchsichtig und es gibt auch nicht wirklich viel darüber zu finden im
Netz, aber nach ein bisschen Spielerei hat sich alles zu voller
Zufriedenheit ergeben.
Nochmals danke!
Mark 99 schrieb:> Steuerung z.B. durch eine Skriptsprache? Dann sorgfältige Auswahl (nicht> einfach so einen Modedreck wie Python)
Python gibt es seit 1991. Was veranlasst Dich zu dem Prädikat
'Modedreck'?
Ist TCL von 1988 besser? Welche Alternativen schlägst Du vor?
Frank
