8-16: Bit declaration / usage problem

[NZ_Design]

I have a structure of 80 odd flags declared as single bits in the same struct.

typedef struct

{

 unsigned bBkLightTimerReset:1;
 unsigned bAllCupReq:1;
 unsigned bTestAll:1;
 unsigned bTestSingleLane:1;
 unsigned bTestSingleDrop:1;
 unsigned bTestRotation:1;
 etc

}FLAGS

I then decleared it

as

FLAGS Flags;

I have a interrupt that calles a routine that sets one flag and clears an other.

The next line after that routine tests the two flags.

If I check the status of these two flags after they are set/cleared they are as I set them. When i get back to the line that tests the two flags they are inverted.

Remebering that the code is all inside an interupt therefore nothing else can affect the flags.

If I declear the struct with uchar ..... instead of unsigned .......:1 they flags all behave as they should. ie there status stays as I set them.

Is there a option I should be setting in the compiler setup or is there a problem with the compilers handling of bits decleared this way.

Message Edited by CrasyCat on 2007-04-13 11:23 AM

[CompilerGuru]

Well, using bitfields is fine if the code is only storing and retrieving it locally. Of course using bitfields is not portable, and you should also think twice before using them with any value transfered or permanently stored. On the other hand, bitfields are more pleasant to use than masks, especially for debugging.

Having 80 bits is not more special than having just 16 bits, the compiler will just use the next bytes to store the additional bits.
As summary, I don't see any special reason why the change from unsigned char to unsigned int would make the code behave differently, in the end, we would have to see a complete app showing the problem.
With such strange error description, the problem is also often somewhere else, for example having not enough stack. (That's definitely something I would check)
Otherwise, more info :smileyhappy:
Daniel

[NZ_Design]

Have since done some playing around with the compiler setting and found if I added this switch -BfaBMS the flags appear to work correctly.

The flags are used throughout the code for indicating when things need to happed.

The stack is set to 0x600 at present.

Is there some where the compiler / map file will tell me how puch stack is recuired.

Daniel

[CrasyCat]

Hello

Basically you should understand that the ANSI C standard does not specify how a compiler is supposed to allocate bits inside of a bitfields. Bits might be allocated MSB or LSB first, there might be some alignment constraints and compiler might insert gaps between bits.

This is why bitfields are per definition not portable.

if your application is relying on the sequence in which the bits are allocated, you better use logical OR or AND operation to set/reset the bits inside of the table.

If you want to use bitfield, your application should be adjusted to whatever the compiler is doing.

CodeWarrior for HC08 & CodeWarrior for HC12 provides a set of options to change allocation scheme within bitfields (-bfaB, -bfaTSR, -BfaGapLimit), but you may not come exactly to the layout you are looking for.

You may have to adjust your application to match whatever the compiler is doing.

Please refer to the Compiler user manual for more information on internal coding for Bitfields.

I hope this helps. 

CrasyCat

[bigmac]

Hello,

The maximum width of a bit field will be compiler dependent.  For CW08 it is 16 bits.  To handle 80 flags, you will probably  need to use multiple structures.  I also suspect that you will need to declare each bit as unsigned int, rather than unsigned.

Regards,

Mac