cpp: fix board I2C configs for C++ support#9571
Conversation
dylad
left a comment
There was a problem hiding this comment.
Checked all files.
ACK and go !
|
wait for murdock! |
|
Let's merge it !!! |
| .speed = I2C_SPEED_NORMAL, | ||
| .scl_pin = GPIO_PIN(PORT_B, 6), | ||
| .sda_pin = GPIO_PIN(PORT_B, 7), | ||
| .scl_af = GPIO_AF_OUT_OD, |
There was a problem hiding this comment.
all those changes are useless since af cannot be changed on STM32 F1.
Normally, the scl_af and sda_af attributes are not used when the CPU is stm32f1.
There was a problem hiding this comment.
This change is needed because of CPP check, @smlng also modified the driver accordingly.
There was a problem hiding this comment.
@aabadie as @dylad wrote, I changed the driver accordingly omitting the #ifdef in there. However, I agree with you as this is kind of non-dynamic and fixed for stm32f1 CPUs it should not be exposed in the configuration of the board, which suggests it might be dynamic. But this is a general problem in many drivers and their config: i.e, that RIOT exposes params in configs that are actually not configurable at all.
Nevertheless, C++ requires to init all struct attributes properly and in order, omitting one or more or changing the order will result in compile errors. Hence I had to expose the scl/sda_af in the config.
and this is bad. look at uart and spi structs in periph_common header, the af attributes are skipped for F1, the same should be done for I2C. I think something went wrong there during the rebase. |
|
We don't have the choice here. If we don't add scl_af sda_af to the periph_conf, CPP apps won't compile so Murdock will never be happy. |
I know but this can be done globally in the CPU code, not in each board peripheral config. |
IMHO no it can't @aabadie , at least not as long as all STM CPUs share the same |
|
I'm pretty sure it can. The same struct is used by 2 different driver implementation. Just use |
with unified driver implementations, I don't see a better way. For me, code duplication is even worse |
|
Why is it better to drop af params ? IMHO its better to have the struct for every family |
|
I'm not saying that we don't want the struct to configure i2c F1 boards. |
|
I agree with @aabadie here, we should do as for uart and spi, see: with uart driver for instance. Same struct but some fields are out for F1. |
|
Forget it, I missed #9574 ;) |
Contribution description
The I2C configuration structs of several boars causes problems when uses with C++, e.g., attributes were missing or not initialised in correct order.
Issues/PRs references