Hallo Leute, ich möchte mit einem Mega8 und der UART ab und zu mal (vielleicht alle 3-4 minuten) mal ein Schaltsignal bestehend aus höchstens 2-3 byte senden. Dafür möchte ich aber nicht direkt einen Baudratenqaurz einsetzen sondern den internen Takt verwenden. Ist dies irgendwie sicher möglich. Ich brauche also nicht die große Geschwindigkeit bei der Übertragung, da sehr wenige Daten, aber die Bytes sollten schon ankommen. Wäre über eine kleine Hilfe in Bezug auf die Fehlerrechnung sehr dankbar, weil ich ziemlich neu in dem Gebiet bin. LG Store
Du kannst das auch wie beim Linbus machen. Ein Sync-Field senden, auf das sich der Empfänger dann einstellt. Natürlich nur bei einer Kommunikation zwischen 2 µCs.
Store schrieb: > sondern den internen Takt verwenden. Ist dies irgendwie sicher möglich. Es kann funktionieren. Es kann aber auch in einem halben Jahr nicht mehr funktionieren. > Ich brauche also nicht die große Geschwindigkeit bei der Übertragung, Darauf kommts nicht an. 3% sind 3%. Egal ob bei 1Mhz oder bei 10Mhz > Wäre über eine kleine Hilfe in Bezug auf die Fehlerrechnung sehr > dankbar, weil ich ziemlich neu in dem Gebiet bin. Du hast doch sicher in der Schule Prozentrechnung gelernt?
@ Store (Gast) >ich möchte mit einem Mega8 und der UART ab und zu mal (vielleicht alle >3-4 minuten) mal ein Schaltsignal bestehend aus höchstens 2-3 byte >senden. Wie oft du sendest ist egal. Die Baudrate muss trotzdem stimmen. >Dafür möchte ich aber nicht direkt einen Baudratenqaurz einsetzen Warum? Zu teuer? >sondern den internen Takt verwenden. Ist dies irgendwie sicher möglich. Jain. Man kann einen 32kHz Uhrenquarz verwenden, damit kann man den internen RC-Oszillator laufend nachregeln. Geht prima. Oder man empfängt von der Gegenstelle periodisch ein bekanntes Zeichen und regelt damit, Autobauerkennung. >Wäre über eine kleine Hilfe in Bezug auf die Fehlerrechnung sehr >dankbar, weil ich ziemlich neu in dem Gebiet bin. Siehe Baudratenquarz. MfG Falk P S Man kann auch den RC-Oszillator kalibrieren, muss dann aber die Temperatr einigermassen konstant halten (so +/-20C).
formel für normale uart: ubrr= (F_CPU/(16*Baudrate))-1 da sollte nach möglichkeit keine krumme zahl rauskommen ansonst ... umstellen nach baudrate und rückrechnen dann weißte mit welcher baudrate der dann sendet wenn es nur zwischen 2 µC ist .... kann man das problemlos machen .. egal welche baudrate
Wie Falk und Karl Heinz schon angedeutet haben ist das mit dem internen Oszillator nicht sicher moeglich. Eine andere moeglichkeit waere es den Uebertragungstakt mit in die Daten einzubetten. Das wird bei vielen Systemen so gemacht. Damit waeres du von der Taktgenauigkeit unabhaengig. Allerdings geht das so nicht mit dem internen Uart. Das Stichwort dafuer ist Manchestercode http://de.wikipedia.org/wiki/Manchester-Code Mit aenlichen Verfahren hat man z.B. die Speicherung auf Disketten u.s.w vorgenommen FM, MFM Verfahren Du muesstes dich allerdings dazu einen entsprechenden "SOFTUART" selber programmieren und auf der Gegenseite das gleiche tun. Aber ansonsten kosten Quarze heute fast nichts mehr. Gruss Helmi
Falk Brunner schrieb: > P. S. Man kann auch den RC-Oszillator kalibrieren, muss dann aber die > Temperatr einigermassen konstant halten (so +/-20C). Und die Spannung. Die 'neuen' Mega48/88/168 laufen bei mir allerdings auch bei unterschiedlicher Temperatur erstaunlich gut mit 4800 baud beim senden, ich denke aber das es vor allem auch auf den Empfänger ankommt wie gut das läuft.
Zu beachten ist, dass du beim Sender 2 Stopbits und beim Empfänger 1 Stopbit einstellst. Dadurch konnte ich bei mir von 4800 auf 9600 Btis/s gehen ohne das mein 50 Zeichen String fehlerhaft übertragen wird.
Wenn man halbwegs konstate Spannung und Temperatur hat kann man den Abgleichwert auch programmieren. z.B. im fertigen Aufbau ein 100 kHz Rechteck ausgeben (mit Timer!) und durch OSCCAL abgleichen. OSCCAL-Wert läst sich dann im Flash oder EEProm ablegen. Muss halt für jeden µC von Hand gemacht werden, oder Routine mit angelegter Referenzfrequenz zum Einmessen verwenden wenn Platz im Flash noch reicht. avr
wenn die Geschwindigkeit egal ist, dann würde ich auf 600 Bit/s gehen und notfalls noch wartzeit zwischen jedem Zeichen. Dann könnten die Takte sogar schon etwas mehr voneinander abweichen. Also ich würde ich nicht so ein Problem draus machen
Hallo, wenn man die Nutzdaten in den ersten bits jedes bytes (direkt nach dem Startbit) unterbringt, ist dort die Taktungenauigkeit noch nicht schlimm. Erst am Ende eines Bytes verschieben sich Sender- und Empfängertakt immer mehr und es gibt Fehler. Bei der Aufgabenstellung, 16-24 bits gelegentlich zu senden, könnte man diese gut auf sechs Bytes verteilen, die jeweils die ersten 4 bits nutzen. Gruß, Martin
>Dadurch konnte ich bei mir von 4800 auf 9600 Btis/s >gehen ohne das mein 50 Zeichen String fehlerhaft übertragen wird. Clever! Wenn ich also 10 Messungen mit 1% Genauigkeit mittele erhalte ich ein Ergebnis mit 0,1% :-) >dann würde ich auf 600 Bit/s gehen >und notfalls noch wartzeit zwischen jedem Zeichen. Auch das hift nicht! Ein rel. proz. err. bleibt ein rel. proz. err.. Auch bei 1Bit/s und 1h Wartezeit.
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.