ATtiny13 - Fuse-Bytes auslesen

[Günter R. (galileo14)]

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

[Oliver (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

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

[Oliver (Gast)]

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

[Au weia Nr. 133087612340458264 (Gast)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[Au weia Nr. 133087612340458264 (Gast)]

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.

[Günter R. (galileo14)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Günter R. (galileo14)]

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