AVR-Chat

I am going to learn so much from this group...... 
  Glad I joined.
   
   
  :  )


[Non-text portions of this message have been removed]

All this is fine. But for many of us hobbyists that know just enough about
C, especially when it comes to AVRs, to be down-right-dangerous...

For me something like the following, is good, proper and works. It is not
fully understood until I dissect.
while ((UCSRA & (1<<UDRE))==0);

while(UCSRA.5 == 0);  //while(USART Data Register Empty)
Haven't tried this but I think it should work and means "while the data
register is empty sit right here".
Now to the Xsperts may disagree. I'm a hobbiest, it works for me and best of
all I understand why it works.

Mike

On 3/14/07, David Appleton <englsprogeny@yahoo.com> wrote:
>
>   I am going to learn so much from this group......
> Glad I joined.
>
>
> : )
>
> [Non-text portions of this message have been removed]
>
> 
>


[Non-text portions of this message have been removed]

On Thu, Mar 22, 2007 at 11:28:53AM -0400, Mike Bronosky wrote:
> All this is fine. But for many of us hobbyists that know just enough
> about C, especially when it comes to AVRs, to be
> down-right-dangerous...
> 
> For me something like the following, is good, proper and works. It is not
> fully understood until I dissect.
> while ((UCSRA & (1<<UDRE))==0);
> 
> while(UCSRA.5 == 0);  //while(USART Data Register Empty)
> Haven't tried this but I think it should work and means "while the
> data register is empty sit right here".

*I* see what you intend but I don't think the compiler will. "5 is not a
member of the struct UCSRA". In fact UCSRA isn't a struct at all so the
dot thing won't work.

Also suggest one pretty-print the while() usage something like this so
that it stands out like a sore thumb that one has a small loop:

	while ((UCSRA & (1<<UDRE))==0)
		;

> Now to the Xsperts may disagree. I'm a hobbiest, it works for me and
> best of all I understand why it works.

As a general rule its always bad to write loops with only one possible
exit. At the least you should provide a time out exit. Or enable the
watchdog timer and kick the dog once prior to entering the above loop.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

>
>
> As a general rule its always bad to write loops with only one possible
> exit. At the least you should provide a time out exit. Or enable the
> watchdog timer and kick the dog once prior to entering the above loop.


I've tried really hard to write my apps so that there is only one WDR, in
the main loop, behind some sanity-checking code like looking at the stack
pointer and critical data.

A convenient thing also, is a "halt and DONT catch fire" routine.
One that puts everything in a safe state and waits for a reset.
Some projects don't need it, but if you have hardware that could be damaged
by hanging in a random state, it's a good idea.


[Non-text portions of this message have been removed]

One can define a struct for something like the USART peripheral and use bit
fields.  This has, in fact, been done for the GCC compiler.  Some folks use
these definitions, but most stick with the shift & mask technique
illustrated below as bit fields are un-portable (you may say, why bother
with something like the AVR, but I used them for an H8 project and got
totally bitten when we needed to transport data across Bluetooth to a PC and
pocket PC devices).

The XXXX.B notation comes from BASCOM and who knows what other non-ansi C
like compilers.  It is a great shorthand, but still broken (IMHO) because
raw numbers are terrible as a way of documenting what is the intent of the
code.

For example (not correct since I don't have my data sheet handy...)

typedef struct
{
	unsigned char UDRE:1;
 	unsigned char UDTXC:1; 	
	unsigned char UDRX:1;	
	...
}
UCSRA_t;

#define UCSRA (*(UCSRA_t*)0xXXXX)	// 0xXXXX SRAM address of peripheral

...

while (UCSRA.UDRE == 0)
	;

Better yet to use the GCC shorthand _BV() to get the "bit value" of a
number.

#define _BV(A) (1<<(A))

While (UCSRA & _BV(UDRE))
	;

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of David Kelly
Sent: Thursday, March 22, 2007 9:04 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Re: Some C help please !

On Thu, Mar 22, 2007 at 11:28:53AM -0400, Mike Bronosky wrote:
> All this is fine. But for many of us hobbyists that know just enough
> about C, especially when it comes to AVRs, to be
> down-right-dangerous...
> 
> For me something like the following, is good, proper and works. It is not
> fully understood until I dissect.
> while ((UCSRA & (1<<UDRE))==0);
> 
> while(UCSRA.5 == 0);  //while(USART Data Register Empty)
> Haven't tried this but I think it should work and means "while the
> data register is empty sit right here".

*I* see what you intend but I don't think the compiler will. "5 is not a
member of the struct UCSRA". In fact UCSRA isn't a struct at all so the
dot thing won't work.

Also suggest one pretty-print the while() usage something like this so
that it stands out like a sore thumb that one has a small loop:

	while ((UCSRA & (1<<UDRE))==0)
		;

> Now to the Xsperts may disagree. I'm a hobbiest, it works for me and
> best of all I understand why it works.

As a general rule its always bad to write loops with only one possible
exit. At the least you should provide a time out exit. Or enable the
watchdog timer and kick the dog once prior to entering the above loop.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.


 
Yahoo! Groups Links

Mike,

   What makes the former syntax nicer is that it has no "magic numbers" 
embedded in the code.  UCSRA.5 does not mean as much as UCSRA.UDRE (if 
that is defined) or as UCSRA & (1<<UDRE) - The latter does not require a 
library of structures defining the bits, just a bunch of #defines. 
You'll pick it up as you go along.  :)

DLC

Mike Bronosky wrote:
> All this is fine. But for many of us hobbyists that know just enough about
> C, especially when it comes to AVRs, to be down-right-dangerous...
> 
> For me something like the following, is good, proper and works. It is not
> fully understood until I dissect.
> while ((UCSRA & (1<<UDRE))==0);
> 
> while(UCSRA.5 == 0);  //while(USART Data Register Empty)
> Haven't tried this but I think it should work and means "while the data
> register is empty sit right here".
> Now to the Xsperts may disagree. I'm a hobbiest, it works for me and best of
> all I understand why it works.
> 
> Mike
> 
> On 3/14/07, David Appleton <englsprogeny@yahoo.com> wrote:
> 
>>  I am going to learn so much from this group......
>>Glad I joined.
>>
>>
>>: )
>>
>>[Non-text portions of this message have been removed]
>>
>>
>>
> 
> 
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 

-- 
---------------------------------------
Dennis Clark    TTT Enterprises
---------------------------------------

Hi Guys, I started this conversation, but after asking the initial
question and getting a few replies, it has become glaringly obvious to
me why (UCSRA &(1 << UDRE)) is better than UCSRA.5

By the way, UCSRA.5 compiles fine in codevision and was how we were
taught to access the AVR registers way back in uni. I realise now that
it is a fairly simplistic way to write the code, and not good if you
want to re-use the code on any other AVR.

The huge advantage of using the shift and mask method is that it makes
pre-written code completely portable to any other AVR micro with the
same names for bits, and generally when two AVR micros have the same
peripherals, they also use the same bit-names, but not necessarily in
the same bit position.

My 2c, glad I asked the question to start of with, the help from
everyone in this group is amazing. 

Cheers
Hein B
Auckland, New Zealand.


--- In AVR-Chat@yahoogroups.com, Dennis Clark <dlc@...> wrote:
>
> Mike,
> 
>    What makes the former syntax nicer is that it has no "magic numbers" 
> embedded in the code.  UCSRA.5 does not mean as much as UCSRA.UDRE (if 
> that is defined) or as UCSRA & (1<<UDRE) - The latter does not
require a 
> library of structures defining the bits, just a bunch of #defines. 
> You'll pick it up as you go along.  :)
> 
> DLC
> 
> Mike Bronosky wrote:
> > All this is fine. But for many of us hobbyists that know just
enough about
> > C, especially when it comes to AVRs, to be down-right-dangerous...
> > 
> > For me something like the following, is good, proper and works. It
is not
> > fully understood until I dissect.
> > while ((UCSRA & (1<<UDRE))==0);
> > 
> > while(UCSRA.5 == 0);  //while(USART Data Register Empty)
> > Haven't tried this but I think it should work and means "while the
data
> > register is empty sit right here".
> > Now to the Xsperts may disagree. I'm a hobbiest, it works for me
and best of

> > all I understand why it works.
> > 
> > Mike
> > 
> > On 3/14/07, David Appleton <englsprogeny@...> wrote:
> > 
> >>  I am going to learn so much from this group......
> >>Glad I joined.
> >>
> >>
> >>: )
> >>
> >>[Non-text portions of this message have been removed]
> >>
> >>
> >>
> > 
> > 
> > 
> > [Non-text portions of this message have been removed]
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> 
> -- 
> ---------------------------------------
> Dennis Clark    TTT Enterprises
> ---------------------------------------
>

On Thu, Mar 22, 2007 at 08:44:08PM -0000, kernels_nz wrote:
>
> The huge advantage of using the shift and mask method is that it makes
> pre-written code completely portable to any other AVR micro with the
> same names for bits, and generally when two AVR micros have the same
> peripherals, they also use the same bit-names, but not necessarily in
> the same bit position.

If someone was interested enough to do the work there is no reason why
each and every register could not be defined as structs with bitfields.
Codewarrior does exactly that. Makes for some *huge* .h files.

If one were determined to do such a thing I think a script should be
written to make structs out of register definitions. This way new CPUs
and new CPU families could be added relatively painlessly with minimum
opportunities for human error.

But (reaching for an example which might not exactly apply) if one
wanted to know of the TX register had 1) just completed or 2) was empty,
then the masking solution allows one to kill two birds with one stone.

Also if the compiler is smart and the device offers bitwise instructions
then the compiler will use bitwise instructions no matter if masks or
bit structs are used. So for code efficiency there is no difference.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Thu, Mar 22, 2007 at 09:28:01AM -0700, larry barello wrote:
> One can define a struct for something like the USART peripheral and
> use bit fields.  This has, in fact, been done for the GCC compiler.

BTDT. An inline mask usually results in smaller and faster code. Also
masks are much better when one is watching multiple bits.

> Better yet to use the GCC shorthand _BV() to get the "bit value" of a
> number.
>
> #define _BV(A) (1<<(A))
>
> While (UCSRA & _BV(UDRE))
> 	;

Yuck. I find (1<<5) or (1<<UDRE) immediately says what is happening
_BV(5) adds an extra level of indirection confusion and _BV(UDRE)
doubles the indirection confusion. I don't find (1<<UDRE) to be
confusing.

We're pretty much bound by the definitions in Atmel's datasheets. But
when I don't have a historical mandate and am creating new definitions
for a project I'll do it more like this:

#define UCSRA_UDRE_m	(1<<5)

Which is obvious when reading that it only applies to UCSRA and _m is a
reminder that its already in mask form.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

David Kelly wrote:
> On Thu, Mar 22, 2007 at 09:28:01AM -0700, larry barello wrote:
> 
>>One can define a struct for something like the USART peripheral and
>>use bit fields.  This has, in fact, been done for the GCC compiler.
> 
> 
> BTDT. An inline mask usually results in smaller and faster code. Also
> masks are much better when one is watching multiple bits.

   Me too, and it makes just as small of code as the bit shift code with 
GCC-AVR.  I compiled both ways and looked at the assembly generated.  I 
got spoiled by Microchip, which does this and I did it with the code 
that I was writing, but only for the registers that I wanted to use.

> 
>>Better yet to use the GCC shorthand _BV() to get the "bit value" of a
>>number.

   Personally I greatly dislike _BV since it is non-intuitive to read.

>>#define _BV(A) (1<<(A))
>>
>>While (UCSRA & _BV(UDRE))
>>	;
> 
> 
> Yuck. I find (1<<5) or (1<<UDRE) immediately says what is happening
> _BV(5) adds an extra level of indirection confusion and _BV(UDRE)
> doubles the indirection confusion. I don't find (1<<UDRE) to be
> confusing.
> 
> We're pretty much bound by the definitions in Atmel's datasheets. But
> when I don't have a historical mandate and am creating new definitions
> for a project I'll do it more like this:
> 
> #define UCSRA_UDRE_m	(1<<5)

yup.

> Which is obvious when reading that it only applies to UCSRA and _m is a
> reminder that its already in mask form.
> 

DLC
-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

David Kelly wrote:
> On Thu, Mar 22, 2007 at 08:44:08PM -0000, kernels_nz wrote:
>> The huge advantage of using the shift and mask method is that it makes
>> pre-written code completely portable to any other AVR micro with the
>> same names for bits, and generally when two AVR micros have the same
>> peripherals, they also use the same bit-names, but not necessarily in
>> the same bit position.
> 
> If someone was interested enough to do the work there is no reason why
> each and every register could not be defined as structs with bitfields.
> Codewarrior does exactly that. Makes for some *huge* .h files.
> 
> If one were determined to do such a thing I think a script should be
> written to make structs out of register definitions. This way new CPUs
> and new CPU families could be added relatively painlessly with minimum
> opportunities for human error.

I already did this; my script works from text copied from the PDF data 
sheets. Admittedly, the XML files are probably more authoritative and 
easier to parse. Plus, Atmel stupidly changed their PDF files to 
disallow copying of text to the clipboard (!) so you have to run the PDF 
through something other than Adobe Reader to get the text.

> But (reaching for an example which might not exactly apply) if one
> wanted to know of the TX register had 1) just completed or 2) was empty,
> then the masking solution allows one to kill two birds with one stone.

So I provided both methods.

For each single bit or contiguous multiple bit field I made a bitfield 
definition.

I also provide numeric definitions for bit numbers.

For each 8-bit register I also provided an asByte byte-wide definition.

For each 9-to-16-bit wide register I also provide an asWord 
two-byte-wide definition.

I also provide definitions for each of the bits, using names from the 
datasheet.

So, using my headers, your example test for tx completed or empty could 
be written:


       if (TXC0 || UDRE0)
          /* do stuff */


or:


       if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))
          /* do stuff */


and the generated code would look like this:


   12:test2.c  ****      if (TXC0 || UDRE0)
  315 0008 5E99      		sbic 43-0x20,6
  316 000a 08C0      		rjmp .L2
  319 000c 5D99      		sbic 43-0x20,5
  320 000e 06C0      		rjmp .L2
   *** /* do stuff */
  332                   .L2

or this (somewhat more efficient):


   15:test2.c  ***       if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))

  324 0010 8AB1      		in r24,42-0x20
  325 0012 8076      		andi r24,lo8(96)
  326 0014 31F0      		breq .L5
   *** /* do stuff */
  338                   .L5



Here's an excerpt from the generated Atmega128 header file (yes, my 
script also generates Doxygen documentation directives):



/*! \addtogroup UCSR0B
  * \brief UCSR0B  ($2A) (page 190)
  * \see PROCESSOR_PDF_URL#page=190
  * @{
  */
typedef union UCSR0B_t {
/*! \cond REG_DETAILS */
   uint8_t asByte;
   struct {
     uint8_t bTXB80 :1;
     uint8_t bRXB80 :1;
     uint8_t bUCSZ02 :1;
     uint8_t bTXEN0 :1;
     uint8_t bRXEN0 :1;
     uint8_t bUDRIE0 :1;
     uint8_t bTXCIE0 :1;
     uint8_t bRXCIE0 :1;
   } b;
/*! \endcond REG_DETAILS */
} UCSR0B_t;
#define UCSR0B_sfr (*(volatile UCSR0B_t *) (0x2A))
#define UCSR0B UCSR0B_sfr.asByte /*entire register*/
/* single bits */
#define TXB80 UCSR0B_sfr.b.bTXB80 /*!< Bit 0 of UCSR0B \sa bitTXB800 
\hideinitializer */
#define RXB80 UCSR0B_sfr.b.bRXB80 /*!< Bit 1 of UCSR0B \sa bitRXB801 
\hideinitializer */
#define UCSZ02 UCSR0B_sfr.b.bUCSZ02 /*!< Bit 2 of UCSR0B \sa bitUCSZ022 
\hideinitializer */
#define TXEN0 UCSR0B_sfr.b.bTXEN0 /*!< Bit 3 of UCSR0B \sa bitTXEN03 
\hideinitializer */
#define RXEN0 UCSR0B_sfr.b.bRXEN0 /*!< Bit 4 of UCSR0B \sa bitRXEN04 
\hideinitializer */
#define UDRIE0 UCSR0B_sfr.b.bUDRIE0 /*!< Bit 5 of UCSR0B \sa bitUDRIE05 
\hideinitializer */
#define TXCIE0 UCSR0B_sfr.b.bTXCIE0 /*!< Bit 6 of UCSR0B \sa bitTXCIE06 
\hideinitializer */
#define RXCIE0 UCSR0B_sfr.b.bRXCIE0 /*!< Bit 7 of UCSR0B \sa bitRXCIE07 
\hideinitializer */
/* bit numbers */
#define bitTXB80 0 /*!< bit number of TXB80*/
#define bitRXB80 1 /*!< bit number of RXB80*/
#define bitUCSZ02 2 /*!< bit number of UCSZ02*/
#define bitTXEN0 3 /*!< bit number of TXEN0*/
#define bitRXEN0 4 /*!< bit number of RXEN0*/
#define bitUDRIE0 5 /*!< bit number of UDRIE0*/
#define bitTXCIE0 6 /*!< bit number of TXCIE0*/
#define bitRXCIE0 7 /*!< bit number of RXCIE0*/
/*! @} */
/*! \addtogroup UCSR0A
  * \brief UCSR0A  ($2B) (page 189)
  * \see PROCESSOR_PDF_URL#page=189
  * @{
  */
typedef union UCSR0A_t {
/*! \cond REG_DETAILS */
   uint8_t asByte;
   struct {
     uint8_t bMPCM0 :1;
     uint8_t bU2X0 :1;
     uint8_t bUPE0 :1;
     uint8_t bDOR0 :1;
     uint8_t bFE0 :1;
     uint8_t bUDRE0 :1;
     uint8_t bTXC0 :1;
     uint8_t bRXC0 :1;
   } b;
/*! \endcond REG_DETAILS */
} UCSR0A_t;
#define UCSR0A_sfr (*(volatile UCSR0A_t *) (0x2B))
#define UCSR0A UCSR0A_sfr.asByte /*entire register*/
/* single bits */
#define MPCM0 UCSR0A_sfr.b.bMPCM0 /*!< Bit 0 of UCSR0A \sa bitMPCM00 
\hideinitializer */
#define U2X0 UCSR0A_sfr.b.bU2X0 /*!< Bit 1 of UCSR0A \sa bitU2X01 
\hideinitializer */
#define UPE0 UCSR0A_sfr.b.bUPE0 /*!< Bit 2 of UCSR0A \sa bitUPE02 
\hideinitializer */
#define DOR0 UCSR0A_sfr.b.bDOR0 /*!< Bit 3 of UCSR0A \sa bitDOR03 
\hideinitializer */
#define FE0 UCSR0A_sfr.b.bFE0 /*!< Bit 4 of UCSR0A \sa bitFE04 
\hideinitializer */
#define UDRE0 UCSR0A_sfr.b.bUDRE0 /*!< Bit 5 of UCSR0A \sa bitUDRE05 
\hideinitializer */
#define TXC0 UCSR0A_sfr.b.bTXC0 /*!< Bit 6 of UCSR0A \sa bitTXC06 
\hideinitializer */
#define RXC0 UCSR0A_sfr.b.bRXC0 /*!< Bit 7 of UCSR0A \sa bitRXC07 
\hideinitializer */
/* bit numbers */
#define bitMPCM0 0 /*!< bit number of MPCM0*/
#define bitU2X0 1 /*!< bit number of U2X0*/
#define bitUPE0 2 /*!< bit number of UPE0*/
#define bitDOR0 3 /*!< bit number of DOR0*/
#define bitFE0 4 /*!< bit number of FE0*/
#define bitUDRE0 5 /*!< bit number of UDRE0*/
#define bitTXC0 6 /*!< bit number of TXC0*/
#define bitRXC0 7 /*!< bit number of RXC0*/
/*! @} */



-- 
Ned Konz
ned@bike-nomad.com
http://bike-nomad.com

I wrote:

> So, using my headers, your example test for tx completed or empty could 
> be written:
> 

[snip]

>        if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))
>           /* do stuff */
> 
> 
> and the generated code would look like this:

[snip]

> or this (somewhat more efficient):
> 
> 
>    15:test2.c  ***       if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))
> 
>   324 0010 8AB1      		in r24,42-0x20
>   325 0012 8076      		andi r24,lo8(96)
>   326 0014 31F0      		breq .L5
>    *** /* do stuff */
>   338                   .L5



And here we see the problem with the bit numbers: they're not connected 
with the register.

I made the mistake of referring to UCSR0B, when TXC0 and UDRE0 are 
actually in UCSR0A.

This is a not-uncommon error using this idiom. You don't have the 
ability to make this error when using bitfields.

The above should be:

         if (UCSR0A & ((1 << bitTXC0) | (1 << bitUDRE0)))
            /* do stuff */


I spent some time making a safer version using C++ templates, but 
haven't been satisifed with its ease of use.

-- 
Ned Konz
ned@bike-nomad.com
http://bike-nomad.com

So ... after the big discussion on  bit-shifting and masking I decided
to rewrite a bit of pretty rough wireless code I use a lot with my new
found appreciation of making my code more portable and tidy-er. 

But! To my dismay I found that the codevision header files dont
contain defines for bits like SPIF in the SPSR (SPI status register)
do the other compilers like GCC and IAR have header files that have
the names of each bit of every register defined ?

I did end up rewriting the code, and to me it is now a thing of
beauty, but I had to go through the header file and #define all the
bits I was using for shift and masking.

Cheers
Hein B
Auckland
New Zealand



--- In AVR-Chat@yahoogroups.com, Ned Konz <ned@...> wrote:
>
> I wrote:
> 
> > So, using my headers, your example test for tx completed or empty
could 
> > be written:
> > 
> 
> [snip]
> 
> >        if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))
> >           /* do stuff */
> > 
> > 
> > and the generated code would look like this:
> 
> [snip]
> 
> > or this (somewhat more efficient):
> > 
> > 
> >    15:test2.c  ***       if (UCSR0B & ((1 << bitTXC0) | (1 <<
bitUDRE0)))

> > 
> >   324 0010 8AB1      		in r24,42-0x20
> >   325 0012 8076      		andi r24,lo8(96)
> >   326 0014 31F0      		breq .L5
> >    *** /* do stuff */
> >   338                   .L5
> 
> 
> 
> And here we see the problem with the bit numbers: they're not connected 
> with the register.
> 
> I made the mistake of referring to UCSR0B, when TXC0 and UDRE0 are 
> actually in UCSR0A.
> 
> This is a not-uncommon error using this idiom. You don't have the 
> ability to make this error when using bitfields.
> 
> The above should be:
> 
>          if (UCSR0A & ((1 << bitTXC0) | (1 << bitUDRE0)))
>             /* do stuff */
> 
> 
> I spent some time making a safer version using C++ templates, but 
> haven't been satisifed with its ease of use.
> 
> -- 
> Ned Konz
> ned@...
> http://bike-nomad.com
>

At 07:38 AM 29/03/2007, you wrote:
>So ... after the big discussion on

Thanks for the even bigger quadruple posting :)


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

At 08:08 AM 3/29/2007 +1000, John Samperi wrote:
>At 07:38 AM 29/03/2007, you wrote:
> >So ... after the big discussion on
>
>Thanks for the even bigger quadruple posting :)

I've been seeing a lot of that from Yahoo today

Robert

http://www.aeolusdevelopment.com/

 From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time?  37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we 
currently have stock."

SORRY ! Wasnt me, no idea why that message got pasted so many times ! 


--- In AVR-Chat@yahoogroups.com, "kernels_nz" <kernels@...> wrote:
>
> So ... after the big discussion on  bit-shifting and masking I decided
> to rewrite a bit of pretty rough wireless code I use a lot with my new
> found appreciation of making my code more portable and tidy-er. 
> 
> But! To my dismay I found that the codevision header files dont
> contain defines for bits like SPIF in the SPSR (SPI status register)
> do the other compilers like GCC and IAR have header files that have
> the names of each bit of every register defined ?
> 
> I did end up rewriting the code, and to me it is now a thing of
> beauty, but I had to go through the header file and #define all the
> bits I was using for shift and masking.
> 
> Cheers
> Hein B
> Auckland
> New Zealand
> 
> 
> 
> --- In AVR-Chat@yahoogroups.com, Ned Konz <ned@> wrote:
> >
> > I wrote:
> > 
> > > So, using my headers, your example test for tx completed or empty
> could 
> > > be written:
> > > 
> > 
> > [snip]
> > 
> > >        if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))
> > >           /* do stuff */
> > > 
> > > 
> > > and the generated code would look like this:
> > 
> > [snip]
> > 
> > > or this (somewhat more efficient):
> > > 
> > > 
> > >    15:test2.c  ***       if (UCSR0B & ((1 << bitTXC0) | (1 <<
> bitUDRE0)))
> > > 
> > >   324 0010 8AB1      		in r24,42-0x20
> > >   325 0012 8076      		andi r24,lo8(96)
> > >   326 0014 31F0      		breq .L5
> > >    *** /* do stuff */
> > >   338                   .L5
> > 
> > 
> > 
> > And here we see the problem with the bit numbers: they're not
connected 

> > with the register.
> > 
> > I made the mistake of referring to UCSR0B, when TXC0 and UDRE0 are 
> > actually in UCSR0A.
> > 
> > This is a not-uncommon error using this idiom. You don't have the 
> > ability to make this error when using bitfields.
> > 
> > The above should be:
> > 
> >          if (UCSR0A & ((1 << bitTXC0) | (1 << bitUDRE0)))
> >             /* do stuff */
> > 
> > 
> > I spent some time making a safer version using C++ templates, but 
> > haven't been satisifed with its ease of use.
> > 
> > -- 
> > Ned Konz
> > ned@
> > http://bike-nomad.com
> >
>

--- John Samperi <samperi@ampertronics.com.au> wrote:

> At 07:38 AM 29/03/2007, you wrote:
> >So ... after the big discussion on
> 
> Thanks for the even bigger quadruple posting :)
> 
> 
> Regards
> 
> John Samperi

I think that was Yahoo.  It happened to me on a couple
of e-mail Lists.

Jeff Engel
Arlington, TX
USA

Happiness is - positive intake manifold pressure.


 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail

IT WAS YOU!! >:(  hehe

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of kernels_nz
Sent: Wednesday, March 28, 2007 5:15 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: Some C help please !

 

SORRY ! Wasnt me, no idea why that message got pasted so many times ! 

--- In AVR-Chat@yahoogroup <mailto:AVR-Chat%40yahoogroups.com> s.com,
"kernels_nz" <kernels@...> wrote:
>
> So ... after the big discussion on bit-shifting and masking I decided
> to rewrite a bit of pretty rough wireless code I use a lot with my new
> found appreciation of making my code more portable and tidy-er. 
> 
> But! To my dismay I found that the codevision header files dont
> contain defines for bits like SPIF in the SPSR (SPI status register)
> do the other compilers like GCC and IAR have header files that have
> the names of each bit of every register defined ?
> 
> I did end up rewriting the code, and to me it is now a thing of
> beauty, but I had to go through the header file and #define all the
> bits I was using for shift and masking.
> 
> Cheers
> Hein B
> Auckland
> New Zealand
> 
> 
> 
> --- In AVR-Chat@yahoogroup <mailto:AVR-Chat%40yahoogroups.com> s.com, Ned
Konz <ned@> wrote:
> >
> > I wrote:
> > 
> > > So, using my headers, your example test for tx completed or empty
> could 
> > > be written:
> > > 
> > 
> > [snip]
> > 
> > > if (UCSR0B & ((1 << bitTXC0) | (1 << bitUDRE0)))
> > > /* do stuff */
> > > 
> > > 
> > > and the generated code would look like this:
> > 
> > [snip]
> > 
> > > or this (somewhat more efficient):
> > > 
> > > 
> > > 15:test2.c *** if (UCSR0B & ((1 << bitTXC0) | (1 <<
> bitUDRE0)))
> > > 
> > > 324 0010 8AB1 in r24,42-0x20
> > > 325 0012 8076 andi r24,lo8(96)
> > > 326 0014 31F0 breq .L5
> > > *** /* do stuff */
> > > 338 .L5
> > 
> > 
> > 
> > And here we see the problem with the bit numbers: they're not
connected 
> > with the register.
> > 
> > I made the mistake of referring to UCSR0B, when TXC0 and UDRE0 are 
> > actually in UCSR0A.
> > 
> > This is a not-uncommon error using this idiom. You don't have the 
> > ability to make this error when using bitfields.
> > 
> > The above should be:
> > 
> > if (UCSR0A & ((1 << bitTXC0) | (1 << bitUDRE0)))
> > /* do stuff */
> > 
> > 
> > I spent some time making a safer version using C++ templates, but 
> > haven't been satisifed with its ease of use.
> > 
> > -- 
> > Ned Konz
> > ned@
> > http://bike- <http://bike-nomad.com> nomad.com
> >
>

 



[Non-text portions of this message have been removed]

On Mar 28, 2007, at 4:38 PM, kernels_nz wrote:

> But! To my dismay I found that the codevision header files dont
> contain defines for bits like SPIF in the SPSR (SPI status register)
> do the other compilers like GCC and IAR have header files that have
> the names of each bit of every register defined ?
>
> I did end up rewriting the code, and to me it is now a thing of
> beauty, but I had to go through the header file and #define all the
> bits I was using for shift and masking.

You were most certainly welcome to download the avr-libc headers to  
link into your project without having to retype everything. Might  
have been easier. Might not.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Yahoo is having problems problems problems ...

Every Yahoogroup I'm on is sending at least 3 copies of every e-mail sent 
to it today. Expect to see a few of this one unless they fixed the bug by 
now ...

Zack

On Thu, 29 Mar 2007, John Samperi wrote:

> At 07:38 AM 29/03/2007, you wrote:
> >So ... after the big discussion on
> 
> Thanks for the even bigger quadruple posting :)
> 
> 
> Regards
> 
> John Samperi
>

On Mar 28, 2007, at 6:36 PM, Jeffrey Engel wrote:

> --- John Samperi <samperi@ampertronics.com.au> wrote:
>
>> At 07:38 AM 29/03/2007, you wrote:
>>> So ... after the big discussion on
>>
>> Thanks for the even bigger quadruple posting :)
>
> I think that was Yahoo.  It happened to me on a couple
> of e-mail Lists.

What seems to be happening is one's ISP delivers the message to Yahoo  
but Yahoo fails to finish the transaction but accepts the message  
anyway. So your ISP isn't told the message was accepted so it backs  
off its timer and resends the message again later when the whole  
process repeats. Each message's repeat interval depends on the ISP it  
is sent from.

This has happened before.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.