So now that msp430-elf is robust enough to be usable, I'm updating BSP430 one last time before taking on a job where I'll be working Nordic chips. I figured I'd add the EXP430FR4133 since it's the first launchpad that mspgcc can't support.
All went swimmingly until I tried to compile the nop bootstrap application, and things blew up in the clock configuration. "Wonderful," I thought, "TI's gone and made a third version of the CS peripheral, subtly incompatible with the original FR57xx CS and the revised FR58xx CS_A."
Nope. It's not subtly incompatible. They've taken the UCS module from the F5xx/6xx chips, rearranged and resized some of the bitfields, and called it a CS module. That's wholesale incompatible, and is pretty much a last straw for me and MSP430. (Understand: I wouldn't care if they had called it a CS4 module or a UCS_A module. But using the same distinguishing __MSP430_HAS_CS__ preprocessor symbol for fundamentally different peripherals is just unacceptable.)
"Completely different but mostly the same." -- Joy
(Bonus points to anybody who knows where that quote comes from.)
All went swimmingly until I tried to compile the nop bootstrap application, and things blew up in the clock configuration. "Wonderful," I thought, "TI's gone and made a third version of the CS peripheral, subtly incompatible with the original FR57xx CS and the revised FR58xx CS_A."
Nope. It's not subtly incompatible. They've taken the UCS module from the F5xx/6xx chips, rearranged and resized some of the bitfields, and called it a CS module. That's wholesale incompatible, and is pretty much a last straw for me and MSP430. (Understand: I wouldn't care if they had called it a CS4 module or a UCS_A module. But using the same distinguishing __MSP430_HAS_CS__ preprocessor symbol for fundamentally different peripherals is just unacceptable.)
"Completely different but mostly the same." -- Joy
(Bonus points to anybody who knows where that quote comes from.)