Kann mir einer sagen, wie ich das Kalibrierungsbyte des ATtin15 zum einstellen des internen Oszillators auf Normwert softwaremäßig auslesen und in das OCCAL-Reg. schreiben kann. Das Kalibrierbyte soll NICHT z. B. mit PonyProg ausgelesen und dann hart ins OCCAL-Reg. geschrieben werden.
das OSCCAL-Byte kann nur über einen Programmer gelesen werden und dann im programmspeicher oder im eeprom abgelegt werden!
Das Kalibrierungsbyte steht immer in der letzten Flash-Adresse. Du kannst es also per LPM auslesen. Damit das klappt, darfst Du aber vor dem Programmieren den ATTiny15 nicht löschen ! Peter
Also ich habe mit PonyProg (Befehl: Löschen) den Prozessor mehrfach gelöscht und wieder neu beschrieben. Das Kalibrierungsbyte kann mit PonyProg immer wieder ausgelesen werden! ? Im Manual S.55 des ATtiny15 steht, daß das Kalibrierungsbyte im "signature address space" steht. Ist der noch was anderes?
Ja, der ist wieder was anderes. Steht aber alles soweit ich weiß auch im Datenblatt, wie man diese Bereiche liest (signature+calbyte sind nicht löschbar!)
Wenn mir jetzt noch einer die konkrete Befehlsfolge zum auslesen dieses Kalibrierungsbytes beim ATtiny15 schickt, wäre das Super.
"Das Kalibrierungsbyte kann mit PonyProg immer wieder ausgelesen werden!" Ja, aber eben nicht mehr aus dem Flash. Da steht es nur drin, wenn der Chip nagelneu ist. Peter
Würde auch zu gerne wissen wie man die Signaturbytes per µC-Programm auslesen kann. Fand im Datenblatt nur den Hinweis, man möge das Kalibrierbyte doch auslesen um es dann im FLASH abzulegen. Im Befehlssatz hab ich auch nichts gefunden. Ich vermute inzwischen schon, dass ein direktes Auslesen per µC-Programm nicht möglich ist. Bei jedem neuen Chip mit einem Programmer erst das FLASH oder das EEPROM (da stehts auch in der letzten Speicherzelle) oder direkt das Signaturbyte auszulesen um dann mit der Hand das gefundene Kalibrierungsbyte im Quellcode eintragen damit es wieder im FLASH landet nachdem es PonyProg gelöscht hat, dann neu zu übersetzen und schließlich zu Programmieren ist nicht besonders bequem. Kennt denn niemand einen einfacheren Weg?
Also nochmal ganz langsam: Während der Entwicklung mußt Du ja immer neu löschen, da liest Du es eben zuerst aus und schreibst es per .DB Anweisung an die letzte Adresse. In der Massenproduktion nimmst Du dann diese .DB-Anweisung wieder raus und programmierst alle ohne sie vorher zu löschen. D.h. dann wird automatisch das Byte genommen, was von Atmel dort schon reinprogrammiert wurde. Peter
Danke, Peter, jetzt habe ich wenigstens die Bestätigung meiner Vermutung, dass ATMEL bei allen kalibrierbaren Typen das Kalibrationsbyte in die letzte Zelle des Flash schreibt. Meine (Selfmade-) ISP-Soft (QB) liest inzwischen beim Löschen automatisch das Kalibrationsbyte aus und schreibt es in die letzte Flash-Zelle (High und Low). - Natürlich nur, wenn das Programm die letzte Zelle nicht belegt, was ja praktisch immer der Fall ist... So kann ich (vorerst den Tiny12 und 15, andere werden folgen) in der Reset-Routine per LPM kalibrieren. Ob andere ISP-Soft das auch anbietet, weiß ich leider nicht. Ich benutze eine Eigenentwicklung, da ich zu blöd war, Pony-ISP zum Laufen zu bringen... ;-(( Bit- & Bytebruch... - ...HanneS...
@Peter "Während der Entwicklung mußt Du ja immer neu löschen, da liest Du es eben zuerst aus und schreibst es per .DB Anweisung an die letzte Adresse." Genauso mach ich es ja momentan. Solange ich in der Entwicklungsphase mit ein- und demselben Teil arbeite ist das auch kein Problem. Die für dieses Teil passende .DB Anweisung steht halt einfach im Quellcode mit drin. "In der Massenproduktion nimmst Du dann diese .DB-Anweisung wieder raus und programmierst alle ohne sie vorher zu löschen. D.h. dann wird automatisch das Byte genommen, was von Atmel dort schon reinprogrammiert wurde." Dachte ich auch. Aber ich habe bisher nur mit PonyProg erfolgreich meinen ATtiny15 programmieren können. Und PonyProg löscht automatisch vor jedem Programmieren nicht nur das FLASH sondern auch das EEPROM. Es hilft also nicht, die .DB-Anweisung herauszunehmen und die vorderen FFs eines neuen Teils einfach mit dem Programm zu überschreiben. PonyProg hat vor dem eigentlichen Programmieren ja das FLASH und das EEPROM bereits bis zum Ende hindurch gelöscht. Weiss jemand mit Sicherheit, dass das Kalibrier- bzw. die Signaturbytes nicht per Programm vom Controller selber auslesbar sind? Dann könnte ich mir weitere Gedanken darüber sparen. Super wäre natürlich wenn jemand weiss wie es geht und bereit ist sein Wissen zu teilen. Oder weiss jemand wie man PonyProg dazu überreden kann das EEPROM nicht vor einer Programmierung des FLASH zu löschen. Dann könnte man das Datum im EEPROM nutzen und das Problem wäre zumindest teilweise behoben. Andi
Vom Controller selbst ist dieser Adressbereich (signature+calbyte) nicht auslesbar! Nur über externen Zugriff!
Ich verwende das STK500 mit AVR Studio 4.0x, da kann man den Programmiervorgang automatisieren: Flash löschen, Programmieren, EEprom Löschen,Programmieren, OSCCAL-Byte automatisch an eine Programm oder EEprom-Adresse schreiben, Fuse und Lockbits setzen alles in einem Durchgang!
In der Atmel Application Note gibts noch einige Hintergründe zum OSCCAL-Byte, da steht z.B, dass bei Typen mit Internen Oszillatoren ab version 3 (mega8,16,32...) das Osccal-Byte automatisch beim Systemstart gelesen und in das entsprechende Register transferiert wird. Nur bei Tiny12/15/Mega163/323 muss man das manuell machen. Allerdings wird man die Mega-Typen eher seltener mit RC-Oszillator verwenden....
Hallo, rätsel immer noch über dem Kalibrierungsbyte-Problem. Wenn ich das datasheet richtig verstehe, müßte die Controller-Software das Kalibrierungsbyte selber auslesen können. Wie ist den Eurer aktueller Wissenstand zu diesem Problem? Kann die Controller-Software das Kal-Byte nun selber nach RESET auslesen und ins OSCCAL-Register schreiben, oder definitiv nicht?????? Wenn ja, wie sieht der Befehlsatz (C-Compiler) aus???? Danke an Euch. Gruß Andreas
Hi... Der Controller bzw. die in ihm laufende Software kann das Kalibrationsbyte NICHT auslesen. Bei neuen (ungelöschten) Chips schreibt ATMEL das Byte zusätzlich in die letzte Flash-Zelle (Highbyte und Lowbyte). Von dort kann es deine Anwendersoft per LPM lesen und nach OSCCAL schreiben. Hast du den AVR gelöscht, dann ist dieses Byte auch mit weg. Dann musst du mit deinem ISP-Programm das Kalibrationsbyte aus dem Signature-Bereich (Adr.0, High-Byte) des AVR lesen und in deinem Programm per .DB-Anweisung in die letzte Flash-Zelle schreiben. Mein Eigenbau-ISP-Programm macht das inzwischen beim Löschen von Tiny12/15 und Calversion3-Typen automatisch. Es liest den Wert aus dem High-Byte des Signature-Bereichs und schreibt es in H- und L-Byte der letzten Flashzelle. Bei CalVers.3-Typen natürlich gemäß der per Fuse-Bits eingestellten Frequenz. @Markus Vohburger: Die AVRs nach Kalibrationsversion 3 (Tiny26, Mega8, Mega85xx usw...) lesen beim PowerOn-Reset das Kalibrationsbyte automatisch nach OSCCAL ein, aber nur dann, wenn der interne 1MHz-Oszillator aktiv ist. Ist der interne Oszillator auf 2, 4 oder 8MHz eingestellt, so ist die Kalibration von Hand zu machen, so wie beim Tiny12/Tiny15. Die Kalibrationsbytes stehen in den H-Bytes des Signature-Bereichs an Adresse 1, 2 und 3 (bei 0 steht das Byte für 1MHz)... Bit- & Bytebruch... ...HanneS...
Hallo, danke für Deine Antwort!! Ich habe mit dem Attiny15l vier Fahrtregler und drei Servosteller gebastelt. Also eine sehr sehr kleine "Massenproduktion". Wenn der Aufwand mit dem Autokalibrieren doch so groß ist, ist der Weg das Kal-byte mit Ponyprog2000 auszulesen, um es per Hand in der Controllersoftware in das OSCCAL-Register zu schreiben, scheinbar doch der einfacherer. Dumm nur, dass ich so die einzelen Chips immer mit einem kleinen Nummernaufkleber markieren muß und für jeden Chip eine eigene c-Datei anlegen muß. Ich arbeite zur Zeit nur mit dem ICCtiny 6.11 C-Compiler von Imagecraft. Gruß Andreas
Hi Andreas... Nix zu danken. Ich hatte mich mal intensiv mit der Kalibration des Tiny12/15 befasst, weil ich für einen Freund einen Fahrtregler programmieren sollte. Beim (mühsamen) Lesen der Dokumentationen (Datenblätter, Appnotes) stellte ich fest, das auch ein Teil der Megas (die mit Kalib-Version 3) von Hand kalibriert werden muss wenn sie nicht mit 1MHz laufen. Dies, und die Tatsache, dass ATMEL bei Auslieferung das Kalibrationsbyte in die letzte Flash-Zelle schreibt, brachte mich dazu, mein ISP-Programm beim Löschen eines kalibrationsfähigen AVR das Kalbyte auslesen und in den Flash eintragen zu lassen. Dass ich einen (zu nix kompatiblen) ISP-Eigenbau benutze, hat damit zu tun, dass Pony und einige andere Tools (Kommandozeilen-Ebene) bei mir nicht funktionierten. Damals war ich ratlos und half mir mit Eigenbau, heute vermute ich, dass Parallel-Verlängerungskabel und Drucker-Umschalter die Ursache waren. Übrigens: Mein Fahrtregler ist per Taste programmierbar (Neutralstellung, Maximaltempo vorwärts) und steuert neben einer H-Brücke noch ein Rückfahrlicht und ein Bremslicht an. Die Programmierung erfolgte allerdings in Assembler (AVR-Studio), an C traue ich mich mangels Wissen noch nicht ran. @Andi: Ich arbeite zwar nicht mit Pony, aber kannst du nicht so vorgehen?: - Hexdatei mit Pony öffnen, - Calbyte aus AVR auslesen, - Calbyte von Hand in die letzten beiden Bytes des Flash-Hexdumps eintragen, - AVR programmieren. Das müsste eigentlich gehen... Bit- & Bytebruch... ...HanneS...
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.