-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
write(...) returns false on sucess unless stopListening() is called first. #734
Comments
According to the datasheet, the data pipes 0 & 1 are open after PoR (power-on-reset), but I chose to close them since There are 2 reasons this could be a problem:
Remember that not all MCU's cut power to the attached peripherals when the MCU's reset button is pressed. This is why I made PS - The docs/examples show proper usage of |
Making begin() force a soft reset is a reasonable goal, I'm not saying revert the change. The fix mentioned in #735 sounds good. My main problem with the issue is that by default it leaves the chip in a state no one wants. (ACKs are enabled but just don't work). The library should avoid leaving the chip in a state that doesn't make any sense. Either set it by default in TX mode with ACKs disabled, or TX mode with ACKs enabled, or RX mode. "TX mode with ACKs enabled but actually unable to actually receive ACKs" makes no sense. It's reasonable(even if incorrect) to assume that stopListening() should only need to be called if startListening() was called first. |
Excellent feedback! I have a few notes though.
Actually, I wanted this state when testing the new examples on multiple radios driven by different MCUs. I found that without an initial inactive state, my payloads were getting intercepted by radios that weren't supposed to be active, and hitting the reset button or re-uploading the program/sketch didn't help.
The naming convention wasn't my choice, but we work with what maniacBug provided from initial release (for backward compatibility).
Again, this is a naming convention problem that can't be properly addressed without breaking backward compatibility. The I'm glad the fix in #735 pleases you, but the fact remains: calling |
Merged #735. Closing this. Expect changes in next release |
Thanks for your work. |
2bndy5@5ba9b5f#diff-d0133d6229b2d23257dc3cd4fb7822b96ae4b8f54d1095ca23abf223582f7968R661
This change has the side effect of making write(...) return false on success unless stopListening() is called first (to correctly set EN_RXADDR).
This is a regression as my previous code used to work correctly without the call.
Auto ACK is documented to be enabled by default so it's excepted that ACKs work correctly, but by closing all receiving pipes by default in begin(), ACKs are never received.
The way this fails is quite hard to debug, since "write(...) returns false on success" is a common issue.
I was pulling my hair out for 3 days going through the usual "make sure your chip is powered properly", "make sure your connections are done properly", "it's probably just a fake chip".
The text was updated successfully, but these errors were encountered: