sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Documentation: Improve pages for ESP boards

Browse Source
This commit is contained in:
Lucas Saavedra Vaz 2023-03-24 11:44:03 -03:00 committed by Petro Karashchenko
parent c961edbe6c
commit c702223fab
28 changed files with 2032 additions and 271 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/introduction/detailed_support.rst
View File

@ -3040,6 +3040,17 @@ Espressif ESP32-C3 Devkit board.
Please, refer to the :doc:`ESP32-C3 </platforms/risc-v/esp32c3/index>` on NuttX for
further information.
ESP32-C6
--------
Initial architectural support for ESP32-C6 (RISC-V) was added in NuttX-12.1.0
**Espressif ESP32-C6 Devkit Board** The NuttX release includes support for
Espressif ESP32-C6 Devkit board.
Please, refer to the :doc:`ESP32-C6 </platforms/risc-v/esp32c6/index>` on NuttX for
further information.
ESP32 (Dual Xtensa LX6)
=======================

1
Documentation/introduction/supported_platforms.rst
View File

@ -70,6 +70,7 @@ from board-to-board. Follow the links for the details:
- :ref:`introduction/detailed_support:LiteX on Arty A7` (1)
- :ref:`introduction/detailed_support:ESP32-C3` (1)
- :ref:`introduction/detailed_support:ESP32-C6` (1)
- Xtensa LX6:

449
Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/index.rst
View File

@ -26,8 +26,8 @@ mount ESP32-C3 DevKit on a breadboard.
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled Boot and RST. The RST button is not available
to software. It pulls the chip enable line that doubles as a reset line.
@ -36,55 +36,66 @@ pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
LEDs
----
Board LEDs
----------
There is one on-board LED that indicates the presence of power.
Another WS2812 LED is connected to GPIO8 and is available for software.
Configurations
==============
nsh
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32c3-devkit:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
adc
---
Basic configuration to run the NuttShell (nsh).
This configuration demonstrates the use of the internal Analog to Digital Converter (ADC).
To check it, you can execute the ``adc`` application::
gpio
____
nsh> adc
adc_main: g_adcstate.count: 0
adc_main: Hardware initialized. Opening the ADC device: /dev/adc0
Sample:
1: channel: 0 value: 870
Sample:
1: channel: 0 value: 870
Sample:
1: channel: 0 value: 865
Sample:
1: channel: 0 value: 859
This is a test for the GPIO driver. It uses GPIO1 and GPIO2 as outputs and
GPIO9 as an interrupt pin.
autopm
------
At the nsh, we can turn the outputs on and off with the following::
This configuration makes the device automatically enter the low power consumption mode
when in the idle state, powering off the cpu and other peripherals.
nsh> gpio -o 1 /dev/gpio0
nsh> gpio -o 1 /dev/gpio1
nsh> gpio -o 0 /dev/gpio0
nsh> gpio -o 0 /dev/gpio1
We can use the interrupt pin to send a signal when the interrupt fires::
nsh> gpio -w 14 /dev/gpio2
The pin is configured as a rising edge interrupt, so after issuing the
above command, connect it to 3.3V.
In minimum power save mode, the station wakes up every DTIM to receive a beacon. The broadcast
data will not be lost because it is transmitted after DTIM. However, it can not save much more
power if DTIM is short as the DTIM is determined by the access point.
ble
---
This configuration is used to enable the Bluetooth Low Energy (BLE) of
ESP32C3 chip.
ESP32-C3 chip.
To test it, just run the following command below...
To test it, just run the following commands below.
Confirm that bnep interface exist:
Confirm that bnep interface exist::
nsh> ifconfig
bnep0 Link encap:UNSPEC at DOWN
inet addr:0.0.0.0 DRaddr:0.0.0.0 Mask:0.0.0.0
Get basic information from it:
Get basic information from it::
nsh> bt bnep0 info
Device: bnep0
@ -102,17 +113,17 @@ Get basic information from it:
Policy: 0
Type: 0
Start the scanning process:
Start the scanning process::
nsh> bt bnep0 scan start
Wait a little bit before stopping it.
Then after some minutes stop it:
Then after some minutes stop it::
nsh> bt bnep0 scan stop
Get the list of BLE devices found around you:
Get the list of BLE devices found around you::
nsh> bt bnep0 scan get
Scan result:
@ -138,6 +149,353 @@ Get the list of BLE devices found around you:
advertiser data: 10 09 4d 69 20 XX XX XX XX XX XX XX XX XX XX 20 e
nsh>
bmp180
------
This configuration enables the use of the BMP180 pressure sensor over I2C.
You can check that the sensor is working by using the ``bmp180`` application::
nsh> bmp180
Pressure value = 91531
Pressure value = 91526
Pressure value = 91525
coremark
--------
This configuration sets the CoreMark benchmark up for running on the maximum
number of cores for this system. It also enables some optimization flags and
disables the NuttShell to get the best possible score.
.. note:: As the NSH is disabled, the application will start as soon as the
system is turned on.
crypto
------
This configuration enables support for the cryptographic hardware and
the ``/dev/crypto`` device file.
cxx
---
Development enviroment ready for C++ applications. You can check if the setup
was successfull by running ``cxxtest``::
nsh> cxxtest
Test ofstream ================================
printf: Starting test_ostream
printf: Successfully opened /dev/console
cout: Successfully opened /dev/console
Writing this to /dev/console
Test iostream ================================
Hello, this is only a test
Print an int: 190
Print a char: d
Test std::vector =============================
v1=1 2 3
Hello World Good Luck
Test std::map ================================
Test C++17 features ==========================
File /proc/meminfo exists!
Invalid file! /invalid
File /proc/version exists!
efuse
-----
This configuration demonstrates the use of the eFuse driver. It can be accessed
through the ``/dev/efuse`` device file.
elf
---
This configuration uses ``apps/examples/elf`` in order to test the ELF loader.
It can be tested by executing the ``elf`` application.
gpio
____
This is a test for the GPIO driver. It uses GPIO1 and GPIO2 as outputs and
GPIO9 as an interrupt pin.
At the nsh, we can turn the outputs on and off with the following::
nsh> gpio -o 1 /dev/gpio0
nsh> gpio -o 1 /dev/gpio1
nsh> gpio -o 0 /dev/gpio0
nsh> gpio -o 0 /dev/gpio1
We can use the interrupt pin to send a signal when the interrupt fires::
nsh> gpio -w 14 /dev/gpio2
The pin is configured as a rising edge interrupt, so after issuing the
above command, connect it to 3.3V.
knsh
----
This is identical to the nsh configuration except that (1) NuttX
is built as PROTECTED mode, monolithic module and the user applications
are built separately and, as a consequence, (2) some features that are
only available in the FLAT build are disabled.
Protected Mode support for ESP32-C3 relies on the RISC-V Physical Memory
Protection (PMP) for implementing isolation between Kernel and Userspace.
The Kernel configures the PMP to restrict the application access to selected
peripherals and specific regions of on-chip memories (Internal ROM and Internal SRAM)
and of the External Flash.
lvgl
----
This is a demonstration of the LVGL graphics library running on the NuttX LCD
driver. You can find LVGL here::
https://www.lvgl.io/
https://github.com/lvgl/lvgl
This configuration uses the LVGL demonstration at `apps/examples/lvgldemo`.
mcuboot_slot_confirm
--------------------
This configuration is used to represent an MCUboot update image that needs to be confirmed
after flashing. The image can be confirmed by using the following command::
nsh> mcuboot_confirm
Application Image successfully confirmed!
For more information, check `this demo <https://www.youtube.com/watch?v=Vzy0rl-ixbc>`_.
module
------
This config is to run ``apps/examples/module``.
nsh
---
Basic configuration to run the NuttShell (nsh).
nvcfgdata
---------
This configuration enables the MTD failsafe mode. You can test it
by running the ``mtdconfig_fs_test`` application::
nsh> mtdconfig_fs_test
test_nvs_mount: test begin
test_nvs_mount: success
test_nvs_write: test begin
test_nvs_write: success
test_nvs_corrupt_expire: test begin
test_nvs_corrupt_expire: success
test_nvs_corrupted_write: test begin
test_nvs_corrupted_write: success
test_nvs_gc: test begin
test_nvs_gc: success
test_nvs_gc_3sectors: test begin
test_nvs_gc_3sectors: success
test_nvs_corrupted_sector_close: test begin
test_nvs_corrupted_sector_close: success
test_nvs_full_sector: test begin
test_nvs_full_sector: success
test_nvs_gc_corrupt_close_ate: test begin
test_nvs_gc_corrupt_close_ate: success
test_nvs_gc_corrupt_ate: test begin
test_nvs_gc_corrupt_ate: success
test_nvs_gc_touched_deleted_ate: test begin
test_nvs_gc_touched_deleted_ate: success
test_nvs_gc_touched_expired_ate: test begin
test_nvs_gc_touched_expired_ate: success
test_nvs_gc_not_touched_expired_ate: test begin
test_nvs_gc_not_touched_expired_ate: success
Final memory usage:
VARIABLE BEFORE AFTER DELTA
======== ======== ======== ========
arena 5bf30 5bf30 0
ordblks 1 1 0
mxordblk 59100 59100 0
uordblks 2e30 2e30 0
fordblks 59100 59100 0
oneshot
-------
This config demonstrate the use of oneshot timers present on the ESP32.
To test it, just run the ``oneshot`` example::
nsh> oneshot
Opening /dev/oneshot
Maximum delay is 4294967295999999
Starting oneshot timer with delay 2000000 microseconds
Waiting...
Finished
ostest
------
This is the NuttX test at ``apps/testing/ostest`` that is run against all new
architecture ports to assure a correct implementation of the OS.
pm
--
This configuration enables the CPU power management through governors.
pwm
---
This configuration demonstrates the use of PWM through a LED connected to GPIO2.
To test it, just execute the ``pwm`` application::
nsh> pwm
pwm_main: starting output with frequency: 10000 duty: 00008000
pwm_main: stopping output
random
------
This configuration shows the use of the ESP32-C3's True Random Number Generator with
entropy sourced from Wi-Fi and Bluetooth noise.
To test it, just run ``rand`` to get 32 randomly generated bytes::
nsh> rand
Reading 8 random numbers
Random values (0x3ffe0b00):
0000 98 b9 66 a2 a2 c0 a2 ae 09 70 93 d1 b5 91 86 c8 ..f......p......
0010 8f 0e 0b 04 29 64 21 72 01 92 7c a2 27 60 6f 90 ....)d!r..|.'`o.
romfs
-----
This configuration enables the ROMFS file system. You can test it by
running the ``romfs`` example::
nsh> romfs
Mounting ROMFS filesystem at target=/usr/local/share with source=/dev/ram1
Traversing directory: /usr/local/share
DIRECTORY: /usr/local/share/adir/
Traversing directory: /usr/local/share/adir
FILE: /usr/local/share/adir/anotherfile.txt/
DIRECTORY: /usr/local/share/adir/subdir/
Traversing directory: /usr/local/share/adir/subdir
FILE: /usr/local/share/adir/subdir/subdirfile.txt/
Continuing directory: /usr/local/share/adir
FILE: /usr/local/share/adir/yafile.txt/
Continuing directory: /usr/local/share
FILE: /usr/local/share/afile.txt/
FILE: /usr/local/share/hfile/
PASSED
rtc
---
This configuration demonstrates the use of the RTC driver through alarms.
You can set an alarm, check its progress and receive a notification after it expires::
nsh> alarm 10
alarm_daemon started
alarm_daemon: Running
Opening /dev/rtc0
Alarm 0 set in 10 seconds
nsh> alarm -r
Opening /dev/rtc0
Alarm 0 is active with 10 seconds to expiration
nsh> alarm_daemon: alarm 0 received
sotest
------
This config is to run apps/examples/sotest.
spiflash
--------
This config tests the external SPI that comes with the ESP32-C3 module connected
through SPI1.
By default a SmartFS file system is selected.
Once booted you can use the following commands to mount the file system::
nsh> mksmartfs /dev/smart0
nsh> mount -t smartfs /dev/smart0 /mnt
Note that mksmartfs is only needed the first time.
sta_softap
----------
With this configuration you can run these commands to be able
to connect your smartphone or laptop to your board::
nsh> ifup wlan1
nsh> dhcpd_start wlan1
nsh> wapi psk wlan1 mypasswd 3
nsh> wapi essid wlan1 nuttxap 1
In this case, you are creating the access point ``nuttxapp`` in your board and to
connect to it on your smartphone you will be required to type the password ``mypasswd``
using WPA2.
The ``dhcpd_start`` is necessary to let your board to associate an IP to your smartphone.
tickless
--------
This configuration enables the support for tickless scheduler mode.
timer
-----
This config test the general use purpose timers. It includes the 4 timers,
adds driver support, registers the timers as devices and includes the timer
example.
To test it, just run the following::
nsh> timer -d /dev/timerx
Where x in the timer instance.
twai
----
This configuration enables the support for the TWAI (Two-Wire Automotive Interface) driver.
You can test it by running the ``can`` example::
nsh> can
nmsgs: 0
min ID: 1 max ID: 2047
Bit timing:
Baud: 1000000
TSEG1: 15
TSEG2: 4
SJW: 3
ID: 1 DLC: 1
uid
---
Enables support for the `BOARDIOC_UNIQUEID boardctl()` command.
usbconsole
----------
This configuration tests the built-in USB-to-serial converter found in ESP32-C3 (revision 3).
``esptool`` can be used to check the version of the chip and if this feature is
supported. Running ``esptool.py -p <port> chip_id`` should have ``Chip is
ESP32-C3 (revision 3)`` in its output.
When connecting the board a new device should appear, a ``/dev/ttyACMX`` on Linux
or a ``/dev/cu.usbmodemXXX`` om macOS.
This can be used to flash and monitor the device with the usual commands::
make download ESPTOOL_PORT=/dev/ttyACM0
minicom -D /dev/ttyACM0
watchdog
--------
@ -147,7 +505,7 @@ example application.
To test it, just run the following command::
nsh> wdog -i /dev/watchdogX
nsh> wdog -i /dev/watchdogX
Where X is the watchdog instance.
@ -160,20 +518,23 @@ and includes the watcher and watched example applications.
To test it, just run the following command::
nsh> watcher
nsh> watched
nsh> watcher
nsh> watched
usbconsole
==========
wifi
----
This configuration tests the built-in USB-to-serial converter found in ESP32-C3 (revision 3).
`esptool` can be used to check the version of the chip and if this feature is
supported. Running `esptool.py -p <port> chip_id` should have `Chip is
ESP32-C3 (revision 3)` in its output.
When connecting the board a new device should appear, a `/dev/ttyACMX` on Linux
or a `/dev/cu.usbmodemXXX` om macOS.
This can be used to flash and monitor the device with the usual commands::
Enables Wi-Fi support. You can define your credentials this way::
make download ESPTOOL_PORT=/dev/ttyACM0
minicom -D /dev/ttyACM0
$ make menuconfig
-> Application Configuration
-> Network Utilities
-> Network initialization (NETUTILS_NETINIT [=y])
-> WAPI Configuration
Or if you don't want to keep it saved in the firmware you can do it
at runtime::
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0

49
Documentation/platforms/risc-v/esp32c3/index.rst
View File

@ -49,10 +49,10 @@ First make sure that ``esptool.py`` is installed. This tool is used to convert
the ELF to a compatible ESP32 image and to flash the image into the board.
It can be installed with: ``pip install esptool``.
Configure the NUttX project: ``./tools/configure.sh esp32c3-devkit:nsh``
Configure the NuttX project: ``./tools/configure.sh esp32c3-devkit:nsh``
Run ``make`` to build the project. Note that the conversion mentioned above is
included in the build process.
The `esptool.py` command to flash all the binaries is::
included in the build process.
The ``esptool.py`` command to flash all the binaries is::
esptool.py --chip esp32c3 --port /dev/ttyUSBXX --baud 921600 write_flash 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 nuttx.bin
@ -60,7 +60,7 @@ However, this is also included in the build process and we can build and flash w
make flash ESPTOOL_PORT=<port> ESPTOOL_BINDIR=../esp-bins
Where ``<port>`` is typically ``/dev/ttyUSB0`` or similar and ``../esp-bins`` is
Where ``<port>`` is typically ``/dev/ttyUSB0`` or similar and ``../esp-bins`` is
the path to the folder containing the bootloader and the partition table
for the ESP32-C3 as explained above.
Note that this step is required only one time. Once the bootloader and partition
@ -70,11 +70,11 @@ would just require: ``make flash ESPTOOL_PORT=/dev/ttyUSBXX``
Debugging with OpenOCD
======================
Download and build OpenOCD from Espressif, that can be found in
https://github.com/espressif/openocd-esp32
Download and build OpenOCD from Espressif, that can be found in
https://github.com/espressif/openocd-esp32
If you have an ESP32-C3 ECO3, no external JTAG is required to debug, the ESP32-C3
integrates a USB-to-JTAG adapter.
integrates a USB-to-JTAG adapter.
OpenOCD can then be used::
@ -89,7 +89,7 @@ It can be connected as follows::
TDO -> GPIO7
Furthermore, an efuse needs to be burnt to be able to debug::
espefuse.py -p <port> burn_efuse DIS_USB_JTAG
OpenOCD can then be used::
@ -104,25 +104,26 @@ The following list indicates the state of peripherals' support in NuttX:
=========== ======= =====
Peripheral Support NOTES
=========== ======= =====
GPIO Yes
UART Yes
SPI Yes
I2C Yes
DMA Yes
Wifi Yes
ADC Yes
AES Yes
Bluetooth Yes
CDC Console Yes Rev.3
DMA Yes
eFuse Yes
GPIO Yes
I2C Yes
LED_PWM Yes
RNG Yes
RSA Yes
RTC Yes
SHA Yes
SPI Yes
SPIFLASH Yes
Timers Yes
Touch Yes
UART Yes
Watchdog Yes
RTC Yes
RNG Yes
AES Yes
eFuse Yes
ADC Yes
Bluetooth Yes
LED_PWM Yes
SHA Yes
RSA Yes
CDC Console Yes Rev.3
Wifi Yes
=========== ======= =====
Secure Boot and Flash Encryption

BIN
Documentation/platforms/risc-v/esp32c6/boards/esp32c6-devkit/esp32-c6-devkitc-1-isometric_v1.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 559 KiB

BIN
Documentation/platforms/risc-v/esp32c6/boards/esp32c6-devkit/esp32-c6-devkitc-1-pin-layout.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 365 KiB

BIN
Documentation/platforms/risc-v/esp32c6/boards/esp32c6-devkit/esp32-c6-devkitc-1-v1.2-annotated-photo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 412 KiB

BIN
Documentation/platforms/risc-v/esp32c6/boards/esp32c6-devkit/esp32-c6-devkitc-1-v1.2-block-diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 77 KiB

104
Documentation/platforms/risc-v/esp32c6/boards/esp32c6-devkit/index.rst Normal file
View File

@ -0,0 +1,104 @@
==================
ESP32-C6-DevKitC-1
==================
ESP32-C6-DevKitC-1 is an entry-level development board based on ESP32-C6-WROOM-1(U),
a general-purpose module with a 8 MB SPI flash. This board integrates complete Wi-Fi,
Bluetooth LE, Zigbee, and Thread functions. You can find the board schematic
`here <https://espressif-docs.readthedocs-hosted.com/projects/espressif-esp-dev-kits/en/latest/_static/esp32-c6-devkitc-1/schematics/esp32-c6-devkitc-1-schematics_v1.2.pdf>`_.
Most of the I/O pins are broken out to the pin headers on both sides for easy interfacing.
Developers can either connect peripherals with jumper wires or mount ESP32-C6-DevKitC-1 on
a breadboard.
.. figure:: esp32-c6-devkitc-1-isometric_v1.2.png
:alt: ESP32-C6-DevKitC-1 Board Layout
:figclass: align-center
ESP32-C6-DevKitC-1 Board Layout
The block diagram below presents main components of the ESP32-C6-DevKitC-1.
.. figure:: esp32-c6-devkitc-1-v1.2-block-diagram.png
:alt: ESP32-C6-DevKitC-1 Electrical Block Diagram
:figclass: align-center
ESP32-C6-DevKitC-1 Electrical Block Diagram
Hardware Components
-------------------
.. figure:: esp32-c6-devkitc-1-v1.2-annotated-photo.png
:alt: ESP32-C6-DevKitC-1 Hardware Components
:figclass: align-center
ESP32-C6-DevKitC-1 Hardware Components
Buttons and LEDs
================
Board Buttons
--------------
There are two buttons labeled Boot and RST. The RST button is not available
to software. It pulls the chip enable line that doubles as a reset line.
The BOOT button is connected to IO9. On reset it is used as a strapping
pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
Board LEDs
----------
There is one on-board LED that indicates the presence of power.
Another WS2812 LED is connected to GPIO8 and is available for software.
Current Measurement
===================
The J5 headers on the ESP32-C6-DevKitC-1 can be used for measuring the current
drawn by the ESP32-C6-WROOM-1(U) module:
- Remove the jumper: Power supply between the module and peripherals on the
board is cut off. To measure the module's current, connect the board with an
ammeter via J5 headers;
- Apply the jumper (factory default): Restore the board's normal functionality.
.. note::
When using 3V3 and GND pin headers to power the board, please remove the J5 jumper,
and connect an ammeter in series to the external circuit to measure the module's current.
Pin Mapping
===========
.. figure:: esp32-c6-devkitc-1-pin-layout.png
:alt: ESP32-C6-DevKitC pin layout
:figclass: align-center
ESP32-C6-DevKitC-1 Pin Layout
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32c6-devkit:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
coremark
--------
This configuration sets the CoreMark benchmark up for running on the maximum
number of cores for this system. It also enables some optimization flags and
disables the NuttShell to get the best possible score.
.. note:: As the NSH is disabled, the application will start as soon as the
system is turned on.
nsh
---
Basic configuration to run the NuttShell (nsh).

57
Documentation/platforms/risc-v/esp32c6/index.rst
View File

@ -49,10 +49,10 @@ First make sure that ``esptool.py`` is installed. This tool is used to convert
the ELF to a compatible ESP32-C6 image and to flash the image into the board.
It can be installed with: ``pip install esptool``.
Configure the NUttX project: ``./tools/configure.sh esp32c6-devkit:nsh``
Configure the NuttX project: ``./tools/configure.sh esp32c6-devkit:nsh``
Run ``make`` to build the project. Note that the conversion mentioned above is
included in the build process.
The `esptool.py` command to flash all the binaries is::
included in the build process.
The ``esptool.py`` command to flash all the binaries is::
esptool.py --chip esp32c6 --port /dev/ttyUSBXX --baud 921600 write_flash 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 nuttx.bin
@ -60,9 +60,58 @@ However, this is also included in the build process and we can build and flash w
make flash ESPTOOL_PORT=<port> ESPTOOL_BINDIR=../esp-bins
Where ``<port>`` is typically ``/dev/ttyUSB0`` or similar and ``../esp-bins`` is
Where ``<port>`` is typically ``/dev/ttyUSB0`` or similar and ``../esp-bins`` is
the path to the folder containing the bootloader and the partition table
for the ESP32-C6 as explained above.
Note that this step is required only one time. Once the bootloader and partition
table are flashed, we don't need to flash them again. So subsequent builds
would just require: ``make flash ESPTOOL_PORT=/dev/ttyUSBXX``
Peripheral Support
==================
The following list indicates the state of peripherals' support in NuttX:
============== =======
Peripheral Support
============== =======
ADC No
AES No
Bluetooth No
CAN/TWAI No
DMA No
ECC No
eFuse No
GPIO No
HMAC No
I2C No
I2S No
Int. Temp. No
LED No
LED_PWM No
MCPWM No
Pulse Counter No
RMT No
RNG No
RSA No
RTC No
SD/MMC No
SDIO No
SHA No
SPI No
SPIFLASH No
Timers No
UART Yes
Watchdog Yes
Wifi No
XTS No
============== =======
Supported Boards
================
.. toctree::
:glob:
:maxdepth: 1
boards/*/*

418
Documentation/platforms/xtensa/esp32/boards/esp32-devkitc/index.rst
View File

@ -30,7 +30,7 @@ Features
Serial Console
==============
UART0 is, by default, the serial console. It connects to the on-board
UART0 is, by default, the serial console. It connects to the on-board
CP2102 converter and is available on the USB connector USB CON8 (J1).
It will show up as /dev/ttypUSB[n] where [n] will probably be 0 (is it 1
@ -39,22 +39,22 @@ on my PC because I have a another device at ttyUSB0).
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled Boot and EN. The EN button is not available
to software. It pulls the chip enable line that doubles as a reset line.
There are two buttons labeled Boot and EN. The EN button is not available
to software. It pulls the chip enable line that doubles as a reset line.
The BOOT button is connected to IO0. On reset it is used as a strapping
The BOOT button is connected to IO0. On reset it is used as a strapping
pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
bootloader. After reset, however, the BOOT button can be used for software
input.
LEDs
----
Board LEDs
----------
There are several on-board LEDs for that indicate the presence of power
and USB activity. None of these are available for use by software.
and USB activity. None of these are available for use by software.
Ethernet
========
@ -155,6 +155,14 @@ Pin Signal Notes
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32-devkitc:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
audio
-----
@ -181,12 +189,11 @@ Prepare a PCM-encoded (`.wav`) audio file with 16 or 24 bits/sample (sampled at
16~48kHz). This file must be placed into a folder in a computer that could
be accessed on the same Wi-Fi network the ESP32 will be connecting to.
Python provides a simple HTTP server. `cd` to the audio file folder on the
Python provides a simple HTTP server. ``cd`` to the audio file folder on the
PC and run::
$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/)
$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/)
Look for your PC IP address and test playing the prepared audio on your
browser:
@ -196,20 +203,143 @@ browser:
After successfully built and flashed, connect the board to the Wi-Fi network::
nsh> wapi psk wlan0 mypasswd 1
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0
nsh> wapi psk wlan0 mypasswd 1
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0
Once connected, open NuttX's player and play the file according to its file
name and the IP address of the HTTP server::
nsh> nxplayer
nxplayer> play http://192.168.1.239:8000/tones.wav
nsh> nxplayer
nxplayer> play http://192.168.1.239:8000/tones.wav
autopm
------
This configuration makes the device automatically enter the low power consumption mode
when in the idle state, powering off the cpu and other peripherals.
In minimum power save mode, the station wakes up every DTIM to receive a beacon. The broadcast
data will not be lost because it is transmitted after DTIM. However, it can not save much more
power if DTIM is short as the DTIM is determined by the access point.
ble
---
This configuration is used to enable Bluetooth Low Energy support for this board. You can scan
for Bluetooth devices using the following commands::
NuttShell (NSH) NuttX-10.2.0
nsh> ifconfig
bnep0 Link encap:UNSPEC at DOWN
inet addr:0.0.0.0 DRaddr:0.0.0.0 Mask:0.0.0.0
wlan0 Link encap:Ethernet HWaddr ac:67:b2:53:8b:ec at UP
inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0
nsh> bt bnep0 scan start
nsh> bt bnep0 scan stop
nsh> bt bnep0 scan get
Scan result:
1. addr: 63:14:2f:b9:9f:83 type: 1
rssi: -90
response type: 3
advertiser data: 1e ff 06 00 01 09 20 02 7c 33 a3 a7 cd c9 44 5b
2. addr: 52:ca:05:b5:ad:77 type: 1
rssi: -82
response type: 3
advertiser data: 1e ff 06 00 01 09 20 02 03 d1 21 57 bf 19 b3 7a
3. addr: 46:8e:b2:cd:94:27 type: 1
rssi: -92
response type: 2
advertiser data: 02 01 1a 09 ff c4 00 10 33 14 12 16 80 02 0a d4
4. addr: 46:8e:b2:cd:94:27 type: 1
rssi: -92
response type: 4
advertiser data: 18 09 5b 4c 47 5d 20 77 65 62 4f 53 20 54 56 20
5. addr: 63:14:2f:b9:9f:83 type: 1
rssi: -80
response type: 3
advertiser data: 1e ff 06 00 01 09 20 02 7c 33 a3 a7 cd c9 44 5b
blewifi
-------
Combines the capabilities of the ``ble`` and ``wifi`` configurations. ESP32 has only one 2.4 GHz
ISM band RF module, which is shared by Bluetooth (BT & BLE) and Wi-Fi, so Bluetooth can't receive
or transmit data while Wi-Fi is receiving or transmitting data and vice versa. Under such circumstances,
ESP32 uses the time-division multiplexing method to receive and transmit packets.
bmp280
------
This configuration enables the use of the BMP280 temperature and pressure sensor over I2C.
You can check that the sensor is working by using the ``sensortest`` application::
nsh> sensortest baro0
baro0: timestamp:66870000 value1:1008.37 value2:31.70
baro0: timestamp:66890000 value1:1008.31 value2:31.70
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x01
nsh> Sample = 1
Sample = 0
coremark
--------
This configuration sets the CoreMark benchmark up for running on the maximum
number of cores for this system. It also enables some optimization flags and
disables the NuttShell to get the best possible score.
.. note:: As the NSH is disabled, the application will start as soon as the
system is turned on.
cxx
---
Development enviroment ready for C++ applications. You can check if the setup
was successfull by running ``cxxtest``::
nsh> cxxtest
Test ofstream ================================
printf: Starting test_ostream
printf: Successfully opened /dev/console
cout: Successfully opened /dev/console
Writing this to /dev/console
Test iostream ================================
Hello, this is only a test
Print an int: 190
Print a char: d
Test std::vector =============================
v1=1 2 3
Hello World Good Luck
Test std::map ================================
Test C++17 features ==========================
File /proc/meminfo exists!
Invalid file! /invalid
File /proc/version exists!
efuse
-----
A config with EFUSE enabled.
A ``wifi`` configuration with the eFuse driver enabled. It can be accessed
through the ``/dev/efuse`` device file.
elf
---
This configuration uses apps/examples/elf in order to test the ELF loader.
It can be tested by executing the ``elf`` application.
i2schar
-------
@ -243,7 +373,7 @@ ESP32 Pin Signal Pin Description
After successfully built and flashed, run on the boards's terminal::
i2schar -p /dev/i2schar[0-1]
i2schar -p /dev/i2schar[0-1]
The corresponding output should show related debug informations.
@ -269,6 +399,50 @@ Flash and PSRAM).
* The PID Controller **does not** prevent the application from accessing
CPU System Registers.
leds
----
This configuration uses the on-board LED (or an external LED connected to GPIO2)
to demonstrate the use of the userleds subsystem::
nsh> leds
leds_main: Starting the led_daemon
leds_main: led_daemon started
led_daemon (pid# 3): Running
led_daemon: Opening /dev/userleds
led_daemon: Supported LEDs 0x01
led_daemon: LED set 0x01
led_daemon: LED set 0x00
led_daemon: LED set 0x01
led_daemon: LED set 0x00
led_daemon: LED set 0x01
max6675
-------
This configuration enables the use of the MAX6675 temperature sensor over SPI.
The following pin configuration is used to connect the sensor:
===== =======
Pin Signal
===== =======
15 CS
14 SCK
12 MISO
===== =======
You can check that the sensor is working by using the ``max6675`` application::
nsh> max6675
Unable to open file /dev/temp1
Unable to open file /dev/temp2
Unable to open file /dev/temp3
Starting...
Channel SSP0/SPI1 Device 0: Temperature = 24!
Channel SSP0/SPI1 Device 1: Not enabled!
Channel SSP1/SPI2 Device 0: Not enabled!
Channel SSP1/SPI2 Device 1: Not enabled!
mcp2515
-------
@ -287,24 +461,50 @@ Pin Signal
The MCP2515 interrupt (INT) pin is connected to the pin 22 of the
ESP32-Devkit.
mmcsdspi
--------
mcuboot_slot_confirm
--------------------
This config tests the SPI driver by connecting an SD Card reader over SPI.
SPI2 is used and kept with the default IOMUX pins, i.e.:
This configuration is used to represent an MCUboot update image that needs to be confirmed
after flashing. The image can be confirmed by using the following command::
===== =======
Pin Signal
===== =======
15 CS
14 SCK
13 MOSI
12 MISO
===== =======
nsh> mcuboot_confirm
Application Image successfully confirmed!
Once booted the following command is used to mount a FAT file system::
For more information, check `this demo <https://www.youtube.com/watch?v=Vzy0rl-ixbc>`_.
nsh> mount -t vfat /dev/mmcsd0 /mnt
mcuboot_update_agent
--------------------
This configuration is used to represent an MCUboot image that contains an update agent
to perform OTA updates. First, you will have to setup a HTTP server to provide the update
image. To do that, we can run a simple Python server on the same folder that contains our
binary file on the computer::
sudo python -m http.server 8080
After this, we can use NSH to connect to our network and use the agent to perform the firmware
update::
nsh> ifup wlan0
nsh> wapi mode wlan0 2
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0
nsh> mcuboot_agent http://<SERVER_IP>:8080/nuttx.bin
For more information, check `this demo <https://www.youtube.com/watch?v=Vzy0rl-ixbc>`_.
modbus
------
This configurations shows how to use this device as a ModBus RTU Slave. After
configuring the desired pins on menuconfig and wiring the RS485 converter, you
can enable the ModBus to respond to queries::
nsh> modbus -e
Now you will be able to read the ModBus registers using an application like ``mbpoll``.
For more information, check `this video <https://www.youtube.com/watch?v=bLUGLJIjt4E>`_.
module
------
@ -317,7 +517,7 @@ mqttc
This configuration tests the MQTT-C publisher example.
From the host, start the broker and subscribe to the :code:`test` topic. Using
`mosquitto` this should be::
``mosquitto`` this should be::
$ mosquitto&
$ mosquitto_sub -t test
@ -343,6 +543,16 @@ outputted::
From the host the message :code:`test` should be outputted.
ms5611
------
This configuration enables the use of the MS5611 pressure sensor over I2C.
You can check that the sensor is working by using the ``sensortest`` application::
nsh> sensortest baro0
baro0: timestamp:66870000 value1:1008.37 value2:31.70
baro0: timestamp:66890000 value1:1008.31 value2:31.70
nsh
---
@ -388,7 +598,7 @@ ESP32 Pin Signal Pin Description
**nxlooper**
The `nxlooper` application captures data from the audio device with receiving
The ``nxlooper`` application captures data from the audio device with receiving
capabilities (the I2S1 on this example) and forwards the audio data frame to
the audio device with transmitting capabilities (the I2S0 on this example).
@ -397,24 +607,42 @@ After successfully built and flashed, run on the boards's terminal::
nsh> nxlooper
nxlooper> loopback
.. note:: `loopback` command default arguments for the channel configuration,
.. note:: ``loopback`` command default arguments for the channel configuration,
the data width and the sample rate are, respectively, 2 channels,
16 bits/sample and 48KHz. These arguments can be supplied to select
different audio formats, for instance::
nxlooper> loopback 2 8 44100
oneshot
-------
This config demonstrate the use of oneshot timers present on the ESP32.
To test it, just run the ``oneshot`` example::
nsh> oneshot
Opening /dev/oneshot
Maximum delay is 4294967295999999
Starting oneshot timer with delay 2000000 microseconds
Waiting...
Finished
ostest
------
This is the NuttX test at apps/testing/ostest that is run against all new
architecture ports to assure a correct implementation of the OS. The default
This is the NuttX test at ``apps/testing/ostest`` that is run against all new
architecture ports to assure a correct implementation of the OS. The default
version is for a single CPU but can be modified for an SMP test by adding::
CONFIG_SMP=y
CONFIG_SMP_NCPUS=2
CONFIG_SPINLOCK=y
pm
--
This configuration enables the CPU power management through governors.
psram
-----
@ -431,11 +659,56 @@ only 64KB on this example (64 * 1024), but you can change this number to
RAMTest: Pattern test: 3f800000 65536 33333333 cccccccc
RAMTest: Address-in-address test: 3f800000 65536
psram_usrheap
-------------
This configuration works just like ``psram`` but allocating the user
heap on the PSRAM.
pwm
---
This configuration demonstrates the use of PWM through a LED connected to GPIO12.
To test it, just execute the ``pwm`` application::
nsh> pwm
pwm_main: starting output with frequency: 10000 duty: 00008000
pwm_main: stopping output
random
------
This configuration shows the use of the ESP32's True Random Number Generator with
entropy sourced from Wi-Fi and Bluetooth noise.
To test it, just run ``rand`` to get 32 randomly generated bytes::
nsh> rand
Reading 8 random numbers
Random values (0x3ffe0b00):
0000 98 b9 66 a2 a2 c0 a2 ae 09 70 93 d1 b5 91 86 c8 ..f......p......
0010 8f 0e 0b 04 29 64 21 72 01 92 7c a2 27 60 6f 90 ....)d!r..|.'`o.
rtc
---
This configuration demonstrates the use of the RTC driver through alarms.
You can set an alarm, check its progress and receive a notification after it expires::
nsh> alarm 10
alarm_daemon started
alarm_daemon: Running
Opening /dev/rtc0
Alarm 0 set in 10 seconds
nsh> alarm -r
Opening /dev/rtc0
Alarm 0 is active with 10 seconds to expiration
nsh> alarm_daemon: alarm 0 received
smp
---
Another NSH configuration, similar to nsh, but also enables
SMP operation. It differs from the nsh configuration only in these
SMP operation. It differs from the nsh configuration only in these
additional settings:
SMP is enabled::
@ -454,13 +727,13 @@ The apps/testing/smp test is included::
sotest
------
This config is to run apps/examples/sotest.
This config is to run ``apps/examples/sotest``.
spiflash
--------
This config tests the external SPI that comes with an ESP32 module connected
through SPI1.
This config tests the external flash memory that comes with the ESP32 module
connected through SPI1.
By default a SmartFS file system is selected.
Once booted you can use the following commands to mount the file system::
@ -470,6 +743,27 @@ Once booted you can use the following commands to mount the file system::
Note that mksmartfs is only needed the first time.
sta_softap
----------
With this configuration you can run these commands to be able
to connect your smartphone or laptop to your board::
nsh> ifup wlan1
nsh> dhcpd_start wlan1
nsh> wapi psk wlan1 mypasswd 3
nsh> wapi essid wlan1 nuttxap 1
In this case, you are creating the access point ``nuttxapp`` in your board and to
connect to it on your smartphone you will be required to type the password ``mypasswd``
using WPA2.
The ``dhcpd_start`` is necessary to let your board to associate an IP to your smartphone.
tickless
--------
This configuration enables the support for tickless scheduler mode.
timer
-----
@ -521,7 +815,7 @@ This example uses littlefs on ESP32's SPI flash to store wasm modules.
nsh> mount -t littlefs /dev/esp32flash /mnt
nsh> iwasm /mnt/....
wapi
wifi
----
Enables Wi-Fi support. You can define your credentials this way::
@ -535,10 +829,15 @@ Enables Wi-Fi support. You can define your credentials this way::
Or if you don't want to keep it saved in the firmware you can do it
at runtime::
nsh> wapi psk wlan0 mypasswd 1
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0
wifi_smp
--------
This configuration is similar to ``wifi``. It also enables multiple cores on the CPU.
watchdog
--------
@ -552,10 +851,35 @@ To test it, just run the following::
Where x is the watchdog instance.
watcher
-------
This configuration is an example of monitoring watchdog interrupts. To test it, enable
the watcher daemon with ``watcher`` and monitor the tasks using ``watched``::
nsh> watcher
Watcher Daemon has started!
nsh> watched
Starting watched tasks
Creating Watched Task 1 - It will not feed the dog
Creating Watched Task 2 - It will feed the dog
Creating Watched Task 3 - It will feed the dog
Creating Watched Task 4 - It will not feed the dog
nsh> *** Printing Tasks Status ***
Watched Task 1 starved the dog.
Watched Task 2 fed the dog.
Watched Task 3 fed the dog.
Watched Task 4 fed the dog.
*** Printing Tasks Status ***
Watched Task 1 starved the dog.
Watched Task 2 fed the dog.
Watched Task 3 fed the dog.
Watched Task 4 starved the dog.
wifinsh
-------
The ``wifinsh`` is similar to the ``wapi`` board example, but it will connect
The ``wifinsh`` is similar to the ``wifi`` board example, but it will connect
automatically to your Access Point (Wi-Fi Router) and will run telnet daemon
in the board. Then you can connect to your board from your computer using the
telnet program.

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-a-v1.2-layout.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 112 KiB

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-b-v1.0-layout.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 106 KiB

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-rmii-clk-from-phy.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-rmii-clk-to-phy.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 25 KiB

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-v1.1-block-diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 72 KiB

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-v1.2-overview.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 526 KiB

BIN
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/esp32-ethernet-kit-v1.2.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 180 KiB

325
Documentation/platforms/xtensa/esp32/boards/esp32-ethernet-kit/index.rst Normal file
View File

@ -0,0 +1,325 @@
..
Ported from ESP-IDF documentation https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-ethernet-kit.html
=======================
ESP32-Ethernet-Kit V1.2
=======================
The ESP32-Ethernet-Kit is an Ethernet-to-Wi-Fi development board that enables Ethernet
devices to be interconnected over Wi-Fi. At the same time, to provide more flexible power
supply options, the ESP32-Ethernet-Kit also supports power over Ethernet (PoE).
You can find the board schematic `here <https://dl.espressif.com/dl/schematics/SCH_ESP32-Ethernet-Kit_A_V1.2_20200528.pdf>`_.
.. figure:: esp32-ethernet-kit-v1.2-overview.png
:alt: ESP32-Ethernet-Kit V1.2 Board Layout
:figclass: align-center
ESP32-Ethernet-Kit V1.2 Board Layout
It consists of two development boards, the Ethernet board A and the PoE board B.
The Ethernet board (A) contains Bluetooth/Wi-Fi dual-mode ESP32-WROVER-E module and IP101GRI,
a Single Port 10/100 Fast Ethernet Transceiver (PHY). The PoE board (B) provides power over
Ethernet functionality. The A board can work independently, without the board B installed.
.. figure:: esp32-ethernet-kit-v1.2.jpg
:alt: ESP32-Ethernet-Kit V1.2
:figclass: align-center
ESP32-Ethernet-Kit V1.2
For the application loading and monitoring, the Ethernet board (A) also features FTDI FT2232H
chip - an advanced multi-interface USB bridge. This chip enables to use JTAG for direct debugging
of ESP32 through the USB interface without a separate JTAG debugger.
The block diagram below presents main components of the ESP32-Ethernet-Kit.
.. figure:: esp32-ethernet-kit-v1.1-block-diagram.png
:alt: ESP32-Ethernet-Kit V1.2 Electrical Block Diagram
:figclass: align-center
ESP32-Ethernet-Kit V1.2 Electrical Block Diagram
Features
========
- ESP32-WROVER-E Module
- JTAG through USB
- Ethernet
- Power over Ethernet (PoE)
- USB-to-UART bridge via micro USB port
Functional Description
======================
The following figures describe the key components, interfaces, and controls of the ESP32-Ethernet-Kit.
Ethernet Board (A)
------------------
.. figure:: esp32-ethernet-kit-a-v1.2-layout.jpg
:alt: ESP32-Ethernet-Kit - Ethernet board (A) layout
:figclass: align-center
ESP32-Ethernet-Kit - Ethernet board (A) layout
PoE Board (B)
-------------
This board converts power delivered over the Ethernet cable (PoE) to provide a power supply
for the Ethernet board (A). The main components of the PoE board (B) are shown on the image below.
.. figure:: esp32-ethernet-kit-b-v1.0-layout.png
:alt: ESP32-Ethernet-Kit - PoE board (B) layout
:figclass: align-center
ESP32-Ethernet-Kit - PoE board (B) layout
The PoE board (B) has the following features:
- Support for IEEE 802.3at
- Power output: 5 V, 1.4 A
To take advantage of the PoE functionality the RJ45 Port of the Ethernet board (A) should be connected
with an Ethernet cable to a switch that supports PoE. When the Ethernet board (A) detects 5 V power output
from the PoE board (B), the USB power will be automatically cut off.
Function Switch
===============
When in On position, this DIP switch is routing listed GPIOs to FT2232H to provide JTAG functionality.
When in Off position, the GPIOs may be used for other purposes.
======= ================
DIP SW GPIO Pin
======= ================
1 GPIO13
2 GPIO12
3 GPIO15
4 GPIO14
======= ================
RMII Clock Selection
====================
The ethernet MAC and PHY under RMII working mode need a common 50 MHz reference clock (i.e. RMII clock)
that can be provided either externally, or generated from internal ESP32 APLL (not recommended).
RMII Clock Sourced Externally by PHY
------------------------------------
By default, the ESP32-Ethernet-Kit is configured to provide RMII clock for the IP101GRI PHY's 50M_CLKO output.
The clock signal is generated by the frequency multiplication of 25 MHz crystal connected to the PHY.
For details, please see the figure below.
.. figure:: esp32-ethernet-kit-rmii-clk-from-phy.png
:align: center
:scale: 80%
:alt: RMII Clock from IP101GRI PHY
:figclass: align-center
RMII Clock from IP101GRI PHY
Please note that the PHY is reset on power up by pulling the RESET_N signal down with a resistor.
ESP32 should assert RESET_N high with GPIO5 to enable PHY. Only this can ensure the power-up of system.
Otherwise ESP32 may enter download mode (when the clock signal of REF_CLK_50M is at a high logic level during
the GPIO0 power-up sampling phase).
RMII Clock Sourced Internally from ESP32's APLL
-----------------------------------------------
Another option is to source the RMII Clock from internal ESP32 APLL, see figure below.
The clock signal coming from GPIO0 is first inverted, to account for transmission line delay,
and then supplied to the PHY.
.. figure:: esp32-ethernet-kit-rmii-clk-to-phy.png
:align: center
:scale: 80%
:alt: RMII Clock from ESP Internal APLL
:figclass: align-center
RMII Clock from ESP Internal APLL
To implement this option, users need to remove or add some RC components on the board.
For details please refer to the `ESP32-Ethernet-Kit V1.2 Ethernet board (A) schematic <https://dl.espressif.com/dl/schematics/SCH_ESP32-Ethernet-Kit_A_V1.2_20200528.pdf>`_,
sheet 2, location D2. Please note that if the APLL is already used for other purposes
(e.g. I2S peripheral), then you have no choice but use an external RMII clock.
Serial Console
==============
UART0 is, by default, the serial console. It connects to the on-board
CP2102N bridge and is available on the USB connector.
It will show up as /dev/ttyUSB[n] where [n] will probably be 0.
Buttons and LEDs
================
Board Buttons
-------------
There are two buttons labeled Boot and EN. The EN button is not available
to software. It pulls the chip enable line that doubles as a reset line.
The BOOT button is connected to IO0. On reset it is used as a strapping
pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
Board LEDs
----------
There are several on-board LEDs for that indicate the presence of power
and USB activity. None of these are available for use by software.
Pin Mapping
===========
.. csv-table::
:header: ESP32-WROVER-E,IP101GRI,UART,JTAG,GPIO,Comments
S_VP,,,,IO36,
S_VN,,,,IO39,
IO34,,,,IO34,
IO35,,,,IO35,
IO32,,,,IO32,
IO33,,,,IO33,
IO25,RXD[0],,,,
IO26,RXD[1],,,,
IO27,CRS_DV,,,,
IO14,,,TMS,IO14,
IO12,,,TDI,IO12,
IO13,,,TCK,IO13,
IO15,,,TDO,IO15,
IO2,,,,IO2,
IO0,REF_CLK,,,,See note 1
IO4,,,,IO4,
IO16,,,,IO16 (NC),See note 2
IO17,,,,IO17 (NC),See note 2
IO5,Reset_N,,,,See note 1
IO18,MDIO,,,,
IO19,TXD[0],,,,
IO21,TX_EN,,,,
RXD0,,RXD,,,
TXD0,,TXD,,,
IO22,TXD[1],,,,
IO23,MDC,,,,
.. note::
1. To prevent the power-on state of the GPIO0 from being affected by the clock output on the PHY side,
the RESET_N signal to PHY defaults to low, turning the clock output off. After power-on you can control
RESET_N with GPIO5 to turn the clock output on. See also `RMII Clock Sourced Externally by PHY`_. For
PHYs that cannot turn off the clock output through RESET_N, it is recommended to use a crystal module
that can be disabled/enabled externally. Similarly like when using RESET_N, the oscillator module should
be disabled by default and turned on by ESP32 after power-up.
For a reference design please see `ESP32-Ethernet-Kit V1.2 Ethernet board (A) schematic <https://dl.espressif.com/dl/schematics/SCH_ESP32-Ethernet-Kit_A_V1.2_20200528.pdf>`_.
2. The ESP32 pins GPIO16 and GPIO17 are not broken out to the ESP32-WROVER-E module and therefore not available for use.
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32-ethernet-kit:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
autopm
------
This configuration makes the device automatically enter the low power consumption mode
when in the idle state, powering off the cpu and other peripherals.
In minimum power save mode, the station wakes up every DTIM to receive a beacon. The broadcast
data will not be lost because it is transmitted after DTIM. However, it can not save much more
power if DTIM is short as the DTIM is determined by the access point.
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x01
nsh> Sample = 1
Sample = 0
ethernet
--------
This configuration is similar to ``wifi`` but uses the Ethernet interface instead
of the WiFi one. It also automatically configures the IP and DNS addresses of the
device. It currently uses the following static configuration:
- IP: 192.168.15.100 (0xc0a80f64)
- Gateway: 192.168.15.1 (0xc0a80f01)
- Netmask: 255.255.255.0 (0xffffff00)
- DNS: 8.8.8.8 (0x08080808)
nsh
---
Basic NuttShell configuration (console enabled in UART0, exposed via
USB connection by means of CP2102 converter, at 115200 bps).
oneshot
-------
This config demonstrate the use of oneshot timers present on the ESP32.
To test it, just run the ``oneshot`` example::
nsh> oneshot
Opening /dev/oneshot
Maximum delay is 4294967295999999
Starting oneshot timer with delay 2000000 microseconds
Waiting...
Finished
rtc
---
This configuration demonstrates the use of the RTC driver through alarms.
You can set an alarm, check its progress and receive a notification after it expires::
nsh> alarm 10
alarm_daemon started
alarm_daemon: Running
Opening /dev/rtc0
Alarm 0 set in 10 seconds
nsh> alarm -r
Opening /dev/rtc0
Alarm 0 is active with 10 seconds to expiration
nsh> alarm_daemon: alarm 0 received
tickless
--------
This configuration enables the support for tickless scheduler mode.
wifi
----
Enables Wi-Fi support. You can define your credentials this way::
$ make menuconfig
-> Application Configuration
-> Network Utilities
-> Network initialization (NETUTILS_NETINIT [=y])
-> WAPI Configuration
Or if you don't want to keep it saved in the firmware you can do it
at runtime::
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0

85
Documentation/platforms/xtensa/esp32/boards/esp32-lyrat/index.rst
View File

@ -45,8 +45,8 @@ It will show up as /dev/ttyUSB[n] where [n] will probably be 0.
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
Two key labeled *Rec* and *Mode*. They are routed to **ESP32-WROVER-E Module**
and intended for developing and testing a UI for audio applications using
@ -72,8 +72,8 @@ Entering of the ESP32 into upload mode may be done in two ways:
by installing jumpers in three headers **JP23**, **JP24** and **JP25**.
Remove all jumpers after upload is complete.
LEDs
----
Board LEDs
----------
A general purpose green LED controlled by the **ESP32-WROVER-E Module** to
indicate certain operation states of the audio application using dedicated
@ -390,6 +390,14 @@ JTAG Header / JP7
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32-lyrat:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
audio
-----
@ -433,13 +441,78 @@ name and the IP address of the HTTP server (For example `tones.wav` and
The codec implementation on the LyraT board was validated using 16-bit,
44.1kHz WAV files. Other configurations might not work as expected.
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x01
nsh> Sample = 1
Sample = 0
.. note::
The ``BOOT`` is connected to GPIO0 that is shared among some peripherals.
To avoid any conflicts, it's not registered in the buttons subsystem and, thus,
is unable to be used.
mmcsdspi
--------
This configuration is used to mount a FAT/FAT32 SD Card into the OS' filesystem.
For the ESP32-LyraT, make sure the DIP switches 1 and 2 are turned to the ON position.
To access the card's files, execute the following commands::
nsh> mount -t vfat /dev/mmcsd0 /mnt
nsh> ls /mnt/
/mnt:
song_16_88200_2ch.wav
song_16_96000_2ch.wav
song_24_44100_2ch.wav
song_32_44100_2ch.wav
nsh
---
Basic NuttShell configuration (console enabled in UART0, exposed via
USB connection by means of the CP2102N bridge, at 115200 bps).
wapi
nxrecorder
----------
This configuration is used to record raw audio from the the ES8388 audio codec
through the I2S0 peripheral to a FAT32 SD Card. By default the audio is recorded from
the on-board microphones.
For the ESP32-LyraT, make sure the DIP switches 1 and 2 are turned to the ON position.
To record audio, execute the following commands::
nsh> mount -t vfat /dev/mmcsd0 /mnt
nsh> nxrecorder
nxrecorder> recordraw /mnt/record.raw
nxrecorder> stop
To play the recorded audio, import the raw data into Audacity and set the encoding to signed
16-bit PCM, the sample rate to 44.1kHz and the number of channels to 2.
wifi
----
Enables Wi-Fi support.
Enables Wi-Fi support. You can define your credentials this way::
$ make menuconfig
-> Application Configuration
-> Network Utilities
-> Network initialization (NETUTILS_NETINIT [=y])
-> WAPI Configuration
Or if you don't want to keep it saved in the firmware you can do it
at runtime::
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0

191
Documentation/platforms/xtensa/esp32/boards/esp32-wrover-kit/index.rst
View File

@ -30,7 +30,7 @@ for direct debugging of ESP32 through the USB interface without a separate
JTAG debugger. ESP-WROVER-KIT makes development convenient, easy, and
cost-effective.
Most of the ESP32 I/O pins are broken out to the board’s pin headers for easy access.
Most of the ESP32 I/O pins are broken out to the board's pin headers for easy access.
Serial Console
==============
@ -44,8 +44,8 @@ the first interface ([n] == 0) is dedicated to the USB-to-JTAG interface.
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled Boot and EN. The EN button is not available
to software. It pulls the chip enable line that doubles as a reset line.
@ -55,8 +55,8 @@ pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
LEDs
----
Board LEDs
----------
There are several on-board LEDs for that indicate the presence of power
and USB activity.
@ -84,22 +84,55 @@ Pin Signal Notes
Configurations
==============
nsh
---
All of the configurations presented below can be tested by running the following commands::
Basic NuttShell configuration (console enabled in UART0, exposed via
USB connection by means of FT2232HL converter, at 115200 bps).
$ ./tools/configure.sh esp32-wrover-kit:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB1 -j
wapi
----
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
Enables Wi-Fi support.
autopm
------
This configuration makes the device automatically enter the low power consumption mode
when in the idle state, powering off the cpu and other peripherals.
In minimum power save mode, the station wakes up every DTIM to receive a beacon. The broadcast
data will not be lost because it is transmitted after DTIM. However, it can not save much more
power if DTIM is short as the DTIM is determined by the access point.
bmp180
------
This configuration enables the use of the BMP180 pressure sensor over I2C.
You can check that the sensor is working by using the ``bmp180`` application::
nsh> bmp180
Pressure value = 91531
Pressure value = 91526
Pressure value = 91525
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x01
nsh> Sample = 1
Sample = 0
gpio
----
This is a test for the GPIO driver. It includes the 3 LEDs and one, arbitrary, GPIO.
For this example, GPIO22 was used.
For this example, GPIO22 was used (defined by the board implementation).
At the nsh, we can turn LEDs on and off with the following::
nsh> gpio -o 1 /dev/gpio0
@ -112,27 +145,49 @@ We can use the interrupt pin to send a signal when the interrupt fires::
The pin is configured to as a rising edge interrupt, so after issuing the
above command, connect it to 3.3V.
spiflash
--------
lcd1602
-------
This config tests the external SPI that comes with an ESP32 module connected
through SPI1.
This configuration is used to demonstrate the use of an LCD1602 display with
the ESP32-WROVER-KIT. You can run an example by executing the following commands::
By default a SmartFS file system is selected.
Once booted you can use the following commands to mount the file system::
nsh> slcd
Opening /dev/slcd0 for read/write access
Attributes:
rows: 2 columns: 16 nbars: 0
max contrast: 0 max brightness: 1
Clear screen
WRITING:
0000: 1b5b46 .[F
Set brightness to 1
Print [Hello]
WRITING:
0000: 1b5b471b5b30304c1b5b4548656c6c6f .[G.[00L.[EHello
mksmartfs /dev/smart0
mount -t smartfs /dev/smart0 /mnt
leds
----
Note that `mksmartfs` is only needed the first time.
This configuration demonstrates the use of the on-board RGB LED with the
`userleds` subsystem. To check the included example, you can execute the
following application::
nx
--
nsh> leds
leds_main: Starting the led_daemon
leds_main: led_daemon started
led_daemon (pid# 3): Running
led_daemon: Opening /dev/userleds
led_daemon: Supported LEDs 0x07
led_daemon: LED set 0x01
nsh> led_daemon: LED set 0x02
led_daemon: LED set 0x03
led_daemon: LED set 0x04
led_daemon: LED set 0x05
This config adds a set of tests using the graphic examples at `apps/example/nx`.
lua
---
This configuration illustrates the use of the LCD with the lower performance
SPI interface.
This configuration demonstrates the use of the of the Lua interpreter on NuttX.
To execute it, just run the ``lua`` application.
lvgl
----
@ -145,10 +200,82 @@ driver. You can find LVGL here::
This configuration uses the LVGL demonstration at `apps/examples/lvgldemo`.
External devices
=================
mmcsdspi
--------
BMP180
------
This configuration is used to mount a FAT/FAT32 SD Card into the OS' filesystem.
To access the card's files, execute the following commands::
When using BMP180 (enabling ``CONFIG_SENSORS_BMP180``), it's expected this device is wired to I2C0 bus.
nsh> mount -t vfat /dev/mmcsd0 /mnt
nsh> ls /mnt/
/mnt:
song_16_88200_2ch.wav
song_16_96000_2ch.wav
song_24_44100_2ch.wav
song_32_44100_2ch.wav
nsh
---
Basic NuttShell configuration (console enabled in UART0, exposed via
USB connection by means of FT2232HL converter, at 115200 bps).
nx
--
This config adds a set of tests using the graphic examples at ``apps/example/nx``.
This configuration illustrates the use of the LCD with the lower performance
SPI interface.
oneshot
-------
This config demonstrate the use of oneshot timers present on the ESP32.
To test it, just run the ``oneshot`` example::
nsh> oneshot
Opening /dev/oneshot
Maximum delay is 4294967295999999
Starting oneshot timer with delay 2000000 microseconds
Waiting...
Finished
rtc
---
This configuration demonstrates the use of the RTC driver through alarms.
You can set an alarm, check its progress and receive a notification after it expires::
nsh> alarm 10
alarm_daemon started
alarm_daemon: Running
Opening /dev/rtc0
Alarm 0 set in 10 seconds
nsh> alarm -r
Opening /dev/rtc0
Alarm 0 is active with 10 seconds to expiration
nsh> alarm_daemon: alarm 0 received
tickless
--------
This configuration enables the support for tickless scheduler mode.
wifi
----
Enables Wi-Fi support. You can define your credentials this way::
$ make menuconfig
-> Application Configuration
-> Network Utilities
-> Network initialization (NETUTILS_NETINIT [=y])
-> WAPI Configuration
Or if you don't want to keep it saved in the firmware you can do it
at runtime::
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0

48
Documentation/platforms/xtensa/esp32/index.rst
View File

@ -90,33 +90,34 @@ The following list indicates the state of peripherals' support in NuttX:
========== ======= =====
Peripheral Support NOTES
========== ======= =====
GPIO Yes
UART Yes
SPI Yes
I2C Yes
ADC No
AES Yes
Bluetooth Yes
CAN/TWAI Yes
DMA Yes
Wifi Yes
eFuse Yes
Ethernet Yes
GPIO Yes
I2C Yes
I2S Yes
LED_PWM Yes
MCPWM No
Pulse_CNT No
RMT No
RNG Yes
RSA No
RTC Yes
SD/MMC No
SDIO No
SHA No
SPI Yes
SPIFLASH Yes
SPIRAM Yes
Timers Yes
Touch Yes
UART Yes
Watchdog Yes
RTC Yes
RNG Yes
AES Yes
eFuse Yes
ADC No
Bluetooth Yes
SDIO No
SD/MMC No
I2S Yes
LED_PWM Yes
RMT No
MCPWM No
Pulse_CNT No
SHA No
RSA No
CAN/TWAI Yes
Wifi Yes
========== ======= =====
Memory Map
@ -285,7 +286,7 @@ In this case a connection to AP with SSID ``myssid`` is done, using ``mypasswd``
password. IP address is obtained via DHCP using ``renew`` command. You can check
the result by running ``ifconfig`` afterwards.
.. tip:: Boards usually expose a ``wapi`` defconfig which enables Wi-Fi
.. tip:: Boards usually expose a ``wifi`` defconfig which enables Wi-Fi
Wi-Fi SoftAP
============
@ -363,6 +364,9 @@ audio subsystem and develop specific usages of the I2S peripheral.
audio-related drivers. That is not the case for the I2S character device driver and
such parameters are set on compile time through `make menuconfig`.
.. warning:: Some upper driver implementations might not handle both transmission and
reception configured at the same time on the same peripheral.
Please check for usage examples using the :doc:`ESP32 DevKitC </platforms/xtensa/esp32/boards/esp32-devkitc/index>`.
Using QEMU

41
Documentation/platforms/xtensa/esp32s2/boards/esp32s2-kaluga-1/index.rst
View File

@ -157,8 +157,8 @@ It will show up as /dev/ttyUSB[n] where [n] will probably be 0.
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled Boot and EN. The EN button is not available
to the software. It pulls the chip enable line that doubles as a reset line.
@ -168,8 +168,8 @@ pin to determine whether the chip boots normally or into the serial
bootloader. After resetting, however, the BOOT button can be used for
software input.
LEDs
----
Board LEDs
----------
There are many on-board LEDs. The only one that can be controlled by software
is a WS2812 RGB LED (U21) addressable LED and is driven by GPIO45.
@ -177,6 +177,39 @@ is a WS2812 RGB LED (U21) addressable LED and is driven by GPIO45.
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32s2-kaluga-1:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons and touch pads::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x7f
nsh> Sample = 32
Sample = 0
Sample = 2
Sample = 0
Sample = 4
Sample = 0
Sample = 8
Sample = 0
Sample = 16
Sample = 0
Sample = 64
Sample = 0
nsh
---

161
Documentation/platforms/xtensa/esp32s2/boards/esp32s2-saola-1/index.rst
View File

@ -39,8 +39,8 @@ It will show up as /dev/ttyUSB[n] where [n] will probably be 0.
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled Boot and EN. The EN button is not available
to the software. It pulls the chip enable line that doubles as a reset line.
@ -50,8 +50,8 @@ pin to determine whether the chip boots normally or into the serial
bootloader. After resetting, however, the BOOT button can be used for
software input.
LEDs
----
Board LEDs
----------
There are two on-board LEDs. RED_LED (D5) indicates the presence of 3.3V
power and is not controlled by software. RGB LED (U6) is a WS2812 addressable
@ -90,6 +90,14 @@ The following configurations use the I2S peripheral::
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32s2-saola-1:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
audio
-----
@ -114,24 +122,92 @@ ESP32-S2 Pin CS4344 Pin Description
**ROMFS example**
Prepare and build the `audio` defconfig::
Prepare and build the ``audio`` defconfig::
$ make -j distclean && ./tools/configure.sh esp32s2-saola-1:audio && make
This will create a temporary folder in `apps/examples/romfs/testdir`. Move
a PCM-encoded (`.wav`) audio file with 16 or 24 bits/sample (sampled at 16~48kHz)
This will create a temporary folder in ``apps/examples/romfs/testdir``. Move
a PCM-encoded (``.wav``) audio file with 16 or 24 bits/sample (sampled at 16~48kHz)
to this folder.
.. note:: You can use :download:`this 440 Hz sinusoidal tone <tone.wav>`.
The audio file should be located at `apps/examples/romfs/testdir/tone.wav`
The audio file should be located at ``apps/examples/romfs/testdir/tone.wav``
Build the project again and flash it (make sure not to clean it, just build)
After successfully built and flashed, load the romfs and play it::
$ nsh> romfs
$ nsh> nxplayer
$ nxplayer> play /usr/share/local/tone.wav
nsh> romfs
nsh> nxplayer
nxplayer> play /usr/share/local/tone.wav
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x01
nsh> Sample = 1
Sample = 0
coremark
--------
This configuration sets the CoreMark benchmark up for running on the maximum
number of cores for this system. It also enables some optimization flags and
disables the NuttShell to get the best possible score.
.. note:: As the NSH is disabled, the application will start as soon as the
system is turned on.
cxx
---
Development enviroment ready for C++ applications. You can check if the setup
was successfull by running ``cxxtest``::
nsh> cxxtest
Test ofstream ================================
printf: Starting test_ostream
printf: Successfully opened /dev/console
cout: Successfully opened /dev/console
Writing this to /dev/console
Test iostream ================================
Hello, this is only a test
Print an int: 190
Print a char: d
Test std::vector =============================
v1=1 2 3
Hello World Good Luck
Test std::map ================================
Test C++17 features ==========================
File /proc/meminfo exists!
Invalid file! /invalid
File /proc/version exists!
gpio
----
This is a test for the GPIO driver. It includes one arbitrary GPIO.
For this example, GPIO1 was used (defined by the board implementation).
At the nsh, we can turn the GPIO output on and off with the following::
nsh> gpio -o 1 /dev/gpio0
nsh> gpio -o 0 /dev/gpio0
i2c
---
This configuration can be used to scan and manipulate I2C devices.
You can scan for all I2C devices using the following command::
nsh> i2c dev 0x00 0x7f
i2schar
-------
@ -154,10 +230,17 @@ ESP32-S2 Pin Signal Pin Description
After successfully built and flashed, run on the boards's terminal::
nsh> i2schar
nsh> i2schar
The corresponding output should show related debug information.
mcuboot_nsh
-----------
Similar configuration as nsh, except that it enables booting from
MCUboot and the experimental features configuration.
You can find more information on the `example's documentation <https://github.com/apache/nuttx-apps/blob/master/examples/mcuboot/swap_test/README.md>`_.
nsh
---
@ -194,22 +277,64 @@ The DOUT pin will output the captured data frame.
**nxlooper**
The `nxlooper` application captures data from the audio device with receiving
The ``nxlooper`` application captures data from the audio device with receiving
capabilities and forwards the audio data frame to the audio device with
transmitting capabilities.
After successfully built and flashed, run on the boards's terminal::
nsh> nxlooper
nxlooper> loopback
nsh> nxlooper
nxlooper> loopback
.. note:: `loopback` command default arguments for the channel configuration,
.. note:: ``loopback`` command default arguments for the channel configuration,
the data width and the sample rate are, respectively, 2 channels,
16 bits/sample and 48KHz. These arguments can be supplied to select
different audio formats, for instance::
nxlooper> loopback 2 8 44100
oneshot
-------
This config demonstrate the use of oneshot timers present on the ESP32-S2.
To test it, just run the ``oneshot`` example::
nsh> oneshot
Opening /dev/oneshot
Maximum delay is 4294967295999999
Starting oneshot timer with delay 2000000 microseconds
Waiting...
Finished
ostest
------
This is the NuttX test at apps/testing/ostest that is run against all new
architecture ports to assure a correct implementation of the OS.
pwm
------
This configuration demonstrates the use of PWM through a LED connected to GPIO2.
To test it, just execute the ``pwm`` application::
nsh> pwm
pwm_main: starting output with frequency: 10000 duty: 00008000
pwm_main: stopping output
random
------
This configuration shows the use of the ESP32-S2's True Random Number Generator with
entropy sourced from Wi-Fi and Bluetooth noise.
To test it, just run ``rand`` to get 32 randomly generated bytes::
nsh> rand
Reading 8 random numbers
Random values (0x3ffe0b00):
0000 98 b9 66 a2 a2 c0 a2 ae 09 70 93 d1 b5 91 86 c8 ..f......p......
0010 8f 0e 0b 04 29 64 21 72 01 92 7c a2 27 60 6f 90 ....)d!r..|.'`o.
timer
-----
@ -219,7 +344,7 @@ example.
To test it, just run the following::
nsh> timer -d /dev/timerx
nsh> timer -d /dev/timerx
Where x in the timer instance.
@ -232,6 +357,6 @@ example.
To test it, just run the following::
nsh> wdog -i /dev/watchdogx
nsh> wdog -i /dev/watchdogx
Where x is the watchdog instance.

52
Documentation/platforms/xtensa/esp32s2/index.rst
View File

@ -48,7 +48,6 @@ Alternatively, you may follow the steps in
Flashing
========
Firmware for ESP32-S2 is flashed via the USB/UART or internal USB DEVICE JTAG interface using the
``esptool.py`` tool.
It's a two-step process where the first converts the ELF file into a ESP32-S2 compatible binary
@ -64,7 +63,7 @@ Bootloader and partitions
ESP32-S2 requires a bootloader to be flashed as well as a set of FLASH partitions. This is only needed the first time
(or any time you which to modify either of these).
An easy way is to use prebuilt binaries for NuttX `from here <https://github.com/espressif/esp-nuttx-bootloader>`_.
An easy way is to use prebuilt binaries for NuttX `from here <https://github.com/espressif/esp-nuttx-bootloader>`__.
In there you will find instructions to rebuild these if necessary.
Once you downloaded both binaries, you can flash them by adding an ``ESPTOOL_BINDIR`` parameter, pointing to the directory where these binaries were downloaded:
@ -97,29 +96,30 @@ The following list indicates the state of peripherals' support in NuttX:
========== ======= =====
Peripheral Support NOTES
========== ======= =====
GPIO Yes
UART Yes
SPI Yes
I2C Yes
ADC No
AES No
CAN/TWAI No
DMA Yes
Wifi No
eFuse No
Ethernet No
GPIO Yes
I2C Yes
I2S Yes
LED_PWM No
Pulse_CNT No
RMT No
RNG Yes
RSA No
RTC Yes
SHA No
SPI Yes
SPIFLASH Yes
SPIRAM Yes
Timers Yes
Touch Yes
UART Yes
Watchdog Yes
RTC Yes
RNG Yes
AES No
eFuse No
ADC No
I2S Yes
LED_PWM No
RMT No
Pulse_CNT No
SHA No
RSA No
CAN/TWAI No
Wifi No
========== ======= =====
Memory Map
@ -242,7 +242,7 @@ Linker Segments
ESP32-S2 has 4 generic timers of 64 bits (2 from Group 0 and 2 from Group 1).
They're accessible as character drivers, the configuration along with a
guidance on how to run the example and the description of the application level
interface can be found :doc:`here </components/drivers/character/timer>`.
interface can be found in the :doc:`timer documentation </components/drivers/character/timer>`.
Watchdog Timers
===============
@ -250,8 +250,8 @@ Watchdog Timers
ESP32-S2 has 3 WDTs. 2 MWDTs from the Timers Module and 1 RWDT from the RTC Module
(Currently not supported yet). They're accessible as character drivers,
The configuration along with a guidance on how to run the example and the description
of the application level interface can be found
:doc:`here </components/drivers/character/watchdog>`.
of the application level interface can be found in the
:doc:`watchdog documentation </components/drivers/character/watchdog>`.
I2S
===
@ -276,7 +276,7 @@ Secure Boot protects a device from running any unauthorized (i.e., unsigned) cod
each piece of software that is being booted is signed. On an ESP32-S2, these pieces of software include
the second stage bootloader and each application binary. Note that the first stage bootloader does not
require signing as it is ROM code thus cannot be changed. This is achieved using specific hardware in
conjunction with MCUboot (read more about MCUboot `here <https://docs.mcuboot.com/>`_).
conjunction with MCUboot (read more about MCUboot `here <https://docs.mcuboot.com/>`__).
The Secure Boot process on the ESP32-S2 involves the following steps performed:
@ -290,7 +290,7 @@ The Secure Boot process on the ESP32-S2 involves the following steps performed:
.. warning:: Once enabled, Secure Boot will not boot a modified bootloader. The bootloader will only boot an
application firmware image if it has a verified digital signature. There are implications for reflashing
updated images once Secure Boot is enabled. You can find more information about the ESP32-S2's Secure boot
`here <https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/security/secure-boot-v2.html>`_.
`here <https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/security/secure-boot-v2.html>`__.
.. note:: As the bootloader image is built on top of the Hardware Abstraction Layer component
of `ESP-IDF <https://github.com/espressif/esp-idf>`_, the
@ -307,7 +307,7 @@ of flash will not be sufficient to recover most flash contents.
.. warning:: After enabling Flash Encryption, an encryption key is generated internally by the device and
cannot be accessed by the user for re-encrypting data and re-flashing the system, hence it will be permanently encrypted.
Re-flashing an encrypted system is complicated and not always possible. You can find more information about the ESP32-S2's Flash Encryption
`here <https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/security/flash-encryption.html>`_.
`here <https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/security/flash-encryption.html>`__.
Prerequisites
-------------
@ -360,7 +360,7 @@ the `MCUboot porting guide <https://github.com/mcu-tools/mcuboot/blob/main/docs/
After you developed an application which implements all desired functions, you need to flash it into the primary image slot
of the device (it will automatically be in the confirmed state, you can learn more about image
confirmation `here <https://docs.mcuboot.com/design.html#image-swapping>`_).
confirmation `here <https://docs.mcuboot.com/design.html#image-swapping>`__).
To flash to the primary image slot, select ``Application image primary slot`` in
:menuselection:`System Type --> Application Image Configuration --> Target slot for image flashing`
and compile it using ``make -j ESPSEC_KEYDIR=~/signing_keys``.

239
Documentation/platforms/xtensa/esp32s3/boards/esp32s3-devkit/index.rst
View File

@ -30,8 +30,8 @@ It will show up as /dev/ttyUSB[n] where [n] will probably be 0.
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled Boot and EN. The EN button is not available
to software. It pulls the chip enable line that doubles as a reset line.
@ -41,8 +41,8 @@ pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
LEDs
----
Board LEDs
----------
There are several on-board LEDs for that indicate the presence of power
and USB activity. None of these are available for use by software.
@ -50,8 +50,98 @@ and USB activity. None of these are available for use by software.
Configurations
==============
.. tip:: Please check commonly used configurations for
:ref:`ESP32-S3 Peripherals <esp32s3_peripheral_support>`
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32s3-devkit:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
buttons
-------
This configuration shows the use of the buttons subsystem. It can be used by executing
the ``buttons`` application and pressing on any of the available board buttons::
nsh> buttons
buttons_main: Starting the button_daemon
buttons_main: button_daemon started
button_daemon: Running
button_daemon: Opening /dev/buttons
button_daemon: Supported BUTTONs 0x01
nsh> Sample = 1
Sample = 0
coremark
--------
This configuration sets the CoreMark benchmark up for running on the maximum
number of cores for this system. It also enables some optimization flags and
disables the NuttShell to get the best possible score.
.. note:: As the NSH is disabled, the application will start as soon as the
system is turned on.
cxx
---
Development enviroment ready for C++ applications. You can check if the setup
was successfull by running ``cxxtest``::
nsh> cxxtest
Test ofstream ================================
printf: Starting test_ostream
printf: Successfully opened /dev/console
cout: Successfully opened /dev/console
Writing this to /dev/console
Test iostream ================================
Hello, this is only a test
Print an int: 190
Print a char: d
Test std::vector =============================
v1=1 2 3
Hello World Good Luck
Test std::map ================================
Test C++17 features ==========================
File /proc/meminfo exists!
Invalid file! /invalid
File /proc/version exists!
i2c
---
This configuration can be used to scan and manipulate I2C devices.
You can scan for all I2C devices using the following command::
nsh> i2c dev 0x00 0x7f
knsh
----
This is identical to the nsh configuration except that (1) NuttX
is built as PROTECTED mode, monolithic module and the user applications
are built separately and, as a consequence, (2) some features that are
only available in the FLAT build are disabled.
Protected Mode support for ESP32-S3 relies on the World Controller (WC)
and Permission Control (PMS) peripherals for implementing isolation
between Kernel and Userspace.
By working together with the MMU and Static MPUs of the ESP32-S3, the WC/PMS
is able to restrict the application access to peripherals, on-chip
memories (Internal ROM and Internal SRAM) and off-chip memories (External
Flash and PSRAM).
.. warning:: The World Controller and Permission Control **do not** prevent
the application from accessing CPU System Registers.
mcuboot_nsh
-----------
Similar configuration as nsh, except that it enables booting from
MCUboot and the experimental features configuration.
You can find more information on the `example's documentation <https://github.com/apache/nuttx-apps/blob/master/examples/mcuboot/swap_test/README.md>`_.
nsh
---
@ -59,8 +149,137 @@ nsh
Basic NuttShell configuration (console enabled in UART0, exposed via
USB connection by means of CP2102 converter, at 115200 bps).
mcuboot_nsh
-----------
oneshot
-------
Similar configuration as nsh, except that it enables booting from
MCUboot and the experimental features configuration.
This config demonstrate the use of oneshot timers present on the ESP32-S3.
To test it, just run the ``oneshot`` example::
nsh> oneshot
Opening /dev/oneshot
Maximum delay is 4294967295999999
Starting oneshot timer with delay 2000000 microseconds
Waiting...
Finished
pwm
---
This configuration demonstrates the use of PWM through a LED connected to GPIO2.
To test it, just execute the ``pwm`` application::
nsh> pwm
pwm_main: starting output with frequency: 10000 duty: 00008000
pwm_main: stopping output
random
------
This configuration shows the use of the ESP32-S3's True Random Number Generator with
entropy sourced from Wi-Fi and Bluetooth noise.
To test it, just run ``rand`` to get 32 randomly generated bytes::
nsh> rand
Reading 8 random numbers
Random values (0x3ffe0b00):
0000 98 b9 66 a2 a2 c0 a2 ae 09 70 93 d1 b5 91 86 c8 ..f......p......
0010 8f 0e 0b 04 29 64 21 72 01 92 7c a2 27 60 6f 90 ....)d!r..|.'`o.
smp
---
Another NSH configuration, similar to nsh, but also enables
SMP operation. It differs from the nsh configuration only in these
additional settings:
SMP is enabled::
CONFIG_SMP=y
CONFIG_SMP_NCPUS=2
CONFIG_SPINLOCK=y
The apps/testing/smp test is included::
CONFIG_TESTING_SMP=y
CONFIG_TESTING_SMP_NBARRIER_THREADS=8
CONFIG_TESTING_SMP_PRIORITY=100
CONFIG_TESTING_SMP_STACKSIZE=2048
spiflash
--------
This config tests the external SPI that comes with the ESP32-S3 module connected
through SPI1.
By default a SmartFS file system is selected.
Once booted you can use the following commands to mount the file system::
nsh> mksmartfs /dev/smart0
nsh> mount -t smartfs /dev/smart0 /mnt
Note that mksmartfs is only needed the first time.
sta_softap
----------
With this configuration you can run these commands to be able
to connect your smartphone or laptop to your board::
nsh> ifup wlan1
nsh> dhcpd_start wlan1
nsh> wapi psk wlan1 mypasswd 3
nsh> wapi essid wlan1 nuttxap 1
In this case, you are creating the access point ``nuttxapp`` in your board and to
connect to it on your smartphone you will be required to type the password ``mypasswd``
using WPA2.
The ``dhcpd_start`` is necessary to let your board to associate an IP to your smartphone.
tickless
--------
This configuration enables the support for tickless scheduler mode.
timer
-----
This config test the general use purpose timers. It includes the 4 timers,
adds driver support, registers the timers as devices and includes the timer
example.
To test it, just run the following::
nsh> timer -d /dev/timerx
Where x in the timer instance.
wifi
----
Enables Wi-Fi support. You can define your credentials this way::
$ make menuconfig
-> Application Configuration
-> Network Utilities
-> Network initialization (NETUTILS_NETINIT [=y])
-> WAPI Configuration
Or if you don't want to keep it saved in the firmware you can do it
at runtime::
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0
watchdog
--------
This config test the watchdog timers. It includes the 2 MWDTS,
adds driver support, registers the WDTs as devices and includes the watchdog
example.
To test it, just run the following::
nsh> wdog -i /dev/watchdogx
Where x is the watchdog instance.

21
Documentation/platforms/xtensa/esp32s3/boards/esp32s3-eye/index.rst
View File

@ -26,17 +26,20 @@ Features
Configurations
==============
All of the configurations presented below can be tested by running the following commands::
$ ./tools/configure.sh esp32s3-eye:<config_name>
$ make flash ESPTOOL_PORT=/dev/ttyUSB0 -j
Where <config_name> is the name of board configuration you want to use, i.e.: nsh, buttons, wifi...
Then use a serial console terminal like ``picocom`` configured to 115200 8N1.
nsh
---
Basic NuttShell configuration (console enabled in USB JTAG SERIAL Device, exposed via
USB connection at 9600 bps).
You can configure this board profile this way:
$ cd nuttxspace/nuttx
$ ./tools/configure.sh esp32s3-eye:nsh
Flashing
========
@ -63,8 +66,8 @@ You can use minicom with /dev/ttyACM0 port at 9600 8n1 or picocom this way:
Buttons and LEDs
================
Buttons
-------
Board Buttons
-------------
There are two buttons labeled BOOT and RST. The RST button is not available
to software. It pulls the chip enable line that doubles as a reset line.
@ -74,8 +77,8 @@ pin to determine whether the chip boots normally or into the serial
bootloader. After reset, however, the BOOT button can be used for software
input.
LEDs
----
Board LEDs
----------
There are several on-board LEDs for that indicate the presence of power
and USB activity. None of these are available for use by software.

51
Documentation/platforms/xtensa/esp32s3/index.rst
View File

@ -89,36 +89,37 @@ The following list indicates the state of peripherals' support in NuttX:
========== ======= =====
Peripheral Support NOTES
========== ======= =====
GPIO Yes
UART Yes
SPI Yes
I2C No
ADC No
AES No
Bluetooth No
CAMERA No
CAN/TWAI No
DMA Yes
Wi-Fi Yes WPA3-SAE supported
eFuse No
GPIO Yes
I2C No
I2S No
LCD No
LED_PWM No
MCPWM No
Pulse_CNT No
RMT No
RNG No
RSA No
RTC No
SD/MMC No
SDIO No
SHA No
SPI Yes
SPIFLASH Yes
SPIRAM Yes
Timers Yes
Watchdog Yes
RTC No
RNG No
AES No
eFuse No
ADC No
Bluetooth No
SDIO No
SD/MMC No
I2S No
LCD No
CAMERA No
LED_PWM No
RMT No
MCPWM No
Pulse_CNT No
SHA No
RSA No
USB SERIAL Yes
Touch Yes
UART Yes
USB OTG No
USB SERIAL Yes
Watchdog Yes
Wi-Fi Yes WPA3-SAE supported
========== ======= =====
.. _esp32s3_peripheral_support:
@ -126,7 +127,7 @@ USB OTG No
Wi-Fi
-----
.. tip:: Boards usually expose a ``wapi`` defconfig which enables Wi-Fi
.. tip:: Boards usually expose a ``wifi`` defconfig which enables Wi-Fi
A standard network interface will be configured and can be initialized such as::