Massive Update: Convert BMS IC code into standard Zephyr driver

[martinjaeger]

This fairly large PR converts the existing BMS IC drivers into a proper Zephyr driver. It was not possible to split the commit into several steps, as all drivers and tests had to be converted at once in order to pass CI.

Rationale

The previous implementation was still based on the Mbed-based firmware and did not follow the Zephyr driver conventions.

Advantages of using the Zephyr driver API:

• Better abstraction and support for multiple ICs on one BMS board.
• Cleaner and more advanced configuration through Devicetree.
• Cleaner implementation of unit tests, as we can use the I2C emulator drivers for mocking.
• This repo can be used as a module for custom BMS implementations.

Implementation Details

The previous implementation did not clearly separate the functions related to the BMS IC (bq769x2, etc.) and the higher-level BMS functions like SOC calculation, state machine or cell parameter setup. All functions were prefixed with bms_.

The new implementation introduces a generic bms_ic driver for chips such as the bq769x0, bq769x2 and isl94202. Analog Devices ICs (LTC68xx series and ADBMSxxxx) can be added in the future and were already considered in the API design, which can be found in include/drivers/bms_ic.h.

Note: These chips are sometimes also called analog front ends or battery monitors. However, especially the bq76952 can do much more than just monitoring or reading analog values. I think a generic name bms_ic is better than bms_afe or bat_monitor.

BMS higher-level functions are defined in include/bms/bms.h and prefixed just with bms_. The file include/bms/bms_common.h contains functions and definitions used both by the BMS IC driver and the BMS application code.

Testing

The code has been extensively tested with the bq76952 (BMS C1 board). Testing for other chips is still ongoing.

[pasrom]

I flashed this changes to the BMS C1 v0.3 and looked at the UART & CAN Communication which worked as expected.

Error Handling: General, if possible, I would use specific error codes (like -EPERM) instead of return -1 for clearer error indication.
Commit Structure: For future commits, I find it really helpful if renamings, like changing &bms.conf.dis_sc_limit to &bms.ic_conf.dis_sc_limit, are done in separate commits. This approach helps keep the commit history clean and easy to follow. It's a good practice that enhances clarity for everyone.

[martinjaeger]

Thanks @pasrom for your review.

As a note regarding atomic commits: You are absolutely right that changes should be done in small atomic steps, so that they are easier to understand and review I'm normally trying to follow this practice as well. However, in this case the driver for the bq769x2 was developed in another project and I could not cherry-pick the individual steps from that project, as the file structure was slightly different and the steps did not cover the drivers for bq769x0 and isl94202. In order to avoid a huge amount of extra work to artificially replicate the steps again, I chose to squash everything into one commit.

[pasrom]

@martinjaeger, thanks for the explanations and clarifications. The changes look good to me now. Approved!