epdiy
epdiy copied to clipboard
vroland
Refactor/160 EpdDisplay part
Hello, This is my proposal to merge the dynamic display configuration. After this you don't need to use menuconfig for the display. You just insert the display like you can see in the Dragon example.
This PR is just a declaration of intentions that partially addresses #160 . The dynamic board config part will be proposed by Micke Prag (In epdiy.slack.com)
It should be extensively tested and if approved then I will go and update all examples since now every example should inject at least the proper EPD you are using for the demos.
Hello @vroland @jdoubleu @mickeprag Shall we ditch this and forget about it? Concept was interesting but I’m not sure if it makes things easier also it got stale after being hanging here for so long. Feedback?
So these changes would allow me to select (and switch) the display at runtime rather than at compile-time (through ifdefs)?
I don't see a real benefit here. I don't have a use case, where switching the display type midway, applies. I'm not even sure if that's even possible (maybe if a display type somehow supports multiple different configurations and waveforms).
The only other feature I could imagine is having more than one display connected to the ESP. Then it would be very hard to select which ones to include at compiler time. However, neither the board, nor the driver support that. And I don't think anyone would need that feature anyways.
Furthermore it increases code size, although slightly, because all those definitions (and waveforms) have to be available at runtime, so they must be included in the binary.
Is there any possible use-case I missed? Otherwise I wouldn't introduce this feature, as long as there is no real benefit in doing so.
Well basically all this was because in #160 "Move away from defines" I though that it could be interesting to also declare the display this way. Let's close it with this comment as there are many other much more important to topics than this and as said previously is already too long here. Thanks for your feedback.
One use case for me is that I have one firmware for multiple boards. So the firmware can detect at runtime what kind of display is connected and initiate the correct one.
This branch will remain on my fork. So if one day we want to implement it we can do it using the latest master