Go Down

Topic: Spezieller Serialmonitor gesucht (Read 1 time) previous topic - next topic

fox00014

#15
Feb 20, 2016, 05:22 am Last Edit: Feb 20, 2016, 08:04 am by fox00014
nur wo Klemmt es. Ich mein.

Terminalprogramm Problem ist sehr wahrscheinlich.

Aber eventuell hängt es daran das wir für den Software Handshake Was im Protokoll vergessen haben was dieses erst überhabt aktiviert oder sowas.

Oder Werden die Steuerzeichen immer noch irgendwie falsch gesendet das sie nicht Interpretiert werden.
Mit anderen Betriebssystemen zu testen finde ich jetzt gar nicht so schlecht. Gibt zumindest hinweise ob es ein OS-BUG ist oder eher an Programm und oder Terminalprogramm Liegt.

----------------------- Nachtrag ------------------------

hab noch ein weiteres Teminalprogramm gefunden. moserial macht auch nen ganz guten eindruck.
Serialport ist eingestellt auf:

Gerät: /dev/ttyUSB0
Bautrate: 9600
DatenBits: 8
Stopbits: 1
Parität: None
Handshake: Software
Zugifsmudus: Read and Write
Lokales Echo: AUS

Erstmal bis hier her richtig???

Oben kann ich verfolgen das ich nach dem Verbindungsaufbau kontinuierlich 0x11 XON empfange.
nach dem Senden eines Befehls z.B.: "G0 X10000" erhalte ich 0x13 XOFF. und das delay lauft. nach ablauf erhalte ich dann nach der Ausgabe wieder 0X11. Soweit scheint es zu laufen.

Sende ich zwei Befehle schnell Hintereinander über die Eingabezeile werden diese sofort gesendet und nicht auf 0x13 reagiert. OK. kann an dem manuellen Senden liegen.

Nun will ich eine Datei Senden. Nach dem ich die Datei ausgewählt habe erhalte ich die meldung: "Warte auf Gegenstelle".
Oben kann ich sehen das weiterhin 0x11 XON entgangen wird.
das Heist doch das wir im Übertragungsprotokoll irgendwas vergessen haben oder???

-------------------------- Nachtrag die 2. ---------------------------------
nach Wikipedia https://de.wikipedia.org/wiki/Datenflusssteuerung gibt es DC1 bis DC4.
XON ist DC1 ist 0x11
XOFF ist DC3 ist 0x13
aber was ist DC2 und DC4. und welche Zeichen entsprechen denen? 0x12 und 0x14?

Kopie aus Wiki:
Software-Flusssteuerung, Software-Handshake, Software-Protokoll oder X-ON/X-OFF[Bearbeiten]
Eine Software-Flusssteuerung wird durch in die Datenübertragung eingefügte Zeichen gesteuert.
Im ASCII-Zeichensatz (ITU-T-Empfehlung T.50) sind die ersten 32 Zeichen für Steuerungsaufgaben reserviert. Vier davon, DC1 bis DC4 (Device Control), sind Gerätesteuerzeichen.
Die Software-Flusssteuerung sollte davon die folgenden Zeichen benutzen:
DC1 (oft als X-ON bezeichnet, engl. für Transmission ON, Zeichencodierung 11hex bzw. 17dez, PC-Tastatur: Strg-Q) und
DC3 (oft als X-OFF bezeichnet, engl. für Transmission OFF, Zeichencodierung 13hex bzw. 19dez,PC-Tastatur: Strg-S).
Diese Zeichen sind sowohl in Richtung Endeinrichtung zum Übertragungsgerät als auch umgedreht nutzbar.
In der Datenübertragung mit Modems gibt es oft die Möglichkeit, diese Zeichen durch Konfiguration umzustellen.
Anwendung[Bearbeiten]
Ist der Sendespeicher des lokalen Modems fast gefüllt, wird das X-OFF-Steuerzeichen in die Empfangsdaten zur eigenen Endeinrichtung eingefügt. Sobald dieser Speicher zur Gegenstelle gesendet wurde und damit wieder leer ist, wird das X-ON-Steuerzeichen eingefügt und damit die Blockierung der Endeinrichtung aufgehoben. Die Übertragungsleitung ist hierdurch vor Datenverlusten gesichert.
Probleme[Bearbeiten]
Beim Versand von Binärdaten dürfen die beiden Steuerzeichen nicht in den Daten auftauchen, da sonst die Datenübertragung unterbrochen wird. Die Zeichen müssen maskiert werden, z. B. dadurch, dass die ganze Datenübertragung so umkodiert wird, dass die Daten als ASCII-Werte der hexadezimalen Zahlen gesendet werden. Ein vor Jahren oft genutztes Format war der Hex-Record von Intel. Dadurch wurde das zu übertragene Datenvolumen aber verdoppelt. Obwohl durch die Umkodierung innerhalb der zu übertragenen Dateien die X-ON/X-OFF-Steuerzeichen nicht mehr vorkommen, war eine Übertragung oft nicht möglich. Das Protokoll X-Modem beinhaltet zum Beispiel einen fortlaufenden Blockzähler von 00hex bis FFhex, so dass unabhängig von den zu übertragenen Daten jedes Datenbyte auftritt.
Die Software-Flusssteuerung sollte nur genutzt werden, wenn es keine Alternative gibt.

--------------------------------------- Nachtrag die 3. ----------------------------------------------------------

Mikrocontrollernet hat eine sehr gute allgemeine Erklärung. aber wirklich weitergebracht hats mich auch nicht...

http://www.mikrocontroller.net/articles/RS-232

Serenifly

#16
Feb 20, 2016, 03:50 pm Last Edit: Feb 20, 2016, 06:26 pm by Serenifly
Quote
Oder Werden die Steuerzeichen immer noch irgendwie falsch gesendet das sie nicht Interpretiert werden.
Bei mir werden die richtig gesendet und empfangen. Aber die Terminal Programme reagieren irgendwie nicht drauf. Getestet mit Realterm und CoolCom. In RealTerm werden sie sogar als DC1 und DC3 angezeigt! In CoolTerm sieht man es wenn man auf Hex Ansicht geht.

Was da schief läuft weiß ich nicht. Es kann ja nicht sein, dass das gerade bei "Datei Senden" ignoriert wird, oder?

Quote
Oben kann ich verfolgen das ich nach dem Verbindungsaufbau kontinuierlich 0x11 XON empfange.
nach dem Senden eines Befehls z.B.: "G0 X10000" erhalte ich 0x13 XOFF. und das delay lauft. nach ablauf erhalte ich dann nach der Ausgabe wieder 0X11. Soweit scheint es zu laufen.
Ich würde XON nur senden nachdem man XOFF gemacht hat und es weiter gehen kann. Das behebt aber das Problem nicht.

Für mich sieht es so aus als ob er kontinuierlich weiter sendet und der Eingangspuffer des Arduino voll läuft, da er während des delay() natürlich nicht geleert wird

Was hilfreich wäre wenn man den gesendeten Text irgendwie anzeigen könnte, so dass man sieht wann was gesendet wird. Aber das erklärt dann immer noch nicht wieso er nicht aufhört.

Quote
aber was ist DC2 und DC4. und welche Zeichen entsprechen denen? 0x12 und 0x14?
Das sind allgemeine Steuerzeichen. Bedenke dass dieser Kram mal für Drucker, Telex u.ä. entwickelt wurde. Dann wurde später verschiedene Übertragungsprotokolle für Computer entwickelt, die mit den Zeichen zum Teil anderen Dinge gemacht haben.


Eine andere Option wäre Hardware Handshaking mit CTS (Clear to Send). Dazu brauchst du aber einen externen TTL/USB Wandler, da du auf den Wandler auf dem Arduino keinen direkten Zugriff hast. Den kann man dann auch nicht an der normalen 0/1 Schnittstelle betreiben, sondern muss sich entweder eine Schnittstelle in Software emulieren (per AltSoftSerial) oder einen Controller mit mehreren Hardware Schnittstellen nehmen.



EDIT:
Ich hatte hier ein paar Tests gemacht und dann angenommen dass er auf XON/XOFF korrekt reagiert. Das war aber Blödsinn. Man sieht nur dass der Arduino die Pause macht. Man sieht nicht wann wirklich gesendet wird. Wahrscheinlich geht das an einem Stück.

Dass es mit kurzen Texten geht, kann eigentlich nur bedeuten dass der PC ständig sendet und der Eingangspuffer des Arduinos voll läuft. Der ist nach 64 Bytes voll. Den größer zu machen bringt auch nichts. Damit verschiebt man das Problem nur.

Man müsste wie gesagt mal angezeigt kommen was gerade gesendet wird. Dann könnte man genau vergleichen was wann abläuft. Erklärt aber immer noch nicht wieso er nicht aufhört zu senden.

fox00014

Unter Windows gibt es wohl nen Freewareprogramm Namens SerialSniffer. Hersteller Download
Damit sollte man den Stream Visoalisieren können.

Bohr artet das aus.

Also zusammen gefasst haben wir festgestellt das mehrere Terminalprogramme auf XOFF während der Dateiübertragung nicht reagieren. Also Schließe ich mal nen Bug in den Programmen aus.

Wir haben festgestellt das der Arduino Serial Buffer überläuft da das Programm nicht auf XOFF Reagiert.
Bei allen Terminalprogrammen war Softwarehandshake ausgewählt.

Hardwarehandshake geht nicht on Board nur 3 Drat Verdratung zu der RS232 vorliegt. Also sind die Protokolleintragungen Kurzgeschlossen.

Also gibt es nur 2 Möglichkeiten.
Bei der normalen Dateiübertragung existiert kein Softwarehandshake.
Oder etwas fehlt damit das Protokoll aktiviert wird.

zu dem Zwek hab ich nach der Bedeutung der Steuerzeichen gegooglelt
Wiki eintrag.
Dummerweise nicht vollständig und bis jetzt hab ich auch noch nichts über das Softwarehandshake gefunden was über unsere bis jetzt spärliche informationen hinaus geht.

Währ schon mal gut zu wissen ob ich da Geister jage oder nicht...

Andere Protokolle hab ich auch schon versucht zu verstehen.
Xmodem übertägt immer in 127 Bit Blöcken. Doof für Zeilenweise Übertragung.
Serialdrucker nur Text eingerichtet. und getestet. Nix keinen Brumm. Und keine infos über das Druckprotokoll.
Erst die Komplette datei einlesen. Das wird wohl den Speicher des Arduinos volkommen sprengen.
Daten auf ner SD-Karte zwischen Speichern. macht ca. 1000 Zyklen danach ist die Durchgeritten.
Alten Ram. Viel zu fiele Pins.
Floppy, ist zu langsam und nicht groß genug. und zu fiele pins.
Festplatte. ist mit Kanonen auf Spatzen. Teuer. und keine Ahnung über SATA.
SSD oder USBStik hat auch Zyklenbeschrenkungen.
Flashspeicher sind einfach nit für dauerhaftes schreiben gemacht.

Also fällt das komplette übertragen der Daten wohl auch raus. Oder???

Serenifly

Hardwarehandshake geht nicht on Board nur 3 Drat Verdratung zu der RS232 vorliegt. Also sind die Protokolleintragungen Kurzgeschlossen.
Es geht mit einem externen USB/TTL Wandler. Da kann man CTS über den Konverter führen

Sich ein eigenes Programm zu schreiben, dass die Datei ausliest und entsprechend pausiert wäre eine Option. Das ist etwas Arbeit, aber nicht allzu kompliziert. Die Einzel-Aufgaben (Datei auslesen. Serial Kommunikation) sind recht trivial.



Es wäre aber nett rauszufinden wieso die Programme einfach munter weitersenden. Das kann ja nicht sein wenn man XON/XOFF aktivieren kann.

fox00014

Externen USB -RS232 Konverter währe eine Option. aber mir wiederstrebt einfach die Tatsache etwas anzubauen was ja Eigendlich schon da ist. mal Ehrlich. das kann es doch nicht sein oder. Wozu Kauft man dann nen Board wenn ma eigendlich doch nur den IC gebraucht hätte und mit Pegelwandlern und allem doch anfängt.
Ne menge Mehrarbeit ohne wirklichen Zugewinn und es sind mindestens 4 IO's weg. Dazu kann man 1 und 2 auch nicht benutzen.
macht dann schon 6 IO's die weg sind. Das muss aderst gehen.

Warum die Programme nicht reagieren ist die große Frage. Ich versteh es auch nit wirklich. das einzige was ich mir vorstellen kann ist das dieses Softwarehandschaking erst noch mit einem anderen Steuerzeichen Aktiviert werden muss oder die Datei Binär gesendet wird was Die ASCII Zeichen umkodieren würde. Und das Terminalprogramm das wieder zurückcodiert.

Eigenes Sendeprogramm zu schreiben wiederstrebt mir eigentlich nur weil ich am Schluss für alle Betriebssysteme was basteln sollte. Und ich das Rad damit Neu erfinden muss.

Extrem cool währe eine Lösung mit einem Standarttreiber oder so. Modemtreiber oder Generec. Nur Text Drucker an RS232. Oder nen Programm was es schon gibt auf allen OS wie z.B. Putty. das ist aber Wiederum als Fernwartungs Konsole gedacht und sprengt wieder den Ramen.

Ideen was man noch testen könnte oder wie man z.B. das mit dem Druckertreiber oder dem Modemtreiber weiter kommt???
halt was benutzen womit XON und XOFF schon früher funktioniert hat?

Serenifly

#20
Feb 21, 2016, 04:08 am Last Edit: Feb 21, 2016, 04:14 am by Serenifly
Wenn man sucht findet man andere die ähnliche Probleme hatten. z.B.:
https://github.com/grbl/grbl/issues/50
Da wird auch berichtet dass das nicht zuverlässig läuft. Siehe auch die Antwort von chamnit am 23 Febr.

Und siehe die vorletzte Antwort. Mit einem FTDI Chip ging es dann (zumindest bei einem). Das Problem soll das der USB/TTL Wandler der Arduino Boards sein. Das macht ein kleiner Atmega.
Da fällt mir ein dass ich einen Mega mit FTDI habe....

Nochwas aber: der PC reagiert nicht unbedingt sofort auf XOFF. Ich habe gelesen, dass oft noch der Hardware FIFO geleert wird. Da das aber nur 16 Byte sein sollen, sollte das keine so großen Probleme machen.


Quote
das einzige was ich mir vorstellen kann ist das dieses Softwarehandschaking erst noch mit einem anderen Steuerzeichen Aktiviert werden muss oder die Datei Binär gesendet wird was Die ASCII Zeichen umkodieren würde. Und das Terminalprogramm das wieder zurückcodiert.
Das ist ASCII

Serenifly

SUCCESS!! :)

Es liegt im der Tat an dem Atmega USB/TTL Wandler :(

Auf meinem Freaduino Mega mit FTDI läuft es! Sowohl mit CoolTerm als auch RealTerm.

fox00014

#22
Feb 21, 2016, 05:15 am Last Edit: Feb 21, 2016, 08:15 am by fox00014
Ich denk das ist ne Software gesteuerte Kommunikation.

Na Happy Birthday.

Also Kurts um. Das geht mit einem  Atmega einfach nicht.
Also geht auch kein Drucker oder Modem Treiber.
Positiv an der Erkenntnis ist das das ne menge Programmierarbeit gespart hat.

Was heißt das für das Project?
Entweder nen Freaduino Mega mit FTDI Kaufen
oder nen FTDI Anbauen.
oder eine SD-Karte Anbasteln und die zum Cachen benutzen.

Ich Tendiere grade zu der 3. Metode.
Daten per PC auf die Karte oder per Serial dreckt rüber schicken.

Ich hol dann mal Widerstände und den Lötkolben raus.

Das kann alles doch nit war sein. Warum?
Ich versteh es nicht. Der PC empfängt 0x13.
Also sollt die Software nicht weiter senden und es kommen maximal noch 16kB.
Die sollten in den 64kB Arduinobuffer. doch rein passen.
Solange Keine Daten zur Verfügung stehen wird 0x11 gesendet. das heist doch Umgekehrt:
Erst wenn der Arduinobuffer leer ist dann werden wieder Daten gesendet.
Warum kann es dann am TTL-USB-Wandler liegen?  :smiley-eek:

Danke auf jeden Fall für eure Hilfe. Alleine währ ich daran wohl verzweifelt.
Andere leute wissen andere Sachen, denken anderst und Googlen halt auch anders.

Ich Bastel Jetzt erstmal, Dann gibt es bestimmt wieder neue Probleme die auftauchen.

Dickes DANKE nochmal!

------------------------------------------ Update -------------------------------------------------

Also ich hab nen Atmega 2560

SD-Kartenadapter hab ich hirnach zusammen gebaut:
https://arduinodiy.wordpress.com/2012/03/28/sd-card-on-arduino/
geändert habe ich die Widerstände:
4K7 ersetzt durch 200R Metalschichtwiederstand
10K ersetzt durch 640R Metalschichtwiederstand
macht nach Adam Riese bei 5V in 3,8V out. 0,5V drüber. Das sollt die SD Mit machen.
als Slot hab ich nen alten MikoSD Kartenadapter genommen.

warum? Kleinere Widerstände bedeuten höhere Belastbarkeit des Spannungsteilers und HF Unempfindlichkeit gegen Einstrahlung.
20mA können die Ausgänge vertragen. Da sollt ich deutlich drunter bleiben.
und zu guter letzt hat ich unter anderm genau diese Größen hier noch liegen. 1/4 W Kohleschichtwiederstände sollten auch reichen mit 220R und 470R. macht ca. 3,4V +- 10%

getestet mit dem Ardoino Beispielprogramm listdir.
darin Zeile 43 von
if (!SD.begin(4)) {
in
if (!SD.begin(53)) {
ändern.

Anschluss des Adapters:
50     Data-Out MISO
52     CLK         SCK
GND VSS        GND
3,3V  VDD        3,3V
51     Data-In    MOSI
53     CS           SS

Serenifly

Quote
Entweder nen Freaduino Mega mit FTDI Kaufen
Der Hersteller ist egal. Da gibt es auch andere. Den Freaduino habe ich mir gekauft weil als Spannungwandler ein Schaltregler drauf ist. Das ist sehr selten.

Aber eBay ist voll von Arduino Klonen, bzw. kompatiblen Boards von chinesischen Herstellern mit CH340 Chips als USB/TTL Wandler. Sowohl UNO als auch Mega. Auch von deutschen Versendern. Der CH340 wird heutzutage eher als die FTDI Chips verwendet, da er wahrscheinlich billiger ist. Aber es ist genau ein dediziertes Konverter IC und kein programmierter µC

Quote
Also sollt die Software nicht weiter senden und es kommen maximal noch 16kB.
Die sollten in den 64kB Arduinobuffer. doch rein passen.
Byte! 64 Byte! Der UNO hat 2kB RAM. Der Mega 8kB. Da kannst du keine riesigen Puffer haben

Quote
Solange Keine Daten zur Verfügung stehen wird 0x11 gesendet.
Wieso dauernd senden? Das sind Schalter. Wenn alles gut geht musst du XON nur einmal senden wenn du wieder bereit bist Daten zu empfangen

Quote
Warum kann es dann am TTL-USB-Wandler liegen?
Wird in dem Github Thread erklärt. Weil der Wandler das nicht 1:1 sofort weiterleitet. Der hat auch 64 Byte Puffer und diese laufen leider nicht synchron mit dem Arduino.

Quote
The Arduino 328p CPU communicates to the USB chip at the set baud rate, but once it gets to the USB chip, it has its own send and receive buffer to communicate with the user's computer. Both chips transmit roughly 64byte packets when full or incomplete ones after a timer has elasped. The Uno has a 4.1ms wait and the FDTI chips have a much longer one at 8-16ms.

This means that an XOFF character can get stuck in the USB chip buffer and be delayed long enough to not be recognized by a terminal program, which will keep sending bytes and overflow the Arduino serial receive buffer. On top of this, (if I understand this correctly) there is also a receive buffer on the USB chip going the other way. USB protocol, I think, sends 64 byte packets to the Arduino USB chip which then get sent to the Arduino 328p CPU at the serial baudrate.

So, in short, XON/XOFF characters can get delayed in the USB-serial emulator chips, while a computer will keep sending up to 64 byte packets at a time

Go Up