AVR-Chat

On Mar 25, 2009, at 10:58 AM, David Kelly wrote:

> On Wed, Mar 25, 2009 at 04:06:21PM -0000, Graham Davies wrote:
> > --- In AVR-Chat@yahoogroups.com, David VanHorn <microbrix@...>  
> wrote:
> >
> > > Casting is something that I'm not up on yet.
> >
> > Casting is taking a variable of one type and treating it as if it  
> were
> > of a different type. You do this in assembler all the time. A
> > strength of C is that the compiler is supposed to protect you from
> > doing it when you don't mean to, as in the above case. An "implicit"
> > cast is one that you don't write but that happens anyway to match up
> > the types. These can be benign (such as treating an 8-bit integer as
> > a 16-bit integer when necessary), wasteful and confusing (such as
> > treating an 8-bit integer as a 16-bit integer when required by the
> > language definition but not strictly necessary), or dangerous and
> > probably wrong, as in your case.
> >
> > With decades of high-level language programming experience behind  
> me,
> > I have a policy of avoiding implicit casts. In other words, I write
> > my casts out in the code. Then, I can see what the compiler is going
> > to do because I'm telling it exactly. These are called "explicit"
> > casts. You might want to consider this.
>
> Casts can get ugly pretty quick, especially when using pointers. I
> usually end up defining a UNION32_t typedef before a project is  
> finished
> so that I can mix types and reach inside values easier.
>
> typedef union {
> struct {
> uint8_t	a,
> b,
> c,
> d;
> } u8;
> struct {
> uint16_t ab,
> cd;
> } u16;
> uint32_t	u32;
> int32_t	 i32;
> } UNION32_t;
>
> Then I can declare "UNION32_t tmp;" and use it as tmp.u32 or tmp.i32  
> or
> just use parts from inside with tmp.u8.a, or whatever.
>
> Before copying this into your own code spend some time thinking about
> tmp.u16.ab and whether its spelled right and in the right location to
> pick up bytes a and b, or b and a, or whether or not the first  
> should be
> c and d. Am pretty sure as shown its not right for an AVR.
>
> -- 
> David Kelly N4HHE, dkelly@HiWAAY.net
> = 
> = 
> ======================================================================
> Whom computers would destroy, they must first drive mad.
>
> 
Thanks, everyone for this great discussion. I am having many of the  
same problems that David van Horn is and this is a great help.

Jim Wagner
Oregon Research Electronics
KA7EHK

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