ChibiOS Free Embedded RTOS

Hi,

this is merely a feature request than an issue. I am missing a macro to determine the maximum clock speed for I2C, depending on driver or port.
For instance, in ADCv2/adc_lld.h the macro "STM32_ADCCLK_MAX" is defined and some ports override it with custom values.
There is no such thing for I2C though, and some other LLDs are missing it as well (CANv1 for instance). Even worse, in I2Cv1/i2c_lld.c, function "i2c_lld_set_clock()", the configuration is checked twice with hard-coded values that differ from each other. One is 4000000 (4MHz) and the other is 400000 (400kHz). Might be I missed something, but I guess it is a typo (which would have been prevented by a macro ).

I need such a macro for setting the I2C clock to the highest possible value, depending on the connected devices. The maximum clock speed for each device is retrieved from the drivers, but the initial value (before determining the minimum of all devices) should be set to the maximum speed the MCU can handle.

Is there chance to integrate such macros in ChibiOS, or is there a particular reason why only some LLDs feature such a macro?

Best regards,
Thomas

Hi,

Are you talking about runtime checks or compile time checks?

Clock maximum values are checked at compile time, configuration structures are checked at runtime.

Giovanni

Hi,

for now I am looking for runtime checks. I think I could calculate my values at compile time as well, but I still don't know what macros to use.

You say I2C clock_speed is checked at compile time, but as I see it for the STM32/LLD/I2Cv1 driver, the clock_speed is only checked in i2c_lld_set_clock() method at runtime and with the values right in the code. In the end there must be a runtime check anyway, since one can modify the configuration at any time.

The point is, however, that the checks that exist so far do not use a macro but inline values. That makes the code hardly portable and prone to typos as explained before.

Note that I encountered this "issue" with the STM32/LLD/I2Cv1 driver, but others might be (and probably are) missing such a macro as well.

Thomas

I will look into adding more compile time checks.

Note that the configuration structures are meant to be non-portable, the non-portability is restricted to those structures, in general it is a good idea to put all configuration structures in a separate module, this makes portability easier.

PAL mode change macros can also have non portable parameters but also those can be managed in a portability layer.

Giovanni