Hi, ich baue mir gerade eine Bluetoothfernsteuerung für ein Modellboot, wobei im Moment ein RN-42 als Empfänger dient und die Steuerbefehle von einer selbstgeschriebenen Android-App empfängt und an den Attiny2313 weiterleitet. Dieser soll die Daten auswerten und dann später entsprechend die Elektronik für das Boot ansteuern. Soweit der Plan. Leider kommt es ab und zu (naja eher alle 2-5 Sekunden) vor, dass das letzte Bit nicht richtig vom µC erkannt wird. Zur Konfiguration: Im Datenblatt vom RN-42 habe ich leider nix zum Frame-Format der UART-Übertragung gefunden, aber hier: http://jonasjuffinger.com/bluetooth-modul-rn-42-kommunikation-mit-atmega16/ meint der Author, dass ein Stopbit und 8 Bits verwendet werden. Die Baudrate habe ich wie im Datenblatt angegeben per Pullupwiderstand auf 9600 runtergeschraubt, da mir das locker reicht und ich doch theoretisch mit dem internen Quarz vom Attiny auskommen müsste, oder? In meiner App sende ich alle 100 ms einen Wert zwischen 0 und 255 (per Slider einstellbar zum Testen). Die Fuses vom µC habe ich je nach Konfiguration (siehe Bilder) auf intern 8MHz oder extern 8MHz-Quarz sowie CLK8 eingestellt, ich habe also in jedem Fall einen Systemtakt von 1MHz. 3V Betriebsspannung für beide IC's von 2 AA Zellen. Abblockkondensatoren haben nix gebracht. Was seltsam ist: Wenn ich mit dem internen Takt arbeite, flackert das letzte Bit/oberste LED wenn ich Werte kleiner als 128 sende. Darüber ist alle i.O. (ist ja dann eh immer an). Aber wenn ich den externen Quarz nehme, dann ist die letzte LED immer aktiv (wtf, warum?), wechselt aber im Fehlerfall (der dann deutlich seltener auftritt) mit der vorletzten >.< Der Fehler tritt erwartungsgemäß häufiger auf, wenn ich in kürzeren Abständen als 100 ms sende, aber das wäre mein Worstcase-wert, weil ich möchte ja, dass mein Boot in Echtzeit reagiert und nicht die nächste Ente plattfährt. In den Bildern sieht man, wie ich das blaue Signal direkt vom RN-42 abgreife, das ist immer fehlerlos. Um zu Testen, ob meine Baudrate vll falsch eingestellt war, lasse ich einfach vom Attiny den gelesenen Wert direkt wieder ausgeben. Das ist das gelbe, fehlerbehaftete Signal. Wie man auf den Oszi-Bildenr sieht, haben beide Signale gleiche "Ausdehnung" also nehme ich mal an, dass die Baudrate stimmt. Was extrem komisch ist: Bevor ich TX konfiguriert hatte, also nur empfangen habe, traten die Fehler häufiger auf. tl;dr Meint ihr, dass es normal ist, dass der Attiny Bytes alle paar Sekunden falsch empfängt wenn ich alle 100 ms eines sende? Nachtrag: Ich habe jetzt auch mal versucht 2 chars direkt hintereinander zu senden, damit kommt der Attiny gar nicht klar. Irgendwas stimmt da nicht. Ich muss später auf jedenfall mindestens 4 Zeichen hintereinander senden (2 Kanäle mit je Steuerwert) :-(
Angehängte Dateien:
-
UART_ohne_Quarz.jpg
580 KB -
UART_mit_Quarz.jpg
350 KB
:
Bearbeitet durch User
Hi >Die >Baudrate habe ich wie im Datenblatt angegeben per Pullupwiderstand auf >9600 runtergeschraubt, Wie ändert man mit einem Pull-Up-Widerstand die Baudrate? > da mir das locker reicht und ich doch theoretisch >mit dem internen Quarz vom Attiny auskommen müsste, oder? Falsch. Der Fehler durch den internen RC-Oszillator wird durch die Baudrate nicht beeinflusst. 9600Bd bei 1MHz gibt einen Fehler von 7%. Da kannst du eigentlich froh sein, das es bei dir so 'gut' funktioniert. MfG Spess
Niklas Beuster schrieb: > Ich habe jetzt auch mal versucht 2 chars direkt hintereinander > zu senden, damit kommt der Attiny gar nicht klar. Geh doch schrittweise ran, d.h., teste den Tiny erstmal mit einem direkten seriellen Signal aus z.B. einem PC. Der PC kann dir auch mal einen längeren String senden, um die UART Empfangsroutine wasserdicht zu machen. Je nach verwendetem seriellen Signal musst du evtl. RS232 Pegel wandeln. Der interne RC Oszillator ist für deinen Fall nicht geeignet. Abgesehen vom intrisischen Fehler ist er auch recht temperaturabhängig. Man kann ihn kalibrieren, aber nur für eine gewisse Aussentemperatur. Bei dir gehts um missionskritische Sachen, nimm also einen Quarz. Wenn das alles gut läuft, gehst wieder über das BT-Modul. Bei jeder Funkübertragung, vor allem wenn es um Sachwerte geht, solltest du dir unabhängig von der in BT festgelegten Fehlerkorrektur ein Protokoll mit Fehlererkennung ausdenken. Das kann von einer simplen XOR Mimik bis zur CRC Prüfsumme gehen.
Niklas Beuster schrieb: > theoretisch mit dem internen Quarz vom Attiny Der Attiny hat keinen internen Quarz. Er hat einen internen RC-Oszillator. Mit diesem kannst du die serielle Schnitte bedienen, wenn du ihn im laufenden Betrieb nachkalibrierst(!). Du misst also immer wieder mal mit einem Timer eine Bitdauer aus und erwartest dann ja einen bestimmten Wert. Wenn dieser Wert nicht stimmt, dann muss der Oszillator nachgestellt werden. Kompliziert? Ja, das ist es. Aber du willst ja unbedingt den Quarz sparen. Und Sparen kostet: Hirnschmalz...
Lothar Miller schrieb: > Kompliziert? Ja, das ist es. Aber du willst ja > unbedingt den Quarz sparen. Und Sparen kostet: Hirnschmalz... Wie gesagt, im zweiten Bild verwende ich ja einen externen Quarz. Das hat nix mit Hirnschmalz zu tun, sondern dass der einfach Platz wegnimmt, der im Modellbau eben kritisch ist. Das Problem ist, dass gerade mit Quarz das MSB als "aktiv" ausgewertet wird, obwohl ich Werte < 128 sende. Daraus könnte man schließen, dass das Frameformat 7 Bit wäre. Das es ein Vorzeichen ist, kann ich eigentlich ausschließen, da ich nur Werte von 0 bis 255 benutze und vor dem Senden sowieso in (byte) casten muss. spess53 schrieb: > Wie ändert man mit einem Pull-Up-Widerstand die Baudrate? Steht im Datenblatt: Man kann zwischen 2 vordefinierten Werten umschalten, der höhere ist im 5 stelligen Bereich. Matthias Sch. schrieb: > Geh doch schrittweise ran, d.h., teste den Tiny erstmal mit einem > direkten seriellen Signal aus z.B. einem PC. Der PC kann dir auch mal > einen längeren String senden, um die UART Empfangsroutine wasserdicht zu > machen. Leider habe ich keinen seriellen Port am Rechner :(, aber ich habe Rx und Tx zum Testen des Moduls auch mal direkt miteinander verbunden und dann mit einer Bluetooth-Terminal-App direkt Zeichen übertragen und empfangen und da kam nie ein Fehler, auf den Oszi-Bildern sieht man ja auch, dass das blaue Signal (abgegriffen vom Empfangspin des Moduls) immer korrekt ist. Achja, das Stopbit ist aber immer high, oder? Also das sieht man nie in den Graphen, darum bin ich davon ausgegangen. Das Startbit ist immer low. Die Idee mit dem Protokoll ist gut, damit habe ich auch schon Erfahrung bei Projekten mit STM32L1 und F4, aber dazu müssten ja erst mal mehr als ein Zeichen hintereinander erkannt werden ;-)
Niklas Beuster schrieb: > ie gesagt, im zweiten Bild verwende ich ja einen externen Quarz. und auch die Fuses richtig eingestellt?
Niklas Beuster schrieb: > Abblockkondensatoren haben nix gebracht. Trotzdem müssen da welche ran. Ganz OHNE ist ganz schlecht. Niklas Beuster schrieb: > Das hat nix mit Hirnschmalz zu tun, sondern dass der einfach Platz > wegnimmt, der im Modellbau eben kritisch ist. Doch, eben: du kannst Platz gegen Hirnschmalz tauschen. Nur muss man dann irgendwo irgendwie nachkalibrieren. Mit dem RC-Oszillator allein geht es nicht... > Wie gesagt, im zweiten Bild verwende ich ja einen externen Quarz Sicher? Zieh den im Betrieb mal ab. Wenns weiterläuft wird er nicht verwendet... > Achja, das Stopbit ist aber immer high, oder? Das Startbit ist immer > low. Ja, so ist es. Du hast doch ein Oszi, dann miss doch mal die genaue Bitdauer aus. Das müssen beim 9600 Baud genau 104us sein.
:
Bearbeitet durch Moderator
Laut Tabelle 58 aus dem ATTiny User Manual hat der uC mit fosc=8MHz bei 9600 bps einen Fehler von 0,2%. Auch mit internen OSC soll also keine Rx Probleme geben. Es sei denn der RN-41 generiert die Baud-rate nicht ganz genau, dann passt es mit dem ATTiny nicht zusammen. Versuch mal die Baudrate auf 4800 oder auf 19200 ein zu stellen, der Fehler sollte auch bei 0,2% bleiben. Machst du eventuell die Port-pins inzwischen unkonfigurieren?
> 9600Bd bei 1MHz gibt einen Fehler von 7%.
Wieso wird eigentlich diesem Hinweis von spess53 nicht nachgegangen?
Mit U2X=1 (und UBRR=12) käme man auf 0.2 % und damit wäre eine
mögliche Fehlerquelle beseitigt.
> eine Minute zu spät...
Ich würde eher sagen, dass wir uns ergänzen, Sie mit alternativer
Baudrate, ich mit U2X.
> dass wir uns ergänzen
Doch nicht: wo lesen Sie, dass der Fragesteller mit 8 MHz arbeitet? Ich
sehe 1 MHz.
(Kennen Sie Orwells 1984? So fühle ich mich manchmal: man dreht sich kurz um, und plötzlich steht etwas ganz anderes da oder wie eben gar nichts mehr.) Ja eben, nur derzeit beträgt der Fehler 7 %!
Der neue Tiny841 hat übrigens 2 UARTs und verbesserte Genauigkeit des internen RC-Oszillators. Somit besteht meist kein Grund mehr für einen externen Quarz, trotz UART. Für Modellbauprojekte super geeignet. Heute würde ich keine Projekte mehr mit dem Attiny2313 machen. Der ist schon relativ alt und hat wenig Speicher. gruß cyblord
:
Bearbeitet durch User
Auch auf die Gefahr hin, mich zu wiederholen: auch eine
> verbesserte Genauigkeit des internen RC-Oszillators
hilft bei einem fixen Fehler von 7 % nur begrenzt.
der alte Hanns schrieb: > Auch auf die Gefahr hin, mich zu wiederholen: auch eine >> verbesserte Genauigkeit des internen RC-Oszillators > hilft bei einem fixen Fehler von 7 % nur begrenzt. War auch nicht darauf bezogen, sondern allgemein auf die ext. Quarz Problematik. Eine passende Baudrate für seinen Takt muss man natürlich so doer so wählen.
Okay - auch ich kann das Mantra 'RS232 nur mit Quarz' nicht mehr hören. Es kommt immer auf die Voraussetzungen an.
der alte Hanns schrieb: > Okay - auch ich kann das Mantra 'RS232 nur mit Quarz' nicht mehr hören. > Es kommt immer auf die Voraussetzungen an. Volle Zustimung. Auch mit den älteren AVRs ging der UART nämlich mit dem internen RC wunderbar, wenn die Baudrate korrekt gewählt war. Sicher, für ein echtes Produkt ist sowas nicht zu empfehlen und man merkt deutliche Abweichungen wenn man die Temperaturen ändert (Schaltung mal in Kühltruhe oder mit 100°C Heißluft draufballern). Aber auf dem Tisch bei Raumtemperatur geht es einfach und diverse Anfängerprobleme mit dem UART werden zu 99,999% nicht daraus resultieren sondern haben einen anderen Grund.
:
Bearbeitet durch User
Angehängte Dateien:
-
0gesendet_128erkannt.jpg
470 KB
Alsooo.. Jetzt geht es. Lösung war, U2X = 1 zu setzen und UBBR entsprechend neu einzustellen (nach der Formel im Datenblatt). Interessant war aber, wieso der Fehler auftrat. Es hatte nix mit der Hardware zu tun (hatte zuvor auch den externen Quarz dran (ja, Fuses gesetzt), mehrere Siebkondensatoren und 3,3V Regler mit anderem Batteriepack). Vielmehr stimmte die Baudrate einfach nicht genau, obwohl ich sie nach 2 verschiedenen Formeln berechnen lies (die im Datenblatt und die von dieser Seite). Im Bild sieht man in blau die korrekte Periode für Startbit + 8 Datenbits = 9 Bits: 944µs. Durch 9 ist 104.89µs, entspricht also einer Baudrate von ca. 9534. Das was ich erkannt hatte, wurde ja direkt mit meinen Einstellungen zurückgesenden – in gelb. Hier sieht man eine kürzere Periode. Also wurde das Stopbit des korrekten Signals wahrscheinlich als letztes Datenbit erkannt (obwohl diese Argumentation jetzt nicht wirklich Sinn macht, kann das sein? Weil er ja schneller abtastet und nicht langsamer).
:
Bearbeitet durch User
Wie Sie auf 9534 kommen, ist mir unklar; nach meiner Berechnung war der
2313 auf 8929 Bd eingestellt, und dann ist es kein Wunder, dass das
letzte Bit nicht richtig gelesen wird, Quarz hin, RC-Oszillator her.
Darauf hatte spess53 in der ersten Antwort um 07:20 hingewiesen
> 9600Bd bei 1MHz gibt einen Fehler von 7%
und wenn er auch nicht gleich noch die Lösung mit U2X=1 gratis
mitlieferte, so war doch alles Weitere seither genau betrachtet eine
Vergeudung von Zeit und Energie.
Hallo, es geht ja noch weiter, ich habe auf einen atTiny4313 gewechselt und er RC Oszillator ist auf eine niedrigere Versorgungsspannung Vcc=~3V auf 8MHZ über den OSCCAL Wert abgeglichen. Diesen Umstand findet man natürlich im Datenblatt und mich hat interessiert, wie groß die Abweichung bei Vcc=5V ist. Somit habe ich bisher bei drei atTiny4313 ein Abgleichverfahren in meiner Firmware implementiert, das die im Datenblatt angegeben Abweichung von +10% @25°C für 8MHz bei Vcc=5V bestätigte. Dadurch musst ich bisher nur den OSCCAL Wert um 1 vermindern. Ich weiß, dass diese Stichprobe nicht sehr groß war, aber weitere 10 atTiny4313 warten auf eine Überprüfung. Verwendet wird auch nur eine Baudrate von 9600 8,N,1 mit U2X = 0.
Für alle Mitleser, noch ein Hinweis, Atmel hat seine Abgeichverfahren hier beschrieben. AVR053: Calibration of the internal RC oscillator # http://www.atmel.com/Images/doc2555.pdf AVR054: Run-time calibration of the internal RC oscillator # http://www.atmel.com/Images/doc2563.pdf AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC # http://www.atmel.com/Images/doc8002.pdf Somit sollte man immer die gesamten AP zum gewählten AVR µC sichten und bei Bedarf auch lesen. Ob man dann das eine oder andere Umsetzen mag, liegt an einem selbst.
:
Bearbeitet durch User
Wenn Sie Ihrer Irrlehre nicht sofort abschwören, werden Sie von der herrschenden Quarz-Fraktion als Ketzer verbrannt.
der alte Hanns, mitten in der Nacht schrieb: > Wenn Sie Ihrer Irrlehre nicht sofort abschwören, werden Sie von der > herrschenden Quarz-Fraktion als Ketzer verbrannt. Aber nein. Wie Lothar bereits erklärt hat, könnte man ja aus der Länge bspw, des Startbits vom BT-Modul den internen Oszillator kalibrieren. Die Frage ist eben, ob man diese Baustelle eröffnen will oder mit ein wenig Hardware das erst mal beiseite schiebt, um eine mögliche Fehlerquelle auszuschließen. Und immerhin hängt hier möglicherweise ein Wertobjekt an diesem Faden. Ich benutze für Debug Ausgaben und andere Spielchen oft den internen Oszillator mit UART, das geht auch in 95% der Fälle problemlos. Aber beim Modellbau sind die restlichen 5% nach Murphy Gesetz genau die, die das Modell in die Botanik schicken.
Mit einer solchen allgemein gehaltenen Aussage überzeugen Sie mich nicht. Aber noch einmal zum Ursprungsthema, und das in aller Deutlichkeit: bereits nach der ersten Antwort war im Prinzip alles gesagt, und somit bekommt der Diskussionstitel eine neue und erhellende Bedeutung: Lese-Störungen
Der alte Hanns mäkelte: >Mit einer solchen allgemein gehaltenen Aussage überzeugen Sie mich >nicht. Können Sie nicht einfach mal die Pfoten von der Tastatur lassen, wenn bereits Alles gesagt ist -bloß noch nicht von Jedem? SCNR
An Ihrem Einwand mag etwas dran sein (die Pfoten verrechnen wir mit dem Sie), ich werde versuchen, mich zu ändern. Auf der anderen Seite: Wenn Sie hier neu sind, dann haben Sie m.E. ein etwas unglückliches Pseudonym gewählt, auch wäre ein Fach- als erster Beitrag angebrachter gewesen. Wenn Sie aber bereits unter anderem Namen Mitglied im Forum oder gar bei dieser Diskussion sind, so sind Sie schlicht und einfach nur feige. Wie werden Sie sich verhalten, wenn einmal wirklich Zivilcourage gefragt ist? Tertium non datur.
Die ganze Diskussion wäre überflüssig wenn Niklas anstatt bytes vom 0 bis 255 zu senden, einfach 0xAA gesendet hätte... Ich habe Tiny2313/4313 in mehr als 20 verschiedenen Schaltungen benutzt, hatte noch NIEMALS irgendwelche probleme mit BaudRaten von 4800-19200. Und einfachste Kalibrierung ist: PC sendet 0xAA, Software im Tiny vergleicht bitzeiten mit Timer - genauer geht's nicht ! Temperaturbedingte Abweichungen sind eine andere Frage...
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.