Hi @ all,
bei meinem nächsten Projekt würde es sich anbieten den internen
Oszillator zu
benutzen, um die XTAL-Pins als I/O zu gebrauchen.
Was mich aber verunsichert:
im Mega8 Manual steht auf S.28 (internal RC Oszillator):
"when this oscillator is selected, ... XTAL1 and XTAL2 should be left
unconnected".
auf Seite 56 (alternate Port Functions PortB):
"when using internal calibrated oscillator (...) PB6/7 functions as
ordinary I/O pin".
Kann mir das jemand erklären oder benutzt (mit internem Takt) jemand die
XTAL-Pins
als I/O ?
Zusatzfragen:
hat hier jemand Erfahrungen, ob -bei internem Takt- das USART-Timing
üblicherweise
noch hinreichend genau ist und ob das Timing bei intern 2-4-8 MHz
schlechter oder gar
unbrauchbar wird (es geht um die Kommunikation mit PCs und anderen
industriell gefertigten
Devices mit ser.SS).
Hat jemand schon mal das "Oscillator Calibration Reg." benutzt und kann
mir sagen, wie
man das macht ? Aus dem Manual werde ich da nicht richtig schlau.
Schöne Grüße
Gunter
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
