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.
Klaus H. schrieb:> Ich nutze zum Austausch von Messdaten fast nur noch json.
...und hoffentlich JSONschema (https://json-schema.org/) oder so etwas.
> 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.
Natürlich kann man JSON-Daten auch streamen.
Sheeva P. schrieb:> ...und hoffentlich JSONschema (https://json-schema.org/) oder so etwas
Auch, oft aber "so etwas" durch Quick-N-Dirty, wenn das nur für mich
gedacht ist.
>Natürlich kann man JSON-Daten auch streamen.
Danke für die Info. Mir gings um das nachträgliche Anhängen an ein File.
Aber vor allem hab ich seid Einsatz von json statt csv keine Probleme
mehr mit Trennzeichen, verschiedenen Ländereinstellungen vom OS, Excel,
usw.
Rainer W. 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.
Natürlich musste wieder eine dusselige Idee kommen.
Ich werde ganz sicher nicht Einstellungen verdrehen, um eine komische
Applikation nutzen zu können und mir damit Probleme bei vielen anderen
zu fangen.
Ich habe eine Software ohne Zugriff, für die habe ich mir auf dem PC
eine Konvertierung geschrieben, unkomfortabel. Bei Anwendungen, die ich
selbst in der Hand habe, schreibt der µC direkt einlesbare Formate.
Manfred P. schrieb:> Ich werde ganz sicher nicht Einstellungen verdrehen, um eine komische> Applikation nutzen zu können und mir damit Probleme bei vielen anderen> zu fangen.
Brauchst du auch nicht dauerhaft machen. Das wäre für die einfache
Methode notwendig (CSV-Datei anklicken, und sie wird in deiner
Tabellenverarbeitung richtig geöffnet).
Etwas aufwändiger ist es, die Datei zu importieren, nachdem du deine
Tabellenverarbeitung geöffnet hast.
Die Tabellenverarbeitungsprogramme, die ich kenne, öffnen dann einen
Import-Dialog, in dem man Parameter- und Dezimaltrennzeichen setzen
kann.
Oder man hält sich halt nicht an den CSV-"Standard" und tauscht die
Zeichen vor der Übertragung aus.
Das Problem der Dezimaltrenner wirst du immer haben, wenn du es einfach
haben willst.
Sheeva P. schrieb:> XML? Mögen tausend Kamelflöhe Dein Gesäß heimsuchen! :-)
Lies einfach meinen späteren Post!
Klaus H. schrieb:> Ich würde als Alternative json nutzen.> Sehr einfach erstellbar, Dezimalpunkt und Trennzeichen sind eindeutig.
Es kommt halt darauf an, was der TO will. Wenn er immer nur einen
Datensatz überträgt, kann man das natürlich auch mit JSON machen. Wenn
es allerdings immer mehrere Datensätze sind, dann schleppt man halt auch
bei JSON relativ viel Overhead mit, den man eigentlich nicht braucht.
Zudem läßt sich JSON auch nicht so einfach parsen, wenn man kein
passendes Framework/Lib dazu hat. Versuche einfach mal eine komplexe
XML- oder JSON-Datei mit einfachen C oder auch Pascal zu parsen. Es geht
schon, aber der Aufwand ist recht hoch, vor allem dann, wenn die Anzahl
der Datensätze variabel ist. Mit CSV geht das vergleichsweise einfach.
Rahul D. schrieb:> Ich bezog mich auf die Verwendung von "|" als Trennzeichen: überflüssig.
Nö das Zeichen hat sich seit gut 25 Jahren in einem Programm, das seit
25 Jahren in einem Konzern weltweit angewendet wird, bewährt. Man wollte
das Programm vor 10 Jahren durch eines mit einer modernen
Programmiersprache, meins ist mit Delphi geschrieben, ersetzen und dabei
sollte die Datenspeicherung auch gleich über XML erfolgen - das ist ja
so toll. Man hat viel Geld in die Hand genommen und 2 Projekte
(Versuche) gestartet. Beide wurden von jungdynamischen Programmierern,
die sich generell nichts sagen ließen, nach insgesamt 8 Jahren des
Versuchs komplett an die Wand gefahren und eingestellt. Ich bin nun seit
gut 2 Jahren im Ruhestand und man benutzt mein Programm immer noch, was
Neues ist noch lange nicht in Sicht. Ganz offensichtlich habe ich mit
meinem Konzept nicht so viel falsch gemacht.
Rahul D. schrieb:> Und selbst da könnte ein Nutzer auf die tolle Idee kommen, das Zeichen> im Text zu benutzen, weil es ihm gerade passt.
Was meinst Du wohl warum ich schrieb, daß man die (alle) Datenfelder in
Anführungszeichen einschließen sollte? Dann ist es völlig Rille was im
Datenfeld selbst steht. Ich meine Excel macht das beim CSV-Export sogar
automatisch, wenn das Trennzeichen im Datenfeld enthalten ist. Das gibt
dann so schöne CSV-Dateien, wo ein Teil der Felder, nämlich nur die die
das Trennzeichen enthalten, in Anführungszeichen steht. Diese Dateien
lassen sich "besonders gut" lesen. Kann aber auch sein das ich es bei
einem anderen Programm so gesehen habe.
Hans schrieb:> Rahul D. schrieb:>> Und selbst da könnte ein Nutzer auf die tolle Idee kommen, das Zeichen>> im Text zu benutzen, weil es ihm gerade passt.> Was meinst Du wohl warum ich schrieb, daß man die (alle) Datenfelder in> Anführungszeichen einschließen sollte? Dann ist es völlig Rille was im> Datenfeld selbst steht. Ich meine Excel macht das beim CSV-Export sogar> automatisch, wenn das Trennzeichen im Datenfeld enthalten ist. Das gibt> dann so schöne CSV-Dateien, wo ein Teil der Felder, nämlich nur die die> das Trennzeichen enthalten, in Anführungszeichen steht. Diese Dateien> lassen sich "besonders gut" lesen. Kann aber auch sein das ich es bei> einem anderen Programm so gesehen habe.
Wenn man nur Yahlen übertragen will, ist es überflüssig, ein anderes
Trennzeichen als das Semikolon zu verwenden.
Hans schrieb:> Ganz offensichtlich habe ich mit> meinem Konzept nicht so viel falsch gemacht.
Hab ich irgendwas anderes behauptet?
[OT]
Manche Forenteilnehmer sehen in jeder Kritik oder Ironie einen
persönlichen Angriff. Man kann sich auch das Leben unnötig schwer
machen.
[/OT]
Klaus H. schrieb:> Aber vor allem hab ich seid Einsatz von json statt csv keine Probleme> mehr mit Trennzeichen, verschiedenen Ländereinstellungen vom OS, Excel,> usw.
Das umgeht man eigentlich recht einfach, wenn man die Daten erst mal mit
Punkt als Dezimaltrenner abspeichert und erst bei der Visualisierung im
landesspezifischen Format formatiert. Das war auch genau ein Punkt bei
meinem Programm, welches ich im letzten Post erwähnt habe. Selbiges
wurde und wird weltweit eingesetzt. Da der Datenaustausch gewährleistet
sein mußte habe ich mich halt dafür entschieden den Dezimalpunkt zu
benutzen, also den Dezimaltrenner den jede mir bekannte
Programmiersprache intern benutzt. Die Landeseinstellungen wurden erst
angezogen wenn die Daten visualisiert wurden, also Anzeige auf dem
Bildschirm bzw. Ausdruck. Das hat immer funktioniert.
Hans schrieb:> Ich meine Excel macht das beim CSV-Export sogar> automatisch, wenn das Trennzeichen im Datenfeld enthalten ist.
Das ja. Allgemein macht Excel sehr vieles "automatisch". Und deshalb
sehr oft auch was falsch. Deswegen ist es Wahnsinn, CSV einfach mit
Excel zu öffnen. Da kommt fast immer an irgendeiner Stelle Mist raus.
Die konfigurierbare Import-Funktion ist schon deutlich besser (wenn
korrekt konfiguriert natürlich), aber auch weit davon entfernt, alles
richtig zu machen. Insbesondere gibt es keine Möglichkeit, zu
konfigurieren, wie das Quotezeichen selber innerhalb von Quotes zu
behandeln ist (bzw. eigentlich: vom Ersteller der CSV behandelt wurde).
Rahul D. schrieb:> [OT]> Manche Forenteilnehmer sehen in jeder Kritik oder Ironie einen> persönlichen Angriff. Man kann sich auch das Leben unnötig schwer> machen.> [/OT]
Wo habe ich das denn als Angriff gesehen?
Ich habe lediglich geschrieben wie ich es seit vielen Jahren halte, weil
es sich so wie beschrieben ganz offensichtlich bewährt hat. Glaube mir
ich mußte Anfangs auch erst mal viele bittere Pillen schlucken, bis ich
die passenden Formate gefunden habe, die zum einen flexibel genug waren
und zugleich einen (weltweiten) Datenaustausch ermöglichten. Zudem
sollten die Files noch möglichst gut lesbar sein. Der Dezimaltrenner war
dabei noch das geringste Problem.
Ob S. schrieb:> Insbesondere gibt es keine Möglichkeit, zu> konfigurieren, wie das Quotezeichen selber innerhalb von Quotes zu> behandeln ist (bzw. eigentlich: vom Ersteller der CSV behandelt wurde)
Da hast Du natürlich recht. 100% bekommt man das natürlich nie hin, weil
es immer wieder Zeichenkombinationen geben kann, die man nicht
vorhersieht.
Wenn konsequent für jedes Feld gequotet wird, dann hat man allerdings
eine relativ gute Chance das Ganze zu umschiffen:
* jeder Datensatz beginnt und endet dann mit einem Quotezeichen (welches
Zeichen zum Quoten genutzt wird ist hierbei egal). Also löscht man das
erste und letzte Zeichen des Datensatzes weg
* Zwischen den Datensätzen steht immer die Kombination
Quotezeichen-Trennzeichen-Quotezeichen. Das diese Kombination in einem
Datenfeld vorkommt ist eher unwahrscheinlich. Diese Kombi ersetzt man
nun durch ein Zeichen, welches mit großer Wahrscheinlichkeit auch nicht
in den Datenfeldern vorkommen wird. Ich benutze da gern das
ASCII-Zeichen 255. Es geht auch jedes andere Zeichen, welches nicht
standardmäßig auf der Tastatur vorhanden ist.
* Nun kann der Datensatz problemlos am Trennzeichen zerlegt werden. Die
meisten Programmiersprachen bieten eine Funktion, die die Zerlegung an
einem Trennzeichen einfach ermöglicht. Wenn die verwendete
Programmiersprache die Zerlegung des Strings an Hand eines Teilstrings
ermöglicht, dann kann man natürlich auf die Ersetzung (Punkt 2) auch
verzichten.
Das Verfahren hört sich auf den ersten Blick kompliziert an,
funktioniert aber recht gut. Hängt natürlich auch ein bischen von der
Programmiersprache ab, was die so für Stringbearbeitung bietet. Mit dem
von mir meist verwendeten Delphi funktioniert das recht gut.
Ist halt nur ein Vorschlag. Jeder kann das handhaben wie er mag. Am Ende
steht das Ziel und wie man da hin kommt ist erst mal zweitrangig.
Rahul D. schrieb:> Wer sich verteidigt, sieht sich angegriffen.
Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.
Hans schrieb:> Wer im Glashaus sitzt, sollte nicht mit Steinen werfen.
Mach ich gerne. Vor allem, wenn man mich nicht versteht.
Offensichtlich drücke ich mich für einige zu kompliziert aus.
Patrick C. schrieb:> Andere moeglichkeit waehre ein file mit ZMODEM zu schicken.> TeraTerm kann der automasisch speichern mit der von> microcontroller angegeben filename.
Zusätzlich noch eine USB-Tastatur emulieren, die beim Anstecken an den
PC TeraTerm startet und die gewünschte vollautomatische Lösung wäre
komplett. Zumindest wenn am PC TeraTerm im passenden Pfad installiert
ist.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten