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

[stevech]

Hope the GCC developers don't do a Mic$oft "We Know What You Want"


-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of gouy yann
Sent: Monday, January 31, 2005 11:37 PM
To: avr-libc-dev; address@hidden
Subject: Re: [avr-libc-dev] Re: [avr-gcc-list] Re: What Happened to the
sbi()and cbi() Macros????


hello,

I have to add that writing C embedded code needs a certain knowledge in C as
it
deals with hardware driving.
Part of this knowledge is certainly bit operators and boolean algebra.

Not having this basic knowledge leads to functions or worse macros
encapsulating  bit operators.

And I finally want to remind everyone (but it was already done once) that
the
mainteners of the whole AVR stuff are volunteers.

DON'T BLAME THEM if every thing is not as you wish and DO IT BY YOURSELF.

I don't like the new C definition of types "uint8_t",... neither the old one
"unsigned char",..., so I defined my own "u8",...

best regards.

    Yann



 --- "E. Weddington" <address@hidden> a écrit :
> Victoria Welch wrote:
>
> >I think some folks are missing the point here.
> >
> >Had the sbi / cbi stuff not been there in the first place
> >AND not been so HEAVILY used, this would hardly be an
> >issue :-).
> >
> >Academic purity is a fine thing, but there is a real world
> >out there where everyone doesn't have a doctorate in C and
> >(believe it or not :-) doesn't want one :-).
> >
> >Most importantly there is the issue of backwards
> >compatibility.  This *IS* a serious real world
> >consideration.
> >
> >
> >
> >This might not be something the academics would encourage
> >but in the real world usage it is IMNSHO indespensible
> >given the existing conditions.
> >
> >Whether we like it or not, all this is out in the real world
> >with people using it.  Maybe these people will learn regex
> >and bit manipulation and replace them all if they don't get
> >discouraged away from it assuming it is just broken.
> >
> >
>
> Look. There's no *academic* anything going on here. We're "real world
> developers" just like you. Quit flaming.
>
> There is a common protocol for dealing with breaking backwards
> compatiblity and it's called "deprecation", which means that it's there
> but it really shouldn't be used because other, more desirable methods
> are available. Eventually, deprecated items are removed.
>
> Remember, these items were deprecated a long time ago and they were
> marked that way in the avr-libc user manual. How hard is it to read it?
>
> I'm sorry you got a hold of some bad examples and you started to write
> your code that way.
>
> >Not everyone is a C guru.  I, for one, started out that way
> >and moved on to a better knowlege of C (Still Not A C
> >Guru(TM) ;-).
> >
> >
> Geez, you don't have to be a "guru" to understand this stuff. There are
> a class of operators in the C language that deal with bit manipulation.
> They are a standard part of the language. They are used heavily and
> extensively by any C code that interacts with hardware, i.e. embedded
> systems and operating systems. It is to be somewhat expected that you
> learn those operators when writing for an embedded microcontroller such
> as the AVR.
>
> A guru would know how to read trigraphs without having to look it up. ;-)
>
> >but I hope some
> >consideration to "legacy" code and potential newbies
> >figures into the decision.
> >
> >
> Hence my proposal for a Bit Operations API. Joerg probably thinks that
> it is unnecessary. I do too. But I can also see where it could be useful
> (and more useful than just the two cbi() and sbi() macros), and it would
> make newbie's lives easier.
>
> Eric
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>






Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos
mails !
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

_______________________________________________
avr-gcc-list mailing list
address@hidden
http://www.avr1.org/mailman/listinfo/avr-gcc-list