Da es in einem anderen Thread intresse an dem Programm gibt mach ich hier mal einen neuen auf. "Serial-IO-Manager is a simple program to send and receive data from a serial interface. The GUI is designed like a chat window with a transmitter/receiver textfield and a command line to send characters and integer values." http://sourceforge.net/projects/serial-io/ Wünsche und sonstige Vorschläge sind erwünscht und willkommen.
Hallo Wilfried, wie im anderen Thread schon angekündigt hätte ich ein paar Erweiterungsvorschläge: 1. Ablegen einer/mehrerer "Sendesequenz(en)" (ein oder auch mehrere Bytes pro Sequenz) und Senden der Sequenz auf Knopfdruck. 2. evtl. automatische Berechnung einer Prüfsumme bzw. CRC. 3. automatisches Auffinden von vorher definierten Patterns in den empfangenen Daten. Gruß und noch ein schönes Wochenende, Christian
Ich hab den Sinn nicht so ganz verstanden. Kann das nicht auch jedes der ungefähr 1000000 Terminalprogramme?
Ich hab keins gefunden, was aus der Zeichenkette "100" eine Zahl 100 macht und diese dann wahlweise als Byte, Short oder Int versendet.
# 3. automatisches Auffinden von vorher definierten Patterns in den # empfangenen Daten. Das heißt Du gibts im Prinzip einen Buffer an "01 02 03" und wenn diese Sequenz auftaucht dann soll das gemeldet werden?
Guten Morgen Wilfried, >Das heißt Du gibts im Prinzip einen Buffer an "01 02 03" und wenn diese >Sequenz auftaucht dann soll das gemeldet werden? Ja genau. Oder einfach diese gefundene Sequenz farbig/fett hervorheben. Ich hatte gestern das Problem, dass ich mit serial-io keine Daten empfangen konnte. Senden funktioniert, aber sobald meine Zielhardware was zurückschickt geht die CPU auf Volllast und nach ~30sec wird serial-io gekillt. An was könnte das liegen? Gruß, Christian
Gute Frage, das Problem hatte ich noch nicht. Ich werde mal versuchen einige sinnvolle Debug-Meldungen in die nächste Version einzubauen. Hoffe wir finden so das Problem.
Hallo Wilfried, der Absturz ist reproduzierbar, hab es nochmal versucht. Diesmal bekam ich nicht "killed" zu lesen sondern: "Segmentation fault (core dumped)". Vielleicht hilft dir ja das was weiter. Gruß, Christian
Kannst Du noch senden, wenn Du nichts empfängst? Und noch eine Frage zur Checksumme: Nach Deiner Methode ist es bei den Werten 255, 30, 6 also (255+30+6)-1 = 34 (?)
Hallo Wilfried, >Kannst Du noch senden, wenn Du nichts empfängst? Solange ich nichts empfange kann ich senden so lang ich will und wieviel ich will. Sobald mein µC was antwortet kracht es. >(255+30+6)-1 = 34 (?) ja genau
Der Absturz muss dann im Thread liegen. Ob ich da einen Fehler mache oder die libSerial einen Bug hat muss ich dann mal versuchen herauszufinden.
Nebenbei.. an den anderen Features arbeite ich gerade... http://sourceforge.net/project/screenshots.php?group_id=188003 Soweit nichts dazwischen kommt sollte das im laufe der nächsten Woche fertig werden.
Hallo Wilfried, der Screenshot sieht vielversprechend aus! Bin schon gespannt ob's dann bei mir auch funktioniert. Einen schönen Muttertag noch :) Gruß, Christian
Hi, Ich hab leider in den letzten 2 Wochen aufgrund viel Arbeit kaum was geschaft. Ich hoffe das ich es dann Anfang der Woche schaffe. Bitte noch etwas Geduld haben =).
Ich habs geschaft an dem Projekt werter zu arbeiten, mir ist allerdings leider schon aufgefallen, das ich vergessen habe die Checksumme zu berechnen. Das mach ich dann morgen wohl morgen abend. Aber um einen ersten Eindruck von der Version 0.2 zu bekommen sollte es schon mal reichen. Die Daten aus den Buffer werden abhängig von den Einstellungen wie bei der Komandozeile auch übertragen. Die Daten in den Events werden zur Zeit als Bytes interpretiert. Hier nehm ich noch Wünsche engegen, ob das erstmal so ok ist oder was sinnvoller wäre.
Hallo Wilfried, vielen Dank schon mal für deine Mühe! Könntest du bitte noch eine kompilierte Version ablegen, oder mir sagen wie ich das selbst machen kann. Ich konnte im neuen Verzeichnis keine ausführbare Datei finden. Leider habe ich nicht den geringsten Schimmer wie ich die ganzen .cpp Datein kompiliere, bzw. was man da alles dazu braucht. Gruß, Christian
Hallo Wilfried, "make" klar, hätte man draufkommen können :) nur das Kompilieren haut nicht so ganz hin: /usr/bin/qmake -unix -o Makefile serial-io.pro g++ -c -pipe -g -O0 -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I. -o DeviceDialog.o DeviceDialog.cpp g++ -c -pipe -g -O0 -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I. -o main.o main.cpp SerialReceiveThread.h:41: Fehler: zusätzliche Qualifizierung »SerialReceiveThread::« an Element »sendData« mainwindow.h:112: Fehler: zusätzliche Qualifizierung »MainWindow::« an Element »maybeSave« make: *** [main.o] Fehler 1 Was könnte da sein? Gruß, Christian
In den angebebenen Dateien steht in den angegebenen Zeilen folgendes: bool SerialReceiveThread::sendData(QByteArray buffer);bool MainWindow::maybeSave(); jeweils "SerialReceiveThread::" und "MainWindow::" muss weg. Ist mir ein Rätsel warum das da steht und warum das bei mir compiliert.
Hallo Wilfried, also nun läufts, danke! Sieht ganz gut aus. Großes Lob! Empfangen funktioniert mit der neuen Version einwandfrei, es stürzt also nichts mehr ab :) konstruktive Kritik: + die "Verbindungseinstellungen" der letzten "Session" werden gespeichert + insgesamt sehr übersichtliches Layout. Gute Idee sind die Karteikarten für Konsole, Buffer, Events - das "Terminalfenster" ist recht klein im Verhältnis zu den restlichen Einstellungen, d.h. man muss die gesendeten/empfangenen Daten in dem kleinen Fensterchen suchen. Die Messages werden auch direkt hintereinander ohne Trennung geschrieben, dies ist etwas unübersichtlich - die Buffer werden nicht editiert. Wenn man auf den Button "Edit" drückt, wird ein neuer Buffer angelegt. - ein gesendeter Buffer erscheint nicht im Terminalfenster - Wie funktioniert das Highlighting? Hat irgendwie nicht funktioniert. Wünsche: - Anzeige der gesendeten/empfangenen Daten im Terminalfenster auch in HEX (evtl mit Time-stamp) - Abspeichermöglichkeit der verschiedenen Buffer ala "Project" (.txt oder XML Datei?) Viele Grüße, Christian
Freut mich das es gefällt =). Ich setzt mich sobald ich Zeit hab ran und werde die Fehler beseitigen. Sollte in den nächsten Tagen passieren.
Angehängte Dateien:
-
serial-io.png
31 KB
Hallo Wilfried, ja ok, aber mach dir keinen Stress! Was mir gerade aufgefallen ist: Bei deinen Screenshots auf sourceforge.net sind Buttons für Vollbild, Verkleinerung und ein Fragezeichen vorhanden. Is bei der von mir kompilierten Version nicht so. Hast du das geändert, oder ist da was schief gelaufen? Gruß, Christian
Interessant, das werde ich mir auch noch mal angucken, denn das Hauptfenster sollte man auf jeden Fall in der Größe verändern können.
So, es gibt mal wieder eine neue Version. Das fenster sollte man nun größer machen können und somit die gesendeten bzw. empfangenen Daten auch besser sehen. Editieren von Buffer/Events geht auch. Die Checksumme wird berechnet und das Highligting hat bei mir auch funktioniert. Trennung der Daten und anzeige in Hex mit Timestamp sowie das Abspeichern und Laden von Buffern/Events kommt dann in der nächsten Version.
Hallo Wilfried, what's wrong?
1 | ch@bastelbude: serial-io> make |
2 | g++ -c -pipe -O0 -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I. -o main.o main.cpp |
3 | In file included from main.cpp:22: |
4 | mainwindow.h:24:26: error: SerialStream.h: No such file or directory |
5 | SerialReceiveThread.h:28: Fehler: »LibSerial« ist kein Namensbereichs-Name |
6 | SerialReceiveThread.h:28: Fehler: expected namespace-name before »;« token |
7 | SerialReceiveThread.h:39: Fehler: »SerialStream« wurde nicht deklariert |
8 | SerialReceiveThread.h:54: Fehler: ISO-C++ verbietet Deklaration von »SerialStream« ohne Typ |
9 | SerialReceiveThread.h:54: Fehler: expected »;« before »*« token |
10 | mainwindow.h:33: Fehler: »LibSerial« ist kein Namensbereichs-Name |
11 | mainwindow.h:33: Fehler: expected namespace-name before »;« token |
12 | mainwindow.h:88: Fehler: »SerialStream« wurde nicht deklariert |
13 | make: *** [main.o] Fehler 1 |
Gruß, Christian
Die Datei "SerialStream.h" wird nicht gefunden. Komisch, hast Du irgendwas an Deinem System verändert?
Hallo Wilfried, >Die Datei "SerialStream.h" wird nicht gefunden. Komisch, hast Du >irgendwas an Deinem System verändert? sorry, ist mein Fehler! Hab mir vorgestern Feisty draufgezogen und da fehlen wahrscheinlich noch ein paar Pakete. Ich werd mich mal kümmern. Danke! Gruß, Christian
Jetz muss ich nochmal nerven... ./serial-io: error while loading shared libraries: libserial.so.0: cannot open shared object file: No such file or directory Die libserial.so.O gibt's aber definitiv in /usr/local/lib/ und ist eine Verknüpfung auf libserial.so.0.0.0 Warum wird die dann nicht gefunden/erkannt?
Hast Du nach dem installieren der Lib mal "ldconfig" ausgeführt? Falls, es dann noch nicht geht führ mal "ldd serial-io" aus und poste mir mal den output.
"ldconfig" habe ich ausgeführt, danach "ldd serial-io"
linux-gate.so.1 => (0xffffe000)
libserial.so.0 => not found
libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0xb78e2000)
libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb775c000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0
(0xb7745000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb765b000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7634000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7628000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb74e7000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb74d0000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xb747f000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb745c000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7453000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb743b000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7427000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7421000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7418000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7383000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb737b000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7375000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7370000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7366000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7363000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb72f8000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb72cd000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb72bf000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb71ce000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb71c9000)
/lib/ld-linux.so.2 (0xb7fdf000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb71a9000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb71a6000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb71a1000)
"libserial.so.0 => not found" wird komischerweise nicht gefunden
Das Problem ist, das der Linker die Datei anscheinend findet, aber die Datei nicht im Lib-Cache ist. "ldconfig -v | grep libserial" sollte eigentlich unter anderem "libserial.so.0 -> libserial.so.0.0.0" ausgeben. Welche Distribution verwendest Du? Da könntest Du dann mal in den Foren gucken was man macht wenn eine LIb nicht gefunden wird. An meinem Programm liegts soweit erstmal nicht.
Ja, ich mach mich mal schlau. Distri: Debian/Ubuntu Danke für den Support! Gruß, Christian
Gern, falls Du keine Lösung findest meld Dich noch mal. Und wenn Du herausfindest woran das liegt wäre ich auch daran interessiert woran das jetzt gelegen hat.
Sodale, jetzt geht's. "/usr/local/lib" war nicht in der "ld.so.conf" eingetragen - konnte also logischerweise auch nicht gefunden werden. Gruß, Christian
So Version 0.3 beta ist fertig. Buffer/Events können nun gespeichert und
geladen werden.
Für die nächste(n) Version(en) plane ich unter anderem:
- Timestamps, Hex Darstellung
- Speichern der Transmitter-Receiver-Daten
- Löschen des TR-Fensters
- Limit des TR-Buffers
- Einstellmöglichkeit des Thread-Timings
- Eine Möglichkeit einen Buffer mit Werten zu belegen,
z.B. Startwert = 1, Increment = 2, 5 Werte: 1 3 5 7 9
- Limitierung der Event-Werte auf 0..255
Soweit so gut =).
Hallo Wilfried, boah, wird ja richtig nobel! Weiter so! Dann fehlt ja nur noch Darstellung in "Bin" und Anzeige der gesendeten/empfangenen Daten in einem separaten Fenster, dann hast du Do****ght für Linux geproggt :) Was heißt ...? > - Einstellmöglichkeit des Thread-Timings > - Eine Möglichkeit einen Buffer mit Werten zu belegen, > z.B. Startwert = 1, Increment = 2, 5 Werte: 1 3 5 7 9 kann ich mir grad keinen Reim drauf machen. Heut Abend werde ich die neue Version gleich mal testen. Gruß, Christian
Die Anzeige Möglichkeit werde ich dann als Option festlegen: Dez, Hex, Bin, ist dann kein Problem. Die Daten wollte ich eigentlich alle in einem Fenster haben, ich kann aber gern eine Split-Option einbauen =). Die Abfrage der Daten von der seriellen Schnittstelle läuft in einem separaten Thread. Dieser wird zu bestimmten Zeiten aufgerufen. Sollte es mal wieder zu Problemem kommen, kann man daran dann etwas experimentieren. Vielleicht ist das zur Zeit für einige Rechner etwas zu schnell, aber das muss man dann sehen. zum Buffer: Wenn ich z.B. einen Buffer mit Daten füllen will und z.B. 500 Werte auf Null setzen möchte, ist das von Hand schon etwas schwer. Dann würde ich sagen: Startwert 0, Inc. = 0, und alle werte sind auf Null. Wenn du z.B. 10 20 30 40 50 übertragen willst, würdest Du Start: 10, Inc 10, Buffergröße 5 setzen.
Hallo Wilfried, wie benutzt man das highlighting? Hab gerade eine sequence angelegt, aber irgendwie passiert da nicht's. Gruß, Christian
Hmm, ja das stört mich noch das das nicht eindeutig ist. Z.B. Du willst die Sequenz "1 2 3 4 5" erkennen, dann stellst Du die Anzahl auf 5 und gibts in die 5 Felder nach einander "1", "2", "3", "4", "5" ein. Dann sollte das gehen.
Ja genau, so habe ich das auch interpretiert. Meine Sequenz, die ich gerne sehen würde: 0x80 0x80; Definierte Sequenz mit Anzahl der Felder=2 und "80" "80"; Ich empfange mehrere Bytes: 128 128 1 1, da 128 -> 0x80 sollte es eigentlich funktionieren, oder?
Hallo Wilfried, eine "kosmetische" Sache ist mir noch aufgefallen: bei "Edit Buffer" heißen die Schaltflächen "Cancel" und "Edit" bei "Edit Event" heißen die Schaltflächen "Cancel" und "Change" Fenster anpassen funktioniert genauso wie Projekt speichern/laden wunderbar. Serial-IO läuft absolut stabil, hatte seit 0.2.1 keine Abstürze mehr. Gruß und ein schönes Wochenende! Christian
Das mit der Sequenz hast Du im Prinzinp richtig verstanden nur werden die werte zur Zeit noch als dezimal interpretiert, das muss ich noch ändern.
Die Schaltflächen ändere ich auch noch, ist mir auch schon aufgefallen. Danke wünsche ebenfalls eine schönes We =).
So hab zwischen durch mal folgendes eingebaut (version 0.3.1):
- Eine Möglichkeit einen Buffer mit Werten zu belegen,
z.B. Startwert = 1, Increment = 2, 5 Werte: 1 3 5 7 9
- Limitierung der Event-Werte auf 0..255
(falsche werte werden rot hinterlegt)
Bleibt also noch:
- Timestamps,
- Hex Darstellung,
- Speichern der Transmitter-Receiver-Daten
- Löschen des TR-Fensters
- Limit des TR-Buffers
- Einstellmöglichkeit des Thread-Timings
=)
Ich grübel da gerade über ein paar Sachen... Wie soll der Timestamp aussehen? 20070721-10:44:37...? Und mit den Aufteilung der Daten ist mir noch eine Idee bekommen um die Übersichtlichkeit zu erhöhen. Wie wäre es wenn die Tabelle in der ersten Spalte den Timestamp enthält, die weiteren 8 Spalten die gesendeten Daten und dann weitere 8 Spalten mit den empfangenen Daten? Was das Thread-Timing angeht habe ich dafür auch noch eine Anwendungsmöglichkeit gefunden. Wenn der Wert zu klein ist, also der Thread häufig aufgerufen wird, dann kommt das Benutzer-Interface mit vielen neuen Daten nicht zurecht.
Den Timestamp finde ich ok so. Ich würde nur für gesendete/empfangene Daten jeweils einen separaten Timestamp spendieren. Es kann ja auch sein, dass die Antwort erst etwas verzögert ankommt, weil die Elektronik vorher irgendetwas zu tun hat (Sensoren auslesen, rechnen, etc...) Wie machst du das dann mit größeren Antworten als 8 Bytes? Die passen ja dann nicht mehr in die Tabelle, oder verstehe ich da was falsch? Das mit dem Threadtiming klingt logisch - kann ich aber nicht beurteilen. Gruß, Christian
Also ich stelle mir das so vor: 20070721-11:30:30 80 80 80 _ __ __ __ __ __ __ __ __ __ __ __ _ 20070721-11:30:45 _ __ __ __ __ __ __ __ 08 08 08 __ __ __ __ _ 20070721-11:31:00 FF FF FF _ __ __ __ __ __ __ __ __ __ __ __ _ 20070721-11:31:15 _ __ __ __ __ __ __ _ FF FF FF 00 00 00 FF FF 20070721-11:31:15 _ __ __ __ __ __ __ __ FF 00 00 00 __ __ __ _ Bedeutet: zu erst 3x 0x80 gesendet, dann 15 Sekunden später 3x 0x80 empfangen, weitere 15 Sekunden später 3x 0xff gesendet... dann wieder 15 sekunden später "FF FF FF 00 00 00 FF FF FF 00 00 00" (hex) empfangen.
Die breite der Tabelle, jeweils 8 Spalten, kann ich auch variabel gestallten, sodaß man das an seine Auflösung anpassen kann, damit man nicht immer scrollen muss.
sieht gut aus ja. D.h. praktisch, wenn 256 Bytes ankommen und Breite=8, dann gibt's 32 Zeilen oder?
Evlt. lasse ich dann auch den Timestamp in den folge Zeilen weg, dann wird das noch etwas übersichtlicher was zusammen gehört.
So, Version 0.4 beta ist raus =). Neue Features: - Timestamps, - Hex Darstellung, - Löschen des TR-Fensters - Limit des TR-Buffers - Einstellmöglichkeit des Thread-Timings Die Daten werden aber zur Zeit erstmal noch hintereinander geschrieben, meine obige Idee, war mir von der Programmierung her zu komplex. Falls erwünscht werde ich bei Gelegenheit noch mal einen Split auf zwei Tabellen einbauen. Außerdem kommt auch noch das Abspeichern des Rx/Tx Buffers. Naja soweit erstmal, ich hoffe ich hab nicht zuviele Bugs eingebaut ;).
Hallo Wilfried, cool, vielen Dank! Hab gleich mal etwas ausprobiert und mir ist folgendes aufgefallen: - Beim Umschalten zwischen dez und hex passieren anscheinend noch ungewünschte Nebeneffekte. Irgendwas wird da falsch umgerechnet/dargestellt. - Wenn ein Buffer mit Hex-Werten gefüllt ist und Anzeigemodus HEX gewählt ist, dann werden die Bytes aus dem Buffer zwar richtig gesendet, aber im Anzeigefenster falsch interpretiert, d.h. obwohl es schon Hex ist, wird praktisch nochmal nach Hex konvertiert. - Highlighting funktioniert bei mir immer noch nicht, ist aber absolut unwichtig. persönliche Anmerkungen von mir: - Wäre es möglich die Pfeile für Connection open/close zu entfernen? Dies würde mehr Platz für's IO-Fenster bringen und die Funtionalität gibt's ja über das Menü "Connection" bzw. Tastenkombination - Besteht die Möglichkeit das IO-Fenster immer zu aktualisieren (nach jedem Senden/Empfangen)? Momentan ist es etwas umständlich immer wieder manuell zu den aktuellen Daten hinzuscrollen. So wie die Daten dargestellt werden ist es meiner Meinung nach voll ok. Wegen mir brauchst du dir die Arbeit mit dem Split nicht machen. Sonst ist das Program schon richtig gut und es macht voll Spaß damit zu arbeiten :) Läuft bei mir schon unter der Kategorie "Standardprogramme". Viele Grüße, Christian
Also die Fehler werde ich beseitigen. Die Speedbutton kann ich ausschalten bzw. das in die Optionen einfügen, außerdem werde ich aber noch etwas an der Gui feilen, damit mehr Platz da ist... das hab ich schon auf dem Zettel =).
So... ich hab jetzt noch mal ein paar Sachen programmiert. Zunächst gibt es jetzt ein Menupunkt "View", darin kannst Du die Toolbar und die Elemente "Send Type" ... "Byte Order" ausblenden. Außerdem hab ich zwischen dem Rx/Tx-Fenster und dem unter Tab-Bereich ein Splitter eingebaut, Du kannst also die Aufteilung frei wählen. Desweiteren hab ich noch den Save-Buffer Dialog eingebaut. Je nach wahl werden die Bytes aus dem Rx/tx Buffer hintereinander weg gespeichert. Um im rx/tx Fenster immer automatisch nach unten zu scrollen gibts jetzt eine neue Option im Options-Dialog. Die Problematik bei der Umwandlung der Daten konnte ich leider noch nicht nachvollziehen, aber auch das werden wir noch hinbekommen. Es wäre toll, wenn Du ein paar Screenshots machen könntest und mir die dann schicken. Das Highlighting hat bei mir funktioniert, ich werde dazu noch mal ein paar Screenshots fertig machen, vielleicht hab ich das noch nicht richtig erklärt oder es hat tatsächlich noch bugs. Desweiteren freut es mich natürlich das das Programm regelmäßigen einsatz findet =))).
Angehängte Dateien:
-
HEX_DEC_umrechnung.png
47 KB
Guten Morgen Wilfried, so, jetzt hast du's geschafft - mir fällt nix mehr ein, bin begeistert! :-D Vielen Dank für die superschnelle Ergänzung! >Die Problematik bei der Umwandlung der Daten konnte ich leider noch >nicht nachvollziehen, aber auch das werden wir noch hinbekommen. Es wäre >toll, wenn Du ein paar Screenshots machen könntest und mir die dann >schicken. Hab dir mal den Screenshot angehängt. Im Buffer sind die Daten als HEX abgelegt (werden zumindest hex gesendet). Die Anzeige wird dann im IO-Fenster nach DEC konvertiert obwohl es schon Hex ist. >Das Highlighting hat bei mir funktioniert, ich werde dazu noch mal ein >paar Screenshots fertig machen, vielleicht hab ich das noch nicht >richtig erklärt oder es hat tatsächlich noch bugs. ok, vielleicht bin ICH auch einfach nur unfähig und kann's nicht bedienen... >Desweiteren freut es mich natürlich das das Programm regelmäßigen >einsatz findet =))) Gerne doch! Viele Grüße, Christian
Ok, werds mal testen, kannst Du mir noch mal das Projekt-File zukommen lassen, dann kann ich das genau so ausführen. Freut mich das das Programm gefällt :).
Hallo Wilfried, ich hätte einen kleinen Wunsch und einen Bug zu melden :) Bug: Bei der Arbeit mit zwei Bildschirmen ist mir aufgefallen, dass wenn serial-io im "Nebenbildschirm" platziert ist und z.B. der Button "connection-open" gedrückt wird, dann erscheint das kleine Menü nicht im Zweitschirm, sondern im Hauptbildschirm. Ebenso mit den Options etc. Wunsch: Wäre es viel Aufwand die letzte empfangene message irgendwie grafisch z.B. fett hervorzuheben? Wenn man die empfangenen Daten über längere Zeit "nebenbei" beobachtet, dann füllt sich ja das Fenster und wird schnell unübersichtlich wenn man nicht dauernd reinschaut, deshalb der Gedanke die letzte message irgendwie hervorzuheben, damit der "kurze Blick" gleich da landet wo er soll. Wäre als option manchmal "nice to have". Viele Grüße, Christian
Den Bug muss ich mir mal anschaun, das zweitere sollte kein Problem sein. Werde ich mir mal vornehmen kann aber noch genau sagen wann. Aber in den nächsten Wochen auf jeden Fall.
FYI: Ich habe Pakete für serial-io für openSUSE erstellt: http://software.opensuse.org/search?p=1&q=serial-io&baseproject=ALL
So die zuletzt gesendeten oder empfangenen Daten werden markiert. -> Version 0.4.2_beta. @Bernhard: Falls Du zukünftig häufiger mal openSuse Pakete erstellst, hättest Du lust dem Projekt bei zu treten und diese Pakete dann in den Download Bereich hoch zuladen?
Herzlichen Dank, Wilfried! Einen schönen Sonntagabend und eine erfolgreiche Woche wünsch ich noch! Gruß, Christian
Hallo Wilfried, ich habe leider keine zwei Bildschirme :) Aber "er" hat ein IBM Thinkpad irgendwas, OS ist ubuntu 7.04 mit 2.6.20-16 Kernel. Ich hoffe das hilft dir etwas weiter. Wenn nicht, dann muss ich genauer fragen. Gruß, Christian
Wilfried, prinzipiell habe ich nichts dagegen wenn ihr die SUSE-RPMs auch im Projekt hochlädt. Allerdings frage ich mich, ob das Vorgehen wirklich sinnvoll ist. Am Ende habt ihr 20 Binärpakete für 5 Architekturen (evtl. kommt z.B. im BuildService PPC dazu), und das kann's auch nicht sein. Stattdessen ist es normalerweise sinnvoll, ein Binary-RPM und ein Binary-DEB zu erstellen, das auf möglichst vielen Distris läuft (d.h. exotische Sachen statisch gelinkt, mit älterer Compiler/glibc-Version übersetzt, etc.) und den Rest den Distris selber zu überlassen. Je nachdem wie sich das entwickelt kann ich das Programm auch in die SUSE-Distribution (also den FTP-Tree, auf der DVD ist kein Platz mehr für so "exotische" Sachen) aufnehmen.
@ Bernhard: ok, bleibe ich erstmal bei den sourcen und bau ggf. noch mal was für Debian. @ Christian: Geht mir mehr darum wie die Bildschirm konfiguriert sind, also die X Config. Ich kann mir vorstellen das es als ein breiter Screen läuft und da er das Programm irgendwann mal rüber geschoben hat. Da ich die Position speichere wird das Programm immer wieder dort hin geschoben, allerdings die Dialoge nicht. Das könnte ich, falls das so ist wie ich denke, wohl ändern.
Wenn du die Xconf brauchst, dann könnte ich diese schon organisieren. Es ist so konfiguriert, dass fließende Übergänge möglich sind, also Fensterchen hin und herschieben. Wie du richtig vermutet hast, werden die Dialoge immer im Hauptbildschirm angezeigt, nicht da wo das Programmfenster platziert ist. Gruß, Christian
Dann gibts für mich zwei Möglichkeiten ich speichere die Positionen der Dialoge oder positioniere sie realtiv zum Hauptfenster. Ich denke Möglichkeit 1 ist besser. Ich werde mal schaun was machbar ist.
Hi, wäre ganz praktisch wenn ihr das Projekt bei Freshmeat (http://www.freshmeat.net) registrieren könntet. Dann kann ich mich einfach für neue Versionen subscriben und bekomme dann eine Mail. Damit ich die Pakete aktuell halten kann. Gruß, Bernhard
Hi, wäre cool, wenn Du Dir einen Account bei Sourceforge holst, dann kannst Du auch infos bekommen bekommen über updates. Wäre für mich einfacher, da ich dann nicht zwei Webseiten flegen muss.
Hi, Ich habe natürlich einen SF-Account. Allerdings finde ich die Option nicht (ich weiß, dass es sie gibt), also wenn du mir sagst wo ich da klicken muss ... :) SF ist mittlerweile so unübersichtlich geworden, IMO. Gruß, Bernhard PS: Freshmeat ist ja keine Seite wo Projekte gehostet werden, steht also nicht in Konkurrenz zu Sourceforge (das wäre Berlios oder Savannah) sondern im Wesentlichen nur eine Softwaredatenbank. Also wenn du willst dass serial-io bekannt wird, dann ist Sourceforge eine gute Anlaufstelle.
> Meinst Du in Deinem letzten satz eher "Freshmeat", denn bei SF bin ich > ja schon ;). Ja :)
Sooooooooo =)... 0.4.3_beta ist raus: Änderungen: - Stopbits können eingestellt werden (default ist "1", wie bisher) - Die Position der Dialoge wird gespeichert, bei dem dualhead setup sollte man maximal einmal den Dialog verschieben müssen. - Ein paar doppelte unrelevante Codezeilen entfernt - Weitere Dokumentation des Quellcodes (Doxyfile)... eher interessant für Leute die sich den Quellcode angucken Außerdem hab ich mich bei freshmeat angemeldet =).
Hallo Wilfried, ich traue es mich fast nicht zu sagen, aber ich hab mir heute Ubuntu 7.10 draufgezogen. Serial-IO wurde neu kompiliert und ausgeführt. Seitdem fehlen beim Fenster wieder die Knöpfe für Maximieren, Minimieren. Sieht also wieder aus wie da: Beitrag "Re: Serial-IO" Gruß, Christian
Hi Wilfried, nun weiß ich an was es liegt. Es sind die Desktop-Effekte. Wenn die "Visual Effects" ausgeschaltet sind, dann sind oben im Fenster alle Knöpfchen da. Schaltet man das Fensterkrimskrams ein, dann ist nur noch der Schließen-Knopf da. So, gute Nacht. Christian
Hmm, seltsam... Scheint aber ja eher am Fenstermanager zu liegen als an meinem Programm. Hast Du schon mal im Ubuntu Forum gefragt?
Angehängte Dateien:
-
serialio.png
41 KB
Also: Du verwendest QDialog als Hauptfenster. Zwar setzt du
richtigerweise die
WindowFlags, aber trotzdem scheint Qt irgendeinen Bug zu haben so dass
das
Fenster trotzdem dem Windowmanager als Dialog präsentiert wird. Zwar
wird der
Fenstertyp (_NET_WM_WINDOW_TYPE) richtig gesetzt
(_NET_WM_WINDOW_TYPE_NORMAL),
aber die Motif-Hints deuten auf einen Dialog hin.
Vergleiche
xprop _MOTIF_WM_HINTS -name "Serial I/O Manager"
mit einem anderen (Qt-)Programm und du wirst feststellen, dass du genau
die
Ausgabe erhältst die ein Dialog hat.
Der Fix ist einfach QMainWindow zu nehmen das ohnehin besser für ein
Hauptfenster geeignet ist. Wenn du den Patch anwendest, sehen Toolbar,
Menüleiste und Statusleiste nicht mehr so komisch aus (was mich schon
immer
gewundert hat), sondern wie bei jedem anderen Programm, d.h. ohne Rand
und die
Toolbar ist verschiebbar.
Siehe Patch und Screenshot als Vergleich.
So, hab den Patch eingebaut. Das wollte ich auch noch geändert haben, ist mir zwar schon aufgefallen, aber mit dem Theme was ich habe viel es nicht so auf. In wenigen Minuten gibts auch ein neues Source Package.
Hi, Ich hab in der letzten Woche mal wieder mehr mit Serial-Io gearbeitet und dabei sind mir einige Verbesserungen eingefallen: Der letzte Name und Pfad unter dem man den TX/RX-Buffer abspeichert wird jetzt beim nächsten Programm start wieder geladen. Für die Buffer kann man jetzt die Attribute Type,Width,Signed und ByteOrder fest einstellen. Wenn man Daten in der Commando Zeile eingibt und überträgt kann man danach einen Buffer anhängen lassen, z.B. wenn man hinter Zeichenketten noch ein linefeed senden will/muss.
Ich hab mal wieder ein paar neue kleine Features eingebaut. Version 0.5.5 beta ist zum Download bereit. Da es inzwischen Infos auf: http://www.sourceforge.net/projects/serial-io/ http://www.freshmeat.net/ http://www.ohloh.net/projects/6971?p=Serial-IO gibt, werd ich in Zukunft neue Releaes hier nicht mehr bekannt geben.
Hallo Zusammen, weiß zwar nicht ob so ein alter thread noch als Anlaufstelle für Probleme geeignet ist aber Probier es trotzdem mal auf diesem Weg. Hab heute mal die Sourcen, der Version 1.0, geladen. Beim kompilieren erhalte ich aber immer folgenden Fehler :
1 | mainwindow.cpp: In member function ‘void MainWindow::openDevice()’: |
2 | mainwindow.cpp:1049: error: ‘class SerialPort’ has no member named ‘GetDtr’ |
3 | mainwindow.cpp:1050: error: ‘class SerialPort’ has no member named ‘GetDsr’ |
4 | mainwindow.cpp:1051: error: ‘class SerialPort’ has no member named ‘GetCts’ |
5 | mainwindow.cpp:1052: error: ‘class SerialPort’ has no member named ‘GetRts’ |
6 | mainwindow.cpp: In member function ‘void MainWindow::setSerialStreamAttributes(SerialPort&, int, int, int, int, int)’: |
7 | mainwindow.cpp:1108: error: ‘FLOW_CONTROL_SOFT’ is not a member of ‘SerialPort’ |
8 | mainwindow.cpp: In member function ‘void MainWindow::viewTools()’: |
9 | mainwindow.cpp:2942: warning: suggest parentheses around assignment used as truth value |
10 | mainwindow.cpp: In member function ‘void MainWindow::viewSendType()’: |
11 | mainwindow.cpp:2947: warning: suggest parentheses around assignment used as truth value |
12 | mainwindow.cpp: In member function ‘void MainWindow::viewWidth()’: |
13 | mainwindow.cpp:2952: warning: suggest parentheses around assignment used as truth value |
14 | mainwindow.cpp: In member function ‘void MainWindow::viewSign()’: |
15 | mainwindow.cpp:2957: warning: suggest parentheses around assignment used as truth value |
16 | mainwindow.cpp: In member function ‘void MainWindow::viewByteOrder()’: |
17 | mainwindow.cpp:2962: warning: suggest parentheses around assignment used as truth value |
18 | mainwindow.cpp: In member function ‘void MainWindow::viewCRC()’: |
19 | mainwindow.cpp:2967: warning: suggest parentheses around assignment used as truth value |
20 | mainwindow.cpp: In member function ‘void MainWindow::viewSignals()’: |
21 | mainwindow.cpp:2972: warning: suggest parentheses around assignment used as truth value |
22 | make: *** [mainwindow.o] Fehler 1 |
Achso benutze Ubuntu 9.10 in der amd64 Version. Falls das hilfreich ist. MfG Alex
Vielen Dank, dass hat mich ein Stück weiter gebracht. Leider beendet er das Kompillieren nun mit folgenden Fehlern:
1 | mainwindow.o: In function `MainWindow::openDevice()': |
2 | mainwindow.cpp:(.text+0x91e2): undefined reference to `SerialPort::GetDtr() const' |
3 | mainwindow.cpp:(.text+0x91f9): undefined reference to `SerialPort::GetDsr() const' |
4 | mainwindow.cpp:(.text+0x9210): undefined reference to `SerialPort::GetCts() const' |
5 | mainwindow.cpp:(.text+0x9227): undefined reference to `SerialPort::GetRts() const' |
6 | SerialReceiveThread.o: In function `SerialReceiveThread::startThread(SerialPort*, unsigned int)': |
7 | SerialReceiveThread.cpp:(.text+0x31d): undefined reference to `SerialPort::GetDsr() const' |
8 | SerialReceiveThread.cpp:(.text+0x329): undefined reference to `SerialPort::GetCts() const' |
9 | SerialReceiveThread.o: In function `SerialReceiveThread::setDTR(bool)': |
10 | SerialReceiveThread.cpp:(.text+0x3c1): undefined reference to `SerialPort::SetDtr(bool)' |
11 | SerialReceiveThread.o: In function `SerialReceiveThread::setRTS(bool)': |
12 | SerialReceiveThread.cpp:(.text+0x4a1): undefined reference to `SerialPort::SetRts(bool)' |
13 | SerialReceiveThread.o: In function `SerialReceiveThread::run()': |
14 | SerialReceiveThread.cpp:(.text+0x647): undefined reference to `SerialPort::GetCts() const' |
15 | SerialReceiveThread.cpp:(.text+0x655): undefined reference to `SerialPort::GetCts() const' |
16 | SerialReceiveThread.cpp:(.text+0x66c): undefined reference to `SerialPort::GetDsr() const' |
17 | SerialReceiveThread.cpp:(.text+0x67a): undefined reference to `SerialPort::GetDsr() const' |
18 | collect2: ld returned 1 exit status |
19 | make: *** [serial-io] Fehler 1 |
Ich werde daraus nicht schlau. Vielleicht ja einer von euch ;) MfG Alex
Nun scheint die libserial.so nicht gefunden zu werden. Bei mir liegt die in "/usr/lib". Wie hast Du die libserial-0.6.0_rc1 installiert?
Bei mir liegt sie auch dort. Wird dort auch von ld gelinkt. Siehe Ausgabe "ldconfig -v | grep libserial" :
1 | /sbin/ldconfig.real: Can't stat /lib/x86_64-linux-gnu: No such file or directory |
2 | libserial.so.0 -> libserial.so.0.0.0 |
3 | /sbin/ldconfig.real: Cannot stat /usr/lib/libinotifytools.so: No such file or directory |
4 | libserial.so.0 -> libserial.so.0.0.0 |
Installiert hab ich sie, da bei ubuntu nicht in den Paketquellen, über eine von mir kompillierte Quell-Version von sourceforge. Also mit
1 | ./configure |
2 | make |
3 | sudo checkinstall |
Weiß allerdings nicht ob das meine Version 0.5.2 aus den Quellen überschrieben hat. MfG Alex
Verda**t bin ich blööd XD Hab ich mir doch die Antwort selbst gegeben. ld linkte noch erfolgreich auf die alte Version. Hab die mal deinstalliert und siehe da jetzt wird auf die 0.6.0 gelinkt und "make" lief ohne Fehler durch. freu Vielen Dank für die Hilfe und Geduld. MfG Alex
Danke für das Tool, konnte es zumindest schonmal erfolgreich kompilieren uns starten. Kann ich damit auch automatische Antwortsequenzen auf eingehende Bytefolgen senden, statt nur Highlighting zu machen?
Hi Leute, vielleicht könnt ihr mir ja weiter helfen... das Kompillieren wird mit dieser Fehlermeldung beendet: g++ -c -pipe -O0 -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I. -I. -o main.o main.cpp In file included from main.cpp:22: mainwindow.h:24: fatal error: SerialPort.h: Datei oder Verzeichnis nicht gefunden compilation terminated. make: *** [main.o] Fehler 1 Gruß, Tobi
Hallo Wilfried, ich wollte mich für dein tolles Programm bedanken. Ich habe ne ganze Weile nach für meine Zwecke geeigneten Tools gesucht aber nichts entsprechendes gefunden. Serial-IO deckt aber alles ab. Also nochmals vielen Dank für deine Arbeit und weiterhin viel Spaß beim programmieren. Gruß, Micha
Hallo Auch von mir ein großes Dankeschön! Ist wirklich eine feine Sache. Genau was ich brauch - perfekt. Also nochmal, vielen Dank! Obwohl, eine Sache wäre fein: wenn der Absender im Log ersichtlich wäre. Jetzt aber MfG
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.