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
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.