Forum: Mikrocontroller und Digitale Elektronik Mega8 - internal Oscillator - XTAL1/2 Pins

Wenn der interne R/C Oszillator genutzt wird können PB6 und PB7 für I/O 
verwendet werden.
Die Stabilität des internen R/C Oszillator ist für seriellen 
Kommunikation ausreichend. Hier kommt es allerdings auf die Baudrate an. 
Ebenso sind Spannungs- und Temperaturdrift siehe Seite 250-257 im 
Datenblatt zu berücksichtigen.

hi mikki,
Danke für Deine Antwort! :-)
>Wenn der interne R/C Oszillator genutzt wird können PB6 und PB7 für I/O verwendet 
werden
hasr Du das schon getestet ?

>Die Stabilität des internen R/C Oszillator ist für seriellen Kommunikation 
ausreichend.
>Hier kommt es allerdings auf die Baudrate an.
ich möchte den Default 9.6/n/8/1 benutzen. Das sollte ja dann keine 
Probleme machen ?!

>Ebenso sind Spannungs- und Temperaturdrift ... zu berücksichtigen.
das dürfte bei mir auch kein Problem sein (Büroanwendung, 7805).

Wie sieht's aus, wenn ich den int. Clock auf 8 MHz stelle ?
Dann muß ich ja wohl die "Calibration Bytes" anfassen.

Die Ecke ist mir noch völlig unklar.

thx again
gunter

Von einer Verwendung des internen RC-Oszillators bei 
UART-Datenverbindungen muß ich abraten: das Datenblatt sieht sehr gut 
aus - die Realität nicht.

'Normalerweise' kann man beim UART-Takt bis zu +/-3% akzeptieren, was 
die ATmega auch scheinbar bieten. In der Praxis lieferte eine Reihe von 
MPUs (mega8, mega16, mega128) bei 8MHz einen Taktfehler von -1,5 -> -2% 
unter Verwendung des eingebrannten calibration-byte - bei Raumtemperatur 
und 5V. Dies hatte zur Folge, daß ein PC die gesendeten Daten richtig, 
ein mit einem Quarz betriebener ATmega diese aber nicht mehr erkennen 
konnte.

Einzelstücke kann man nachträglich abgleichen, für eine Serie kann ich 
nur Quarz (dann auch gleich 16MHz) oder keram. Resonator empfehlen. Bei 
Atmel sollte man vielleicht die Uhren mit frischem Sand füllen.

Hi Michael,

Danke für diese wertvollen Infos !!!

Ich beschäftige mich nicht erst seit gestern mit uP's (Z80, 6502 und 
Konsorten kenne ich noch gut).
Wie Du schreibst, hat mich mein unangenehmes Gefühl (bzgl. 
RC-Oszillator-) da ja wohl nicht getrogen.

>Einzelstücke kann man nachträglich abgleichen
Vielleicht geht es bei diesem Projekt um Serie - dann aber um 
Stückzahlen, die durchaus noch einzeln abgeglichen werden könnten.

Mich würde interessieren, wie man das sinnvoll macht !
Mit 'nem Testprogramm ständig $AA bzw. $55 ausgeben und mit'm Oszi die 
Zeiten messen ?

Schönen Gruß
Gunter

Hallo nochmal,

das Problem mit dem Calibration Byte hat sich erledigt !

Danke für Eure Tips !  :-)))


Wen's interessiert - nachfolgend meine "Erkenntnisse":

das Cal.Byte kann Pony-Prog lesen (Menu Command).
bei meinem (ersten) Mega8 ist der Wert 158 (dez.)

ich habe für meine Tests 9600 Bd eingestellt, was für 10 Bit eine Zeit 
von 1041,6666... usec ergeben sollte.

mit 16MHz Quarz konnte ich keinen Fehler messen: 1042 usec

mit internen 8MHz habe ich zunächst 1026 usec gemessen also +1,5%

nachdem ich das Cal.Byte mit 155 (dez.) geladen habe, messe ich 1044 
usec, also -0,2%.

Thema Serienfertigung:

vier weitere Mega8 (aus der gleichen Herstellungswoche / Charge? ) 
ergaben mit diesem Programm -0,2%, +0,4%, +1,5% und +2,1% (!!!). Alles 
bei Raumtemperatur.

Also kann man Michael nur recht geben:
entweder auf den int. Oszillator verzichten oder jeden uC einzeln 
kalibrieren.

Schöne Grüße
Gunter

Hallo Gunter,

vielen Dank für Deine  Messungen und Deine Bestätigung.

Bei den neueren ATmegas habe ich ein weiteres Problem, was ich im Auge 
behalten werde: ich finde im gelöschten EEPROM ein paar Bytes mit dem 
Wert 0x7f, obwohl ich diese Plätze nie angesprochen habe - interner 
brownout aktiv. Dies fällt auf, seit ich das EEPROM mit dem Löschschutz 
bei Neuprogrammierung versehen habe; früher wurde immer alles platt 
gemacht Flash+EEPROM.

Vielleicht hat noch jemand gleiche Beobachtungen gemacht ?

Michael

Hi,

hätte da auch noch ne Frage dazu. Wie sieht es denn mit I²C und SPI bei 
Gebrauch des internen Oszillators aus? Kann es da Probleme geben?
Sollte eigentlich nicht, da der Takt ja jeweils vom sendenden Controller 
erzeugt wird, oder?


Gruß, ERDI - Soft.

Hi,

Nachtrag:
mit dem internen RC-Oszillator kann ich die XTAL-Pins problemlos 
benutzen.
Was mir der Satz auf S.28 des Manuals sagen will (siehe 1.Posting) ist 
mir weiterhin schleierhaft.

@Michael
>vielen Dank für Deine Messungen
der Informationsfluß hier soll ja keine Einbahnstraße sein !

Zum EEProm kann ich Dir leider nichts sagen. Ich mache auch (noch) alles 
platt und habe noch nicht mal den Brownout aktiviert. Bislang keine 
Probleme. Dennoch liest man hier ja öfter von Problemen mit dem EEProm. 
Neulich berichtete ein "Kollege" er speichere die Daten zwei Mal und 
prüft diese mittels Checksumme ...

@ERDI - Soft
I²C und SPI sind ja synchrone Protokolle. Die sind davon nicht 
betroffen.
Betroffen ist wiederum das EEProm. Im Manual steht eine Warnung, das 
CalibrationByte nicht zu sehr zu verändern
(Mega8 Manual, S.29).

Gunter

nur mal so als gedanke,
der besagte satz des datenblattes bezieht sich sicherlich auf xtal1 und 
2, und nicht auf die alternativfunktion der pins, sprich wenn diese als 
normale io dinger verwendet werden, dann sind doch xtal immer noch 
unconected, oder?

Hallo Gunter,

das Datenblatt vom Mega8 ist wohl die abgemagerte Version des 
Datenblattes vom Mega16. Dort findet man den gleichen Hinweis auf die 
XTAL-Pins: beim Mega8 einfach ignorieren. Bei allen Datenblättern muß 
man immer auch zwischen den Zeilen lesen!

Die Probleme, die gewöhnlich dem EEPROM zugeschrieben werden, beruhen 
zumeist auf einer fehlenden Resetschaltung. Ich bin auch zurückhaltend, 
Gerüchte über Fehler anzunehmen, wenn man nicht weiß, wie andere Leute 
ihre Bauteile handhaben.

Vielleicht aktivierst Du bei Dir den brownout (bit 6+7 vom fuse high 
byte) und verbietest das Löschen des EEPROM (bit 3 vom fuse low byte) 
und liest sporadisch das EEPROM aus, ob dort Werte != 0xff stehen. Bei 
diesen Einstellungen der fusebytes dürfte das nicht auftreten.
Auf Grund Deiner Z80+6502 Vergangenheit wirst Du sicherlich kompetente 
Auskunft geben können, ob das EEPROM stabil arbeitet.

Michael

Hi Michael,

>Bei allen Datenblättern muß man immer auch zwischen den Zeilen lesen!
Naja - mit "should be unconnected" meinen die Amis ja "_darf_ nichts 
angeschlossen werden". Ist schon ein grober Schnitzer! Wo ich da schon 
öfter gestolpert bin, sind die Fußnoten in winziger Schrift meist unter 
Tabellen. Es gibt Datenblätter, da stehen da (und nur da) extrem 
wichtige Informationen ...

>fehlenden Resetschaltung.
Tja - auch da habe ich nur ein RC-Glied

>Vielleicht aktivierst Du bei Dir den brownout ...
werde ich am WE wirklich mal tun. Vielleicht verkauft meine Firma ja die 
Mimik und dann muß das EEProm zu 100% funktionieren.

>Auf Grund Deiner Z80+6502 Vergangenheit ...
oooch, das waren doch nur Beispiele.
Angefangen habe ich mit Fortran und Lochkarten. Dann Assembler und 
Pascal auf einer DEC PDP11. Zwischendurch mal als Praktikum PID-Regelung 
in 8048 Assembler. Dann PL/1, CICS, Cobol. Später Assembler auf einer 
Tandem. Dann kam 68HC11 für Regelungen und NEC V25 für CCD-Kameras ...
Nur an Basic bin ich irgendwie vorbeigekommen :-)

Und weil ich jetzt beruflich fast ausschließlich mit Netzwerken zu tun 
habe, wollte ich privat wieder mal etwas mit uPs basteln und schon 
entstehen in meiner Firma Ideen, welche Probleme damit sicher lösen 
könnte.

Schöne Grüße
Gunter

Hi all,

@Michael
wie angekündigt habe ich am WE den Brownout und den EEProm-Schutz 
eingeschaltet.
Das Programm hat die Nacht von Fr. auf Sa. seine Runden gedreht -> keine 
Probleme.

Sa. und So. habe ich dann den Mega8 mindestens 100 Mal neu programmiert.
Die Betriebsspannung habe ich dabei aber nur selten abgeschaltet.

Sa. hatte ich den Programmer eingestellt, daß er versucht hat das EEProm 
zu schreiben,
So. hatte ich das Schreiben abgeschaltet -->
keine Probleme: sowohl die Testroutine, als auch das Einlesen des 
EEProms mit dem
Programmer bestätigten: überall  "hex FF".

Hast Du den Eindruck, daß die "7F-Probleme" beim Anlegen der 
Betriebsspannung kommen ?
Oder hast Du die Fehler schon beim Programmieren beobachtet ?

Ich werde am 1.Mai mal probieren, alle 10 sek. (mit meinem 
Frequenzgenerator) die Netz-
spannung aus- und einzuschalten (unbeaufsichtigt möchte ich das nicht 
tun) und -bei einem
Fehler (irgendwo <> $FF, wie der Pascal'er sagt) - das komplette EEProm 
mit "0" zu beschreiben.


Bis dann
Gunter