Open lonerzzz opened 1 year ago
The 2nd function is implemented as getChipUniqueId() or something - refer to the docs, there's a complete reference of the LT class (which is also aliased as ESP). Adding fully compatible functions with the same names is also a good idea.
Actually, I think you can substitute getChipRevision with getChipFamilyName or getBoard, which are implemented. There's also getChipType which returns an enum value.
Actually, there's much more of these functions that I thought. See here: https://docs.libretuya.ml/docs/reference/lt-api/
Since I'll be refactoring the project anyway, do you think a separate ESP class, fully compatible with ESP32 class, should be added? Right now it's aliased to the LT class, but since their structure is mostly different, I'm not sure if that aliasing makes any sense now.
If I were doing it, I would create a parent class for the LT and the ESP class and add the common functions there with appropriate wrappers in each child class. That way, you reuse in those cases where it makes sense and there is only one class to worry about for these capabilities.
I see the getChipId function now. Thanks for the document reference.
Regarding getChipRevision, this should be the version number of a chip given that they will make mistakes and often have to release replacement versions to correct specific problems.
The functions related to flash operation are useful when working multiple boards.
Flash reading writing is implemented in a separate class. I'll consider adding these methods as well.
There's no "revision" term here; we know so little about these chips that there's no way we could find a revision number.
Maybe save the revision for later. Over time, more people will play with these chips and more information can be extracted from them. I know that I have had to implement different application level or framework code at different times because chips had bugs that needed to be worked around.
Most of ESP class functions are now implemented. Do you need anything else in particular, or can this issue be solved?
The following would be useful functions to port to the class LibreTuyaClass to understand the chip being used:
getChipRevision getEfuseMac or a a generically named unique chip identifier equivalent getFlashChipMode getFlashChipSpeed