Hallo zusammen, Ich bräuchte mal einen Tip oder ein Statement ob es möglich ist... Im Programmerdialog des AVR Studio kann man über den Atmel ICE aus dem Signaturbereich die Kalibrierungsbytes für die möglichen Frequenzen des internen RC-Oszillators auslesen und an eine beliebige Speicherzelle des Flash oder EEPROMs schreiben um es dann von dort im Programmcode in das OSCCAL-Register zu transferieren und damit den RC-Oszillator auf eine relativ genaue Arbeitsfrequenz zu trimmen. So weit so gut. Wenn ich nun einige Dutzend von den AVR zu brennen habe, ist diese manuelle Vorgehensweise doch recht lästig, aufwendig und zeitraubend. Das muss sich doch automatisieren lassen. Fuses lassen sich doch auch aus dem Quellcode schreiben ... .elf-File?, ... Makefile?... Was Studio und der ICE manuell kann, muss sich doch automatisieren lassen. Insbesondere etwas von dem man liest, dass es einige Programmer beherrschen sollen. Leider liest man nie welche! Google hat mich nicht weitergebracht. Vielleicht könnt ihr mir helfen wie's automatisch geht ??? Danke schon mal Ede_Wolf PS:ATMega16A
Hi Dann papp einfach einen Quarz oder REsunator dran. MfG Spess
Hi REsunator -> Resonator MfG Spess
Die im Atmel gespeicherten Kalibrierbytes werden doch automatisch beim Reset in das OSCCAL eingetragen. Nur wenn Du es besser als die Fabrik mache willst, kannst Du die Teile ausmessen und manuell kalibrieren. Oder Du machst es zur Laufzeit mit einem externen Referenztakt von einem UART oder einem anderen zeitstabilen Signal, dessen Periode Du mit der internen Zeit vergleichst und entsprechend gegensteuerst.
Aähmmm, ... ich hatte vergessen hinzuzufügen dass die Frage sich auf die Automatisierung zum Einfügen des Osccal- Bytes beim Programmieren bezieht und nicht auf das mögliche nachträgliche Einfügen von Quarzen oder Resonatoren in fertige Hardware !?!? Ja, es wird ein Kalibrierungwert beim Reset in das OSCCAL eingetragen. Aber eben nur der für die Taktfrequenz von 1MHz. Wenn ich 8 MHz benutze, muss ich den Kalibrierungswert selbst manuell einfügen. -> So sagt zumindest das Datenblatt.
:
Bearbeitet durch User
Schau mal in einen fabrikneuen AVR, da stehen schon die Kalibrierbytes am Ende des Flash und des EEPROM. Du darfst nur vor dem Programmieren nicht löschen, dann bleiben sie erhalten.
Also ich meine mich dunkel erinnern zu können daß der avrdude einen Kommandozeilenswitch hat der sich darauf bezieht, hab das aber nie selbst angewendet. Ich war einmal in der Verlegenheit das OSCCAL verwenden zu müssen, da hab ichs dann am Ende ganz pragmatisch so gelöst daß das Gerät sich beim Einschalten selbst kalibrieren konnte anhand eines von außen angelegten Signals bekannter Pulslänge, das hat es gemessen und seinen OSCCAL entsprechend korrigiert. Das wurde ganz am Schluss mit dem fertig aufgebauten Gerät im Rahmen des Endtests durchgeführt, das Kalibriersignal wurde bequemerweise mit dem ohnehin in dem Moment angeschlossenen PC-USB-UART generiert, also keine zusätzliche Hardware nötig.
:
Bearbeitet durch User
Thomas E. schrieb im Beitrag #4912290: > E. S. schrieb: >> Aähmmm, ... ich hatte vergessen hinzuzufügen > > Du hast vor allen Dingen vergessen, hinzuzufügen, welchen Sinn das haben > soll. Das erschließt sich nämlich niemandem. Hm, ...ich möchte die von Atmel bei der Herstellung ermittelten und mitgegebenen Korrekturwerte für Kalibrierung des RC-Oszillators benutzen um einen einigermaßen genauen Takt zu haben, der ansonsten ohne Benutzen dieser Korrektur erheblich abweichen kann. Für Timingaufgaben in meiner Anwendung ist DIESE Korrektur ausreichend. Ohne diese Maßname NICHT. Ich will es nur nicht JEDES MAL MANUELL machen müssen. Warum erschließt sich das niemand ?? Bin ich zu blöd das zu erklären? Also nochmal: Nur DAS und nichts anderes möchte ich wissen: Gibt es im AVR-Studio mit Atmel ICE beim Programmieren des ATMega16A eine Möglichkeit das OSCCAL Korrekturbyte für 8MHz AUTOMATISCH auszulesen und an eine Speicheradresse im Flash oder EEPROM zu schreiben? Wie das angeblich einige andere Programmer können.
E. S. schrieb: > eine > Möglichkeit das OSCCAL Korrekturbyte für 8MHz AUTOMATISCH auszulesen und > an eine Speicheradresse im Flash oder EEPROM zu schreiben? Wozu? Das steht doch zur Laufzeit schon im OSCCAL-Register?
Bernd K. schrieb: > Wozu? Das steht doch zur Laufzeit schon im OSCCAL-Register? Die alten AVRs haben noch 4 Cal-Bytes. Aber wie gesagt, die stehen ab Werk schon im Flash/EEPROM. Einfach nur das Häckchen beim Löschen rausmachen vor dem Programmieren.
Peter D. schrieb: > Schau mal in einen fabrikneuen AVR, da stehen schon die Kalibrierbytes > am Ende des Flash und des EEPROM. > Du darfst nur vor dem Programmieren nicht löschen, dann bleiben sie > erhalten. Danke Peter, Ja, bei Fabrikneuen soll das so sein, wobei es scheinbar aber bei den ATMEGA16A mit denen ich's hier zu tun habe scheinbar nicht so zu sein scheint. ...Vorsichtig ausgedrückt weil ich es nicht selbst verifiziert habe. Das ist aber noch nicht mal das Hauptproblem, sondern dass ich viel Updates machen muss, und da geht's nicht ohne vorheriges Löschen.
Hi >Gibt es im >AVR-Studio mit Atmel ICE beim Programmieren des ATMega16A eine >Möglichkeit das OSCCAL Korrekturbyte für 8MHz AUTOMATISCH auszulesen und >an eine Speicheradresse im Flash oder EEPROM zu schreiben? Wie das >angeblich einige andere Programmer können. Im 4er-Studio gibt es unter unter 'Auto' im Programmer-Dialog einen Punkt 'Write osc. cal. byte'. Das sollte es eigentlich sein. Habe ich aber noch nie benutzt. MfG Spess
E. S. schrieb: > und da geht's nicht ohne vorheriges Löschen. Irgendwer versteht hier etwas nicht. Vielleicht bin ich das ja. Aber bei den mir bekannten AVRs, der Atmega16 gehört nicht dazu, wird das OSCAL nicht gelöscht. Weder mit Eeprom- noch mit Flash-Erase. Das wäre nach meinem Dafürhalten auch ziemlich bescheuert, das da als Werkskalibrierung reinzuschreiben und es dann bei der Standardprozedur Erase before Programming zu löschen.
:
Bearbeitet durch User
Thomas E. schrieb im Beitrag #4912332: > Bernd K. schrieb: >> Wozu? Das steht doch zur Laufzeit schon im OSCCAL-Register? > > Irgendwie scheint da jemand ganz gewaltig auf dem Holzweg zu sein. ATMEGA16A Datasheet Kapitel 26.4 The ATmega16A stores four different calibration values for the internal RC Oscillator. Thesebytes resides in the signature row High Byte of the addresses 0x0000, 0x0001, 0x0002, and0x0003 for 1, 2, 4, and 8 Mhz respectively. During Reset, the 1 MHz value is automaticallyloaded into the OSCCAL Register. If other frequencies are used, the calibration value has to beloaded manually, ....
E. S. schrieb: > If other frequencies are used, the calibration > value has to beloaded manually, .... OK. Das erklärt einiges.
Thomas E. schrieb: > E. S. schrieb: >> und da geht's nicht ohne vorheriges Löschen. > > Irgendwer versteht hier etwas nicht. Vielleicht bin ich das ja. > > Aber bei den mir bekannten AVRs, der Atmega16 gehört nicht dazu, wird > das OSCAL nicht gelöscht. Weder mit Eeprom- noch mit Flash-Erase. > > Das wäre nach meinem Dafürhalten auch ziemlich bescheuert, das da als > Werkskalibrierung reinzuschreiben und es dann bei der Standardprozedur > Erase before Programming zu löschen. Doch, das ist so. Ich hab's nicht erfunden.
spess53 schrieb: > Hi > >>Gibt es im >>AVR-Studio mit Atmel ICE beim Programmieren des ATMega16A eine >>Möglichkeit das OSCCAL Korrekturbyte für 8MHz AUTOMATISCH auszulesen und >>an eine Speicheradresse im Flash oder EEPROM zu schreiben? Wie das >>angeblich einige andere Programmer können. > > Im 4er-Studio gibt es unter unter 'Auto' im Programmer-Dialog einen > Punkt > 'Write osc. cal. byte'. Das sollte es eigentlich sein. Habe ich aber > noch nie benutzt. > > MfG Spess Jepp, das hab ich auch schon mal gesehen. Leider liegt das Generationen zurück und in 7 finde ich nichts dergleichen.
Die AN von Atmel dazu hattest du schon gesehen? http://www.atmel.com/images/atmel-2555-internal-rc-oscillator-calibration-for-tinyavr-and-megaavr-devices_applicationnote_avr053.pdf
Alexander S. schrieb: > Die AN von Atmel dazu hattest du schon gesehen? > > http://www.atmel.com/images/atmel-2555-internal-rc-oscillator-calibration-for-tinyavr-and-megaavr-devices_applicationnote_avr053.pdf Ja, hab ich gesehen. Leider ist auch diese Methode mit recht viel Aufwand verbunden und macht eigentlich das Gegenteil von Einsparung von Aufwand. Wenn ich einen zuverlässigen reproduzierbaren Input am UART hätte würde ich sogar diese "AUTOBAUD"- Methode implementieren, aber das hab ich leider nicht wirklich.
Bernd K. schrieb: > Also ich meine mich dunkel erinnern zu können daß der avrdude einen > Kommandozeilenswitch hat der sich darauf bezieht, hab das aber nie > selbst angewendet. Ja Bernd, genau sowas findet man bei der Suche, aber anstatt OpenSource/Freeware/Shareware hat man teures Markenequipment und doch keine Lösung. > Ich war einmal in der Verlegenheit das OSCCAL verwenden zu müssen, da > hab ichs dann am Ende ganz pragmatisch so gelöst daß das Gerät sich beim > Einschalten selbst kalibrieren konnte anhand eines von außen angelegten > Signals... Möglicherweise wird es auf so etwas hinauslaufen...
Vielleicht hilft folgender Link weiter wenn Du das Problem mit Markensoftware lösen musst: http://atmel.force.com/support/articles/en_US/FAQ/Command-Line-Programming Bei uns wird Produktionsflashen an nem separaten Arbeitsplatz gemacht auf dem genau die Tools installiert sind die minimal nötig sind um den Programmieradapter zu bedienen plus zugehörige Scripte bzw. selbstgebaute zweckdienliche GUI die das steuern so daß der Benutzer letztendlich nur noch Gerät auswählen, anstöpseln und Taste drücken muss. Für AVR werkelt dort als Backend avrdude (und ein unzerstörbarer Diamex-ALL). Für ARM ist sind es die J-Link Kommandozeilentools (und ein ausrangierter J-Link). Und die ganze Kiste läuft übrigens unter Debian 8, das macht das ganze viel einfacher aufzusetzen, entspannter zu warten und befreit einen auch von dem unsäglichen USB-Treibergewürge (beonders bei Atmel) und sonstigen Windows-Krankheiten.
E. S. schrieb: > Ja, es wird ein Kalibrierungwert beim Reset in das OSCCAL eingetragen. > Aber eben nur der für die Taktfrequenz von 1MHz. Wenn ich 8 MHz benutze, > muss ich den Kalibrierungswert selbst manuell einfügen. E. S. schrieb: > The ATmega16A stores four different calibration values for the internal > RC Oscillator. Thesebytes resides in the signature row High Byte of the > addresses 0x0000, 0x0001, 0x0002, and0x0003 for 1, 2, 4, and 8 Mhz > respectively. Was versteh ich hier nicht? Oben schreibst du, daß du 8MHz benutzt. Und unten zitierst du selbst aus dem Datenblatt, daß der Wert für 1, 2, 4 und 8MHz gespeichert ist.
E. S. schrieb: > Leider ist auch diese Methode mit recht viel > Aufwand verbunden und macht eigentlich das Gegenteil von Einsparung von > Aufwand. > Wenn ich einen zuverlässigen reproduzierbaren Input am UART hätte würde > ich sogar diese "AUTOBAUD"- Methode implementieren, aber das hab ich > leider nicht wirklich. Was du auf jeden Fall hast: Maximale Umständlichkeit bei der Erlangung der der "calibration bytes". Die kann man doch zur Laufzeit der Anwendung einfach direkt an der Quelle auslesen, nämlich aus der "signature row" (also von dort, wo auch der Programmer sie herholen würde). Es gibt also keinerlei Notwendigkeit dafür, sie der Anwendung über irgendwelche idiotischen Umwege mittels Programmer per Flash oder EEPROM bereitzustellen...
c-hater schrieb: > Die kann man doch zur Laufzeit der > Anwendung einfach direkt an der Quelle auslesen, nämlich aus der > "signature row" (also von dort, wo auch der Programmer sie herholen > würde). Ich bin erstaunt! Einige wenige AVR, ja... Aber so absolut? Verblüffung pur...
c-hater schrieb: > Die kann man doch zur Laufzeit der > Anwendung einfach direkt an der Quelle auslesen, nämlich aus der > "signature row" (also von dort, wo auch der Programmer sie herholen > würde). Geht aber nur beim Nachfolger ATmega164. Der alte ATmega16 kanns nicht. Man kann sich aber eine kleine Batch schreiben, die STK500.exe aufruft. Damit kann man dann das Cal-Byte in eine Flash/EEPROM-Adresse schreiben.
1 | O Read oscillator callibration byte. 'address' is the address of |
2 | the calibration byte as decribed in the data sheet of the device. |
3 | Se Write oscillator call. byte to EEPROM memory. 'addr' is byte address |
4 | Sf Write oscillator call. byte to FLASH memory. 'addr' is byte address |
Peter D. schrieb: > Geht aber nur beim Nachfolger ATmega164. Der alte ATmega16 kanns nicht. Bist du da sicher? Ich werde jetzt gerade etwas unsicher und werde es einfach noch mal ausprobieren, bevor ich Unsinn poste. Aber wenn ich mich richtig erinnere, war das auch bei den alten Gammelteilen möglich. Es war nur nicht im Detail (also mit Beispielcode) dokumentiert, wie es zu machen ist. Die Adressen der calibration bytes sind aber immerhin dokumentiert, das konnte ich auf die Schnelle dem DB entnehmen... Hab' im Moment keinen entsprechenden ATMega greifbar, um es ausprobieren zu können, aber alten Code gefunden, der es tut oder zumindest tun will. Leider habe ich damals nicht drangeschrieben, ob es funktioniert hat... Schönes Beispiel dafür, wie wichtig hinreichende Dokumentation auch für einen selber ist bzw. irgendwann mal sein kann...
c-hater schrieb: > Bist du da sicher? Ich bin mir so sicher, wie ich nur sein kann, dass meine Lieblinge, die ATMega328P, es nicht können. Wäre allerdings sehr erfreut, wenn ich mich irren würde. Denn das Gehampel hat mich auch schon einige male gestört.
Arduino F. schrieb: > Ich bin mir so sicher, wie ich nur sein kann, dass meine Lieblinge, die > ATMega328P, es nicht können. Da muß ich Dich enttäuschen, die können es:
1 | 27.8.10 Reading the Signature Row from Software |
2 | Table 27-5. Signature Row Addressing |
3 | RC Oscillator Calibration Byte 0x0001 |
Nur die alten ATmega8,16,32 und ATmega48 können es nicht.
:
Bearbeitet durch User
Peter D. schrieb: > Da muß ich Dich enttäuschen, Danke, für diese Enttäuschung! Ein klein bisschen, frage ich mich, wieso ich das vorher nicht hin bekommen habe..... Aber egal, das gehört bei einer ordentlichen Enttäuschung auch mal dazu. In meinem Datenblatt ist das übrigens: > 30.8.10. Reading the Signature Row from Software Aber auch nicht weniger gut versteckt.
1 | #include <avr/boot.h> |
2 | |
3 | |
4 | void setup() |
5 | {
|
6 | Serial.begin(9600); |
7 | |
8 | byte osccal = OSCCAL ; |
9 | |
10 | |
11 | Serial.print("OSCCAL Register: "); |
12 | Serial.println(osccal,HEX); |
13 | |
14 | |
15 | |
16 | osccal = boot_signature_byte_get(1); |
17 | |
18 | Serial.print("OSCCAL Signatur: "); |
19 | Serial.println(osccal, HEX); |
20 | }
|
21 | |
22 | void loop() {} |
Vielen Dank an alle die sich die Zeit genommen haben mir mit diversen Tips weiterzuhelfen. Die Summe aus einigen davon, noch intesiveres Studieren vieler Webseiten und schließlich stundenlanges unermüdliches herumprobieren haben endlich zu einer praktikablen Lösung geführt mit der ich leben kann. Alexander S. schrieb: Die AN von Atmel dazu hattest du schon gesehen? http://www.atmel.com/images/atmel-2555-internal-rc... das war der erste Ansatz der nicht funktioniert hat. Avrdude war der zweite an dem ich verzweifelt bin, weil der ewig den ICE nicht kennen wollte. U.A. Vielleicht hilft folgender Link weiter wenn Du das Problem mit Markensoftware lösen musst: http://atmel.force.com/support/articles/en_US/FAQ/... Bei uns wird Produktionsflashen an nem separaten Arbeitsplatz gemacht auf dem genau die Tools installiert sind die minimal nötig sind um den Programmieradapter zu bedienen plus zugehörige Scripte..... Dann also wieder zurück zur AVR053 die wir endlich zum Schnurren gebracht haben, aber letztlich nur durch einen DOWNgrade auf 6.2.!!!! @#&*!@?#&%**!!!! So ist es nun letztlich eine Batch mit den Kommandozeilenparametern für ATProgram geworden, nun wahlweise mit Kalibrierung auf eine externe Frequenz (viel langsamer weil aufwendiger) oder eben nur die schnelle Übername der Kalibrierungbytes ins EEPROM. Also vielen Dank nochmal an alle Helfer!
Hi
>Also vielen Dank nochmal an alle Helfer!
Was nutzt das ganze nun eigentlich? Das gilt für eine Temperatur und
für eine Betriebsspannung. Außerhalb läuft es aus dem Ruder.
MfG Spess
Hi 1-Punkt-Kalibrierung? Immerhin genauer, als ganz ohne. MfG
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.