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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ...
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
[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.
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.
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.
