www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Taktquelle ändern


Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist blöd, weil du nicht verrätst, um welchen µC es geht.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
at90can128 von atmel

Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das geht mit den AVR nicht.  Die MSP430 koennen das. Die AVR 
koennen vom Hauptoszillator auf einen 32kHz schalten, das war's

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke...das hilft mir dann schon mal...oder auch nicht

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Du könntest evtl. eine externe Taktquelle benutzen.Wenn die thermisch
abgeschirmt ist, erübrigt sich die Umschaltung.

MfG Spess

Autor: Netbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Currywurst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
getbr:   clr   XL
         clr   XH
getbr1:  sbic  rxpin
         rjmp  getbr1
getbr2:  adiw  XL,1       ;2
         sbic  rxpin      ;2
         rjmp  getbr3
         nop              ;1
         nop              ;1
         rjmp  getbr2     ;2
getbr3:  out   UBBRL,XL
         out   UBBRH,XH
         ret  

Je niedriger die Baudrate ist, um so größer und damit auch umso genauer 
wird der gemessene Wert.

Gruß Jörg


Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.