[AXP2101] Power management implementation discussion

[TD-er]

I did start this PR yesterday to implement support for AXP2101.
#1015

This was merged into a new feature branch @cyberman54 was already working on for his T-Beam Supreme board.

I was looking into the Meshtastic firmware repo to see if there is already some proven config so we can be (more?) sure about correct PMU settings since it is quite tricky to develop for the power management chip as it can easily fry your (expensive) board.

Found this: https://github.com/meshtastic/firmware/blob/master/variants/tbeam-s3-core/variant.h
So apparently there are 2 I2C busses in use.
This means we might also need to add defines and check which Wire bus is used for which device, as is also done in Meshtastic:
https://github.com/meshtastic/firmware/blob/51f3ce5e600b08dd96ce9a9aa3e37384456ba347/variants/tbeam-s3-core/variant.h#L46-L48

N.B. I think the folder structure using variants as how it is done in Meshtastic is also a good idea to make it more clean as it allows for separate platformio.ini files and pins_arduino.h

[TD-er]

As mentioned by @cyberman54 here: #1015 (comment)

Meanwhile, i found some prior art here:
https://github.com/meshtastic/firmware/blob/master/src/Power.cpp#L843

This should work, because the purchased T-Beam Supreme S3 came with working Meshtastic firmware preinstalled.

[cyberman54]

@TD-er i put together a first working version, tested successfully on a t-beam supremes3 module. Lora & BME280 disabled yet. There is some additional work required to get Lora stack running on the SX1262, and bosch sensortec library currently is not configurable for s3 (i opened issue at bosch for this). Concerning the power part, in this work in progress version hardware settings are mixed between hal file an powerXXX.cpp files. Thus, there is some more abstraction necessary to keep powerXXX.cpp parts clean of board related settings.

[TD-er]

Yep, I think there needs to be some sort of set of defines which DCDC/LDO channels should be set to what level in each state (sleep/running/etc)
This way you can just define those in the hal file for the board and only use generic checks in the powerXXX.cpp files.

[cyberman54]

In generally i'm not sure if it makes sense to enhance the paxcounter project. I found that there are some universal esp32 platform projects like your espeasy and meshtastic. Probably it's better to go the way to integrate core paxcounter functionality as a module in those platforms. For this purpose, the paxcounter core functionality was outsourced to a separate library, libpax. Someone used this already to integrate this as a module in meshtastic.

Nevertheless you are welcome to enhance the power features.
I will take care of the Lora SX1262 enhancement, so that there is a paxcounter version for T-Beam v1.2, and T-Supreme S3. I'm not going to add more boards. But it's okay if other people do.

[TD-er]

Yep, the modularity approach is what I also envision for the separate blocks now present in ESP32-Paxcounter.
The reason I was looking into the power chips as how it is used in ESP32-PaxCounter is because this project is more tailored to the boards I have laying around using these power chips.
So it is a good platform to get to know the chips and of course whenever I find something that can be improved, a PR will be submitted.

I'm now looking at your latest commit and I see there is for sure also some need to add at least a define in the hal file which I2C bus is connected to the PMU as you now use a hard-coded one in power.cpp

So there should be something like this:

#ifndef PMU_I2C_BUS
#define PMU_I2C_BUS Wire
#endif 

And then in your Supreme S3 board hal file something like this:

#define PMU_I2C_BUS Wire1

[cyberman54]

I already added such kind of logic in power.cpp:

#if (defined(PMU_SDA) && defined(PMU_SCL))
static const uint8_t i2c_sda = PMU_SDA;
static const uint8_t i2c_scl = PMU_SCL;
TwoWire i2c_pmu = Wire1;
#else
static const uint8_t i2c_sda = SDA;
static const uint8_t i2c_scl = SCL;
TwoWire i2c_pmu = Wire;
#define PMU_BUS Wire
#endif