Hallo zusammen, ich suche eine Möglichkeit, Daten, die in Form eines Arrays in einer µC-Firmware (STM32G4xx) vorliegen, in Echtzeit graphisch auf dem PC darzustellen. Es handelt sich z.B. um die Amplitude eine DFT, oder ähnliches. Eine serielle Schnittstelle zur Datenübertragung wäre nur umständlich zu benutzen, wesentlich einfacher wäre es über ST-Link (inkl. SWO). Bisher habe ich für so etwas öfter mal Stm32Viewer benutzt, allerdings wäre es m.W. da ur sehr umständlich, damit ganze Arrays darzustellen. Einzelne Variablen über die Zeit ist sehr komfortabel. Weitere Anforderung: die Visualisierungs-SW muss unter Linux laufen. Danke für alle Hinweise!
Raoul D. schrieb: > Eine serielle Schnittstelle zur Datenübertragung wäre nur > umständlich zu benutzen, wesentlich einfacher wäre es über ST-Link > (inkl. SWO). Heute ist doch noch gar nicht Freitag.
Rahul D. schrieb: > Raoul D. schrieb: >> Eine serielle Schnittstelle zur Datenübertragung wäre nur >> umständlich zu benutzen, wesentlich einfacher wäre es über ST-Link >> (inkl. SWO). > > Heute ist doch noch gar nicht Freitag. Guten Morgen ;-)
Raoul D. schrieb: > Weitere Anforderung: die Visualisierungs-SW muss unter Linux laufen. Klingt wie ein Entwicklungsauftrag. Was zahlst du? Mal im Ernst, was gibt es einfacheres als eine serielle Schnittstelle?
Ada J. Quiroz schrieb: > Raoul D. schrieb: >> Weitere Anforderung: die Visualisierungs-SW muss unter Linux laufen. > > Klingt wie ein Entwicklungsauftrag. Was zahlst du? > > Mal im Ernst, was gibt es einfacheres als eine serielle Schnittstelle? Klaro, wenn es die HW hergibt, was in diesem Fall nicht direkt gegeben ist. SWO ist ja nicht sooo weit entfernt.
Gar nicht so kompliziert, da die neueren ST-Links ja einen virtuellen Com-Port bereitstellen. Man muss halt ein wenig aufpassen, dass die Datenrate begrenzt bleibt. Ich mache solche Visualisierungen mit Matlab, aber mit Python sollte das auch keine Raketenwissenschaft sein.
https://github.com/nesnes/teleplot Wäre so ein Tool über seriell oder UDP. Oder https://github.com/nathandunk/BetterSerialPlotter
Ada J. Quiroz schrieb: > Raoul D. schrieb: >> Weitere Anforderung: die Visualisierungs-SW muss unter Linux laufen. > > Klingt wie ein Entwicklungsauftrag. "ich suche eine Möglichkeit" "Danke für alle Hinweise!" Ganz eindeutig.
J. S. (jojos) >https://github.com/nesnes/teleplot Super genial, ich habe es gerade ausprobiert, weil es das als Online-Version gibt: https://teleplot.fr/ Gut, die Daten gehen vermutlich einmal um die halbe Welt ...
> Weitere Anforderung: die Visualisierungs-SW muss unter Linux laufen.
Keine Grosse Sache.
Ich hab mir das vor ein paar Jahren mal selber geschrieben, einfach
vom Compiler ein Mapfile mit den Adressen der Variablen erzeugen lassen.
Dann schnell ein Tool mit Qt zusammengeklickt das die Daten an den
Adressen mit den Seggertools aus der MCU rausliesst.
Wahr eigentlich ziemlich einfach...
Vanye
Visualisierung... erstmal sollte bekannt sein um wie viele Megapixel pro Sekunde es denn gehen soll. Da Serial als zu trivial oder so betrachtet wird, allenfalls Ethernet. Dort arbeitet man mit sockets.
Til S. schrieb: > Evtl. hilft das hier? > > https://www.segger.com/products/debug-probes/j-link/tools/j-scope/ Danke!
Christoph M. schrieb: > J. S. (jojos) >>https://github.com/nesnes/teleplot > > Super genial, ich habe es gerade ausprobiert, weil es das als > Online-Version gibt: > https://teleplot.fr/ > > Gut, die Daten gehen vermutlich einmal um die halbe Welt ... Schaut sehr gut aus. Das kann man auch lokal laufen lassen und die Daten aus dem st-trace dahinein pipen.
J. S. schrieb: > https://github.com/nesnes/teleplot > Wäre so ein Tool über seriell oder UDP. > Oder > https://github.com/nathandunk/BetterSerialPlotter Danke! Auch gut.
Vanye R. schrieb: > Ich hab mir das vor ein paar Jahren mal selber geschrieben, einfach > vom Compiler ein Mapfile mit den Adressen der Variablen erzeugen lassen. > Wie gesagt: STM32Viewer ist da schon sehr genial, leider sind Arrays nur umständlich möglich.
Rahul D. schrieb: > Raoul D. schrieb: >> Eine serielle Schnittstelle zur Datenübertragung wäre nur >> umständlich zu benutzen, wesentlich einfacher wäre es über ST-Link >> (inkl. SWO). > > Heute ist doch noch gar nicht Freitag. Du bist sicher einer der Gründe, warum dieses Forum in der realen Welt oft als "Arschlochforum" bezeichnet wird.
Purzel H. schrieb: > Visualisierung... erstmal sollte bekannt sein um wie viele Megapixel pro > Sekunde es denn gehen soll. Wer hat von Megapixel gesprochen??? > Da Serial als zu trivial oder so Wo hast Du das jetzt her?
Purzel H. schrieb: > Visualisierung... erstmal sollte bekannt sein um wie viele Megapixel pro > Sekunde es denn gehen soll. Man überträgt Rohdaten, keine Megapixel. Die bildliche Darstellung dieser Rohdaten übernimmt dann der Zielrechner.
Ich habe auch schon serielle Schnittstellen mit 500KBit benutzt. Weiterhin besitzt der Prozessor doch auch USB? Laut https://www.st.com/resource/en/product_training/STM32G4-Peripheral-USB_Full_Speed_Device_interface_USB.pdf sogar USB2, also 480 Mbit/sek. Und damit kommst du nicht klar? Wieviele Gigabytes/sek sollen übertragen werden?
Raoul D. schrieb: > Du bist sicher einer der Gründe, warum dieses Forum in der realen Welt > oft als "Arschlochforum" bezeichnet wird. Für die Antwort hast du aber lange gebraucht. Jetzt wissen wir aber auch, wieso du aus der "realen Welt" hier hergefunden hast... Wenn man deinen ersten Post liest, lässt sich vermuten, dass es sich dabei um einen der typischen Freitagsposts handelt. Es gibt Entwickler, die nicht mit sowas wie Debuggern aufgewachsen sind. Die machen sowas per serieller Schnittstelle (die meisten Arduino-Benutzer sind auch darauf angewiesen). Da Du ja offensichtlich schon damit Erfahrung hattest, hättest du meine Kommentar entweder freundlich beantworten oder einfach überscrollen können. Viel Erfolg noch mit deinem P(r)ojekt.
Rahul D. schrieb: > Da Du ja offensichtlich schon damit Erfahrung hattest, hättest du meine > Kommentar entweder freundlich beantworten oder einfach überscrollen > können. Statt mir zu sagen, was ich hätte tun sollen, hättest Du besser gleich eine konstruktive Antwort gegeben. Aber das scheint Dir ja immer noch nicht möglich zu sein.
Raoul D. schrieb: > Statt mir zu sagen, was ich hätte tun sollen, hättest Du besser gleich > eine konstruktive Antwort gegeben. Aber das scheint Dir ja immer noch > nicht möglich zu sein. Meine mögliche Antwort ("per serieller Schnittstell") hast du ja schon vorweg pauschal abgelehnt.
Etwas ernüchternde Bilanz: * BetterSerialPlotter - bei einem Datenstrom mit einer Spalte läuft es eigentlich ganz gut, allerdings beginnt der Plot immer im letzten Drittel des Fensters, ab und zu Abstürze - bei einem zweispaltigen Datenstrom stürzt es sofort ab. * Teleplot bei hoher Datenrate (921600Bd) werden viele Werte unterschlagen * Serialplot Sehr stabil und schnell, kann nur leider keine xy-Plots. Daher nochmal die Frage: hat jemand noch einen Tipp explizit ergänzt um xy-Plots?
Das Einfachste dürfe sein, die Daten per st-trace oder seriell per picocom zu empfangen und in 'gnuplot' zu "pipen":
1 | picocom -q -b 921600 --imap=lfcrlf /dev/ttyUSB0 | gnuplot |
In der firmware dann den Datenstrom erzeugen:
1 | outln("set title 'ESC'");
|
2 | outln("plot '-' w lines");
|
3 | ... Daten |
4 | outln("e");
|
:
Bearbeitet durch User
Habe das auch mal mit Matlab und der seriellen bei 115k gemacht. Lief gut und die FFT zur Kreuzkorrelation war auf Matlab super einfach in einer Zeile. Habe auf Linux auch ausgeliefert, aber Matlab kostet halt Lizenzen und man kriegt anschliessend dauernd Werbung um Updates zu kaufen.
:
Bearbeitet durch User
Ich werfe nochmal https://github.com/klonyyy/STMViewer in den Ring. Das sollte alles können was der TO will. Gruß Alex
J. V. schrieb: > Habe das auch mal mit Matlab und der seriellen bei 115k gemacht. Lief > gut und die FFT zur Kreuzkorrelation war auf Matlab super einfach in > einer Zeile. Habe auf Linux auch ausgeliefert, aber Matlab kostet halt > Lizenzen und man kriegt anschliessend dauernd Werbung um Updates zu > kaufen. Wenn man die Daten auf dem Rechner hat lässt sich das gleich auch gut mit Python erreichen. Die Performance von einem Matlab Script / Applikation erreicht man damit auch.
Alex E. schrieb: > Ich werfe nochmal > https://github.com/klonyyy/STMViewer > in den Ring. Das sollte alles können was der TO will. Steht schon im Eingangspost, auch wenn ich den Namen nicht ganz richtig hatte ;-) Aber: STMViewer kann das leider (noch) nicht, also, ein ganzes Array schritthaltend darzustellen.
Raoul D. schrieb: > Alex E. schrieb: >> Ich werfe nochmal >> https://github.com/klonyyy/STMViewer >> in den Ring. Das sollte alles können was der TO will. > > Steht schon im Eingangspost, auch wenn ich den Namen nicht ganz richtig > hatte ;-) > > Aber: STMViewer kann das leider (noch) nicht, also, ein ganzes Array > schritthaltend darzustellen. Hast du das auch mit dem TraceViewer probiert. Oder meinst du das du ein Array and Daten hast die du Zeitgleich also als eine Kurve darstellen willst? Ich habe sowas intern über etwas Code gemacht. Array zwischenspeichern und dann auf einen tmp variablen abspielen so das der Trace das senden konnte. Ist leider ein Umweg aber dieses dumpen von Kurven oder Oberflächen ist mir im STM32 Bereich bisher nicht untergekommen. Im Linux, ROS Bereich gibt es da einiges. Das hilft dir aber konkret nicht.
Alex E. schrieb: > Hast du das auch mit dem TraceViewer probiert. Der TraceViewer macht ja auch einen zeitlichen Verlauf der Tracedaten, die auf den TraceChannels kommen. Das ist auch manchmal spannend, aber das ist gerade nicht das Problem ... > Oder meinst du das du ein > Array and Daten hast die du Zeitgleich also als eine Kurve darstellen > willst? Ja, ich möchte eben nicht den Wert eines skalaren Objektes über der Zeit darstellen, sondern eines Arrays (1-dimensionales Objekt). In diesem Fall sind des die Amplituden der DFT-Werte. Also, ein Diagramm mit bspw. 1024 Werten, jeder Wert a_i stellt die Amplitude bei einer Frequenz f_i = (fs / 2) * i / 1024 dar. Und dieses ganze Diagramm wird dann mit einer bestimmten Wiederholrate updated, eben wie man üblicherweise ein Spektrum darstellt, über der Frequenz und nicht über der Zeit. Ein Wasserfalldiagramm braucht es natürlich nicht zu sein.
Sowas habe ich für Bahnkurven so gemacht das die berechnete Kurve in einer 1ms Task auf ein Tracekanal geschrieben wird. Alle 1ms also ein neuer Index des Arrays. Das lässt sich mit trace gut darstellen. Oder plotjuggler nehmen und die Daten als Json über UDP raus blasen.
Raoul D. schrieb: > In diesem Fall sind des die Amplituden der DFT-Werte. Also, ein Diagramm > mit bspw. 1024 Werten, jeder Wert a_i stellt die Amplitude bei einer > Frequenz f_i = (fs / 2) * i / 1024 dar. Und dieses ganze Diagramm wird > dann mit einer bestimmten Wiederholrate updated, eben wie man > üblicherweise ein Spektrum darstellt, über der Frequenz und nicht über > der Zeit. Schnapsidee. Die DFT macht der PC schneller als der µC und die Datenrate bleibt auch gleich. Wie auch immer: Die serielle Verbindung kann eh immer nur Daten hintereinander übertragen, also musst Du Dein Array eben in ein Datentelegramm verpacken. Notfalls mit mit printf() oder als Array mit Pausenzeichen oder oder oder.
:
Bearbeitet durch User
Walter T. schrieb: > Schnapsidee. Die DFT macht der PC schneller als der µC und die Datenrate > bleibt auch gleich. Ach ... auf die Idee bin ich noch gar nicht gekommen ;-) Dann kurzerhand die DFT-Werte wieder zurück übertragen, damit der µC weiterrechnen kann ... Hammer! Walter T. schrieb: > Wie auch immer: Die serielle Verbindung kann eh immer nur Daten > hintereinander übertragen, also musst Du Dein Array eben in ein > Datentelegramm verpacken. Notfalls mit mit printf() oder als Array mit > Pausenzeichen oder oder oder. Klar, besser würde ich 32768 Drähte anschließen, damit ich meine Werte parallel übertragen kann.
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.