Closed rockaport closed 5 years ago
hey thanks for the PR, seems mostly good to me!
i remember there being something cursed wrt. weak symbol resolution when putting the startup files in an archive/library, but, i wrote this so long ago i can't remember why it was a problem :-/
so if this is all linking / locating things in the vector table / running properly it's probably okay...
ahh it might be to do with weak symbol resolution based on library ordering, which would suggest so long as the startup library is the resolved last it should work okay.
Interesting. I'll keep that in mind. There's some details related to compiling for embedded projects that I'm not very experienced with. I've been modelling the makefile generation from the simplicity studio examples and sofar it's been compiling and running fine on the BGM13 for your example and another timer based thing I'm experimenting with.
However, I'm working through the Bluetooth/rail/Hal library integration now and there's a bit more that's involved in that. There's an explicit start/end group for prebuilt libraries and managing that with normal libraries is becoming cumbersome. Plus that probably should be left up the end user because it gets into application specific usage, so I'm not sure if I'll submit a PR for that when I'm done.
Honestly, I don't know if this is "just how it is" or if compiling for embedded devices is the wild west. There's been several moments where I'm staring at the build and thinking to myself "wtf"
it's been compiling and running fine
that's a pretty good indication!
so I'm not sure if I'll submit a PR for that when I'm done
(no pressure but) i'd definitely love to see it! working with BLE on the BGM modules would mean i could offer this as alternative to simplicity studio for a couple of courses.
Honestly, I don't know if this is "just how it is" or if compiling for embedded devices is the wild west.
yeeah, it's a bit of both ime. we're a couple of decades behind the curve, and vendors are more interested in shipping their own weird GUIs than building any sensible tooling.
you might be interested in rust-embedded, it's still early days (board support and BLE and things are still very much a work in progress), but, it will be an interesting / modern alternative, and the docs do a good job of covering a bunch of embedded-building esoterica. also feel free to open issues here ^_^
ahh it might be to do with weak symbol resolution based on library ordering, which would suggest so long as the startup library is the resolved last it should work okay.
Do you have a suggestion for how I can test this? Both your delay based sample and this timer one work. Would it fail at compile or runtime?
void TIMER0_IRQHandler(void) {
TIMER_IntClear(TIMER0, TIMER_IF_CC0);
GPIO_PinOutToggle(BSP_LED1_PORT, BSP_LED1_PIN);
}
void enableLedTimer() {
// enable the timer compare
TIMER_InitCC_TypeDef timerInitCc = TIMER_INITCC_DEFAULT;
timerInitCc.mode = timerCCModeCompare;
timerInitCc.filter = true;
TIMER_InitCC(TIMER0, 0, &timerInitCc);
// enable interrupts
NVIC_EnableIRQ(TIMER0_IRQn);
TIMER_IntEnable(TIMER0, TIMER_IF_CC0);
// f = f_HFPERCLK / (2^(PRESC + 1) * (TOP + 1)) ... maybe * 2
TIMER_TopSet(TIMER0, 7813);
TIMER_Init_TypeDef timerInitTypeDef = TIMER_INIT_DEFAULT;
timerInitTypeDef.debugRun = true;
timerInitTypeDef.prescale = timerPrescale1024;
TIMER_Init(TIMER0, &timerInitTypeDef);
}
I'm just throwing this out there in case you want to merge it. I opted to refactor all the libraries into cmake library projects.