pkg/semtech-loramac: model in Kconfig#18005
Conversation
drivers/sx127x/Kconfig
Outdated
|
|
||
| config MODULE_SX1272 | ||
| bool "SX1272" | ||
| select MODULE_SX127X |
There was a problem hiding this comment.
The usage of choices for the variant was a design decision for all drivers. We know that it requires to select both the driver module and variant, but that is only needed when the variant is to be forced. In case the board has the device connected to it, the HAVE_* symbol would be selected, indicating a preference for the choice.
We have considered the approach you have here in the past (actually we started modelling like that), but we realized that it would not allow us to use modules that enable defaults (MODULE_NETDEV_DEFAULT in this case). Now, when such default is enabled, the driver module would be enabled (if the correct feature is present) and the correct variant would be the default choice option. This can't be done when the entry-point is the choice. There is some info in this PR https://github.com/RIOT-OS/RIOT/pull/17556/files#diff-2132175f34702f4d76287f4df5c5f5db02d097c2778e5ac47da4c88ef8f13acdR517.
There was a problem hiding this comment.
From the board with hardwired radio perspective that could make sense. From the end user that plugged the radio on its board, I think it doesn't make sense since he won't have the HAVE_ symbol defined for his board (thinking of a nucleo64 where one plugs an mbed lora shield), resulting in the user having to enable both sx127x and sx1276 (or sx1272 depending on the shield he is using).
Offline @fjmolinas told me that the choice was here to prevent both sx1272 and sx1276 to be enabled at the same time. But in make one could do that already. I would rather stick to the same behavior as make as a first step and after think of solutions for this problem later.
3ca8520 to
c60bebb
Compare
MrKevinWeiss
left a comment
There was a problem hiding this comment.
It would be good if we keep the same design here.
I know that it is a bit verbose to require both the module and the variant explicitly since the variant would require the module.
This has been played with for quite some time now and it the best solution given the constraints we are dealing with.
I strongly push the HAVE_* because I think having a verbose (and machine readable) description of the board is a good thing.
We can open up the conversation and look for a better way.
I have no objection with the |
2e2281c to
2004b3e
Compare
|
I removed the Kconfig changes related to sx127x driver and added the missing symbols in loramac applications config. Locally the dependency resolution is the same as with Make so I have good hopes that it will pass Murdock now. |
MrKevinWeiss
left a comment
There was a problem hiding this comment.
I don't know if you want to note this somewhere but after the migration is complete we can probably remove most of the CONFIG_MODULE_SX1276=y and just default be that but if boards have something different then it should use it.
This is only be we need to match the make system and currently it is not implemented.
examples/lorawan/Kconfig
Outdated
| bool | ||
| default y | ||
| depends on TEST_KCONFIG | ||
| select MODULE_PERIPH_RTC if HAS_PERIPH_RTC |
There was a problem hiding this comment.
Maybe this could help
| select MODULE_PERIPH_RTC if HAS_PERIPH_RTC | |
| select MODULE_PERIPH_RTC if HAS_PERIPH_RTC && !HAVE_SHARED_PERIPH_RTT_PERIPH_RTC |
763f175 to
f5c3448
Compare
f3f7720 to
0ec135b
Compare
|
Ahh no fail fast, good... if this really is the last one then we can go. If there are more than maybe there needs to be a better way. |
|
|
|
I guess it is because the first iteration of make has I wonder what the ideal behaviour is, use both backeds (since the msec will be able to sleep) or stop with this, if I am using a backend for something else then just use that one (which saves space but prevents sleep). |
|
Murdock is finally green here! |
MrKevinWeiss
left a comment
There was a problem hiding this comment.
ACK, lets see what a larger test will say but I think we need to move on this one. This does change make to have a more consistent ztimer backend selection... It might have some effect for those who assumed power savings over code size.
|
bors merge |
18005: pkg/semtech-loramac: model in Kconfig r=MrKevinWeiss a=aabadie Co-authored-by: Alexandre Abadie <[email protected]>
|
bors cancel (trying to fill a merge 🚋 ) |
|
Canceled. |
|
bors merge |
18005: pkg/semtech-loramac: model in Kconfig r=aabadie a=aabadie 19660: cpu/rpx0xx: Fix kconfig model r=aabadie a=MrKevinWeiss ### Contribution description Broken master due to incorrect model of the periph_pio in kconfig. ### Testing procedure Green murdock (now that the board is added to the list) ### Issues/PRs references Look at the master CI... Co-authored-by: Alexandre Abadie <[email protected]> Co-authored-by: MrKevinWeiss <[email protected]>
|
bors cancel |
|
Canceled. |
|
bors merge |
18005: pkg/semtech-loramac: model in Kconfig r=aabadie a=aabadie 19576: boards: add stm32l496g-disco support r=aabadie a=gschorcht ### Contribution description The PR adds the board definition for the STM2L496G-DISO board. It is the same board that is also shipped with the P-L496G-CELL02 LTE pack for which we already have the board definition `p-l496g-cell02`. However, `stm32l496g-disco` provides a complete configuration of the board and supports the following features in addition to `p-l496g-cell02`: ``` > FEATURES_PROVIDED += periph_adc > FEATURES_PROVIDED += periph_dac > FEATURES_PROVIDED += periph_dma > FEATURES_PROVIDED += periph_pwm > FEATURES_PROVIDED += periph_uart_hw_fc > FEATURES_PROVIDED += arduino ``` In the long term, `p-l496g-cell02` is to be based on the new full `stm32l496g-disco` board definition. The CPT and the LCD display are not yet supported since they are connected to/controlled by the MFX (a STM32L152-based sub-system) and the FMC peripheral. ### Testing procedure All basic tests should work with the new board definition. The following tests were executed and did succeed: - [x] `tests/periph/adc` - [x] `tests/periph/dac` - [x] `tests/periph/i2c` for `I2C_DEV(0)`, `I2C_DEV(1)` is not exposed and not tested - [x] `tests/periph/pwm` - [x] `tests/periph/spi` for `SPI_DEV(0)`, `SPI_DEV(1) connection not soldered and not tested - [x] `tests/periph/timer` for `TIMER_DEV(0)` and `TIMER_DEV(1)` - [x] `tests/periph/uart` for `UART_DEV(0)`, `UART_DEV(1)` and `UART_DEV(2)` - [x] `tests/usbus_cdc_ecm` together with `stdio_cdc_acm` ### Issues/PRs references ~Depends on PR #19571~ ~Depends on PR #19572~ ~Depends on PR #19573~ 19650: drivers/nrf24l01p: model in kconfig r=aabadie a=aabadie 19660: cpu/rpx0xx: Fix kconfig model r=aabadie a=MrKevinWeiss ### Contribution description Broken master due to incorrect model of the periph_pio in kconfig. ### Testing procedure Green murdock (now that the board is added to the list) ### Issues/PRs references Look at the master CI... Co-authored-by: Alexandre Abadie <[email protected]> Co-authored-by: Gunar Schorcht <[email protected]> Co-authored-by: MrKevinWeiss <[email protected]>
|
Build failed (retrying...): |
|
bors cancel |
|
Canceled. |
|
bors merge |
|
bors cancel Some concerns about ztimer are arising in private. |
|
Canceled. |
|
Maybe I will try different PR that will only deal with the problems with ztimer, it is out of scope of this PR and should probably be blocklisted or wait until the ztimer pr is done. |
|
This PR is no longer needed |
Contribution description
As the title says.
To fully match the Make dependency resolution, I had to modify the sx127x Kconfig file by removing the usage of choices. Maybe this is wrong but I don't see how to properly include
MODULE_SX1276to the build with Kconfig. Looking attests/driver_sx127xit seems to be possible by pulling in bothMODULE_SX1276andMODULE_SX127X. That seems bogus and counter intuitive to me as I would expect the sx127x moduie to be pulled in automatically like it's done by this PR.Note that this PR won't pass Murdock because of a mismatch resolution of the random module dependencies (again a choice is in the loop).
Testing procedure
Green Murdock
Issues/PRs references
#16875