Open oclyke opened 1 month ago
It's pretty painful to look back on this code today :), but a couple of comments or suggestions:
Wire
library and any dependency on Arduino altogether. There is no reason for them. The I²C interface is a no-brainer abstraction[^2], and a handful of platform examples would cover the majority of use-cases so that most users wouldn't have to provide a concrete implementation anyway.monitor
is a state machine abstraction at a higher-level than the PD protocol's, and the example
demonstrates general use.void STUSB4500::processAlerts(void)
) and the PD state machine (void STUSB4500::update(void)
). These are the trickiest, most nuanced parts of the code. They may look straightforward, but the order and timing is quite delicate to support bus/signal requirements of both I²C and USB PD simultaneously. Again, refer to the Go port for comparison.Hope all this helps! Had a lot of fun with this IC.
[^1]: The official ST driver package does provide an example of real-time moderation, but it is heavily dependent on STM32 HAL and can only target a single host device (NUCLEO-F072RB). This Arduino library was originally a "generalized" (hah) port of that ST firmware.
[^2]: The following C++ is an example I²C interface I use in my projects. It's the bare minimum so that it's easy to implement everywhere, and it's generalized enough to cover most use cases:
Hello there. Thank you for authoring this library. It seems to be the most complete (as compared with the SparkFun lib) and simple (as compared with others like the ST reference software or an Entree USB-PD CAN adapter board I found on Tindie.)
I would like to see the dependency on Arduino's facilities abstracted away so that the logic for updating NVM, managing profiles, etc can be used on other devices.
The advantage, as I see it, is to gain more community support around a single repository and enable users to easily port the functionality to their own target. Users could depend on this repo as a git submodule, add the necessary (core) source files and headers into their own build system, and provide their own interface definitions.
My proposed approach would be as follows:
stusb4500_interface_t
) which defines a minimum set of platform functionality (read / write 16-bit data on I2C bus) as well as context (void pointer)As a maintainer you would not be expected to support any additional platforms as long as the Arduino reference implementation continues to work through this abstraction.
You can see an example of how I have implemented this structure in the past with SparkFun's ICM-20948 library. Here's a link to the portable C header file: https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/main/src/util/ICM_20948_C.h
I will start work on this project in my own fork of your repo (thank you for MIT licensing!) and if you're interested in bringing it all under one roof I would love to see that happen.
Thanks for your consideration!