Hallo, ich weiß zwar, daß das Thema OSCCAL schon ein paar Mal diskutiert wurde, leider jedoch wohl nicht, wenn ein Quarz verwendet wird und OSCCAL nur für das interne EEPROM Bedeutung hat. Genau das ist bei mir der Fall. Ich hatte bisher einen 8535, der mit Quarz und internem EEPROM prima gearbeitet hat. Nun muss ich umsteigen auf mega8535. Es ist klar, daß ich die Fuses umstellen muss, damit die neue CPU den Quarz benutzt statt den RC-Oszillator. Unklar ist mir nur, warum das Teil dann scheinbar nicht in der Lage ist sich an diesem Quarz auch für das interne EEPROM zu orientieren. Laut Datenblatt nimmt das EEPROM bei mega8535 den 1MHz-Takt her. Damit wäre ich aber langsamer als bisher. Gibt es denn eine rasche Lösung ohne viel Assemblercode um das EEPROM wieder so schnell wie beim 8535 zu bekommen? Mehr will ich ja gar nicht. Präzisionsfanatiker bin ich an der Stelle nicht. Es muss halt funktionieren. Matthias
Hi >Unklar ist mir nur, warum das Teil dann scheinbar nicht in der Lage ist >sich an diesem Quarz auch für das interne EEPROM zu orientieren. 1. Das macht der AT90S8535 auch nicht. 2. Das Beschreiben einer EEPROM-Zelle benötigt eine bestimmte Zeit, die unabhängig von der Taktfrequenz des Controllers ist MfG Spess
@Spess: In der AVR086 zum Ersetzen des 8535 durch den Mega8535 steht auf S.7: Beim 8535 hängt die EEPROM-Schreibzeit von der Betriebsspannung ab. Bei 5V sind es typisch 2.5ms. Beim mega8535 benötigt die Schreibzeit 8448 Zyklen des calibrated RC-Oszillator. Wenn er nun auf 1MHz arbeitet (default) so liegt die Schreibzeit damit dann bei 8.4ms. Das ist also mehr als das 3-fache als das Vorgängermodell. Aus diesem Grund suche ich eine praktikable Abhilfe. Ich verwende 2 Quarze, einen mit 7.xx MHz und einen mit 32kHz. Nur nützen mir die wohl leider nichts, weil das EEPROM sich an dem ungenauen Oszillator orientiert. Es steht extra dabei, daß das Schreiben von OSCCAL die Frequenz des calibrated RC-Oszillator verändert und somit auch die EEPROM-Schreibzeit. Matthias
Hi Du kannst die Schreibzeit nicht einfach verkürzen, die ist systembedingt. Ich vermute, das die längere Schreibzeit bei den ATMegas durch eine andere EEPROM-Tchnologie bedingt ist, da sich andere Parameter (z.B.Schreibzyklen) verbessert haben. Hast du ein massives Problem damit? MfG Spess
Hi, ich verstehe nicht recht, warum die Teile nun so langsam geworden sind. Faktor 3 ist ja nicht von Pappe. Normalerweise werden die Strukturen ja kleiner und so sollte auch die Energiemenge kleiner werden, die da benötigt wird. EEPROMS hatten schon immer viele Zyklen. Nur die Flashs waren oft schlecht. Ich würde schon gerne die Angaben des Herstellers auch verstehen, wenn er da schreibt, daß die Schreibzeit an diesem Oszillator hängt. Im Datenblatt sah ich eine Tabelle, wo darüber stand, daß der calibrated Osc auf 1MHz, 2, 4 und 8 MHz laufen kann. Ist das dann mit dem EEPROM möglich oder muss jedesmal wenn man aufs EEPROM schreiben will auf 1MHz runtergeschaltet werden? So sehr klar ist das nicht beschrieben auf der Seite 30. Es steht da was von einer Nominalfrequenz. Nur was ist das? Sollen das die 1 MHz sein? 10% darf man da angeblich drüber gehen. Dann wären 2-8MHz ja nicht zulässig. Die Tabelle ist zudem reichlich unklar. Ich sehe da Werte von 50-200% für den RC-Oszi. Wenn die Nominalfrequenz 1MHz beträgt, so wären 50% davon 500kHz und 200% davon 2MHz. 4 oder 8MHz wären dann laut dieser Liste nicht möglich. Wie ist es denn jetzt nun? Ich werde aus dem Datenblatt nicht schlau. Matthias
In meinem Datenblatt steht, dass für das EEPROM grundsätzlich der 1 MHz-Oszillator verwendet wird, unabhängig von den CKSEL-Settings. Außerdem steht da, dass bei der Benutzung des EEPROM den Oszillator mit Hilfe von OSCCAL um nicht mehr als 10 % verändern soll.
@Johannes: Danke für den Hinweis auf Deine Interpretation des Datenblatts. Demnach ist das Teil 3x langsamer als früher und nicht schneller zu bekommen. Aus der Tabelle mit 50-200% für den RC-Oszi werde ich immer noch nicht schlau. Wenn die Nominalfrequenz 1MHz beträgt, so wären 50% davon 500kHz und 200% davon 2MHz. 4 oder 8MHz wären dann laut dieser Liste gar nicht möglich. Matthias
Matthias W. wrote: > 4 oder 8MHz wären dann laut dieser Liste > gar nicht möglich. Der ATMega8535 hat vier unterschiedliche RC-Kombinationen mit 1, 2, 4 und 8 MHz nomineller Frequenz. Welcher von denen aktiv ist, hängt von den CKSEL-Fuses ab. Und für jeden dieser 4 Takte gibt es zwei Diagramme im Datenblatt, eines für die Temperaturabhängigkeit der Frequenz und eines mit den OSCCAL-Werten... Warum das EEPROM-Schreiben jetzt langsamer ist, kann ich nicht sagen. Aber lt. Datenblatt dauert ein Schreibzugriff etwas über 8 ms. Und der Wert ist weitgehend konstant, da immer der 1 MHz-Oszillator benutzt wird.
@Johannes: wenn der RC-Oszi über fuses benutzt wird sehe ich aber ein Problem. Wenn die Fuses so stehen, daß der Oszi auf 8MHz laufen wie soll man dann auf das EEPROM zugreifen können? Die Fuses kann der Controller im Betrieb ja kaum temporär mal schnell umprogrammieren. Übrigens: Die Cksel-Fuses habe ich laut Datenblatt nun wie folgt für meinen externen Quarz eingestellt: CKopt 1 : 1 Cksel 3..1: 111 für 7MHz Quarz SUT 1..0: 10 für 4.1ms Startzeit wo nimmt jetzt das EEPROM seine Frequenz her, wenn mit genau diesen Fuses normaler- weise der RC Oszi verstellt wird? Auf der Seite 30 fand ich dazu nichts erhellendes. Oder hast Du da eine Seitenangabe für mich? Matthias
Matthias W. wrote: > wenn der RC-Oszi über fuses benutzt wird > sehe ich aber ein Problem. > > Wenn die Fuses so stehen, daß der Oszi auf 8MHz > laufen wie soll man dann auf das EEPROM > zugreifen können? Indem er weiterhin den 1MHz Oszillator für das EEPROM verwendet.
@Benedict: noch einmal zum Verständnis: Der mega8535 nimmt also den RC Oszi mit 1 Mhz für das EEPROM her, egal wie die Fuses nun stehen, die normaler- weise den RC Oszi umstellen? Ist das hardwaretechnisch erklärbar? Gibt es da ein Bild dazu? Matthias
Der RC-Oszi wird wohl immer mit 8 MHz laufen, die 1,2 und 4 MHz sind dann runtergeteilte Werte. Dann kann er immer die 1 MHz für das interne Timing verwenden. Wenn man dann aber z.B. die 8 MHz verwenden und diese auf z.B. 10 MHz hochsetzt sind die 1 MHz ebenfalls verstimmt, und das interne Timing wird nicht mehr eingehalten. Das ist allerdings nur meine Interpretation und ich bin nicht Atmel. /Atmel
/Atmel wrote: > Der RC-Oszi wird wohl immer mit 8 MHz laufen, die 1,2 und 4 MHz > sind dann runtergeteilte Werte. Nein. Das ist nur bei den neueren AVRs so (mega48 und ähnliche). Die alten haben wirklich 4 getrennte Oszillatoren, daher auch 4 unterschiedliche Werte für OSCCAL. @ Matthias W. Im mega8535 Datenblatt auf Seite 20: Unter "Table 1. EEPROM Programming Time" steht: Note: 1. Uses 1 MHz clock, independent of CKSEL Fuse settings.
Ich meinte mit "immer", daß es egal ist, wie die Fuses des MEGA8535 gesetzt sind. War halt verständlich wie das Orginal :-D /Atmel
Danke für die Hinweise. Danke auch an Benedikt für Seite 20 ! Wenn es 4 Oszillatoren sind kann das EEPROM sich den passenden ja raussuchen. Dann müsste es EEPROM jedenfalls hinhauen, auch wenn ich die Fuses für den externen Clock für 7MHz gewählt habe. Wählt der AVR automatisch auch die Fabrikkalibration aus? Unkalib. ist das Ding ja reichlich ungenau. Wenn ich mit dem Ponyprog reinschaue gibt er 169 aus. Bei den anderen chips könnte es ja anders sein. Muss ich da programmtechnisch beim Umstieg auf den mega8535 vom 8535 noch ein paar Zeilen Code einfügen um den RC-Oszillator zu tunen, oder ist das in diesem Fall nicht nötig? Beim 8535 musste ich da ja nichts tun. Matthias
> Wählt der AVR automatisch auch > die Fabrikkalibration aus? Das ist von Typ zu Typ unterschiedlich. Der Mega8535 kalibriert bei Reset nur den 1MHz-Oszillator. Schau Dir mal die Appnote AVR053 an: http://www.atmel.com/dyn/resources/prod_documents/doc2555.pdf Da steht so ziemlich alles Wissenswerte drin. ...
@Hannes: Danke für den Link. Ich fasse kurz zusammen, wie ich es verstehe: Da steht, daß eine Calib gemacht wurde im Werk, bei 5V. Prima. Dabei betreib ich das Teil ja auch. Sie reden davon das factory calib byte zu lesen und in den Speicher zu übertragen. Da die Fabrikcalib mindestens 10% genau ist bräuchte ich keine eigene Calib durchzuführen für die Nutzung des EEPROMs. Auch ok. Es steht hier wieder, daß die Fuses für die Nutzung des RC-Osz. entsprechend zu programmieren sind. Ich habe ja die Fuses für den externen Quarz programmiert. Es steht auch, daß bei den meisten Bausteinen der Fabrikwert aus der Signature Row automatisch geladen wird und nach OSCCAL kopiert. Wenn es beim mega8535 so wäre bräuchte ich ja nichts tun und nichts weiter beachten. Es wär ja schon ein ziemlicher Aufwand jedesmal mit einem Programmierwerkzeug das Calib byte aus der Signature Row auszulesen und dann in Flash oder EEPROM zu speichern, von wo aus das Hauptprogramm es dann umkopieren kann ins OSCCAL. Das EEPROM ist bei mir voll mit Daten. Bliebe also nur das Flash. Offenbar gibt es mehrere Oszillatorversionen. Der mega8535 steht nicht in der Liste AVR053. Da soll man dann in RC_Calibration.asm schauen. In dieser Datei, wenn man sie endlich findet (z.B. Beitrag "Frequenzkalibrierung") steht dann nicht gerade viel drin außer der Targetfrequenz und der Genauigkeit in %. Es wird includiert die m8535.asm, die dann die m8535def.inc einbindet. Leider weiß ich so nun immer noch nicht welche Oszillatorversion der mega8535 hat. Ich vermute mal daß es die Version 3.x ist. Es fällt mir schwer zu diesem Thema rasch brauchbare Infos zu finden. Überall steht ein bisschen was. Manches verwirrt, wie mich z.B. das Datenblatt des mega8535 zu diesem Thema. Siehe oben. Muss ich jetzt wirklich alle Datenblätter lesen? Matthias
Matthias W. wrote:
> Muss ich jetzt wirklich alle Datenblätter lesen?
Nein. Du musst nur das Datenblatt des ATMega8535 lesen. Da steht nämlich
klipp und klar drin, dass das 1 MHz-Calibration Byte automatisch geladen
wird. Wenn auf eine andere Frequenz kalibriert werden soll, dann muss
das betreffende Calibration Byte von Hand aus der Signature Row geladen
werden. Dafür wird aber weder irgendwelcher Speicher im EEPROM noch im
Flash benötigt (letzteres natürlich mit Ausnahme des zusätzlichen Codes
für das Umkopieren).
Ich verstehe allerdings absolut nicht, warum Du Dir überhaupt einen
Kopf wegen der Kalibrierung des internen RC-Oszillators machst, wenn Du
einen externen Oszillator als Taktquelle verwendest... Wenn Du einen
Quarz dran hast und die Fuses entsprechend konfiguriert sind, dann kann
Dir die Kalibrierung völlig egal sein. Die Kalibrierung und die damit
verbundenen Einschränkungen in Sachen OSCCAL sind nur dann relevant,
wenn Du einen der internen RC-Oszillatoren als Taktquelle verwendest und
diesen auf einer von seiner Nennfrequenz abweichenden Frequenz betreiben
willst, was eine erhebliche Änderung von OSCCAL zur Folge hätte.
@Johannes: Ich bin zufrieden, wenn ich sicher bin, daß ich es richtig gemacht habe. Ich hoffte ja alle wichtigen Infos in dem Blatt für den Umstieg vom 8535 auf den mega8535 zu finden. Leider bleiben Unklarheiten nach dem Lesen dieser Note und dem Lesen des mega8535-Datenblatts. Oben schriebst Du: In meinem Datenblatt steht, dass für das EEPROM grundsätzlich der 1 MHz-Oszillator verwendet wird, unabhängig von den CKSEL-Settings. Demnach ist damit der interne RC-Oszi gemeint. So hatte ich das Datenblatt auch verstanden. Wenn das 1 MHz-Calibration Byte automatisch geladen wird sollte es ja kein Problem geben. Danke ! Matthias
S. 239 im aktuellen Datenblatt (Abschnitt "Calibration Byte"):
1 | "The ATmega8535 stores four different calibration values for the internal RC Oscillator. |
2 | These bytes resides in the signature row high byte of the addresses 0x000, 0x0001, |
3 | 0x0002, and 0x0003 for 1, 2, 4, and 8 MHz respectively. During Reset, the 1 MHz value |
4 | is automatically loaded into the OSCCAL Register. If other frequencies are used, the |
5 | calibration value has to be loaded manually, see “Oscillator Calibration Register – OSCCAL” |
6 | on page 30 for details." |
@Johannes: Danke für den klaren Hinweis ! Mit Ponyprog 2.07 konnte ich den Wert auf 0x000 auslesen, also für die 1MHz. 169 steht da bei mir drin. Das Auslesen 0x0001, 0x0002 und 0x0003 brachte aber keine anderen Werte. Keine Ahnung warum da nichts kam. Ich tippte einfach diese Adressen in das Fenster und dann unten auf den Knopf. Egal, ich brauche die Werte für die anderen Frequenzen ja nicht. Ist halt schade, daß mir das Auslesen nicht gelang. Oder steht da überall 169 drin? Matthias
Offensichtlich gibt es 4 Speicherwerte und einen Oszillator.
@Oork: Das mit dem "einen" RC-Oszillator schien nicht so ganz klar. Siehe oben. Da gab es auch mal die Meinung, daß es 4 sein könnten: "Die alten haben wirklich 4 getrennte Oszillatoren" Der Text "values for the" deutet wieder auf einen einzigen hin. An einen der Speicherwerte kam ich ran, an die anderen nicht - warum auch immer. Matthias
Es gibt vier Oszillatoren! andernfalls wäre es gar nicht möglich, dass für das EEPROM immer der 1 MHz-Takt verwendet wird, auch wenn ein anderer RC-Takt aktiv ist. Es gibt aber nur ein OSCCAL-Register, und deshalb ist es wichtig, dass bei der Verwendung eines der internen Oszillatoren als Haupttakt der OSCCAL-Wert nicht zu stark verändert wird. Die Kalibrierungswerte selbst haben untereinander i.d.R. nur relativ geringe Abweichungen, weshalb es praktisch egal ist, ob der 1 MHz-Wert im OSCCAL steht oder der 4 MHz-Wert. BTW: Wenn Du nach der Application Note gehst, wäre das ein Oszillator vom Typ 3.
> Offenbar gibt es mehrere Oszillatorversionen. > Der mega8535 steht nicht in der Liste AVR053. Die neueste Version habe ich noch nicht gelesen, aber die ältere Version von AVR053 (von der STK500-CDROM) stuft den Mega8535 in Kalibrationsmode 3.0 ein. > Mit Ponyprog 2.07 konnte ich den Wert auf 0x000 > auslesen, also für die 1MHz. 169 steht da bei mir > drin. Ponyprog ist nicht das Maß der Dinge, soviel ich weiß (ich nutze es nicht), kann es nur das Calibrationsbyte an Adresse 0 auslesen. Das Auslesen der anderen drei Adressen sind nicht in Ponyprog implementiert. Schau mal im Datenblatt des Mega8535 bei der Beschreibung des ISP-Protokolls, da siehst Du, dass es mehr Möglichkeiten gibt, als Ponyprog bietet. Meiner Meinung nach bezieht sich die Warnung betreffs OSCCAL und EEP nur darauf, dass man die internen Oszilklatoren nicht "übertakten" soll, da dies die EEP-Zugriffe unzuverlässig macht. Bei externem (baudratentauglichen) Quarz habe ich noch nie Probleme gehabt und hatte mich auch nicht an OSCCAL vergriffen (wozu auch?). Das Einzige, was ich (fast) immer mache: Ich setze nach jedem EEP-Zugriff EEAR auf eine unbenutzte Adresse. Das stammt noch aus der Zeit der Classic-AVRs und hat sich als Schutz gegen versehentliches Löschen einzelner EEP-Zellen bewährt. ...
@Hannes: Danke für Deine Version 2555C-AVR-02/04 der Datei. Da steht ja wirklich etwas von Version 3 beim mega8535. In der neueren Version 2555G-AVR-05/06, die ich hatte steht nichts mehr vom mega8535, so als ob es das Teil nicht mehr gäbe. Seltsam. Dabei gibt es das Teil ja bei Rei..... aktuell zu kaufen. Welches Tool nimmst Du denn statt dem Ponyprog her? Seit 2002 war ich mit dem Pony recht zufrieden. Ich hatte eine Menge Probleme mit dem internen EEPROM bei den alten 8535, bis ich dann einen Spannungsregler mit Reset-Ausgang von TI verwendete. Damit waren die Probleme fort. Irgendwann sank wohl die Spannung ab und so wurde das EEPROM verändert durch Unsinn, den die CPU dann wohl anstellte. Wie gesagt - keinerlei Probleme mehr seit ich den Reset am Spannungsregler nutze und nicht den Powergood so wie zuvor. Matthias
> Welches Tool nimmst Du denn statt dem Ponyprog her? Ich benutze seit einigen Jahren nur noch das AVR-Studio mit STK500 bzw. Dragon. Davor nutzte ich einen Eigenbau, da Pony bei mir nicht lief (was vermutlich mit zu langen Leitungen zu tun hatte): http://www.hanneslux.de/avr/isp/isp.html Diesen Eigenbau würde ich (heute) niemandem mehr empfehlen, er wird auch schon lange nicht mehr gepflegt. Beim Erstellen der QB-Software musste ich mich allerdings intensiv mit dem ISP-Protokoll beschäftigen, der damals zuerst verwendete AT90S1200 verhält sich auch noch etwas zickig. Meine Soft liest übrigens bei jedem Brennen eines calibrierbaren AVRs das zum Takt passende Calibrationsbyte aus und fügt es am Flash-Ende (letzte Zelle, L- und H-Byte) ein, falls dort kein Programmcode ist. Das erlaubte sehr einfaches Calibrieren per Software, besonders bei Tiny12 und Tiny15, die ja bei Reset nicht automatisch calibriert werden. > so als ob es das Teil nicht mehr gäbe. Der Tiny26 wurde damals auch vergessen, er verhielt sich aber wie Mega8/8515/8535. ;-) > Ich hatte eine Menge Probleme mit dem internen EEPROM bei den alten > 8535, Ich anfangs auch. Dann fiel mir auf, dass immer die Zelle gelöscht/verändert wurde, auf die beim langsamen Absinken der Spannung beim Ausschalten das Adressregister zeigte. Also setzte ich nach jedem Zugriff das Adressregister auf eine unbenutzte Zelle (meist Adresse 0) und schon hatte die Vergesslichkeit ein Ende. Bei den Tinies und Megas gibt es ja BOD, wenn das aktiviert ist, gibt es auch keine Probleme mehr mit dem EEP. ...
@Hannes: Danke für den Hinweis auf Deine Tool-Kette. Das hat sicher eine Menge Zeit gekostet die Hardware aufzubauen und das ausgefeilte Programm zu schreiben. Ich weiß wie lange ich damals an meinem Zapper baute und programmierte an Code und Oberfläche. Immer wieder gab es überraschende Fehler. Das AVR-Studio verwendete ich nicht so gerne. Ich benötigte bald den Assembler mit der Möglichkeit defines zu verwalten. Beim Studio fand ich auf die Schnelle nicht die Einstellung, daß ein EEPROM-file mit erstellt wurde. Mit der Kommandozeilenversion avrasm2 kam ich schneller zu Ergebnissen. Mit einem Tiny hatte ich auch mal was gemacht. Bei der Programmierung der Fuses war die Logik von Ponyprog anders rum und am Ende hatte ich wohl den RC-Oszillator abgeschaltet und konnte das Teil auf die einfache Art nicht mehr verwenden. Das ist alles schon ein paar Jahre her. Matthias
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.