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
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.