I2C Interface Integration

[JoelHer]

Integration for the I2C protocol.

The interface should implement the Object Layer.

• Device communication handling
• Bus and status handling

The physical layer is handled by the MCU peripheral and board-level wiring.

Scope

This issue covers the software-side I2C interface abstraction used by Vigilant Engine.
It should provide a generic API for initializing the bus, communicating with I2C devices, and handling transfer/status events, without binding higher-level code to a specific MCU implementation.

Responsibilities

The I2C interface should provide:

• Initialization and deinitialization
• Bus configuration
• Read / write / combined transactions
• Addressing support
• Status and error reporting
• device probing / presence check
• Portable abstraction for different backends

Requirements

Bus handling

• Initialize the I2C peripheral
• Configure bus frequency
• Support selecting SDA / SCL pins where applicable
• Start and stop the interface cleanly

Device communication

• Write bytes to a device
• Read bytes from a device
• Support combined write-then-read transactions
• Support register-based access helpers
• Support 7-bit addressing
• Consider optional 10-bit support if backend allows it

Status handling

• Expose interface state:
  • uninitialized
  • ready
  • busy
  • error
• Report common bus errors where available:
  • timeout
  • NACK
  • arbitration lost
  • bus busy
  • invalid configuration

Proposed API surface

Example responsibilities for the interface:

• init(...)
• deinit()
• write(address, data)
• read(address, length)
• writeRead(address, txData, rxLength)
• writeRegister(address, reg, data)
• readRegister(address, reg, length)
• probe(address)
• getStatus()

Notes

• This issue covers the generic interface only.
• Device-specific drivers should be implemented separately.
• The abstraction should be portable so different MCU I2C backends can be attached later.
• Thread-safety / locking behavior should be defined if multiple modules may access the same bus.

[tillx4]

regarding the multi-threading idea: the driver has an asynchronous mode, where the i2c driver calls return immediately and you can define a call-back for handling errors/returned data etc. I think using this would be the cleanest approach.
then in the separate modules (comms, master, nose, etc.) you can use an rtos task which is dedicated to constantly reading and writing data from the specific i2c devices that the module has. The callback function should also be separate for each esp module, so honestly further work on i2c in vigilant engine directly is very little.
this would conceptually be very similar to how I did the narrowband comms, a task which periodically wakes and does some asynchronous calls, and goes back to sleep. any return values are handled by callbacks or in the case of narrowband interrupts.