drivers/NINAW10: Allow for an argument at WLAN() and BLE() for hardware wiring. #11188
Conversation
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
|
Code size report: |
bce0bef to
4a95c59
Compare
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #11188 +/- ##
=======================================
Coverage 98.50% 98.50%
=======================================
Files 155 155
Lines 20549 20549
=======================================
Hits 20241 20241
Misses 308 308 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
4a95c59 to
1d6f925
Compare
For ports where these SPI pins have to be specified. Side change: Remove obsolete code from network_ninaw10.c, which caused compile errors.
Using a second optional parameter to the WLAN contructor. Call: wlan=WLAN(mode=<ifmode>, wiring=(SPI, CS_pin, Busy_pin, RST_pin, GP0_pin)) The keywords are optional, unless only wiring is to be set. All parameters must be objects of the respective types. The GPIO0 pin must be specified, but it does not have to be wired at the moment, if the respective Pin at the WiFi module is pulled up. It is of course needed for firmware upgrade of the WiFi module. The signal names are those used by Adafruit airlift modules. The table below shows the mapping between pin names and internal Pin numbers. A genuine ESP32 board should use the NINA W102 firmware and pin mapping. Driver NINA Airlift Airlift Name W102 pin Name pin ---------------------------------- MOSI 12 MOSI 14 MISO 23 MISO 23 SCK 18 SCK 18 GPIO1 5 CS 5 ACK 33 Busy 33 RESET EN Reset EN GPIO0 0 GPIO0 0 Bluetooth Pins ---------------------------------- CTS 33 CTS 33 (shared with ACK) RTS 12 RTS 14 (shared with MOSI) TX 1 TX 1 (host TX) RX 3 RX 3 (host RX) RTS must be low for Bluetooth to work. To enable Bluetooth, reset the NINAW10 with CS held low.
This argument is meant to contain the objects needed for the communication with the Bluetooth device. At least that's an UART, but it may be a tuple/list with a UART and additional parameters. The number and type of these parameters must checked by the respective mpbthciport.c code.
It is not used by the driver. Instead of a Pin object, "None" can be specified.
d23af13 to
42f3340
Compare
|
These changes are included in PR #11219. |
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 PR allows to supply an additional argument to the WLAN() and BLE() constructors defining the
way, a WIFI/BLE module is connected to the board. An example for such a module is a ESP32 device with NINA firmware, like of course the ublox NINA W102, Adafruit Airlift or any genuine ESP32 board.
If these are not already assembled to a MP board, the wiring of the WIFI/BLE module is not contained in the board definition files, but must be supplied at runtime.
The approach for checking these parameters is different. Since the WLAN() module is a specific NINA W10 one, the parameters are checked in the constructor code. For BLE() is is not possible, since that constructor is not specific for a single board. So the argument is just taken and stored, and the check for validity is done by the hardware specific driver, when it is used.