drivers/NINAW10: Allow for an argument at WLAN() and BLE() for hardware wiring.#11188
Closed
robert-hh wants to merge 5 commits into
Closed
drivers/NINAW10: Allow for an argument at WLAN() and BLE() for hardware wiring.#11188robert-hh wants to merge 5 commits into
robert-hh wants to merge 5 commits into
Conversation
|
Code size report: |
robert-hh
force-pushed
the
drivers_ninaw10
branch
from
bce0bef to
4a95c59
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #11188 +/- ##
=======================================
Coverage 98.50% 98.50%
=======================================
Files 155 155
Lines 20549 20549
=======================================
Hits 20241 20241
Misses 308 308 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
robert-hh
force-pushed
the
drivers_ninaw10
branch
from
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.
robert-hh
force-pushed
the
drivers_ninaw10
branch
from
d23af13 to
42f3340
Compare
Contributor
Author
|
These changes are included in PR #11219. |
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
2 participants
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.