cpu/msp430: reorganize code#19733
Conversation
fa71e09 to
6e743fd
Compare
|
Testing results:
|
a425dea to
b6b0e0c
Compare
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
|
Interesting: I wonder how it got 2 bytes smaller while still using the same instructions. Maybe padding. Anyway, all diff actual diffs are the addresses to subroutine calls, branches or jumps. And this is due to different layout of the symbols in the memory map, likely due to alphabetical sorting being different now. IMO this is close enough to "binaries don't change" as it gets for such a mayor restructuring. |
The MSP430 vendor files already provide macros containing register constants and symbols (provided via linker scripts) containing addresses of peripheral registers. So lets make use of that rather than maintaining a long list of constants.
Done. I also added a change I forgot to push that changes the GPIO driver so that indeed instructions don't change (and 6 byte |
|
bors merge |
19733: cpu/msp430: reorganize code r=maribu a=maribu ### Contribution description RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this: ```C #ifndef UART_USE_USCI /* implementation of x1xx peripheral ... */ #else /* implementation of F2xx/G2xx peripheral ... */ #endif /* zero shared code between both variants */ ``` This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families. In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that. [MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf [MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf 19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18 Co-authored-by: Marian Buschsieweke <[email protected]> Co-authored-by: Fabian Hüßler <[email protected]>
|
bors cancel |
|
Canceled. |
19733: cpu/msp430: reorganize code r=maribu a=maribu ### Contribution description RIOT supports two distinct families of the MSP430: The [MSP430 x1xx] MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this: ```C #ifndef UART_USE_USCI /* implementation of x1xx peripheral ... */ #else /* implementation of F2xx/G2xx peripheral ... */ #endif /* zero shared code between both variants */ ``` This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families. In addition, it cleans up the `msp430_regs.h` by dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that. [MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf [MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf 19747: gnrc/ipv6/nib: reset rs_sent counter also for not-6LN interfaces r=maribu a=fabian18 Co-authored-by: Marian Buschsieweke <[email protected]> Co-authored-by: Fabian Hüßler <[email protected]>
|
bors cancel |
|
This PR was included in a batch that was canceled, it will be automatically retried |
|
Canceled. |
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
🎉 thx :) |
Contribution description
RIOT supports two distinct families of the MSP430: The MSP430 x1xx MCU family and the MSP430 F2xx/G2xx MCU family. For both incompatible MCU families the code was located in the msp430fxyz folder, resulting in case of the UART driver in particularly bizarre code looking roughly like this:
This moves peripheral drivers shared between the two families to msp430_common and splits the SPI and UART driver into two MCU families.
In addition, it cleans up the
msp430_regs.hby dropping most of it and using the macros and symbols provided by the vendor header files. There is little reason for us to maintain constants when TI is already doing that.Testing procedure
This only moves code, it doesn't change it. Other than debug symbols changed, I don't expect differences in the generated binaries.
Issues/PRs references
None