Porting code from a PIC to AVR - bitfields

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The existing code has a bitfield ( which I've not used before ), e.g:

struct {
int1 enable;
int1 stuff;
int8 spare:4;
int8 RFoption:4;
int8 RTgType:4;
}b;

and the bits are subsequently referenced in the main program using the dot operator.
I'm not sure of the int1,int8 declarations or how to convert it to GCC style.
Can I do the same or similar within WinAVR?

Pointers appreciated

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If this structure used only internally and is not written or read to/from any external interface (which is a bad idea with bitfields or structures in general) then reasonable alternative would be:

#include 

struct {
  uint8_t enable  : 1;
  uint8_t stuff   : 1;
  uint8_t spare   : 4;
  uint8_t         : 2; // may be omitted 
  uint8_t RFoption: 4;
  uint8_t RTgType : 4;
} b;

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't blindly use uint8_t (or unsigned, which would be the same). The original bit fields all used a signed int. You would have to investigate the original source code if the signedness matters or not.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see all the int1's have been replaced by the uint8, but afaik int1 is a single bool, int8 is an 8 bit variabl. Was the alternative correct with :

  uint8_t         : 2; // may be omitted 

Could someone comment the effect of each line?

Sorry - I'm being a bit dim now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I see all the int1's have been replaced by the uint8, but afaik int1 is a single bool,

No, the int1's have been replaced with "uint8_t xxx : 1". The ": 1" reserves 1 bit.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rowifi wrote:
Was the alternative correct with :

  uint8_t         : 2; // may be omitted 

Could someone comment the effect of each line?

The thing is that your original structure described 14 bits and compiler is free to place them in the arbitrary order, so some documentation reading is required if you want to reproduce the exact order. In memory 14 bits are rounded to 16 so 2 bits must be left unused. To indicate unused bits C specification allows to have unnamed bitfields.

With this alternative code should compile, to say if alternative is fully correct we'll need to see original code.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to my knowledge the compiler is not allowed to put struct members in arbitrary order. Struct members order is defined by user, only big/little endian problem can affect the byte order.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The compiler can put them in whichever order it likes. e.g. msb first or lsb first

It can insert padding between the members in any way that it likes. It will preserve the relative storage order of the members. i.e. it will not shuffle the members.

This is only relevant to people trying to fiddle with the structure. e.g. exporting the memory or accessing as a different data type.

'b.stuff' or 'b.spare' will behave the same with any compiler on any platform. So should only be a porting issue if you override the rules. e.g. casting or deliberately accessing indirectly as a different type.

As far as I can remember bitfields are always unsigned.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Revelant information about bitfields:
http://publib.boulder.ibm.com/in...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh also it looks like the pic format is non standard, int1 meaning a one byte integer, while int8_t is an 8 bit integer (same thing, except for those odd ball ancient computers with 6 bit bytes, aka PDP8)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kscharf wrote:
Oh also it looks like the pic format is non standard, int1 meaning a one byte integer,

No, int1 is actually 1 bit in CCS-PICC syntax.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex,

If you want an example of the most convoluted non-standard C compiler. Just look at CCS-PICC.

It is as if someone looked at the 14 bit PIC and thought what an horrible architecture, let us create an abortion. And CCS-PICC was born.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Alex,

If you want an example of the most convoluted non-standard C compiler. Just look at CCS-PICC.

It is as if someone looked at the 14 bit PIC and thought what an horrible architecture, let us create an abortion. And CCS-PICC was born.

David.


Well trying to make a C compiler for the pic14 arch. is like putting a square peg in a round hole anyway.