Beim ATtiny13 habe ich Probleme, die Fuse-Bytes auszulesen. Beim Compilieren des Makros "boot_lock_fuse_bits_get" gibt AVRGCC die Fehlermeldung "BLBSET undeclared" (WinAVR 20090313). In der Tat gibt es beim ATtiny13 dieses Bit nicht, vielmehr hier das Bit RFLB. Sollte das nicht im Makro als prozessorabhängige Fallunterscheidung abgedeckt sein? Hat jemand Erfahrung mit dem Auslesen der Fuse-Bytes bei den Tinys? Danke. Günter
Gast
#1275779
In der avr-libc heisst nunmal alles genau so, wie im Datenblatt. >Sollte das >nicht im Makro als prozessorabhängige Fallunterscheidung abgedeckt sein? Wie das Makro aussieht, steht ja in der doku: http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html#gd2cbdea59ffec2e77ee2e63106459797 Wenn BLBSET beim ATtiny13 nicht exisitiert, kannst du es auch nicht lesen. Falls RFLB exakt die selbe Funktion hat, und dein Code für mehrere AVR's kompilierbar sein soll, musst du dir da selber was zusammen-definen. Oliver
> Falls RFLB exakt die selbe Funktion hat, und dein Code für > mehrere AVR's kompilierbar sein soll, musst du dir da selber was > zusammen-definen. Oder aber gleich einen Patch für die avr-libc erarbeiten und dort einreichen.
Gast
#1275871
BLBSET und RFLB haben NICHT die selbe Funktionalität (BLBSET gilt für lesen und schreiben, RFLB nur fürs lesen), daher haben die unterschiedlichen Namen schon einen Sinn. Oliver
Gast
#1275880
> gleich einen Patch für die avr-libc erarbeiten und dort einreichen.
In dem Fall müsste er wohl einen Patch für die avr-libc UND die
existierenden und verteilten sowie die zukünftigen Datenblätter bei
ATMEL einreichen, damit es keine endlosen Verwirrungen und massenweise
immer wieder dieselben Threads hier und anderswo in den Foren gibt.
Ok, er kann den Patch natürlich einreichen. Ist sicher eine gute
Übung, um sich über die Konsequenzen klar zu werden. Hehe.
Au weia Nr. 133087612340458264 schrieb: > In dem Fall müsste er wohl einen Patch für die avr-libc UND die > existierenden und verteilten sowie die zukünftigen Datenblätter bei > ATMEL einreichen, ... Hast du den Artikel vor dir auch gelesen? Beide Bits haben nicht die gleiche Funktionalität.
Gast
#1275907
Ja, dann erübrigt sich das natürlich sowieso. Schon klar. Aber ein Patch für eine Vereinheitlichung von Dingen, die in den Datenblättern nicht einheitlich sind, das wäre schon ein ziemliches Unterfangen. Nur sowas meinte ich.
Ich hatte mir vorher durchaus den Code für das Makro "boot_lock_fuse_bits_get" angesehen. Genauere Nachforschungen haben ergeben, daß es beim Tiny13 offensichtlich nicht möglich ist, per Programm die Fuses zu schreiben; man kann sie lediglich lesen. Daher wohl der andere Name "RFLB". Für das Lesen hat aber RFLB genau die gleiche Funktion wie anderswo BLBSET (nur daß es halt lediglich das Lesen ermöglicht). Ich habe auch einen Patch für die "boot.h" erarbeitet. Wenn man dort die Zeile #define __BOOT_LOCK_BITS_SET (_BV(__SPM_ENABLE) | _BV(BLBSET)) ersetzt durch #if defined(RFLB) #define __BOOT_LOCK_BITS_SET (_BV(__SPM_ENABLE) | _BV(RFLB)) #else #define __BOOT_LOCK_BITS_SET (_BV(__SPM_ENABLE) | _BV(BLBSET)) #endif so funktioniert das Lesen von Fuse-Bytes mit dem genannten Makro auch beim Tiny13 (und wohl auch bei anderen ähnlichen Prozessoren). Nebenwirkungen habe ich aber nicht geprüft, z.B. was bei Aufruf des Makros "boot_lock_fuse_bits_set" beim Tiny13 passiert (das sollte man wohl nicht tun). Wie man so einen Patch einreicht, weiß ich aber nicht.
Günter R. schrieb: > Wie man so einen Patch einreicht, weiß ich aber nicht. Hier: https://savannah.nongnu.org/patch/?group=avr-libc Bitte möglichst als Ausgabe von diff -u. > Nebenwirkungen > habe ich aber nicht geprüft, z.B. was bei Aufruf des Makros > "boot_lock_fuse_bits_set" beim Tiny13 passiert (das sollte man wohl > nicht tun). Man sollte den Makro "boot_lock_fuse_bits_set" dann gar nicht erst definieren. Das geht mit ein bisschen #ifdef. Das sauberste wäre es, die Definition von __BOOT_LOCK_BITS_SET noch um eine bspw. mit dem Namen __BOOT_LOCK_BITS_GET zu erweitern. __BOOT_LOCK_BITS_SET bleibt dann unverändert und wird nur definiert, wenn es ein BLBSET gibt. __BOOT_LOCK_BITS_GET benutzt wahlweise BLBSET oder RFLB und wird dann innerhalb von "boot_lock_fuse_bits_get" benutzt. Sind ein paar Zeilen mehr, aber es wäre sauber.
Jörg Wunsch schrieb: > Das sauberste wäre > es, die Definition von __BOOT_LOCK_BITS_SET noch um eine bspw. mit > dem Namen __BOOT_LOCK_BITS_GET zu erweitern. __BOOT_LOCK_BITS_SET > bleibt dann unverändert und wird nur definiert, wenn es ein BLBSET > gibt. __BOOT_LOCK_BITS_GET benutzt wahlweise BLBSET oder RFLB und > wird dann innerhalb von "boot_lock_fuse_bits_get" benutzt. Sind > ein paar Zeilen mehr, aber es wäre sauber. Sehr gute Idee. Habe ich bei meinem Boot.h schon eingepflegt. Anmeldung bei savannah ist am Laufen ...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.