Bit-fields as structure members with a limited range, sure, they're a
way of saving data space at the (probable) expense of code space.
Of course, in this context, they're portable.
Bit-fields as a hardware-register access scheme, that's not portable,
Given, if the code is indelibly tied to a particular CPU architecture in
the first place (such as
an on-chip peripherals), that's not necessarily a problem (unless
perhaps
you're
dealing with an architecture that can be found in different endian-ness).
For a peripheral that may be used independently of a CPU architecture,
portability may be a concern, or probably ought to be a concern.
Cheers,
Dana K6JQ
On Tue, Oct 22, 2013 at 12:54 AM, Paul Curtis wrote:
> **
> ** **
>
> Awful lot of words about something that really doesn't buy much.****
>
> ** **
>
> Bit-fields are a great concept. They're non-portable. Too bad.****
>
> ** **
>
> Bit fields are portable they work on all compilers that claim to support
> ISO C and are a way of conserving data space at the expense of code space
> (in most cases). What they dont have is the ability to precisely map
> device registers or protocol fields across architectures and compilers, yet
> some customers think that they should. Theyre wrong, there are other ways
> of making that happen portably.****
>
> ** **
>
> ** **
>
> --****
>
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk****
>
> SolderCore Development Platform http://www.soldercore.com****
>
>
>
Awful lot of words about something that really doesn't buy much.
Bit-fields are a great concept. They're non-portable. Too bad.
Bit fields are portable - they work on all compilers that claim to support
ISO C and are a way of conserving data space at the expense of code space
(in most cases). What they don't have is the ability to precisely map
device registers or protocol fields across architectures and compilers, yet
some customers think that they should. They're wrong, there are other
ways
of making that happen portably.
Most of what you write in embedded development is non-portable, or at
least not directly portable. So what do you lose by using bitfields?
Nothing.
Bitfields are a great concept. Enough said.
mvh.,
David > Awful lot of words about something that really
doesn't buy much.
>
> Bit-fields are a great concept. They're non-portable. Too bad.
>
> Enough said.
>
> Cheers,
>
> Dana K6JQ
> On Mon, Oct 21, 2013 at 1:17 PM, David Brown
> > wrote:
>
> __
>
>
> Hi,
>
> I know what MISRA stands for - and I know what it is used for. But I
> also know that many of its rules are bad for embedded software
> development. Some have the excuse that they reduce the risk of certain
> types of mistake if you have terrible quality tools - unfortunately,
> some tools in common use /are/ poor quality.
>
> It is true that bitfields have portability issues. But there are /no/
> issues with using bitfields with quality tools, and there are /no/
> issues with using bitfields that are confirmed correct for the
> toolchain
> you are using. When you are using bitfields defined in toolchain
> headers to match the device you are using, there are /no/ portability
> issues because the code is clearly non-portable (and if another
> compiler
> for the same device has a different bitfield ordering, then either it
> has headers in the new order, or it does not have bitfield headers.
> Either way, you have /no/ chance of successfully compiling incorrect
> code).
>
> And because bitfields tie the field to the main structure much more
> tightly than shifts and masks do, they reduce the risk of errors.
> Therefore they are a good idea and contribute to safer and more
> reliable
> development processes.
>
> mvh.,
>
> David
>
> On 21/10/13 20:23, DRAGOS Condurache wrote:
> > One reason why MISRA does not use bitfields is because they are not
> > portable. When you work at your own project at home nobody can
> tell you
> > what to use or how to write your code, but when you have to create
> > portable code for multiple projects you have to reconsider using
> bitfelds.
> > MISRA = "Motor Industry Software Reliability Association";
> >
> > *--
> > Dragos Condurache*
>
> > Software Development Engineer at Continental Automotive Systems,
Sibiu
> > 0755-685-983
> >
>
>
> >
> > On Mon, Oct 21, 2013 at 9:49 AM, David Brown
>
> > >> wrote:
> >
> >
> > 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
>
> >
Reply by Dana Myers●October 21, 20132013-10-21
Awful lot of words about something that really doesn't buy much.
Bit-fields are a great concept. They're non-portable. Too bad.
Enough said.
Cheers,
Dana K6JQ
On Mon, Oct 21, 2013 at 1:17 PM, David Brown wrote:
> **
> Hi,
>
> I know what MISRA stands for - and I know what it is used for. But I
> also know that many of its rules are bad for embedded software
> development. Some have the excuse that they reduce the risk of certain
> types of mistake if you have terrible quality tools - unfortunately,
> some tools in common use /are/ poor quality.
>
> It is true that bitfields have portability issues. But there are /no/
> issues with using bitfields with quality tools, and there are /no/
> issues with using bitfields that are confirmed correct for the toolchain
> you are using. When you are using bitfields defined in toolchain
> headers to match the device you are using, there are /no/ portability
> issues because the code is clearly non-portable (and if another compiler
> for the same device has a different bitfield ordering, then either it
> has headers in the new order, or it does not have bitfield headers.
> Either way, you have /no/ chance of successfully compiling incorrect code).
>
> And because bitfields tie the field to the main structure much more
> tightly than shifts and masks do, they reduce the risk of errors.
> Therefore they are a good idea and contribute to safer and more reliable
> development processes.
>
> mvh.,
>
> David
> On 21/10/13 20:23, DRAGOS Condurache wrote:
> > One reason why MISRA does not use bitfields is because they are not
> > portable. When you work at your own project at home nobody can tell you
> > what to use or how to write your code, but when you have to create
> > portable code for multiple projects you have to reconsider using
> bitfelds.
> > MISRA = "Motor Industry Software Reliability Association";
> >
> > *--
> > Dragos Condurache*
>
> > Software Development Engineer at Continental Automotive Systems, Sibiu
> > 0755-685-983
> > <
>
https://www.facebook.com/pages/Continental-Automotive-Systems-Sibiu/292150000844726?ref=br_rs
> > >
> >
> > On Mon, Oct 21, 2013 at 9:49 AM, David Brown
> > > wrote:
> >
> >
> > 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
> >
>
Reply by David Brown●October 21, 20132013-10-21
Hi,
I know what MISRA stands for - and I know what it is used for. But I
also know that many of its rules are bad for embedded software
development. Some have the excuse that they reduce the risk of certain
types of mistake if you have terrible quality tools - unfortunately,
some tools in common use /are/ poor quality.
It is true that bitfields have portability issues. But there are /no/
issues with using bitfields with quality tools, and there are /no/
issues with using bitfields that are confirmed correct for the toolchain
you are using. When you are using bitfields defined in toolchain
headers to match the device you are using, there are /no/ portability
issues because the code is clearly non-portable (and if another compiler
for the same device has a different bitfield ordering, then either it
has headers in the new order, or it does not have bitfield headers.
Either way, you have /no/ chance of successfully compiling incorrect code).
And because bitfields tie the field to the main structure much more
tightly than shifts and masks do, they reduce the risk of errors.
Therefore they are a good idea and contribute to safer and more reliable
development processes.
mvh.,
David
On 21/10/13 20:23, DRAGOS Condurache wrote: > One reason why MISRA does not use bitfields is
because they are not
> portable. When you work at your own project at home nobody can tell you
> what to use or how to write your code, but when you have to create
> portable code for multiple projects you have to reconsider using bitfelds.
> MISRA = "Motor Industry Software Reliability Association";
>
> *--
> Dragos Condurache*
> Software Development Engineer at Continental Automotive Systems, Sibiu
> 0755-685-983
>
> On Mon, Oct 21, 2013 at 9:49 AM, David Brown
> > wrote:
> 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
Reply by DRAGOS Condurache●October 21, 20132013-10-21
One reason why MISRA does not use bitfields is because they are not
portable. When you work at your own project at home nobody can tell you
what to use or how to write your code, but when you have to create portable
code for multiple projects you have to reconsider using bitfelds.
MISRA = "Motor Industry Software Reliability Association";
*--
Dragos Condurache*
Software Development Engineer at Continental Automotive Systems, Sibiu
0755-685-983
On Mon, Oct 21, 2013 at 9:49 AM, David Brown wrote:
>
> 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
>
>
> Yahoo! Groups Links
Reply by David Brown●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.
Reply by Hugo Brunert●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.
Reply by Paul Curtis●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.
Reply by Brian Drummond●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.
