AVR-Chat

David VanHorn wrote
>On Mon, Jan 12, 2009 at 11:46 AM, subscriptions@aeolusdevelopment.com
><subscriptions@aeolusdevelopment.com> wrote:
>> David VanHorn Wrote
>>>> Right terms, think of bit fields.
>>>
>>>Cool, I haven't read about bit fields yet.
>>
>> Just don't use them to define I/O.  That way lies perdition ;)
>
>hmm.. Do you have an example?

1'st issue is 'portability of meaning'.  How bitfields are assigned is
compiler dependent so you always have to check when using them.  Compared
to just masking as appropriate, you are not saving enough mental effort to
make it worthwhile, especially since the benefit is just for a few lines of
I/O code.

2'nd and far larger issue is you just gave up control over how the
read/write are performed.  Not a problem (maybe a benefit) for internal
flags.  For I/O this shows up in several area's
   - bitfields typically are performed as a read/modify write sequence. 
This will fail (sometimes dramatically) for read only and write only
registers.  For instance given a pair of registers 
    read only register A at address 100
    write only register B at address 100

define a struct to access B with a bitfields of run and scale.  register A
is a status register that clears when read.  Now writing to the scale
bitfield will read address 100 (thus register A) mask off the appropriate
bits, or in the new scale and write back to address 100 (register B).  In
the process of updating the scale you have also unintentionally cleared
register A and possibly changed the run field.

There are also other issues but that should be enough to start with.

Robert


------------------------------------

Yahoo! Groups Links





--------------------------------------------------------------------
mail2web LIVE – Free email based on Microsoft® Exchange technology -
http://link.mail2web.com/LIVE