Hallo zusammen! Ich habe ein Temperatur - Messsystem mit einem Atmega8 (Interner Oszillator 8MHz) aufgebaut. Auf dem Board befinden sich 3 NTCs die über den adc ausgewertet werden. Diese Werte werden daraufhin über die serielle Schnittstelle an den PC geschickt. Alle Bauteile die ich verwende sind für einen Temperaturbereich bis 85°C spezifiziert. Allerdings habe ich das Problem, dass ab ca 50°C die Ausgabe meines Protokols falsch wird. Es werden immer Zeichen verändert. (Gerade bei den ausgegebenen Textteilen auffällig) Zum schreiben auf die RS232 benutze ich die in Codevision enthaltene printf Funktion! Die Baudrate liegt bei 9600 also eigentlich nicht besonders schnell. Gruß Stephan
Laß mich raten, Du benutzt den internen RC-Oszillator. Nimm nen Quarz und die Probleme sind weg. Peter
@Peter: das brauchst Du nóch nicht einmal zu raten, Stephan hat es ja geschrieben. :-) Aber stimmt schon, wenn man den Takt für die RS232 aus 8MHz ableitet, trifft man die 9600 baud nicht exakt. Wenn sich dann der Takt durch Temperaturschwankungen noch etwas verschiebt, kann man schnell den Toleranzbereich verlassen, so daß es zu Übertragungsfehlern kommen kann. Gruß, Markus_8051
bei einem msp430 konnte (und kann es weiterhin) ich mit dem internen oszillator eine stabile 57 kbit verbindung halten, 115 kbit waren allerdings etwas kritisch bei starken temperaturänderungen. in einer kleinen klimakammer hier kann ich alle temperaturen zwischen knapp über 0 und 60 grad durchlaufen lassen und daten mitprotokollieren. ein test (einmal rauf + einmal runter) dauert dabei etwa 2 stunden. der temperatureinfluss auf die baudrate ist deutlich zu sehen. mit einem vorhandenen 32 khz (stromsparende gesamtschaltung verbrauch 11 µA) habe ich da aber eine genaue referenz und kann die oszillatorfrequenz einigermassen genau mit dem timer messen. dies geschieht automatisch jede minute. da der msp auch die chiptemperatur auslesbar anbietet kompensiere ich den drift einfach. die messergebnisse eines einzelnen msp übernehme ich dabei für die nachbauten. bis jetzt läuft das bei allen nachbauten völlig problemlos, ob bei zimmertemperatur oder draussen. um den exakten teilerfaktor zur baudrategenerierung zu finden bin ich experimentell vorgegeangen und habe die fehlerhäufigkeit bei verschiedenen teilerfaktoren (bei 57 kbit) auf 2 PC gemessen. es ergibt sich da eine art umgekhrte gauss-verteilung. habe den wert im "tal" der kurve genommen. die ergebnisse der 2 pc waren fast genau gleich. so ein vorgehen ist leider ziemlich zeitaufwendig. spart aber die 50 ct für einen hf quarz und kann den stromverbrauch drastisch senken, denn nur für die datenübertragungszeiten wird kurz der prozessortakt voll hochgefahren um beste genauigkeit zu erreichen. wenn die üblichen baudraten doch bloss vielfache von 32,768 wären... seuffzzz...
@dicky wenn Du den RC-Generator mit einem 32kHz Quarz nachregelst, hast du doch wieder eine quarzstabilen Wert, ist quasi eine PLL in Software. Geht beim ATMega8 aber auch. Wo nun aber das Problem mit den 32kHz sein soll, verstehe ich nicht. Du must doch nur die Zählwerte der Timer entsprechend wählen, damit der RC-Generator eine baudfreundliche Frequenz hat (z.B. 32kHz * 225 ergibt baudfreundliche 7,3728MHz). Peter
das musst du mir noch mal vorrechnen, was du glaubst damit gespart zu haben. Ein Quarz kostet in Stückzahlen >500 gerade mal 25 Cent, ein Keramikresonator ca. 8 Cent. Wieviele 10.000 Stk willst du denn verkaufen, um deine tage(wochen?)lange Entwicklungs- und Testarbeit wieder hereinzuholen?
Bitte 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.