• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 1223 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bit field manipulation of two output ports

Efstratios Petrou
Prodigy 140 points
Other Parts Discussed in Thread: MSP430F6638

Hi forum users,

my task is to send data from the MCU MSP430F6638 to the LCD Driver ILI9341 using the 8080-I 16-Bit parallel MCU interface. In other words, in order to write a pixel to my display I have to send 16-bit data using 16 output pins of the MCU.

Now, my problem is how can I do this bit field manipulation effectively. I have tried a forum solution but unsuccessfully:

  http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/219088.aspx

This is what I have done taking into consideration the above link:

Linker Command File

P4OUT_bit:origin=0x223, length=0x0001;
P8OUT_bit:origin=0x263, length=0x0001;
P4OUT_bit:origin=0x282, length=0x0001;

dts028atft.h

extern volatile struct {
unsigned int pin0:1;
unsigned int pin1:1;
unsigned int pin2:1;
unsigned int pin3:1;
unsigned int pin4:1;
unsigned int pin5:1;
unsigned int pin6:1;
unsigned int pin7:1;
}P4OUT_bit;

extern volatile struct  {
unsigned int pin0:1;
unsigned int pin1:1;
unsigned int pin2:1;
unsigned int pin3:1;
unsigned int pin4:1;
unsigned int pin5:1;
unsigned int pin6:1;
unsigned int pin7:1;
}P8OUT_bit;

extern volatile struct  {
unsigned int pin0:1;
unsigned int pin1:1;
unsigned int pin2:1;
unsigned int pin3:1;
unsigned int pin4:1;
unsigned int pin5:1;
unsigned int pin6:1;
unsigned int pin7:1;
}P9OUT_bit;

#define DB0 P4OUT_bit.pin2
#define DB1 P4OUT_bit.pin3
#define DB2 P4OUT_bit.pin4
#define DB3 P4OUT_bit.pin5
#define DB4 P4OUT_bit.pin6
#define DB5 P4OUT_bit.pin7
#define DB6 P8OUT_bit.pin0
#define DB7 P8OUT_bit.pin5
#define DB8 P8OUT_bit.pin6
#define DB9 P8OUT_bit.pin7
#define DB10 P9OUT_bit.pin0
#define DB11 P9OUT_bit.pin1
#define DB12 P9OUT_bit.pin2
#define DB13 P9OUT_bit.pin3
#define DB14 P9OUT_bit.pin4
#define DB15 P9OUT_bit.pin5

Without changing the Symbol Management, I have got the following errors and Warnings:

Errors
errors encountered during linking; "Project_MSP430F6638.out" not built             Project_MSP430F6638    line 0    1366970122846    1807
unresolved symbol P4OUT_bit, first referenced in ./dts028atft_320x240.obj        Project_MSP430F6638    line 0    1366970122846    1804
unresolved symbol P8OUT_bit, first referenced in ./dts028atft_320x240.obj        Project_MSP430F6638    line 0    1366970122846    1805
unresolved symbol P9OUT_bit, first referenced in ./dts028atft_320x240.obj        Project_MSP430F6638    line 0    1366970122846    1806

Warnings
absolute symbol "length" being redefined                            Project_MSP430F6638    line 0    1366970122846    1800
absolute symbol "P4OUT_bit:origin" being redefined        Project_MSP430F6638    line 0    1366970122846    1801
absolute symbol "P8OUT_bit:origin" being redefined        Project_MSP430F6638    line 0    1366970122846    1802
absolute symbol "P9OUT_bit:origin" being redefined        Project_MSP430F6638    line 0    1366970122846    1803

Please could you tell me how I can solve this problem?

Thanks in advance,

Stratos

  • 0
    Guru 227245 points

    Efstratios Petrou said:
    Now, my problem is how can I do this bit field manipulation effectively.

    By not using bitfields on hardware registers. This is convenient but will most certainly cause inefficient and ineffective code.
    Since hardware registers are volatile, the compiler must not perform any optimization on and around accesses to hardware registers. This also means that any bitfield operation must be carried out independently. The compiler cannot group multiple accesses to the bitfield into one instruction.

    This is one of the reasons why the earlier provided bitfields in the MSP header files are deprecated or even removed from the newer headers.

    Another one is that IMHO the order of bitfields is not guaranteed. Even though bits are usually placed in the bitfield the order you define them, this is AFAIK not required by the standard. You cannot safely assume that on each compiler your pin0 will correspond to BIT0 of the register. pin0 will always correspond to pin0, which is sufficient for the C standard, but of course not for it's implicit meaning regarding physical port pins.

    Just use the byte-sized registers and set and clear bits with &~, | and BIT0..BIT7 (or aliases like "#define pin0 BIT0"  if you really need them)

  • 0 in reply to Jens-Michael Gross
    Guru 35585 points

    Jens-Michael Gross said:
    By not using bitfields on hardware registers

    Or, indeed, at all!

    There is absolutely no guarantee whatsoever that bitfields will give any advantage, and there is some risk that they will actually be less efficient.

    They are an absolute minefiled of Gotchas!

    They are (almost) entirely non-portable - in the words of K&R: "Almost everything about fields is implementation-dependent"

    Jens-Michael Gross said:
    IMHO the order of bitfields is not guaranteed

    No need for "IMHO" there:  the order is, indeed, implementation-defined - and some implementations do not do what you might expect at all!

    Jens-Michael Gross said:
    this is AFAIK not required by the standard.

    Correct.

    Jens-Michael Gross said:
    You cannot safely assuem that on each compiler your pin0 will correspond to BIT0

    Correct.

    Jens-Michael Gross said:
    Just use the byte-sized registers and set and clear bits with &~, | and BIT0..BIT7

    Absolutely!

  • 0 in reply to Andy Neil
    Guru 35585 points

    Andy Neil said:

    They are an absolute minefiled of Gotchas!

    For an example, see: http://www.keil.com/forum/22951/

**Attention** This is a public forum