set RESET to Pull.UP when set to input #2
Merged
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 fixes the generation of the RESET signal to the RFM9x chip for CP3.0 - I'm still not sure why it worked on 2.x but this change works on both 2.x and 3.0.
The reset sequence for the RFM9x is far more complex than the one for the RFM69, but as Tony noted, it works this way. When I tried the same sequence in the RFM69, it did not work and resulted in a corrupted File System on my feather_m0. So for now, let stick with this ;-)
I tested this with a pair of rfm9x featherwings attached to a feather_m0_express and a feather_m0_supersized (8Mbyte SPI flash) with both CP3.0 master and CP 2.2..4.
I did find that it works well with the default baudrate setting (10000000) as long as the wing is plugged directly into the feather. I had some transmission errors when I used a "doubler". It has been reported before for the rfm69 that it may be necessary to lower the baud rate for breakout boards and even apparently for any separation of the boards.