I2C Driver Implementation with RTOS STM32 HAL

[taisirhassan]

I2C Module Implementation
Implements RTOS-friendly I2C interface for processor board sensors. Key features:

Interrupt-based transfers (no polling)
Configurable timeouts per device
Simple peripheral-based interface (no need to manage HAL handles)
One device per bus design from latest board revision

[Redstone-ray]

I know this is still WIP, but IMU, BARO and MAG are not three different peripherals, please double check the relevant documentation to understand which three IMUs we are using

[taisirhassan]

I know this is still WIP, but IMU, BARO and MAG are not three different peripherals, please double check the relevant documentation to understand which three IMUs we are using

Updated to use the right IMUs, had a general one that I forgot to change. Thanks for pointing it out.

[Redstone-ray]

Thanks for your update, quick question

• you indicated a max len of "max 255 byte", but len is a uint16_t, which can exceed your limit of 255?
• should the data be modifiable? if not, declare it as a constant

[taisirhassan]

Thanks for your update, quick question

• you indicated a max len of "max 255 byte", but len is a uint16_t, which can exceed your limit of 255?
• should the data be modifiable? if not, declare it as a constant

You're right on both points. I changed len to uint8_t to match the 255-byte limit and made data const in write_reg() since it's read-only. I kept data non-const in read_reg() since it needs to be written to the buffer. Thanks.

[celery6]

few nits. also left a comment in design doc abt updating the diagram. otherwise this looks great

[Joe-Joe-Joe-Joe]

If we're commenting in this level of detail might as well use doxygen

[taisirhassan]

honestly had no idea on what level of detail I should've utilized but would doxygen be good atp if we're assuming the user isn't familiar with the design document? @celery6

[celery6]

any code on its own should always contain documentation regardless of whether design doc exists or not.

Idc about doxygen or any other style tbh but sure lets make doxygen style our standard from now on

[Joe-Joe-Joe-Joe]

How exactly do you register the callbacks? Are you going to write a dedicated callback for each i2c device, then have the init function pass those function pointers behind the scenes? Would it be cleaner (since you callbacks are just one-liners to give the correct semaphore aiui) to implement the global callback function and a simple switch-case based on which handle called the callback?

[taisirhassan]

How exactly do you register the callbacks? Are you going to write a dedicated callback for each i2c device, then have the init function pass those function pointers behind the scenes? Would it be cleaner (since you callbacks are just one-liners to give the correct semaphore aiui) to implement the global callback function and a simple switch-case based on which handle called the callback?

I was planning on using a single global callback for the i2c module, as you said it's just the same callback logic just on different semaphores it would be a lot less repetitive.

[celery6]

could change comment style to doxygen otherwise LGTM!!!