Spezieller Serialmonitor gesucht

International Deutsch
21

Wenn man sucht findet man andere die ähnliche Probleme hatten. z.B.:

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.

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

22

SUCCESS!! :slight_smile:

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

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

23

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? :astonished:

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:

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

24

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

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

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

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.

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