Hi, ich schreibe gerade auf dem STM32F446VET eine Applikation, die Kommandos über UART vom HOST-PC erhält, diese abarbeitet und Antworten zurück sendet. Bin dabei, die Kommandostrukturen, den Parser und die Ausführungsschichten zu schreiben. Da steckt viel ANSI C (strtok_r, atoi, etc.) drin, wo ich alles andere als sattelfest bin. Das im Debug zu testen, ist aufwendig, zumal auch die Host-App in C# noch in der Mache ist. Also müsste ich da vom Terminal aus senden. Wie kann ich Teile dieser App (.c/.h) Module woandershin auslagern und dort auf die Schnelle austesten? Habe das schonmal in Code::Blocks probiert, war aber auch alles andere als straightforward. Kennt jemand hier solche Tricks? Kann ich in der CubeIDE auch ein C-Projekt mit MinGW aufsetzen und das gschwind in der Konsole ausgeben lassen? Danke an die Experten der Tafelrunde!
> Bin dabei, die Kommandostrukturen, den Parser und die > Ausführungsschichten zu schreiben. Als ich sowas das letztemal brauchte habe ich mir das von flex schreiben lassen. .-) Vanye
Du kannst das auf Deinem PC testen. Die hardwareabhängigen Funktionen (UART,...) kapselst Du in Funktionen, und Dein Parser wird auf dem PC genauso funktionieren wie auf dem STM32. Auf dem PC kannst Du in der Regel besser und einfacher testen, ohne den Code jedesmal hochzuladen. Da Du auch C# Code hast: Das Visual Studio sollte eigentlich auch C Code veraerbeiten können. Eventuell musst Du die passenden Teile nachinstallieren. fchk
Wenn dein Code anständig gekapselt ist und keine Abhängigen zu den STM Libraries hat, dann kanns Du den einfach zusammen mit Testcode in eine Ausführbare Detei für deinen PC kompilieren und dort starten. Nennt man UnitTest.
Frank K. schrieb: > Du kannst das auf Deinem PC testen. Genau so würde ich das auch machen. Kapseln über eine HAL und dann Unittest schreiben die du auf dem PC laufen lassen kannst. Musst du dir halt die ganzen Szenarien überlegen die dir einfallen. Zu kurz, zu lang, Wertebereiche, Terminierungen usw.
:
Bearbeitet durch User
Danke, bin gerade dabei das zu versuchen, mit MSYS2 und VSCode. Mal sehen, ob die Module sauber gekapselt sind, aber ich glaube schon. Die Befehlshandler enthalten HAL-Befehle.
Warum schreibt man eine M2M Kommunikation in einer Art und Weise, dass sie String-Vergleiche benötigt? Habt Ihr da Vorgaben, dass es Menschenlesbar sein muss oder wollt Ihr die Befehle per Terminal emulieren können? Ich frage nur, weil es wirklich viel viel effizienter geht, wenn man sich in Pointer Tabellen und Function-Pointer einarbeitet. Danach geht alles sehr viel schneller und vor allem sehr sicher.
Ulrich schrieb: > Ich frage nur, Ich verstehe deine Frage nicht so recht. Ich habe eine Struct für Commands:
1 | const Command_t myCommands[] = |
2 | {
|
3 | { .code = 'K', |
4 | .name = "Relais", |
5 | .handler = switch_relay, |
6 | },
|
7 | { .code = 'V', // immer mit Strom |
8 | .name = "Voltage", |
9 | .handler = get_volt, |
10 | }, etc... |
jedes Command hat seinen Funktionszeiger auf das was ich Handler nannte. Aber zunächst bearbeitet der Parser den empfangenen String vom Port und separiert die Parameter, übergibt dann an den Handler.
Ulrich schrieb: > Habt Ihr da Vorgaben, dass es > Menschenlesbar sein muss oder wollt Ihr die Befehle per Terminal > emulieren können? P.S.: Ja, letzteres. Ich finde es gut, wenn ich an der Anlage, eben an der Steuersoftware vorbei, Kommandos auslösen kann.
Gunnar F. schrieb: > Kann ich in der CubeIDE auch ein > C-Projekt mit MinGW aufsetzen und das gschwind in der Konsole ausgeben > lassen? Theoretisch müsste das gehen, denn die IDE besteht im Kern aus Eclipse mit dem CDT Plugin. Schaue dir dessen Doku an. https://projects.eclipse.org/projects/tools.cdt
:
Bearbeitet durch User
Gunnar F. schrieb: > Kann ich in der CubeIDE auch ein > C-Projekt mit MinGW aufsetzen und das gschwind in der Konsole ausgeben > lassen? Ja das hab ich schon oft genau so gemacht. Falls du von der klassischen STM32CubeIDE auf VS Code umsteigst, hier ein Tutorial für ein modernes Setup mit VS Code: https://github.com/Erlkoenig90/VSCodeCMakeDemo Das geht auch parallel in der selben VS Code Instanz die für STM32 genutzt wird.
Gunnar F. schrieb: > Wie kann ich Teile dieser App (.c/.h) Module woandershin auslagern und > dort auf die Schnelle austesten? Lobenswerte Herangehensweise! Das Ding hat auch einen Namen "Test driven developpment". Dafür gibts auch ein passendes Buch, das du dir evtl. anschauen solltest: ... Scheißlangen Amazon-Link gelöscht ... "Test Driven Development for Embedded C". Von J.W. Grenning. Das verwendet aber das Ziel als Plattform. Nicht tragisch, die Techniken sind gleich. Wenn du eine andere Plattform verwendest, achte penibel darauf, dass die Typen gleich sind. Also keine int. -> <stdint.h>
Mit minicom (https://linux.die.net/man/1/minicom) kann man einfache Kommunikation automatisieren (https://linux.die.net/man/1/runscript). Damit habe ich besonders mit dem expect Schlüsselwort im Kontext AT-Kommandos gute Erfahrungen gemacht. Nick schrieb: > "Test Driven Development for Embedded C". Von J.W. Grenning. Das > verwendet aber das Ziel als Plattform. Nicht tragisch, die Techniken > sind gleich. Das Buch kann ich für komplexere Fälle nur empfehlen.
:
Bearbeitet durch User
NICHT ernst gemeint: DA10 von W&G https://www.amikon-shop.de/messtechnik/da10-datenanalysator-wandel-goltermann/a-2921 Wenn das Timing wichtig ist und Antworten innerhalb einer gegebenen Zeit. Hatte ich tatsächlich vor nicht mal 10 Jahren verwendet für ein komplexeres Protokoll. Aber nur zu Anfang. :-)) Ihr dürft gerne auch lachen!
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.