Hi! Gibt es die Möglichkeit die Fuse Bits des laufenden MCs zu verändern, daß dieser bspw. zunächst durch einen Quarz getaktet wird und dann durch den internen Oszillator z.B. durch einen Interrupt?! Hoffe die Frage ist nicht allzu blöd...
Nein, das geht mit den AVR nicht. Die MSP430 koennen das. Die AVR koennen vom Hauptoszillator auf einen 32kHz schalten, das war's
"Die AVR koennen vom Hauptoszillator auf einen 32kHz schalten, das war's" Meiner Meinung nach: nicht mal das. Der 32kHz speisst nur den Timer/Counter2, ohne die Möglichkeit, den CPUclk, IOclk etc. damit zu fahren. Zumindest beim Atmega32 ist es so.
Neuere AVRs können die Taktrate über nen Prescaler im Betrieb umschalten, die Taktquelle selbst aber nicht. Mal ne andere Frage: wozu soll das gut sein? Stromsparen? Zieht denn ein Quarz so viel mehr als der intern RC?
Die Leute von Atmel sind offenbar ueberzeut dass die jeztigen Moeglichkeiten reichen. Man nimmt entweder einen Quarz wenn man kommunizieren will, oder den RC wenn nicht. Der RC eines PIC ist genuegend genau fuer serielle Kommunikation, beim AVR ist das nicht der Fall. Und dann schaltet man den Prozessor ab wenn man ihn nicht braucht. Dazu gibt es eine ganze Palette von sleepstates. Wenn man noch besser werden will, nimmt man den 32KHz mode um lange Zeit zu schlafen. Bei den sleepstates muss man jeweils beachten, dass das Aufwachen nicht unbedingt sofort geschieht. Das Anschwingen des Quarzen kann man zB in den Fusebits einstellen, das kann bis 16k Zyklen dauern plus 65ms delay.
Nun ich will mit dem Mikrocontroller Widerstände messen und das bei Temperaturen zwischen -40 und 125°C Der AT90CAN hält diese Temperaturen aus...ein Quarz leider nicht. Deshalb muss der interne Oszillator herhalten. Um aber die Messdaten nach den Messungen via UART zum PC zu schicken brauche ich (soweit ich das hier in dem Forum gelesen hab) einen möglichst genauen Takt und den kriegt man mit dem RC nich hin @Zacc: meinst du die PICs könnten das oder geht die Kommunikation bei diesen Temperaturen auch flöten...dann würde ich nen PIC nehmen...vorrausgesetzt da gibt es auch welche die 125° abkönnen...
Hi Du könntest evtl. eine externe Taktquelle benutzen.Wenn die thermisch abgeschirmt ist, erübrigt sich die Umschaltung. MfG Spess
Hier im Forum wird ständig verbreitet, dass serielle Kommunikation mit dem internen Taktgeber nicht klappt. Das stimmt nach meinen Erfahrungen nicht allgemein: Ich habe mehrere Mega8 und Mega16 mit internem Takt 1MHz und der Baudrate 2400 im Einsatz, es gab noch nie Probleme! Ganz banal programmiert mit Bascom ... Solltest Du also keine (zu) hohe Taktfrequenz und Baudrate haben: Kein Problem oder zumindest probieren, dann weiß man's ...
165°C Temperaturdifferenz und RC Oszillator ist allg. eine sehr schlechte Idee. Auch ein Pic hat in so einem Fall arge Probleme mit der Frequenzstabilität. Am einfachsten wäre ein RC Oszi und RS232 mit RTS/CTS und X-Modem Protokoll.
Gast wrote: > 165°C Temperaturdifferenz und RC Oszillator ist allg. eine sehr > schlechte Idee. Kommt drauf an, wie genau die Frequenz während der Messung sein muss. Wenn die Schaltung vor dem Auslesen wieder auf Zimmertemperatur gebracht wird, ändert sich zumindestens fürs Auslesen nichts. Mit niedriger Baudrate kann es klappen, vor allem, wenn man den internen RC noch mal nachkalibirert. Andere Idee: Die Daten über irgendeine synchrone Schnittstelle ausgeben, evtl nen zweiten AVR als Schnittstellenwandler dazwischen.
Es gibt Quarze für den Erweiterten Temperaturbereich zu kaufen. Normale Quarze haben jenseits ihrer nominalen Temperatur zwar nicht mehr ihre Nennfrequenz, funktionieren aber immer noch genauer als ein Interner RC Oszillator. Quarze hören erst beim überschreiten der Curie-Temperatur auf zu Schwingen. Diese liegt mit über 500 Grad jenseits von Gut und Böse.
> Hier im Forum wird ständig verbreitet, dass serielle Kommunikation > mit dem internen Taktgeber nicht klappt. Wenn du das ein klein wenig umformulierst, wirds richtig: "Hier im Forum wird ständig verbreitet, dass serielle Kommunikation mit dem internen Taktgeber nicht zuverlässig klappt. Ich mach das auch mal mit interem Osz, sofern nur darum geht, in der Entwicklungsphase den Debug-Output seriell zu übertragen. Man sollte indes davon Abstand nehmen, produktiv so zu arbeiten.
@Netbird: > Das stimmt nach meinen Erfahrungen nicht allgemein: Richtig, allgemein kann es funktionieren, wenn der µC in einem sehr engen Temperaturbereich betrieben wird und der interne Oszillator entsprechend kalibriert ist. Für den vom OP angegebenen Temperaturbereich kann man allerdings mit 100%iger Sicherheit sagen, dass es ohne viel Zusatzaufwand definitiv nicht funktioniert. Schau Dir mal im Datenblatt die Frequenz-Temperatur-Diagramme an. Dann wirst Du schnell feststellen, dass das so nichts wird. Wie weiter oben bereits erwähnt gibt es in dem Temperaturbereich bereits mit Quarzen erhebliche Probleme. In so einem Fall braucht man einen RC-Oszillator gar nicht zu erwähnen. Die einzige mit vertretbarem Aufwand realisierbare Möglichkeit wäre eine Temperaturkompensation über das OSCCAL-Register des µC anhand der erwähnten Diagramme im Datenblatt. Dazu müsste die Temperatur des µC gemessen und der OSCCAL-Wert entsprechend angeglichen werden. @Uwe: > Mit niedriger Baudrate kann es klappen Der Fehler ist relativ und hat nichts mit der Baudrate zu tun, solange sich die betrachteten Baudraten bei der aktuellen CPU-Frequenz mit gleicher Genauigkeit einstellen lassen! Wenn Es mit 9600 Baud nicht klappt, dann auch nicht mit 2400 Baud oder so.
> Der Fehler ist relativ und hat nichts mit der Baudrate zu tun Bischen schon. Wenn man die begrenzten Fähigkeiten der Transceiver-Bausteine (z.B. MAX232, worst case: Optokoppler) mit in Rechnung stellt, kann es bei hohen Bitraten enger werden.
Ich wuerde mal die These aufstellen, dass irgend ein Quarz ueber diesen Temperaturbereich immer noch genauer ist als der RC. Schwingen tut der Quarz sicher von -70 bis +180Grad. Wenn sich bei -80Grad das CO2 abzulagern beginnt wird die Frequenz sinken.
Anderer Vorschlag: Der Host sendet zur Initialisierung der Messung z.B. 0xff an den Controller. Dieser misst die LOW Zeit für das Startbit am RX Pin und erhält daraus die Zeitkonstante für die serielle Übertragung. Damit wäre auch eine automatische Baudratenanpassung möglich. Bei 8 Takten je Messzyklus und U2X=1 kann der erhaltene Wert im X-Register direkt nach UBBR geschrieben werden. Messung:
1 | getbr: clr XL |
2 | clr XH |
3 | getbr1: sbic rxpin |
4 | rjmp getbr1 |
5 | getbr2: adiw XL,1 ;2 |
6 | sbic rxpin ;2 |
7 | rjmp getbr3 |
8 | nop ;1 |
9 | nop ;1 |
10 | rjmp getbr2 ;2 |
11 | getbr3: out UBBRL,XL |
12 | out UBBRH,XH |
13 | ret |
Je niedriger die Baudrate ist, um so größer und damit auch umso genauer wird der gemessene Wert. Gruß Jörg
Es gibt wie schon skizziert 2 Fehlerquellen: - Taktfrequenz: relativer Fehler - Verzögerungszeiten des Transceivers, teilweise unterschiedlich je nach Flanke: absoluter Fehler. Der Einfluss des absoluten Fehlers sinkt mit der Länge des gemessenen Zustands. Andersrum ausgedrückt: Wenn man nur die Länge vom Startbit misst, maximiert man den Einfluss des absoluten Fehlers.
Danke erstmal für die vielen Antworten... Also das auslesen der Daten
soll erstmal dann nach den Temperaturzyklen also bei Raumtemperatur
geschehen. So wie ich das jetzt hier verstanden habe sollte das bei
geringer Baudrate mit dem internen Oszillator gehen...
> Es gibt Quarze für den Erweiterten Temperaturbereich zu kaufen.
WO??? Hab bisher nur welche finden können von 0-70°C
Zum Temperaturbereich des Quarzes. Vergiss den. Es betrifft nur die Frequenz. Erstens ist die reversibel mit der Temperatur und zweitens liest du ja eh bei RT.
@Ralf: Fällt mir grad noch auf: Du schreibst, dass Dein µC von -40 bis +125°C spezifiziert ist. Hast Du etwa die Automotive-Version des AT90CAN128? Nach einem Blick in dessen Datenblatt habe ich nämlich mit einigem Erstaunen festgestellt, dass der RC-Oszi im AT90CAN Automotive im Vergleich zu den in den "normalen" AVRs verbauten eine relativ geringe Temperaturdrift besitzt (keine 5 % Abweichung über den gesamten Betriebstemperaturbereich). Wenn man den vernünftig kalibriert, dann könnte es sogar mit asynchroner Übertragung klappen. Aber das müsste man ausprobieren und das ganze steht und fällt dann natürlich mit einer ebenfalls sehr temperaturstabilen Spannungsversorgung. Ich habe allerdings generell den Eindruck, dass ATMEL bei den neueren AVRs qualitativ bessere Oszis einbaut als bei den älteren.
Ja, ist die Automotive-Version! Ok, ich werd bei dem Board vorsichtshalber ein Quarz + 2 C's vorsehen...nimmt ja nicht viel Platz weg. Versuche es dann mal mit beiden Varianten... Danke an alle!
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.