Posted on May 17, 2011 at 12:24I'm using these macros to define pointers to bit-band bits:
#define BB_BIT(NAME, REGISTER, BIT_NUMBER, BASE, BB_BASE) static volatile int* const (NAME) = ((int *) ((BB_BASE) + (((int) &(REGISTER)) - (BASE)) * 32 + (BIT_NUMBER) * 4));
#define PERIPHERAL_BIT(NAME, REGISTER, BIT_NUMBER) BB_BIT(NAME, REGISTER, BIT_NUMBER, PERIPH_BASE, PERIPH_BB_BASE)
and using them like this:
PERIPHERAL_BIT(LED, GPIOC->ODR, 12);
void f(void) { *LED = 1; }
this defines ''static volatile int* const'' pointers that should be as efficient as macros. now I don't know the first thing about arm assembler but when the code is compiled as c it's clear that it's optimized and that the bit-band bit address is loaded into r2 as if it were a constant from .L40:
.L38:
ldr r2, .L40
mov r0, #393216
ldr r3, [r2, #0]
eor r3, r3, #1
str r3, [r2, #0]
bl busyWait
b .L38
.L41:
.align 2
.L40:
.word 1109524912
(incidentally, the use of offline constants like .L40 beats the prefetch mechanism; can't it be done any better?)
however when the same code is compiled as c++, it's not optimized:
ldr r3, .L49
ldr r4, [r3, #0]
.L47:
ldr r3, [r4, #0]
mov r0, #393216
eor r3, r3, #1
str r3, [r4, #0]
bl _Z8busyWaiti
b .L47
.L50:
.align 2
.L49:
.word .LANCHOR0
here .L49 holds the address of the pointer pointing to the bit-band bit address (the pointer is called .LANCHOR0 (strangely similar to my nick) and not LED, since it's static).
why the c++ compile is less optimized is anybody's guess. I think there's no good reason for it, could someone comment?
anyway, this means that .LANCHOR0 must be initialized. in c this would be done through the .data section, but in c++ initializations invoke constructors which may have side effects, so copying memory is not sufficient and user code must be run (in the general case). g++ chose to handle this initialization with code, and puts a pointer to the code in section .init_array.
the linker script should dump that section into the flash and init symbols describing it's extent, and the boot code should read that data and invoke the initializers before invoking main. I've never seen a linker script in my life before, but it's clear that mine is not dumping .init_array into the flash, and besides the boot code that comes with the stm32 fwlib wouldn't invoke the initializers either. so that's why the code fails.
being naive, I thought I could simply modify both things so that the list of initializers would get called, but there must be more to it than that. in particular, since a constructor could refer to a global constructed value, how is initialization ordered across compile modules so that inits are done in the right order? (if such an order is guaranteed by c++, and I imagine it is.) (there must also be a similar mechanism for destructing globals, but that not important for non-hosted embedded apps.)
could somebody point to c++ startup code and linker script samples? as you can guess I'm also unfamiliar with gcc...
in short, I want to handle abstractions, not details!
🙂
