Repository navigation
fix: stop the CC1101 driver's "IO is not set as GPIO" log spam - #75
Merged
Merged
Conversation
Copied from the registry package lsatan/SmartRC-CC1101-Driver-Lib@2.5.7
(upstream unmaintained since 2021) so it can be fixed for Arduino 3.x in
the next commit. This commit is the untouched copy, so that diff shows
every change. Licence: LICENSE.txt ("permission to modify and publish").
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Arduino 3.x tracks which peripheral owns each pin and logs when a pin the SPI bus owns is used through digitalRead()/digitalWrite(). The vendored SmartRC-CC1101 driver does both: - Every register access waits for CHIP_RDYn with digitalRead(MISO): one "IO 19 is not set as GPIO" warning per access, about one every 4 s from the RSSI read in decodeFrame(). It now reads the pad with gpio_get_level(), which returns the same level without the ownership check. - Init() set SCK and MOSI with digitalWrite() after SpiStart(), which the core refused with an error each boot. The writes are gone; the bus idles them. The MISO wait also had no bound, so a missing or dead module hung the caller. It now gives up after 10 ms. No native test: the driver only builds for the ESP32. To check on hardware: the serial log should have no "is not set as GPIO" lines, and frames should still decode with an RSSI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or 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.
Summary
On Arduino 3.3 (#71) the serial log fills with:
The Arduino 3.x core tracks which peripheral owns each pin and logs when an SPI pin is used through
digitalRead()/digitalWrite(). The CC1101 driver does both. Its registry package (lsatan/SmartRC-CC1101-Driver-Lib2.5.7) has been unmaintained since 2021, so it now lives inlib/:gpio_get_level()reads the same pad without the ownership check. The writes inInit()already did nothing under 3.3, and the bus idles SCK and MOSI anyway. The MISO wait had no bound, so a missing or dead module hung the caller; it now gives up after 10 ms (the chip is ready within a few hundred µs). The changes are markedESPSomfy-RTS:in the source. The repeating warning comes from the RSSI read indecodeFrame(), one per received frame.Evidence
IO 19 is not set as GPIOwarnings in 20 minutes of a release build's serial log, plus the IO 18 and IO 23 errors at every boot.After: the release build compiles against the copy in
lib/(.pio/build/esp32dev/libd34/SmartRC-CC1101-Driver-Lib).pio test -e native: 415/415 passed.esp32devbuilds, with 21,648 bytes free in the OTA slot. There's no native test because the driver only builds for the ESP32.Hold before merge: not yet run on hardware. Flash
esp32devand check that the serial log has nois not set as GPIOlines and that received frames still show an RSSI.Merge Danger
Door: two-way
Revert both commits to go back to the registry package.
Blast Radius: radio
Every CC1101 register access goes through the new wait. If the module isn't ready within 10 ms, the access now goes ahead instead of hanging. That doesn't make a missing module visible:
getCC1101()only checks that the version register reads above 0, and a floating MISO usually reads0xFF. Later driver updates have to be merged intolib/by hand, but upstream hasn't released since 2021.🤖 Generated with Claude Code