I2cshell #2348
Merged
I2cshell #2348
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
|
Ar we waiting for ESP counterpart to be ready, or should we merge already ? |
bernd-herzog
approved these changes
Nov 8, 2024
|
🚀 |
htotoo
added a commit
to htotoo/portapack-mayhem
that referenced
this pull request
Nov 11, 2024
I2C shell implementation.
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.
This provides a shell over i2c.
The PPMOD driver now polls each second it the module has anything to send to pp, and i'll download all if it has.
The sensors polling is maintained by an internal "timer", each 10th second.
Fixed the ExtModule app where the module's app counter wasn't displayed correctly.
The shell is not created, until the first compatible module (that provides FEAT_SHELL) is connected.
Uses the same shell commands as the USB part.
I2C shell buffer is 64byte instead of 128.
Each time it needs to send the whole 64 byte + 1 leading byte, that indicates hasmore in the upper bit, and the length IN THAT PACKET in the remaining 7 bits. (is the packet is not full, we indicate this with the size).
The stream from PP to esp is simpler, since it needs to send the data with the stream. The stream buffer is 64 byte, and oNofityI2cFromShell will get max 64 byte data. The command will get max 64 bytes. If it get less, the ESP part will get less to. Since there is a vector, it's size wont be sent. (can get from vector size).
ESP part is coming soon. (the esp32pp project has an ugly variant online to test out, but no release with this yet)