Hallo zusammen
Ich habe ein Testgerät gebaut, dass über einen Hall-Sensor gewisse
Magnetfeldwerte misst und diese auf einem EEPROM speichert.
Schliesse ich das Testgerät an den PC an, möchte ich über ein GUI diese
Messdaten aus dem EEPROM direkt in ein .csv File speichern.
Soweit mal die Grundidee.
Ich verwende ein STM32G071 Nucleo Board und arbeite mit der STM32 Cube
IDE. GUI und auch EEPROM Treiber existiert alles schon, das eigentliche
Problem aber ist ein wesentlich grundlegenderer Schritt: Das Erstellen
der .csv Datei. Ich habe mich an einem kleinen Beispielprogramm
versucht, das mit fopen eine einfache Textdatei erstellen und irgendwas
reinschreiben soll:
Allerdings wird beim entsprechenden Pfad kein File erstellt. Back- bzw
Forwardslash beim Pfad schon ausprobiert... Stelle ich mir das zu
einfach vor oder entgeht mir ein wesentlicher Punkt?
Oder hat jemand vielleicht eine andere Idee, wie man das lösen könnte?
Mir ist bewusst, dass sich aus Terminalprogrammen wie Tera Term die
Messdaten in eine Textdatei und anschliessend von da in ein .csv File
extrahieren liessen, das ist auch der Weg, wie es bis anhin
funktioniert. Ich stelle mir aber vor, über mein GUI ein Kommando über
die UART Schnittstelle an meine CPU zu schicken, mit welchem dann direkt
die Messdaten in ein .csv File übertragen werden. Jemand eine Idee, wie
ich .csv Files mit der CubeIDE erstellen kann?
Äh ne - ohne Software auf dem PC geht das nicht. Du kannst mit versuchen
einen USB-Stick zu emulieren, aber selbst da musst Du am PC die Datei
noch rüber ziehen. Autostart auf mobilen Datenträgern ist mittlerweile
meist gesperrt. Und das ist auch gut so.
Du kannst natürlich eine Tastatur emulieren, damit einen Editor starten,
die Daten quasi eintippen und vom Editor auf dem PC speichern lassen.
Das wäre die schrägste Variante.
Ich würde vermutlich eine SD-Karte an den STM anflanschen und die Datei
darauf ablegen. Aber auch da muss man per Hand die SD-Karte umstecken
und die Datei am PC kopieren.
Oder Du machst eine ganz eigene Art von USB-Gerät auf und hast eine
eigene Software auf dem PC, die auf das Anstöpseln eines solchen Geräts
lauert, dann die Daten herüberzieht und ablegt. Das wäre die
schwierigste Variante.
Eros S. schrieb:> Back- bzw Forwardslash beim Pfad schon ausprobiert
Nur als Ergänzung hierzu (dein eigentliches Problem hat ja mein
Vorredner schon beschrieben): gewöhn dir Vorwärtsstriche an. Auch
Windows kapiert die, denn die funktioneren seit MS-DOS 3.x, sie
funktionieren nur nicht in command.com bzw. cmd.exe.
Dein String da oben bedeutet nämlich in C:
1
C:<TAB>emp<TAB>est.txt
Noch zum eigentlichen Problem: wenn der PC sowieso die ganze Zeit
verbunden ist, dann bringe den STM dazu, eine serielle Schnittstelle
über USB zu emulieren und schreibe deine CSV-Datensätze auf diese raus.
Auf dem PC lässt du dann ein stinknormales Terminalprogramm diese alle
mitmeißeln.
Jörg W. schrieb:> Noch zum eigentlichen Problem: wenn der PC sowieso die ganze Zeit> verbunden ist, dann bringe den STM dazu, eine serielle Schnittstelle> über USB zu emulieren und schreibe deine CSV-Datensätze auf diese raus.
Das Problem ist, dass der PC tatsächlich eben NICHT die ganze Zeit
verbunden ist, sonst wäre die Geschichte etwas einfacher. Dann würde ich
es genau so machen.
Frank O. schrieb:> Ich würde vermutlich eine SD-Karte an den STM anflanschen und die Datei> darauf ablegen. Aber auch da muss man per Hand die SD-Karte umstecken> und die Datei am PC kopieren.
Scheint mir auch die sinnvollste Methode, gibt glaube ich auch genug
Youtube Tutorials zur Erstellung von Ordnerstrukturen auf einer SD-Card
mit STM32 CPUs. Dann werde ich mich mal nach einem SD-Card Zusatzboard
umsehen.
Danke an die Beteiligten
Eros S. schrieb:> Ich habe ein Testgerät gebaut, dass über einen Hall-Sensor gewisse> Magnetfeldwerte misst und diese auf einem EEPROM speichert.> Schliesse ich das Testgerät an den PC an, möchte ich über ein GUI diese> Messdaten aus dem EEPROM direkt in ein .csv File speichern.
passt eh schon ganz gut - teile und herrsche.
das klingt so als ob das Speichern der Daten in den EEPROM funktioniert.
am PC erstellt du dir ein kleines Programm, das z.B. über die serielle
Schnittstelle ein Kommando an den STM schickt. der antwortet mit den
Daten, die du dann einfach wohin auch immer speicherst.
Eros S. schrieb:> FILE *demo;> demo = fopen("C:\temp\test.txt", "w");
Wieder einer der ein ganzes Windows auf seinem STM hat...
Respekt.
Du verdrehst da zwei Ding die so gar nichts miteinander zu tun haben.
Eros S. schrieb:> zur Erstellung von Ordnerstrukturen auf einer SD-Card
Die Verzeichnisstruktur ist dein kleinstes Problem ;-), für ein paar
simple Logfiles brauchst du die auch kaum. Die kann man auch flach ohne
große Hierarchie abspeichern.
Du brauchst halt irgendwas an Code, was die SD-Karte ansteuern kann, und
das musst du dann hinter die ganze Posix-Funktionen für
open/close/read/write klemmen, auf denen fopen und Konsorten aufsetzen.
Die werden in der Form, wie du die Bibliotheken benutzt, sehr
wahrscheinlich nur "stubs" sein, die einfach mal nichts machen (damit
sich die Sache überhaupt linken lässt).
Fabrikneue NUCELOs melden sich doch beim Verbinden per USB mit einem
(Windows-) PC auch als Datenträger an.
Das müsste man hier implementieren (USB-Protokollklasse "MSC"?) und dann
"nur" den Zugriff aufs EEPROM als Datenträger umleiten.
Adam P. schrieb:> Eros S. schrieb:>> FILE *demo;>> demo = fopen("C:\temp\test.txt", "w");>> Wieder einer der ein ganzes Windows auf seinem STM hat...> Respekt.
Das ist nicht nötig, per Semihosting funktioniert das schon.
Hier ist das Semihosting für STM32CubeIDE beschrieben:
https://community.st.com/t5/stm32-mcus/how-to-use-semihosting-with-stm32cubeide-and-stm32/ta-p/49742
Beim LPC/MCUExpresso war es noch einfacher, da reichte es ein Häkchen zu
setzen in den Linkereinstellungen.
Einen Haken hat es natürlich in der Anwendung:
- es braucht die Debughardware und den laufenden Debugger (IDE oder GDB)
- die Aufrufe sind blockierend, ohne den Debugger hängt das Programm an
der Stelle. Man kann aber abfragen ob der Debugger angehängt ist.
Von daher ist es für viele Anwendungen sicher besser eine SD Card oder
ein SPI Flash einzubauen.
Andere moeglichkeit waehre ein file mit ZMODEM zu schicken.
TeraTerm kann der automasisch speichern mit der von microcontroller
angegeben filename. Mann bekommt dan waehrend der empfang ein TeraTerm
window "ZMODEM Receive" mit Fortschrittsanzeige.
Patrick aus die Niederlaende
Patrick C. schrieb:> Andere moeglichkeit waehre ein file mit ZMODEM zu schicken.
Hilft aber nichts, wenn der Computer nicht dauerhaft angeschlossen ist.
J. S. schrieb:> Von daher ist es für viele Anwendungen sicher besser eine SD Card oder> ein SPI Flash einzubauen.
Ich hatte für Testzwecke das gleiche Problem wie folgt gelöst:
- Messdaten RAW auf SD Karte schreiben (ohne Dateisystem)
- Daten per USB an PC übertragen
- Kleines C Tool geschrieben das mir aus den RAW Binär Daten eine CSV
zusammenbastelt.
Manchmal ist KISS einfach die beste Lösung.
Adam P. schrieb:> Manchmal ist KISS einfach die beste Lösung.
Naja, eine Implementierung, um überhaupt erst einmal auf eine SD-Karte
zu schreiben (entweder via bitbanging oder über irgendeine
Hardware-Schnittstelle der MCU) brauchst du so oder so. Das ist ja
erstmal der eigentliche Dreh- und Angel-Punkt.
FAT-Implementierungen gibt es doch dann ausreichend, die man obendrauf
setzen kann, bspw. die bekannte von Chan. Das Zeug ist erprobt und
zuverlässig, da würde ich mich nicht noch mit einem weiteren Tool auf
der PC-Seite herumschlagen, um Rohdaten zu konvertieren.
Und es ist kompatibler, die SD Karte kann ohne Aufwand überall gelesen
werden
Bei größeren Controllern mit SDIO/MMC sind auch hohe R/W
Geschwindigkeiten möglich.
Jörg W. schrieb:> Naja, eine Implementierung, um überhaupt erst einmal auf eine SD-Karte> zu schreiben (entweder via bitbanging oder über irgendeine> Hardware-Schnittstelle der MCU) brauchst du so oder so.
Nein, denn die Daten stehen ja bereits im EEPROM.
Eros S. schrieb:> Ich habe ein Testgerät gebaut, dass über einen Hall-Sensor gewisse> Magnetfeldwerte misst und diese auf einem EEPROM speichert.>> Schliesse ich das Testgerät an den PC an, möchte ich über ein GUI diese> Messdaten aus dem EEPROM direkt in ein .csv File speichern.
USB-Seriell die Daten aus dem EEPROM (z.B. als raw Hex kodiert) auf den
PC übertragen und dort in CSV wandeln - oder direkt als CSV kodiert
übertragen und nur abspeichern. Es läuft also auf eine einfache
Terminal-Emulation mit wenigen Kommandos hinaus, z.B. STATUS, READ,
CLEAR, wie bereits von Daniel vorgeschlagen.
Daniel F. schrieb:> das klingt so als ob das Speichern der Daten in den EEPROM funktioniert.> am PC erstellt du dir ein kleines Programm, das z.B. über die serielle> Schnittstelle ein Kommando an den STM schickt. der antwortet mit den> Daten, die du dann einfach wohin auch immer speicherst.
Martin H. schrieb:> Jörg W. schrieb:>> Naja, eine Implementierung, um überhaupt erst einmal auf eine SD-Karte>> zu schreiben (entweder via bitbanging oder über irgendeine>> Hardware-Schnittstelle der MCU) brauchst du so oder so.>> Nein, denn die Daten stehen ja bereits im EEPROM.
Du schreibst über etwas komplett anderes als ich.
J. S. schrieb:> Und es ist kompatibler, die SD Karte kann ohne Aufwand überall gelesen> werden
Ja kann man machen, ich sah bei meiner Anwendung kein Mehrwert für den
zusätzlichen Overhead von einem Dateisystem.
Die Karte ist fest im System verbaut.
Jörg W. schrieb:> da würde ich mich nicht noch mit einem weiteren Tool auf> der PC-Seite herumschlagen, um Rohdaten zu konvertieren.
Und im Laufe der Zeit kommt dann mit Sicherheit das
Punkt-Komma-Komma-Semikolon-Dilemma und das lässt sich flexibler am PC
lösen - BTDT.
Martin H. schrieb:> Und im Laufe der Zeit kommt dann mit Sicherheit das> Punkt-Komma-Komma-Semikolon-Dilemma und das lässt sich...
...mit TAB lösen. Warum mag das kaum jemand?
Bauform B. schrieb:> ...mit TAB lösen. Warum mag das kaum jemand?
Weil das schlecht zu lesen ist, wenn in den Daten selbst Leerzeichen
vorkommen.
Saubere Lösung wäre jedes Datenfeld im csv-String in Anführungszeichen
zu setzen, dann ist man in der Wahl des Trennzeichens völlig frei - es
darf sogar in den Daten selbst vorkommen, und es läßt sich zudem noch
gut lesen, weil man die Datenfelder besser erkennt.
Noch ne Trage an den TO: Läuft Dein gepostetes Progrämmle auf dem STM
oder denm PC? Wenn es auf dem STM läuft kann es so eigentlich nicht
funktionieren.
Die Lösung von Daniel
(Beitrag "Re: Messdaten in csv oder Textdatei schreiben") halte ich für
zielführend. Du bastelst Dir ein Programm für den PC, welches einen
Befehl an den STM sendet, woraufhin der STM den EEPROM ausliest und die
Daten an den PC sendet. Dieser erledigt dann auch das Speichern im
csv-Format.
Flunder schrieb:> Als Trennzeichen : gute Idee
Geht auch, ich habe meist ; bevorzugt.
Ich hatte allerdings Probleme eine SD-Karte an den STM32 anzubinden. Es
stellte sich heraus, dass der Code, den CubeMX 6.7.0 dafür generiert,
einfach nur Grütze ist. Es gab hier im Forum den Tipp mit einem
altehrwürdigen Beispielcode zu starten. Das hat dann funktioniert. Im
Endeffekt sind die Routinen dafür meist sowieso die von ElmChan.
Martin H. schrieb:> Und im Laufe der Zeit kommt dann mit Sicherheit das> Punkt-Komma-Komma-Semikolon-Dilemma und das lässt sich flexibler am PC> lösen - BTDT.
Definitonsproblem...
Was spricht gegen das Semikolon als Feldtrenner?
Wie es aussieht will der TO ja nur Zahlen und keine Texte speichern.
Wenn er in C Fließkommazahlen ausgibt, werden die Nachkommastelle mit
"." abgetrennt.
Viele machen so eine Auswertung ja mit Excel: Da kann man den Import
entsprechend konfigurieren.
Rahul D. schrieb:> Definitonsproblem...> Was spricht gegen das Semikolon als Feldtrenner?> Wie es aussieht will der TO ja nur Zahlen und keine Texte speichern.> Wenn er in C Fließkommazahlen ausgibt, werden die Nachkommastelle mit> "." abgetrennt.
Ich habe auch gern das Semikolon als Feldtrenner benutzt, weil es in
Zahlendarstellungen nicht und in Texten (falls man auch Textfelder
speichern muß) selten vorkommt. Wenn man das Format selber bestimmen
kann, dann dies | ein gutes Trennzeichen, da es in normalen Texten und
Zahlen ncht vorkommt. Ich benutze das gern um z.B. bei serieller
Übertragung die einzelnen Stringanteile abzutrennen.
Als Zahlenschreibweise hat sich der Punkt als Dezimaltrenner bewährt.
Die meisten Programmiersprachen arbeiten damit als Dezimaltrennzeichen
und man baucht so die Landeseinstellungen beim Schreiben in die bzw.
Lesen aus der Datei nicht beachten. Wenn man Daten global austauschen
muß ist das ein großer Vorteil. Die Konvertierung in landespezifische
Darstellungen erfolgt dann erst bei einer eventuellen visuellen Ausgabe.
Man könnte fast den Eindruck gewinnen, man diskutiert gar nicht mehr des
TOs Problem. Der TO hat sich ja auch inzw. entfernt ob des inkompetenten
Foren-Volks ...
Vielen Dank für die vielen Antworten und Ideen.
Ich habe über Visual Studio ein kleines GUI entworfen, das über die UART
Schnittstelle meines Nucleo Boards mit dem STM32 kommuniziert.
Tatsächlich weiss ich auch nicht, wieso ich da nicht selbst drauf
gekommen bin, aber die Idee, die Daten vom EEPROM per UART zu übertragen
und dann mit Visual Studio eventuell in eine .csv oder Textdatei
schreiben gefällt mir.
Mal sehen ob Visual Studio diesbezüglich was kann, kenne mich mit dem
Tool noch nicht so gut aus. Werde mich morgen mal wieder melden und
schauen, ob ich da was hinbekomme.
Eros S. schrieb:>> Ich würde vermutlich eine SD-Karte an den STM anflanschen und die Datei>> darauf ablegen. Aber auch da muss man per Hand die SD-Karte umstecken>> und die Datei am PC kopieren.>> Scheint mir auch die sinnvollste Methode, gibt glaube ich auch genug> Youtube Tutorials zur Erstellung von Ordnerstrukturen auf einer SD-Card> mit STM32 CPUs.
Datenlogging auf SD-Kartem habe ich mit Arduino (AT328) gebaut, dafür
gibt es fertige Klassen ("library"). Übrigens ohne youtube! Wird sich
auch für STM finden lassen.
Ich habe Ärger gefangen, dass viele Karten nach einer Weile schreiben
nicht mehr zügig antworten und die fertige Software damit nicht umgehen
kann - musst Du unbedingt testen. Ich konnte ein paar 2Gb-Karten von ATP
und Xmore bekommen, die dieses Problem nicht haben.
Ich habe Ärger mit dem Dezimalpunkt gefangen, den meine deutsche
Tabellenkalkulation nicht mag. Das habe ich tatsächlich selbst
gebastelt, meine Variablen zu zerlegen und als neuen String mit Komma
zur Karte zu schreiben.
> Dann werde ich mich mal nach einem SD-Card Zusatzboard umsehen.
Gibt es beim Chinesen billig aus dem Umfeld Arduino. Dein STM hat 3,3V,
dann muß auf dem µSD-Board der AMS1117-33 runter und überbrückt werden.
Der 74LVC125 ist auch über, aber sollte nicht stören.
Oder es muß nicht MIKRO-SD sein, die 'große' lässt sich besser anfassen.
Hans schrieb:> Rahul D. schrieb:>> Definitonsproblem...>> Was spricht gegen das Semikolon als Feldtrenner?>> Wie es aussieht will der TO ja nur Zahlen und keine Texte speichern.>> Wenn er in C Fließkommazahlen ausgibt, werden die Nachkommastelle mit>> "." abgetrennt.> Ich habe auch gern das Semikolon als Feldtrenner benutzt, weil es in> Zahlendarstellungen nicht und in Texten (falls man auch Textfelder> speichern muß) selten vorkommt. Wenn man das Format selber bestimmen> kann, dann dies | ein gutes Trennzeichen, da es in normalen Texten und> Zahlen ncht vorkommt. Ich benutze das gern um z.B. bei serieller> Übertragung die einzelnen Stringanteile abzutrennen.> Als Zahlenschreibweise hat sich der Punkt als Dezimaltrenner bewährt.> Die meisten Programmiersprachen arbeiten damit als Dezimaltrennzeichen> und man baucht so die Landeseinstellungen beim Schreiben in die bzw.> Lesen aus der Datei nicht beachten. Wenn man Daten global austauschen> muß ist das ein großer Vorteil. Die Konvertierung in landespezifische> Darstellungen erfolgt dann erst bei einer eventuellen visuellen Ausgabe.
Dann kann man die Daten auch gleich per XML serialisieren...
Das versteht auch Visual Studio (inklusive Library).
Erzeugt halt etwas Overhead; ist aber auch universell.
Wieviele Daten sind es denn. Gegenüber SD-Karte ist RS232 langsam.
Selbst dann, wenn man die SD-Karte nur mit einer Datenleitung und 25 MHz
ansprechen kann.
Rahul D. schrieb:> Dann kann man die Daten auch gleich per XML serialisieren...> Das versteht auch Visual Studio (inklusive Library).
Das versteht auch csv!
XML ist an dieser Stelle völlig oversized und erzeugt am Ende nur
unnötigen Ballast. CSV kann von allen Tabellenkalkulationen problemlos
eingelesen werden, was eine Auswertung und Visualisierung vereinfacht.
Das Einlesen von csv läßt sich i.d.R. viel einfacher umsetzen und ist
mit jeder beliebigen Programmiersprache relativ einfach umzusetzen. XML
ohne ein entsprechendes Framework/Library grenzt da schon eher an
Harikiri.
Hans schrieb:> Das versteht auch csv!> XML ist an dieser Stelle völlig oversized
Ich würde als Alternative json nutzen.
Sehr einfach erstellbar, Dezimalpunkt und Trennzeichen sind eindeutig.
PC seitig alles vorhanden.
Ich nutze zum Austausch von Messdaten fast nur noch json.
Ein Nachteil haben json umd xml zu csv: Es muss in sich abgeschlossen
sein. Man kann keine Daten einfach an ein erstelltes File anhaengen. das
geht am einfachstel in csv/tsv.
Hans schrieb:> XML ist an dieser Stelle völlig oversized und erzeugt am Ende nur> unnötigen Ballast.
Ironie ist nicht so dein Ding, oder?
Ich bezog mich auf die Verwendung von "|" als Trennzeichen: überflüssig.
Was nur bei der Übertragung von Texten notwendig wäre.
Und selbst da könnte ein Nutzer auf die tolle Idee kommen, das Zeichen
im Text zu benutzen, weil es ihm gerade passt.
Ähnlich wie bei SQL-Injections....
Man braucht das Trennzeichen nicht durch ein ganz anderes zu ersetzen,
wenn man den Sonderfall "ein Semikolon könnte in der Übertragung auch in
dem Daten vorkommen." ausklammert.
Ansonsten hast du Recht.
Manfred P. schrieb:> Ich habe Ärger mit dem Dezimalpunkt gefangen, den meine deutsche> Tabellenkalkulation nicht mag.
Du könntest deine "deutsche Tabellenkalkulation" auf Punkt als Dezimal
Trennzeichen einstellen, also unabhängig von der Ländereinstellung
deines Betriebssystems. Dann hätte der Ärger ein Ende.
Adam P. schrieb:> Manchmal ist KISS einfach die beste Lösung.
Das war bisher der einzige (in meinen Augen) sinnvolle Vorschlag.
Zum Speichermedium: Wenn das Eeprom für die Menge der Daten reicht, dann
kann man es nehmen. Man muss sich aber im klaren sein, dass es eben nur
eine gewisse Anzahl von Schreibzyklen gibt. Da ist die SD-Karte im
Vorteil wenn man eine aus dem professionellen Bereich nimmt.
Die Daten im Mikrocontroller schon vorzuformatieren ist ziemlich
unsinnig. Auch noch gar als ASCII. Wozu? Der PC hat dafür einfach die
besseren Voraussetzungen. "Unendlich" Rechenleistung und ist dann bei
Änderungen viel besser wartbar und das System ist flexibel, egal welches
Format dann am Ende im PC steht. Der Mikrocontroller muss nie wieder
geändert werden. Im einfachsten Fall sendet man ein Speicherabbild des
Eeproms/SD-Karte zum PC und der dekodiert das dann. Ein festes
Binärformat im Eeprom/SD-Karte und dann die Werte binär zu übertragen
ohne diese nochmal umzuformatieren geht ja auch.
Aber schon im Mikrocontroller ein was auch immer für geartetes
ASCII-Format? Wozu? Welchen Vorteil hat das?
900ss schrieb:> Die Daten im Mikrocontroller schon vorzuformatieren ist ziemlich> unsinnig.
Bei einer SD-Karte sehe ich das nicht so: passend formatiert, kann man
sie ohne weitere (eigene) Programme am PC direkt benutzen.
Bezüglich der Haltbarkeit: wesentlicher Vorteil der SD-Karte wäre an
dieser Stelle die Wechselbarkeit. Inwiefern ein EEPROM mit einer Million
garantierter Schreibzyklen (was ich so auf Anhieb als typischen Wert
finde) genügt, muss der TE für sich halt durchrechnen. Ist ja auch nicht
gerade wenig. Man muss natürlich gucken, dass man ihn "reihum"
beschreibt und nicht nur immer wieder den ersten Teil von vorn nach
hinten.
900ss schrieb:> Man muss sich aber im klaren sein, dass es eben nur> eine gewisse Anzahl von Schreibzyklen gibt. Da ist die SD-Karte im> Vorteil wenn man eine aus dem professionellen Bereich nimmt.
Auch eine SD-Karte hat das Problem mit den Schreibzyklen. Um diese
Thematik vor dem Nutzer zu verstecken, braucht der Kartencontroller
gelegentlich Zeit für sich, so dass ein ausreichender Schreibpuffer
zwischen Anwendung und Controller zur Verfügung stehen muss, um diese
Zeiten der "Unpässlichkeit" zu überbrücken.
Rainer W. schrieb:> Auch eine SD-Karte hat das Problem mit den Schreibzyklen.
Ja wie jeder Flash basierte Speicher. Professionelle SD-Karten haben ein
eingebautes Management um den Speicher zu "entlasten". Und ja, Pausen
wird man ggfs. handeln müssen.
Ist hier aber nicht so das Thema. Darf der TO nur nicht vergessen.
Jörg W. schrieb:> Bei einer SD-Karte sehe ich das nicht so: passend formatiert, kann man> sie ohne weitere (eigene) Programme am PC direkt benutzen.
Ja schon. Es stimmt, es ist manchmal "schön", einfach den Texteditor zu
nehmen und in die Daten zu schauen. Wenn der uc genug Kapazitäten hat,
dann kann man natürlich ein Filesystem und die ASCII Formatierung
vornehmen. Hängt halt vom Einzelfall ab. Trotzdem ist es anders einfach
flexibler, einfacher wartbar weil das meiste auf dem PC stattfindet und
nur das notwendige auf dem uc.
Man könnte Browser Serial nutzen um einen String zu senden z.B.
"xxxdownloaddataxxx" damit die Daten gesendet werden, liest die
gesendeten Daten in eine Variable und gibt diese als z.B. "Json" oder
als CSV mit direktdownload aus.
Mit Json hätte man ein Objekt und könnte mit Einzeilern den Download als
XML,CSV,txt, binär anbieten, bzw auch gleich eine Vorschau als Graph
anzeigen.
Thread beobachten
Seitenaufteilung abschalten