BTM222 - UART Problem

[Benjamin O. (otbe)]

Hallo Zusammen,

ich möchte gerne Daten vom Mikrocontroller (Atmega88) via Bluetooth an 
das Handy (Android) senden. Nutze dafür das BTM222 (baud 38400, 8N1) und 
die App "Bluetooth SPP Manager". Am AVR benutze ich einen 8Mhz Quarz und 
als UART Lib die von Peter Fleury. Das Ganze funktioniert auch soweit 
ganz gut, aber leider nicht dauerhaft.

Nach einiger Zeit (und diese ist nicht vorhersagbar) kommt da irgendwas 
aus dem Tritt was die Übertragung der Daten per UART angeht. Ich sende 
in der Regel Strings in der Form

"  20.43442;  50.23133; 100.00; 0.05\n" (ohne ")

in Abständen von 250ms. Am Anfang passt das auch alles und wenn der 
Fehler auftritt, kommen am Ende falsche Daten in der Form von z.B.

"  20.43442  50.23133 100.00 0.05\n" (ohne das Trennzeichen ; im besten 
Fall)

oder

"  2043442.  00231.33 10000 0.05\n"

an. Ich nehme an, dass das BTM irgendwann Start&Stopbits nicht mehr 
richtig mitbekommt und dann natürlich Müll überträgt, allerdings weiß 
ich nicht wie ich das umgehen soll, da ich auf das "auf die Leitung" 
bringen ja keinen Einfluss habe (wegen der Hardware UART Schnittstelle). 
Eine Aufsplittung des Strings in mehrere Teile (mehrere uart_puts()) 
oder das Einfügen von delays hilft ein wenig aber nicht dauerhaft.

Hat jemand eine Idee oder Erfahrungen was man da machen kann?

Danke schön :)

Grüße,
otbe

[Karl H. (kbuchegg)]

Benjamin O. schrieb:

> Eine Aufsplittung des Strings in mehrere Teile (mehrere uart_puts())
> oder das Einfügen von delays hilft ein wenig aber nicht dauerhaft.

Sieht für mich danach aus, als ob du ein Handshake (Hardware oder 
Software) brauchst.
Sprich: du ballerst deine Daten zu schnell in das BTM rein, so dass 
dieses mit der Übertragung nicht mehr mitkommt. Das BTM wird intern 
einen Buffer haben, der für solche Fälle kurzzeitig zwischenspeichern 
kann. Aber wenn die Daten natürlich dauerhaft zu schnell angeliefert 
werden, dann geht der irgendwann über.

Das wäre meine Arbeitshypothese.
Prüfen könnte man sie, indem man mal nachsieht ob das BTM kurzzeitig zu 
einem 'Daten-Übertragungsstop' per Handshake aufruft (sofern aktiviert) 
bzw. indem du die 250ms mal großzügig erhöhst.

[Benjamin O. (otbe)]

Hallo Karl,

danke für deine Antwort. Ich wollte gerade mit der Implementierung von 
RTS/CTS anfangen, da habe ich nochmal was anderes probiert.
Die Zahlen in dem String werden ja vom Atmega berechnet und mittels 
dtostrf() in einen String umgewandelt. Jetzt habe ich mal nur 
geschrieben

uart_puts("  20.43442;  50.23133; 100.00; 0.05\n");

und siehe da es läuft seit über einer Stunde ohne Fehler.

Nach genauerem Prüfen hat sich nun herausgestellt, dass der Fehler in 
der dtostrf Funktion lag bzw in dem Input. Der Buffer war in seltenen 
Fällen (genau dann wenn die Bestimmung der Zahlen eh etwas spinnt) genau 
1 Zeichen zu klein (\0). Jetzt klappt es ohne Probleme :)

Danke!

Grüße,
otbe