Re: [avr-gcc-list] What Happened to the sbi() and cbi() Macros????

[Victoria Welch]

Hello Bruce,

Wonderfully made points all.

On Sunday 30 January 2005 17:37, Bruce D. Lightner wrote:
> E. Weddington wrote:
> > Erik Walthinsen wrote:
> >> E. Weddington wrote:
> >>> They've been deprecated for a long time. They were
> >>> finally removed in the 1.2.x series. They're gone for
> >>> good.
> >>
> >> I still have not figured out what the logic is behind
> >> removing two of the most useful macros possible on a
> >> machine where ALL IO is preformed by setting and
> >> clearing bits.
> >>
> >> Please, enlighten me.
> >
> > Go look at the implementation of the sbi and cbi macros
> > and you'll see why. ;-)

Perhaps some of us just use the sbi/cbi macros (quite 
successfully, I might add) and have been since we started 
using the avr-gcc toolchain.

Personally, I take that comment as elitist, arrogant, 
patronizing and insulting to those of use the language and 
are not low level gurus.

> > Eric
>
> I just looked at the file "sfr_defs.h" where sbi() and
> cbi() macros are defined and I don't see what the problem
> is, nor do I see anything humorous about the code or the
> situation...
>
> Eric, please enlighten me!  Exactly why were the "sbi()
> and cbi() macros removed?!!
>
> Are *all* the "input/output" macros gone (e.g.,
> bit_is_set(), bit_is_clear(), inb(), inw(), outb(),
> outw()...)?
>
> If you need someone to "maintain" the file "sfr_defs.h",
> then I'm sure you can find lot's of volunteers...like me!

Bravo!  I like a rational attitude :-)!   I'm no guru but if 
I can help, let me know and I'll do whatever I can although 
that might not be much :-/.

> I've followed the "avr-gcc" mailing list every day for
> many years and I don't remember *any* inquiries, surveys,
> or votes regarding this recent "improvement" to avr-gcc,
> namely removing "depricated" I/O marcos.

I'm pretty new to the list, but it did come as a shock to 
get pages of errors over this.  Fortunately it was easy 
enough to fix after some research.

> So, please enlighten us as to why these macros cannot
> remain in the library.  I for one am ready listen to
> reason, but please also think long and hard about what
> removing them does to many of us long time end-users of
> avr-gcc.  And don't get me wrong, we folks that make
> daily use of the wonderful things that the maintainers of
> "avr-gcc" and it's libraries have created truly do
> appreciate your hard work!  And, we thank you!!

Very much so, the efforts of all involved in this are more 
greatly appreciated than there are words suitable to 
express it!

This is not a great big deal although I do wonder why these 
disappeared when they certainly appear to have a VERY wide 
and heavy usage (at least amoungst those I work with and 
know who do work with the avr-gcc tools.)

> However, as the comments in the "sfr_defs.h" source code
> say regarding the "missing" macros, they are included
> for...
>
>    "For backwards compatibility"
>
> I personally have created well over 100 "avr-gcc"
> projects that make use of one or more now "depricated"
> I/O macros.  I have hundreds of thousands of AVR-based
> devices in the field that use avr-gcc source code that
> references these macros.  Responsibility for supporting
> that installed base resets with me.
>
> Although I, like most(?) others make less and less use of
> "depricated" macros for new code, I do not want to be
> forced to revisit perfectly fine, field-proven, debugged
> and tested avr-gcc code just because a macro was
> "depricated" and I (or one of my customers) has decided
> to (or has been forced to) upgrade the "avr-gcc" toolset.
>  I don't know about you, but I know that "fixing" working
> source code is an invitation for new bugs. And, bugs cost
> time to fix, and time is money...to anyone but a
> hobbyist.
>
> Does anyone else want to comment?  Am I overreacting?

No, I don't think you are overreacting at all.  "If it ain't 
broke, don't fix it" comes to mind here.  Especially 
something that I know for me and a number of others has 
been HEAVILY used for quite some time.

The suggested method might be pure, but it sure as hell, 
IMNSHO, is not as clear as the sbi / cbi constructs.  I'm 
no purist so I just add the following to my defs.h file:


/* defines for backward compatibility */
#ifndef cbi
 #define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
 #define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif

It was looking at the massive amount of time, effort and 
hassle to replace all the sbi /cbi stuff alone that sent me 
off looking for the above.

That said, some gracious soul sent me what appears to be a 
better set of macros, I just need to take some time and 
look them over, but I suspect that I will use them.

> How about a vote on this?

I dunno about a vote, it is certainly easy to fix and one of 
the joys of open source and C is that you do not need to 
just swallow what one isfed :-).

Yes, I am a little miffed over the original comment on this, 
but I'll get over it :-).

To the developers involved, please understand that your work 
is GREATLY appreciated and enjoyed. 

For those involved with this (IMO) little fiasco, it might 
be a good idea to see what kind of impacts something like 
this  is going to cause before just dumping them out of 
hand.

Take care, V.
-- 
Victoria Welch, WV9K/7.  "Engineering is the art of making 
what you want from things you can get."-  Jerry Avins
"Learning about the U.S. from the mainstream media is like 
learning about plumbing by sitting in a cesspool."  -- 
Michael Phelps