|
1 |
| -# DT Overlays |
| 1 | +# How to add board variants |
2 | 2 |
|
3 |
| -Once you create the overlay files inside ``variants/<BOARD_NAME>`` you need to make zephyr understand where it is or else it simply will not find the overlay file and throw errors. |
4 |
| -Inorder to point the build system to your overlay file, you need to modify the ``samples/CMakeLists`` file and replace ``set(DTC_OVERLAY_FILE $ENV{HOME}/zephyrproject/modules/lib/Arduino-Zephyr-API/variants/ARDUINO_NANO33BLE/arduino_nano_33_ble.overlay)`` with your path. |
| 3 | +This module uses the board name (supplied at build time by the `-b |
| 4 | +arduino_nano_33_ble` flag) to correctly map Arduino pin names/numbers to the |
| 5 | +target board. To add board support: |
| 6 | + |
| 7 | +1. Add a folder inside of the variants folder that matches the name of your |
| 8 | + board |
| 9 | +2. Add an overlay file and a pinmap header file that match the name of the board |
| 10 | +3. Add your new headerfile to an `#ifdef` statement in the variants.h file |
| 11 | + |
| 12 | +An example of this structure is shown below. |
| 13 | + |
| 14 | +```tree |
| 15 | +├── variants |
| 16 | +│ ├── arduino_nano_33_ble |
| 17 | +│ │ ├── arduino_nano_33_ble.overlay |
| 18 | +│ │ └── arduino_nano_33_ble_pinmap.h |
| 19 | +``` |
| 20 | + |
| 21 | +## DeviceTree Overlay files for Arduino boards |
| 22 | + |
| 23 | +This module requires that your Arduino header pins be mapped in the DeviceTree |
| 24 | +to a `zephyr,user` node using the `d0_gpios` format for each pin. Follow the |
| 25 | +examples in the variants directory to create an overlay file and a header file |
| 26 | +for your board. |
| 27 | + |
| 28 | +### Overlays using previously-defined Arduino headers |
| 29 | + |
| 30 | +When an Arduino header exists in a board's in-tree DTS file it can easily be |
| 31 | +used to create the necessary overlay file. Assign the relevant mapping using the |
| 32 | +Arduino header label (usually either `&arduino_header` or `&arduino_nano_header` |
| 33 | +and the `gpio_map` number. The second number is used to add GPIO flags and may |
| 34 | +safely be left as zero. |
| 35 | + |
| 36 | +For example, creating an overlay file for the Nordic nRF52840 Development Kit |
| 37 | +uses [the Arduino header definitions](https://github.com/zephyrproject-rtos/zephyr/blob/6f8ee2cdf7dd4d746de58909204ea0ce156d5bb4/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts#L74-L101), beginning with the first digital pin: |
| 38 | + |
| 39 | +``` |
| 40 | +/ { |
| 41 | + zephyr,user { |
| 42 | + d0_gpios = <&arduino_header 6 0>; /* Digital */ |
| 43 | + d1_gpios = <&arduino_header 7 0>; |
| 44 | + ... |
| 45 | + d13_gpios = <&arduino_header 19 0>; |
| 46 | + d14_gpios = <&arduino_header 0 0>; /* Analog */ |
| 47 | + d15_gpios = <&arduino_header 1 0>; |
| 48 | + ... |
| 49 | + d19_gpios = <&arduino_header 5 0>; |
| 50 | + d20_gpios = <&arduino_header 20 0>; /* SDA */ |
| 51 | + d21_gpios = <&arduino_header 21 0>; /* SCL */ |
| 52 | + d22_gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; /* LED0 */ |
| 53 | + }; |
| 54 | +}; |
| 55 | +``` |
| 56 | + |
| 57 | +### Overlays from scratch |
| 58 | + |
| 59 | +You can see in the example above that there is no mapping for `LED0` in the |
| 60 | +board's Arduino header definition so it has been added using the Zephyr `gpios` |
| 61 | +syntax (port, pin, flags). When creating an overlay file that doesn't have an |
| 62 | +Arduino header defined, you should follow this syntax for adding all pins |
| 63 | + |
| 64 | +### You control the pin mapping |
| 65 | + |
| 66 | +Zephyr [chooses to map Arduino headers beginning with the Analog |
| 67 | +pins](https://docs.zephyrproject.org/latest/build/dts/api/bindings/gpio/arduino-header-r3.html), |
| 68 | +but the overlay file example above begins with the digital pins. This is to |
| 69 | +match user |
| 70 | +expectation that issuing `pinMode(0,OUTPUT);` should control digital pin 0 (and |
| 71 | +not pin 6). In the same way, the Analog 0 pin was mapped to D14 as this is |
| 72 | +likely what a shield made for the Arduino Uno R3 header would expect. |
| 73 | + |
| 74 | +Ultimately the mapping is completely up to you and should match the needs of the |
| 75 | +sketch you will be compiling. |
| 76 | + |
| 77 | +## Creating the pinmap header file |
| 78 | + |
| 79 | +It is recommended that you copy an existing pinmap file from one of the board |
| 80 | +folders inside of the variants folder. For the most part, this header file will |
| 81 | +not change from board to board. |
| 82 | + |
| 83 | +One example of a change that you may find useful is mapping additional pins. For |
| 84 | +example, the LEDs on the nRF52840 are not connected to any of the Arduino header |
| 85 | +pins. To define a built-in LED for this board, a 22nd pin definition was added. |
| 86 | + |
| 87 | +Your pinmap header file must be added to the variants.h file by adding three |
| 88 | +lines using this format: |
| 89 | + |
| 90 | +```c |
| 91 | +#ifdef CONFIG_BOARD_NRF52840DK_NRF52840 |
| 92 | +#include "nrf52840dk_nrf52840.h" |
| 93 | +#endif // CONFIG_BOARD_NRF52840DK_NRF52840 |
| 94 | +``` |
5 | 95 |
|
6 |
| -TODO |
|
0 commit comments