[avr-libc-dev] [bug #24323] many headers define EFUSE_DEFAULT as 0xff inconsistently

[Juergen Weigert]

URL:
  <http://savannah.nongnu.org/bugs/?24323>

                 Summary: many headers define EFUSE_DEFAULT as 0xff
inconsistently
                 Project: AVR C Runtime Library
            Submitted by: jnweiger
            Submitted on: Sun 21 Sep 2008 12:18:30 AM GMT
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.6.2
           Fixed Release: None

    _______________________________________________________

Details:

LFUSE_DEFAULT and HFUSE_DEFAULT in avr/io*.h are defined using noninverted
bit values (unprogrammed=0, programmed=1),
[this is mildly confusing, but okay as long as it is consistent. all other
reference to fuse bits use an inverted logic of programmed=0,
unprogrammed=1.]

EFUSE_DEFAULT is inconsistent. We often see 0xff which is meant as
representing the inverted logic. But whenever EFUSE is not 0xff, it uses
noninverted logic, just like L and H-Fuse.

Example:
Compare default of bit 0 in e-fuse of mega48 and mega88:
The manual doc2545p280f says 1=unprogrammed for both devices, but the headers
define a 1 for mega48 and a 0 for mega88.

Can we assume that nobody really uses the xFUSE_DEFAULT values? If so, I'd
suggest to make them all inverted logic. 
(yes, that would bit-flip all xFUSE_DEFAULTs, except where efuse has 0xff)
If that sounds too scary, let us achive consistency by 
#define EFUSE_DEFAULT 0x00 where it is now 0xff.





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?24323>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/