rogerdahl / m5stickc-idf Goto Github PK

As suggested by @teuteuguy on issue #1:

I do have some concerns about how everything is tightly interlocked. Meaning that for example button presses and display backlight in my mind are user-based business logic, and user should be free to disconnect those capabilities.
Wondering if theres a way of simplifying the code to the bare minimum functionalities ?

I understand the concern about the dependencies between "subcomponents". For example, I was hesitant whether making the display backlight functions under m5power or m5display. At the end I went for the most intuitive route, which is having them in m5display (since it is operating on the display, even though it is the power IC that does it). M5StickC is a whole set of components working as a single device and I think this IDF component should leverage that to allow for advanced functionality.

You are referring to the display timeout capability specifically. Using that feature is optional. If a user program does not use buttons at all, there is no point on activating the screen timeout, and yet the user can use the display and turn it on and off at will. Likewise, if a user program does not use the display at all, it can still use buttons freely.

A feature that I plan on implementing is auto-rotation of the screen using the IMU. That will connect those two subcomponents, but it is needed for advanced functionality and simplifying the user program. Then again, user will be able to use the display without the IMU and vice-versa.

I would not go for a bare-bone version of the component, because the point of it is having features to simplify user program. These are features that could be shared/used by many M5Stick-based projects. Hence, I think this is a good place to have them. Their use is not mandatory, but optional.

Paraphrasing you @teuteuguy, the user is free to disconnect those capabilities. Actually they are not even enabled by default. The user has to explicitly enable them to use them in their user-based business logic.

Let's keep discussing this. I would like to have your input.

Could you merge the outstanding pull requests? I have some more changes to contribute for ESP-IDF 4.2 as well.

I'd be willing to maintain this project if you no longer have time.

Simply trying to run this, i get errors that esp_event_loop_handle_t is not declared ...