Ich habe ein kleines Projekt gestartet, und entstanden ist das kleine Tool USM der Universal Serial Monitor. Es dient dazu die Daten eines Mikrocontrollers auszulesen und anzuzeigen. Eigentlich wollte ich nur meine rudimentären Python Kenntnisse etwas verbessern und dabei ist dieses kleine Tool entstanden.
Vielleicht hat jemand noch Ideen, was man noch hinzufügen kann ....
Loggingfunktion, Zeilenende/Newline-Erkennung (nur CR, nur LF,
CR/LF), HEX- BIN- ASCII-Darstellung, Sendefunktion evtl. zusätzlich mit
Festtexten...
An der Loggingfunktion bin ich tatsächlich gerade dran. Ist aber nicht so einfach .... Sendefunktion ist eine gute Idee, schreib ich auf die Todo-Liste. Über die HEX-, BIN- ASCII Darstellung muss ich noch mal nachdenken.
Sendefunktion ist eine gute Idee, schreib ich auf die Todo-Liste.
Musst dir nur Gedanken machen, wie du die non-ASCII-Zeichen hinbekommst.
Die werden ja auch manchmal gebraucht (STX, ETX u.a.).
Nach etwas nachdenken, glaube ich, die Übertragung mit Steuerzeichen sollte unbedingt mit rein. Ich werde das in meine Todo-Liste aufnehmen. Zur Zeit kämpfe ich aber noch mit dem loggen. Aktuell baue ich beim beheben eines Bugs gefühlt drei neue ein .....
Ich habe den Python Quellcode ganz normal in eine EXE umgewandelt, damit
das Programm direkt ausführbar ist. Ist das falsch?
Nö ist es nicht unbedingt, EXE ist der Standard unter Windows. Es ruft halt die Bedenkenträger auf den Plan (s.u.), aber mehr auch nicht.
F. P. schrieb im Beitrag #8100137:
Ein Python-Programm als EXE-Datei? Das soll "universal" sein? Eher
Malware, also Vorsicht!
Allerdings sperrst Du mit dem Compilieren des Pythonscriptes die Nutzer anderer OS (Mac, Linux, BSD, ...) erst mal aus. Die müßten dann erst mal eine VM oder Wine bemühen um das Programm ans Laufen zu bekommen. Mit einem einfachen Pythonscript wäre das einfacher, da die Leute die Dein Prog interessiert vermutlich Python auf ihrem System installiert haben.
Die Leute die Interesse an Deinem Programm haben machen eher konstruktive Vorschläge, so wie der Niklas und der Helmut.
Wenn Du Dein Programm als Pythoncode zur Verfügung stellst, wirst Du halt noch mehr Leute ansprechen und der eine oder andere wird dann vielleicht sogar aktiv daran mit arbeiten. Am Ende ist es aber Deine Entscheidung, wie Du das Programm veröffentlichst.
Nach dem langen Wochenende gibt es jetzt eine neue Version von meinem kleinen Tool USM dem Universal Serial Monitor. Die aktuelle Version ist die v0.4.4.
Die Daten und der Graph können jetzt abgespeichert werden.
Aber .txt Format schreibe ich auf meine Todo-Liste ....
Da man csv's oftmals mit Tabellenkalkulationen weiter verarbeitet, wären einige Anpassungen im csv-Format sinnvoll. Schick wäre es, wenn man diese Anpassungen wählbar machen könnte
Beim Speichern des csv-Files den Dezimal- und Datentrenner frei wählbar machen. So wie Dein csv aktuell ist, werden die Fließkommazahlen als reiner Text von einer Tabellenkalkulation eingelesen, sofern diese auf deutsch eingestellt ist. Im deutschsprachigen Raum ist es besser den Dezimaltrenner auf "," und den Feldtrenner auf ";" einzustellen, dann wird von der Tabellenkalkulation alles korrekt erkannt (gerade mit Libreoffice auf dem Mac getestet).
Eine weitere Sache wäre, daß man bei Bedarf die Feldwerte in Hochkommata setzen kann, also so "1.62V","2011". Das braucht man, wenn der Feldwert den Feldtrenner als Zeichen enthält. Auch das Feature mit den Hochkommata wählbar machen.
Ein weiterer Stolperstein beim Auswerten mit der Tabellenkalkulation ist im ersten Feld die am Zahlenwert angehängte Einheit. Auch diese führt dazu, daß dies nicht als Zahl erkannt wird, was die Auswertung erschwert. Hier mal darüber nachdenken ob hier ein Extrafeld für die Einheit nicht besser wäre.
Schön wären auch ein oder zwei Headerzeilen, die den Inhalt der Datei erklären. In der ersten Zeile könnte eine Beschreibung stehen z.B.
1
Spannung,Digits
und in der zweiten Zeile die Einheiten z.B.
1
V,
.
Das sind nur Vorschläge was man an dieser Stelle so machen könnte. Denke einfach mal darüber nach und probiere auch mal aus was beim Einlesen in eine Tabellenkalkulation heraus kommt. Was da am End herauskommt hängt auch ein bischen von der Tabellenkalkulation ab also ruhig mehrere ausprobieren wenn Du die Möglichkeit hast.
Frage zum Logging: wenn ich kein csv haben möchte, sondern nur die
nativen Strings als .txt, geht das auch?
Dann benenne die Datei einfach in .txt um. Wenn der Feldtrenner stört dann diesen mit einem Editor Deiner Wahl per "Ersetzen" durch ein Leerzeichen ersetzen.
Eine Frage sei noch erlaubt, wozu soll das native Textformat gut sein? Das erschließt sich mir nicht wirklich.
Eine Frage sei noch erlaubt, wozu soll das native Textformat gut sein?
Das erschließt sich mir nicht wirklich.
Das ist dann sinnvoll, wenn ich den Output einer seriellen Schnittstelle monitoren möchte, ohne mir grosse Gedanke zu machen, welche Zeichen da vorkommen. Wenn du z.B. sowas hast (aus meinem aktuellen Projekt)
Eine weitere Sache wäre, daß man bei Bedarf die Feldwerte in
Hochkommata setzen kann, also so "1.62V","2011". Das braucht man, wenn
der Feldwert den Feldtrenner als Zeichen enthält. Auch das Feature mit
den Hochkommata wählbar machen.
Ein weiterer Stolperstein beim Auswerten mit der Tabellenkalkulation ist
im ersten Feld die am Zahlenwert angehängte Einheit. Auch diese führt
Die Daten im linken Fenster (Empfangene Daten) sind ja die Rohdaten, wie sie vom Mikrocontroller kommen. Wenn man das "V" nicht möchte, muss man das einfach im Programm des Controllers weglassen. Ich habe jetzt noch mal verschiedene Excel Versionen getestet, bei der einen Excel-Version werden die Daten komplett in eine Spalte eingelesen und bei der anderen Version geht ein Fenster auf, bei der man bestimmen kann was der Trenner zwischen den Daten ist. Wenn man bei der Datendatei das .csv durch ein .txt ändert scheinen alle Excel-Versionen dieses Fenster zu öffnen und die Daten werden dann problemlos in verschiedene Spalten importiert. Ich weiß aber noch nicht, ob das an der Excel-Version generell oder an den Einstellungen liegt. Ich überlege schon, ganz auf das .csv Format zu verzichten und nur .txt ermögliche ....
Bitte beantworte die Frage nach dem Quellcode. Wenn Du keinen veröffentlichen möchtest, werde ich den Thread nach "Mikrocontroller und Digitale Elektronik" verschieben.
Dieses Unterforum hat den Untertitel:
----- schnipp -----
Hier könnt ihr Projekte, Schaltungen oder Codeschnipsel vorstellen. Projekte bitte nur mit Code oder Schaltplan posten (falls ihr nur Fotos vorstellen möchtet, bitte in "Zeigt her eure Kunstwerke"). Bitte hier keine Fragen posten.
----- schnapp -----
Bitte beantworte die Frage nach dem Quellcode. Wenn Du keinen
veröffentlichen möchtest, werde ich den Thread nach "Mikrocontroller und
Digitale Elektronik" verschieben.
Dieses Unterforum hat den Untertitel:
----- schnipp -----
Hier könnt ihr Projekte, Schaltungen oder Codeschnipsel vorstellen.
Projekte bitte nur mit Code oder Schaltplan posten (falls ihr nur Fotos
vorstellen möchtet, bitte in "Zeigt her eure Kunstwerke"). Bitte hier
keine Fragen posten.
----- schnapp -----
Der Code fehlt aber bisher.
Mit dem Quellcode bin ich mir noch nicht sicher. Also verschiebe den Thread bitte in die andere Kategorie. Danke für den Hinweis!
Das besondere Deines Programms scheint ja die Darstellung von Graphen aus den Daten zu sein, die über eine serielle Schnittstelle gesendet werden. Für alles andere gibt es ja schon hunderte Terminal-Programme, z.T. schon in die IDEs eingebaut.
Wenn es also um die grafische Darstellung von Live-Daten geht, würde ich mich genau darauf konzentrieren und es wirklich universell verwendbar machen. D.h.
Die Schnittstelle sollte weiterhin und gleichzeitig auch für normale Debug-Ausgaben nutzbar sein, d.h. Daten für die Grafen am besten mit einer Preambel (z.B. USM) starten.
Anzahl, Art und Darstellung der Daten sollte ebenfalls über die Schnittstelle konfigurierbar sein. (z.B. Spannung und Strom gleichzeitig, blau und rot eingefärbt, Einheiten V und mA) Um den sendenden Controller zu entlasten, könnte man auch die Skalierung konfigurieren, und dann nur noch Hex-Digits senden.
Bisher gibt es nur yt-Diagramme. Man könnte weitere hinzunehmen (xy, Polardarstellung, Zeitmessung, Statistik, ...)
Die Diagramme sollten sich bzgl. der gesendeten Werte automatisch anpassen, oder sich vorab über die Schnittstelle fest konfigurieren lassen. Die jetzige Lösung über Einstellungen in Deinem Programm ist das unflexibelste, weil man so vorab wissen muss, was für Daten für wie lange kommen. Einstellungen im Programm sind sinnvoll, wenn man nur einen Ausschnitt aus den Empfangenen Daten sehen will (wie ggf. an einem Speicher-Oszilloskop)
Die Ausgaben vom Controller könnten dann z.B. so aussehen
1
Bordinitialisierung
2
usm#0 init type=yt, unit="V", color=blue
3
usm#1 init type=yt, unit="mA", color=red
4
Firmware Version 0.3.9
5
usm#0 1.35
6
usm#1 80.7
7
usm#0 1.33
8
usm#0 1.28
9
usm#0 1.08
10
usm#1 43.3
11
Warning: Lower level reached!
12
usm#0 0.97
13
usm#0 0.83
Man kann beliebig weitere Kurven hinzutun, und man könnte für eine bessere Übersicht im Debug-Fenster auch die USM-Zeilen herausfiltern und gar nicht erst anzeigen. Die Zeit fürs yt-Diagramm ergibt sich automatisch aus der Empfangszeit. Möchte man das nicht und den Zeitspempel jeweils als Datum mitsenden, könnte man eine andere Diagrammart mit "recorded time", z.B. yrt erfinden.
Vielleicht wäre es dann noch sinnvoll, über die Verwendung einer Open-Source-Lizenz nachzudenken, oder ein User-Interface (nicht nur für Debugging) über einen Webserver bereitzustellen.
screen.jpg
(380 KB)
