esp32 impl #1
Open
esp32 impl #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey Florian - I have been working on an implementation of your code for esp32. This is quite a bit different from your approach in that the esp32 does everything that the nano and the d1mini does. I am not proposing you merge this PR but I want to provide you with some info...
Would you prefer to have the option to maintain an esp32 implementation along side your code or would you prefer if I maintain this separate from your impl - in which case I might let the codebase diverge a bit more.
The difference between the nano+d1mini and esp32 platforms are signifficant and it would probably be necessary to break the virtual display stuff into an explicit library that can be built and referenced by both implementations. This PR does not reflect those changes and so if you want to pursue the idea of merging the code I would then close this PR and provide another PR with more stuff in it. I also have syncronous APIs in my code that would need to be ported and provided alongside your mqtt integration. All doable but I will only pursue if you see value, otherwize I can make a clean separation between the implementations and simply refer back to your project as the starting point for mine.