Onestone,
Bitfield is the specific implementation as:
P1DIR_bit.P3 = 1;
P1DIR_bit.P4 = 0;
P1DIR_bit.P5 = 1;
P1DIR_bit.P6 = 1;
P1DIR_bit.P7 = 0;
And not the bit manipulation itself.
The most recommended way to manipulate bits is with bitwise ande bitshifts.
Cheers,
On Sun, Oct 20, 2013 at 9:31 PM, Onestone wrote:
> **
> Bitfields are key to embedded systems. That is what a microcontroller
> does. hence if C isn't suited for bitfields it follows that it isn't
suited
> for embedded microcontroller designs.
>
> Al
> On 21/10/2013 7:13 AM, Luis Filipe Rossi wrote:
>
> Bitfields are not recommended for most applications. As stated in MISRA,
> its implementation is not well defined so you can get different results
> among different compilers.
> On Sun, Oct 20, 2013 at 10:55 AM, Bill Knight wrote:
>
>> Also if it is needed by the hardware, you can simultaneously set, clear
>> and no-op bits in the same register by:
>>
>> P1DIR = ((P1DIR & ~(BIT4 | BIT7)) | (BIT3 | BIT5 | BIT6));
>>
>> Regards
>> -Bill Knight
>> R O SoftWare
>>
>> On 10/19/2013 8:46 PM, o...@yahoo.com wrote:
>>
>> With io430g2553.h, you can use statements such as:
>> P1DIR_bit.P3 = 1;
>> P1DIR_bit.P4 = 0;
>> P1DIR_bit.P5 = 1;
>> P1DIR_bit.P6 = 1;
>> P1DIR_bit.P7 = 0;
>>
>> With msp430g2553.h, you can do the same by:
>> P1DIR |= BIT3+BIT5+BIT6;
>> P1DIR &= ~(BIT4+BIT7);
>>
>> BTW, io430g2553 has 2796 lines while msp430g2553.h has 986 lines.
>> ---In m..., wrote:
>>
>> The deprecated header file io430g2553.h has those definitions. Using
>> |= to set bits and &= to clear bits instead are more efficient. You can
>> also use ^= to flip bits.
>> ---In m..., wrote:
>>
>> Hi! I am new and start learning MSP430G2553. And i read a book named
>> "MSP430 Microcontroller B asics" in chapter3.2. The book introduce the bit
>> fields structure for the header file. But i can't find the bit fields
>> definition in msp430g2553 header file. And it cause me a problem if i want
>> to read or write the single bit of the register. Is there any new way to
>> read or write single bit like bit fields structure in in g2553? Or should
i
>> write the header file by myself?
>>
> --
> Lu Filipe Rossi
> Electrical Engineer
> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> Escola Politnica
> Universidade de S Paulo
> Cel. +55 (11) 97662-9234
>
>
--
Lu Filipe Rossi
Electrical Engineer
Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
Escola Politnica
Universidade de S Paulo
Cel. +55 (11) 97662-9234
Bit fields?
Started by ●October 18, 2013
Reply by ●October 20, 20132013-10-20
Reply by ●October 20, 20132013-10-20
The C implementation of bit-fields is the feature which allows one
to define integer fields of a structure with a specific bit-size:
struct {
unsigned field1:2;
int field2:6;
} foo;
That's not portable, not in the way that bits are ordered by a compiler.
Of course, C permits manipulation of bits using bit masks such as
(1 << bit_num) in various forms.
Nothing new here, this is well-documented in using C for hardware
access.
Dana K6JQ
to define integer fields of a structure with a specific bit-size:
struct {
unsigned field1:2;
int field2:6;
} foo;
That's not portable, not in the way that bits are ordered by a compiler.
Of course, C permits manipulation of bits using bit masks such as
(1 << bit_num) in various forms.
Nothing new here, this is well-documented in using C for hardware
access.
Dana K6JQ
Reply by ●October 21, 20132013-10-21
MISRA is not a indicator of good programming style - it is merely an
indicator of what is allowed in the MISRA standard. There are good
reasons for having a specific standard, especially within a particular
field (automotive software) - but don't make the mistake of thinking all
MISRA rules are /good/ rules. A great many of them could be replaced by
"write structured code" and "get a compiler with decent static error
checking, enable the warnings and write warning-free code" - then you
could drop many of the worst style forced on you by MISRA (like
Yoda-style comparisons).
Bitfields are not defined by the C standard, but their ordering /is/
defined by the ABI that any given target-compiler pair uses. In the
majority of cases (of decent processors, including the msp430), the ABI
is consistent for all compilers for the same target. So while you
cannot guarantee that the bitfield ordering is the same for the msp430
as for the ARM Cortex M3, you can be sure that the ordering is the same
for msp430 with IAR, gcc, CCS, etc. And you can be /very/ sure that the
ordering is correct for the headers that come with your toolchain.
The use of shifts and masks clearly has its place - for some uses, it is
the best solution. But for others, bitfields are better, as they have a
number of clear advantages - primarily that they tie the real bitfield
to the register in question. Code in this form:
IE2.UCA0TXIE = 1;
is clearer and safer than code like :
IE2 |= UCA0TXIE;
because the former will fail to compile if "IE2" does not have a bit
named "UCA0TXIE" - while the later will compile fine without any way to
get a warning.
MISRA is absolutely wrong on this one.
mvh.,
David
On 20/10/13 22:43, Luis Filipe Rossi wrote:
>
>
> Bitfields are not recommended for most applications. As stated in MISRA,
> its implementation is not well defined so you can get different results
> among different compilers.
> On Sun, Oct 20, 2013 at 10:55 AM, Bill Knight > > wrote:
>
> __
>
>
> Also if it is needed by the hardware, you can simultaneously set,
> clear and no-op bits in the same register by:
>
> P1DIR = ((P1DIR & ~(BIT4 | BIT7)) | (BIT3 | BIT5 | BIT6));
>
> Regards
> -Bill Knight
> R O SoftWare
>
> On 10/19/2013 8:46 PM, o...@yahoo.com
> wrote:
>> With io430g2553.h, you can use statements such as:
>> P1DIR_bit.P3 = 1;
>> P1DIR_bit.P4 = 0;
>> P1DIR_bit.P5 = 1;
>> P1DIR_bit.P6 = 1;
>> P1DIR_bit.P7 = 0;
>>
>> With msp430g2553.h, you can do the same by:
>> P1DIR |= BIT3+BIT5+BIT6;
>> P1DIR &= ~(BIT4+BIT7);
>>
>> BTW, io430g2553 has 2796 lines while msp430g2553.h has 986 lines.
>>
>>
>>
>> ---In m... ,
>> wrote:
>>
>> The deprecated header file io430g2553.h has those definitions.
>> Using |= to set bits and &= to clear bits instead are more
>> efficient. You can also use ^= to flip bits.
>>
>> ---In m... ,
>> wrote:
>>
>> Hi! I am new and start learning MSP430G2553. And i read a book
>> named "MSP430 Microcontroller B asics" in chapter3.2. The book
>> introduce the bit fields structure for the header file. But i
>> can't find the bit fields definition in msp430g2553 header file.
>> And it cause me a problem if i want to read or write the single
>> bit of the register. Is there any new way to read or write single
>> bit like bit fields structure in in g2553? Or should i write the
>> header file by myself?
> --
> Lu Filipe Rossi
> Electrical Engineer
> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> Escola Politnica
> Universidade de S Paulo
> Cel. +55 (11) 97662-9234
indicator of what is allowed in the MISRA standard. There are good
reasons for having a specific standard, especially within a particular
field (automotive software) - but don't make the mistake of thinking all
MISRA rules are /good/ rules. A great many of them could be replaced by
"write structured code" and "get a compiler with decent static error
checking, enable the warnings and write warning-free code" - then you
could drop many of the worst style forced on you by MISRA (like
Yoda-style comparisons).
Bitfields are not defined by the C standard, but their ordering /is/
defined by the ABI that any given target-compiler pair uses. In the
majority of cases (of decent processors, including the msp430), the ABI
is consistent for all compilers for the same target. So while you
cannot guarantee that the bitfield ordering is the same for the msp430
as for the ARM Cortex M3, you can be sure that the ordering is the same
for msp430 with IAR, gcc, CCS, etc. And you can be /very/ sure that the
ordering is correct for the headers that come with your toolchain.
The use of shifts and masks clearly has its place - for some uses, it is
the best solution. But for others, bitfields are better, as they have a
number of clear advantages - primarily that they tie the real bitfield
to the register in question. Code in this form:
IE2.UCA0TXIE = 1;
is clearer and safer than code like :
IE2 |= UCA0TXIE;
because the former will fail to compile if "IE2" does not have a bit
named "UCA0TXIE" - while the later will compile fine without any way to
get a warning.
MISRA is absolutely wrong on this one.
mvh.,
David
On 20/10/13 22:43, Luis Filipe Rossi wrote:
>
>
> Bitfields are not recommended for most applications. As stated in MISRA,
> its implementation is not well defined so you can get different results
> among different compilers.
> On Sun, Oct 20, 2013 at 10:55 AM, Bill Knight > > wrote:
>
> __
>
>
> Also if it is needed by the hardware, you can simultaneously set,
> clear and no-op bits in the same register by:
>
> P1DIR = ((P1DIR & ~(BIT4 | BIT7)) | (BIT3 | BIT5 | BIT6));
>
> Regards
> -Bill Knight
> R O SoftWare
>
> On 10/19/2013 8:46 PM, o...@yahoo.com
> wrote:
>> With io430g2553.h, you can use statements such as:
>> P1DIR_bit.P3 = 1;
>> P1DIR_bit.P4 = 0;
>> P1DIR_bit.P5 = 1;
>> P1DIR_bit.P6 = 1;
>> P1DIR_bit.P7 = 0;
>>
>> With msp430g2553.h, you can do the same by:
>> P1DIR |= BIT3+BIT5+BIT6;
>> P1DIR &= ~(BIT4+BIT7);
>>
>> BTW, io430g2553 has 2796 lines while msp430g2553.h has 986 lines.
>>
>>
>>
>> ---In m... ,
>> wrote:
>>
>> The deprecated header file io430g2553.h has those definitions.
>> Using |= to set bits and &= to clear bits instead are more
>> efficient. You can also use ^= to flip bits.
>>
>> ---In m... ,
>> wrote:
>>
>> Hi! I am new and start learning MSP430G2553. And i read a book
>> named "MSP430 Microcontroller B asics" in chapter3.2. The book
>> introduce the bit fields structure for the header file. But i
>> can't find the bit fields definition in msp430g2553 header file.
>> And it cause me a problem if i want to read or write the single
>> bit of the register. Is there any new way to read or write single
>> bit like bit fields structure in in g2553? Or should i write the
>> header file by myself?
> --
> Lu Filipe Rossi
> Electrical Engineer
> Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
> Escola Politnica
> Universidade de S Paulo
> Cel. +55 (11) 97662-9234
Reply by ●October 21, 20132013-10-21
The C implementation of bit-fields is the feature which allows one
to define integer fields of a structure with a specific bit-size:
struct {
unsigned field1:2;
int field2:6;
} foo;
That's not portable, not in the way that bits are ordered by a compiler.
Of course, C permits manipulation of bits using bit masks such as
(1 << bit_num) in various forms.
Nothing new here, this is well-documented in using C for hardware
access.
That may be true for many compilers. However, an ABI may mandate that a
compiler do many things in addition to that required by Plain Old C. An ABI
defines the calling convention, it may well define the object format and the
way names are converted to linker symbols. It may also define the way that
bit fields work and the way they are allocated and assign additional
semantics. The 88000 ABI was like this. The ARM AEABI one also.
So whilst I agree that bit fields are inherently non-portable within C when
mapping to device registers, the addition of an ABI makes them useful. This
is akin to a C coding standard, you use it or you don't.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
to define integer fields of a structure with a specific bit-size:
struct {
unsigned field1:2;
int field2:6;
} foo;
That's not portable, not in the way that bits are ordered by a compiler.
Of course, C permits manipulation of bits using bit masks such as
(1 << bit_num) in various forms.
Nothing new here, this is well-documented in using C for hardware
access.
That may be true for many compilers. However, an ABI may mandate that a
compiler do many things in addition to that required by Plain Old C. An ABI
defines the calling convention, it may well define the object format and the
way names are converted to linker symbols. It may also define the way that
bit fields work and the way they are allocated and assign additional
semantics. The 88000 ABI was like this. The ARM AEABI one also.
So whilst I agree that bit fields are inherently non-portable within C when
mapping to device registers, the addition of an ABI makes them useful. This
is akin to a C coding standard, you use it or you don't.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●October 21, 20132013-10-21
> Bitfields are not defined by the C standard, but their ordering /is/
> defined by the ABI that any given target-compiler pair uses. In the
> majority of cases (of decent processors, including the msp430), the ABI is
> consistent for all compilers for the same target. So while you cannot
> guarantee that the bitfield ordering is the same for the msp430 as for the
> ARM Cortex M3, you can be sure that the ordering is the same for msp430
> with IAR, gcc, CCS, etc.
The MSP430 has no defined ABI.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●October 21, 20132013-10-21
On 21/10/13 10:31, Paul Curtis wrote:
>
>> Bitfields are not defined by the C standard, but their ordering /is/
>> defined by the ABI that any given target-compiler pair uses. In the
>> majority of cases (of decent processors, including the msp430), the ABI is
>> consistent for all compilers for the same target. So while you cannot
>> guarantee that the bitfield ordering is the same for the msp430 as for the
>> ARM Cortex M3, you can be sure that the ordering is the same for msp430
>> with IAR, gcc, CCS, etc.
>
> The MSP430 has no defined ABI.
>
OK (I guess you'd know!)
But in the case of bitfields, I think all msp430 compilers will conform
to little-endian bit ordering. There may not be an official ABI
standardising it, but anything else would be /really/ strange.
However, it is always best to use the header files that come with your
toolchain - if these have bitfields defined, then the order in these
definitions will match the order used by the compiler.
Using bitfields in data that is moved between tools or between targets
is always risky as they are not standardised, but using them within a
program is safe.
>
>> Bitfields are not defined by the C standard, but their ordering /is/
>> defined by the ABI that any given target-compiler pair uses. In the
>> majority of cases (of decent processors, including the msp430), the ABI is
>> consistent for all compilers for the same target. So while you cannot
>> guarantee that the bitfield ordering is the same for the msp430 as for the
>> ARM Cortex M3, you can be sure that the ordering is the same for msp430
>> with IAR, gcc, CCS, etc.
>
> The MSP430 has no defined ABI.
>
OK (I guess you'd know!)
But in the case of bitfields, I think all msp430 compilers will conform
to little-endian bit ordering. There may not be an official ABI
standardising it, but anything else would be /really/ strange.
However, it is always best to use the header files that come with your
toolchain - if these have bitfields defined, then the order in these
definitions will match the order used by the compiler.
Using bitfields in data that is moved between tools or between targets
is always risky as they are not standardised, but using them within a
program is safe.
Reply by ●October 21, 20132013-10-21
On Mon, 2013-10-21 at 10:01 +1030, Onestone wrote:
> Bitfields are key to embedded systems. That is what a microcontroller
> does. hence if C isn't suited for bitfields it follows that it isn't
> suited for embedded microcontroller designs.
There are alternatives.
Ada has superb support for embedded programming including bitfield
manipulation, and experimentally, msp-gcc built with Ada support seems
to work well on the MSP430 (so far, without support for the larger
devices or multitasking). This is mainly down to the (IMO) superb job
done by the folks writing the msp-gcc back end.
Currently its bitfield definitions are only auto-generated from the C
header files, I haven't attempted a more Ada-style conversion into, for
example, records as described in the McCormick book. But bit accesses do
compile down to the expected bit access instructions.
http://sourceforge.net/projects/msp430ada/
if anyone's interested in taking a look.
- Brian
> Bitfields are key to embedded systems. That is what a microcontroller
> does. hence if C isn't suited for bitfields it follows that it isn't
> suited for embedded microcontroller designs.
There are alternatives.
Ada has superb support for embedded programming including bitfield
manipulation, and experimentally, msp-gcc built with Ada support seems
to work well on the MSP430 (so far, without support for the larger
devices or multitasking). This is mainly down to the (IMO) superb job
done by the folks writing the msp-gcc back end.
Currently its bitfield definitions are only auto-generated from the C
header files, I haven't attempted a more Ada-style conversion into, for
example, records as described in the McCormick book. But bit accesses do
compile down to the expected bit access instructions.
http://sourceforge.net/projects/msp430ada/
if anyone's interested in taking a look.
- Brian
Reply by ●October 21, 20132013-10-21
> >> Bitfields are not defined by the C standard, but
their ordering /is/
> >> defined by the ABI that any given target-compiler pair uses. In the
> >> majority of cases (of decent processors, including the msp430), the
> >> ABI is consistent for all compilers for the same target. So while you
> >> cannot guarantee that the bitfield ordering is the same for the
> >> msp430 as for the ARM Cortex M3, you can be sure that the ordering is
> >> the same for msp430 with IAR, gcc, CCS, etc.
> >
> > The MSP430 has no defined ABI.
>
> OK (I guess you'd know!)
>
> But in the case of bitfields, I think all msp430 compilers will conform to
> little-endian bit ordering. There may not be an official ABI
> standardising it, but anything else would be /really/ strange.
I'm not sure what little-endian bit ordering would be, but typically most
compilers that I have come across (and coded) allocate bitfields in
declaration order from the most significant bits down to the least
significant bits within a storage unit.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> >> defined by the ABI that any given target-compiler pair uses. In the
> >> majority of cases (of decent processors, including the msp430), the
> >> ABI is consistent for all compilers for the same target. So while you
> >> cannot guarantee that the bitfield ordering is the same for the
> >> msp430 as for the ARM Cortex M3, you can be sure that the ordering is
> >> the same for msp430 with IAR, gcc, CCS, etc.
> >
> > The MSP430 has no defined ABI.
>
> OK (I guess you'd know!)
>
> But in the case of bitfields, I think all msp430 compilers will conform to
> little-endian bit ordering. There may not be an official ABI
> standardising it, but anything else would be /really/ strange.
I'm not sure what little-endian bit ordering would be, but typically most
compilers that I have come across (and coded) allocate bitfields in
declaration order from the most significant bits down to the least
significant bits within a storage unit.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●October 21, 20132013-10-21
From: m... [mailto:m...] On Behalf Of Paulo Ricardo Pabst
Sent: Saturday, October 19, 2013 9:54 PM
To: m...
Subject: Re: [msp430] RE: Bit fields?
But is better to use:
P1DIR |= BIT3|BIT5|BIT6;
P1DIR &= ~(BIT4|BIT7);
To avoid errors like using the same bit twice and getting an erroneos value.
--Paulo Ricardo
o...@yahoo.com escreveu:
With io430g2553.h, you can use statements such as:
P1DIR_bit.P3 = 1;
P1DIR_bit.P4 = 0;
P1DIR_bit.P5 = 1;
P1DIR_bit.P6 = 1;
P1DIR_bit.P7 = 0;
With msp430g2553.h, you can do the same by:
P1DIR |= BIT3+BIT5+BIT6;
P1DIR &= ~(BIT4+BIT7);
One simple advice,
It’s bad practice to ADD bits when you are using bit arithmetic, OR them instead, and you will not get into trouble.
BTW, io430g2553 has 2796 lines while msp430g2553.h has 986 lines.
---In m..., wrote:
The deprecated header file io430g2553.h has those definitions. Using |= to set bits and &= to clear bits instead are more efficient. You can also use ^= to flip bits.
---In m..., wrote:
Hi! I am new and start learning MSP430G2553. And i read a book named "MSP430 Microcontroller Bas ics" in chapter3.2. The book introduce the bit fields structure for the header file. But i can't find the bit fields definition in msp430g2553 header file. And it cause me a problem if i want to read or write the single bit of the register. Is there any new way to read or write single bit like bit fields structure in in g2553? Or should i write the header file by myself?
--
E-mail enviado do meu celular Android usando K-9 Mail. Por favor, desculpe minha brevidade.
Sent: Saturday, October 19, 2013 9:54 PM
To: m...
Subject: Re: [msp430] RE: Bit fields?
But is better to use:
P1DIR |= BIT3|BIT5|BIT6;
P1DIR &= ~(BIT4|BIT7);
To avoid errors like using the same bit twice and getting an erroneos value.
--Paulo Ricardo
o...@yahoo.com escreveu:
With io430g2553.h, you can use statements such as:
P1DIR_bit.P3 = 1;
P1DIR_bit.P4 = 0;
P1DIR_bit.P5 = 1;
P1DIR_bit.P6 = 1;
P1DIR_bit.P7 = 0;
With msp430g2553.h, you can do the same by:
P1DIR |= BIT3+BIT5+BIT6;
P1DIR &= ~(BIT4+BIT7);
One simple advice,
It’s bad practice to ADD bits when you are using bit arithmetic, OR them instead, and you will not get into trouble.
BTW, io430g2553 has 2796 lines while msp430g2553.h has 986 lines.
---In m..., wrote:
The deprecated header file io430g2553.h has those definitions. Using |= to set bits and &= to clear bits instead are more efficient. You can also use ^= to flip bits.
---In m..., wrote:
Hi! I am new and start learning MSP430G2553. And i read a book named "MSP430 Microcontroller Bas ics" in chapter3.2. The book introduce the bit fields structure for the header file. But i can't find the bit fields definition in msp430g2553 header file. And it cause me a problem if i want to read or write the single bit of the register. Is there any new way to read or write single bit like bit fields structure in in g2553? Or should i write the header file by myself?
--
E-mail enviado do meu celular Android usando K-9 Mail. Por favor, desculpe minha brevidade.
Reply by ●October 21, 20132013-10-21
On 21/10/13 12:09, Paul Curtis wrote:
>>>> Bitfields are not defined by the C standard, but their ordering /is/
>>>> defined by the ABI that any given target-compiler pair uses. In the
>>>> majority of cases (of decent processors, including the msp430), the
>>>> ABI is consistent for all compilers for the same target. So while you
>>>> cannot guarantee that the bitfield ordering is the same for the
>>>> msp430 as for the ARM Cortex M3, you can be sure that the ordering is
>>>> the same for msp430 with IAR, gcc, CCS, etc.
>>>
>>> The MSP430 has no defined ABI.
>>
>> OK (I guess you'd know!)
>>
>> But in the case of bitfields, I think all msp430 compilers will conform to
>> little-endian bit ordering. There may not be an official ABI
>> standardising it, but anything else would be /really/ strange.
>
> I'm not sure what little-endian bit ordering would be, but typically most
> compilers that I have come across (and coded) allocate bitfields in
> declaration order from the most significant bits down to the least
> significant bits within a storage unit.
>
Little-endian bit ordering has the least significant bit first, which is
the most common for little-endian processors. What you are describing
is big-endian ordering, which is common on big-endian processors (such
as the PPC or Coldfire). But there is no fixed rule here - this is just
the most common choice. Compilers can have different orderings - MS
famously changed the order its compiler used from big-endian bit
ordering to little-endian bit ordering between two compiler versions.
ARM EABI defines bit ordering this way - little-endian bit ordering in
little-endian mode, and big-endian bit ordering in big-endian mode. gcc
also always uses this convention unless the ABI specifies something
different, so the msp430-gcc port uses little-endian bitfield order.
If other msp430 ports have a different order, then I've learned
something new today.
And that just re-enforces the point that the ordering is not consistent
across different tools and different targets, unless specified by the
ABI, but it /is/ consistent within a tool and its headers. So bitfields
are safe to use within a program, and it is safe to use
toolchain-supplied headers that use bitfield definitions. But it is not
safe to assume that bitfield ordering is the same for different
compilers or targets.
>>>> Bitfields are not defined by the C standard, but their ordering /is/
>>>> defined by the ABI that any given target-compiler pair uses. In the
>>>> majority of cases (of decent processors, including the msp430), the
>>>> ABI is consistent for all compilers for the same target. So while you
>>>> cannot guarantee that the bitfield ordering is the same for the
>>>> msp430 as for the ARM Cortex M3, you can be sure that the ordering is
>>>> the same for msp430 with IAR, gcc, CCS, etc.
>>>
>>> The MSP430 has no defined ABI.
>>
>> OK (I guess you'd know!)
>>
>> But in the case of bitfields, I think all msp430 compilers will conform to
>> little-endian bit ordering. There may not be an official ABI
>> standardising it, but anything else would be /really/ strange.
>
> I'm not sure what little-endian bit ordering would be, but typically most
> compilers that I have come across (and coded) allocate bitfields in
> declaration order from the most significant bits down to the least
> significant bits within a storage unit.
>
Little-endian bit ordering has the least significant bit first, which is
the most common for little-endian processors. What you are describing
is big-endian ordering, which is common on big-endian processors (such
as the PPC or Coldfire). But there is no fixed rule here - this is just
the most common choice. Compilers can have different orderings - MS
famously changed the order its compiler used from big-endian bit
ordering to little-endian bit ordering between two compiler versions.
ARM EABI defines bit ordering this way - little-endian bit ordering in
little-endian mode, and big-endian bit ordering in big-endian mode. gcc
also always uses this convention unless the ABI specifies something
different, so the msp430-gcc port uses little-endian bitfield order.
If other msp430 ports have a different order, then I've learned
something new today.
And that just re-enforces the point that the ordering is not consistent
across different tools and different targets, unless specified by the
ABI, but it /is/ consistent within a tool and its headers. So bitfields
are safe to use within a program, and it is safe to use
toolchain-supplied headers that use bitfield definitions. But it is not
safe to assume that bitfield ordering is the same for different
compilers or targets.
