Assertions for uninitialized locks must not be triggered as long as the scheduler is not running. Furthemore, the handling of the __malloc_static_object lock is only necessary for ESP8266.
The directory `dist/tools/esptool` already contains a couple of ESP tools and not only esptool.py. As the location for a couple of ESP related tools, it is more clear to call it `esptools` instead of `esptool`.
Module `esp_idf_nvs_flash` uses C++ code. Since `esp_idf_nvs_flash` module is always enabled on ESP8266, the permanent dependency on `cpp` is correct. But on ESP32, the `esp_idf_nvs_flash` module is only enabled if `esp_wifi_any` is used. Only in that case the compilation should depend on module `cpp`.
The vendor binary libraries of ESP-IDF are provided as a separate GIT repository. These libraries are defined as separate package for two reasons: 1. RIOT packages don't support to clone GIT repositories recursively; 2. ESP-IDF pulls a lot of other GIT repositories that are not needed when it is cloned recursively.
Previously, a default value for ESP_WIFI_PASS was intentionally defined only if DOXYGEN was also defined, to allow ESP_WIFI_PASS to be left undefined for using APs without authentication. With PR #17415 the definition was changed to always define a default value for EPS_WIFI_PASS. This made it impossible to use APs without authentication. The commit reverts this change.
The semantics of defining an SSID prefix that overrides the already defined SSID exactly when and only when it is set, and then enabling dynamic SSID generation with that prefix, made handling the parameter definition unnecessarily difficult and hard to understand.
Defining a boolean option that enables dynamic SSID generation, which then simply reuses the defined SSID as a prefix, makes it much more understandable and easier to handle, especially with respect to Kconfig.
On the ESP32 it is often not possible with the I2C software implementation to communicate with an AIP31068 based LCD module. Therefore, the I2C hardware implementation is enabled when the AIP31068 driver is used, but it is more buggy than stable. The timing of the two implementations seems to be almost identical. The only difference is that the hardware implementation clears the bus before each access by sending 10 clock pulses on the SCL line while SDA is LOW. Using the same mechanism during I2C initialization for the software implementation solves the communication problem with the AIP31068.
The same software implementation works reliably with the AIP31068 on the ESP8266.
cpu/esp_common/syscalls.c💯 error (memleak): Memory leak: mtx
cpu/esp_common/syscalls.c:131: error (memleak): Memory leak: rmtx
cpu/esp_common/syscalls.c:365: error (comparePointers): Subtracting pointers that point to different objects
cpu/esp_common/thread_arch.c:355: error (comparePointers): Comparing pointers that point to different objects
cpu/esp8266/startup.c:59: error (comparePointers): Subtracting pointers that point to different objects
RIOT-OS uses part of Espressif ESP8266 RTOS SDK to build support for
this CPU. The SDK includes some vendor-provided closed source
pre-compiled libraries that we need to modify to adapt to RIOT-OS
usage. This library modifications was done once and uploaded to a fork
of the vendor repository and was provided as an environment variable.
This patch changes two things:
1. It installs the SDK as a RIOT PKG from the new pkg/esp8266_sdk
directory instead of requiring the user to download it separately.
2. It performs the library modifications (symbol renames) on the pkg
Makefile removing the need to use a fork with the modifications applied
and simplifying the SDK update and future modifications.
This change sets the SDK package version (git SHA) to the same one that
our fork was using as a parent in the vendor repository, meaning that
the output libraries are exactly the same as before.
Tested with
```
ESP8266_RTOS_SDK_DIR=/dev/null USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
and verified that the program works. The boot message now includes:
```
ESP8266-RTOS-SDK Version v3.1-51-g913a06a9
```
confirming the SDK version used.
`/dev/null` in the test is just to make sure that no evaluation of
`ESP8266_RTOS_SDK_DIR` in make is affected by the environment variable
value which would be set to the SDK for people who followed the set up
instructions before this change.
Tested the checkout size:
```bash
$ du -hs build/pkg/esp8266_sdk/
124M build/pkg/esp8266_sdk/
```
If esp_idf_heap is not used, implement calloc through a custom wrapper
function on top of malloc to add overflow detection, which is not
present in the newlib forks with xtensa support yet.
The esp8266 CPU has actually two hardware UART peripherals. UART0 is
used by the boot ROM for flashing and serial output during boot,
typically at a baudrate of 74880 bps until the bootloader or application
sets the more standard 115200 baudrate. This UART0 device has two
possible pins for TXD, GPIO1 and GPIO2, which are both set to TXD by the
boot ROM. esp8266 modules will typically have GPIO1 labeled as the TX
pin, but it is possible to use GPIO2 for that purpose even while
flashing the device with esptool.py.
The second device, UART1, also has two options for TXD, GPIO2 and GPIO7,
and only one option for RXD, GPIO8. However, GPIO7 and GPIO8 are used
by the flash internally so those options are not very useful unless
maybe while running from IRAM with the flash disabled, for example for
a debugger over UART1.
This patch allows boards to override UART{0,1}_{R,T}XD in their
periph_conf.h to configure the uart selection. Defining UART1_TX will
make the UART_DEV(1) device available.
Tested with:
```CFLAGS='-DUART1_TXD=GPIO2' make -C tests/periph_uart BOARD=esp8266-esp-12x flash term```
* Connected one USB-UART to the standard GPIO1 and GPIO3 for flashing
and console. After flashing we see the manual test output at 115200
bps
* Connected a second USB-UART with RX to GPIO2 running at 74880.
Then run on the first console:
```
> init 1 74880
> send 1 hello
```
The word "hello" appears on the second UART connection.
Note that GPIO2 is used during boot for UART0's TX until the application
or bootloader set it to a regular GPIO, so some boot ROM messages at
74880 bps are visible. After running `init 1 74880` it is set to UART1's
TX.
In I2C, clock stretching occurs when the controller stops driving SCL
down but the peripheral continues to drive SCL down until the value of
SDA that is expected to be set by the peripheral is ready. This allows a
peripheral to communicate at a high speed but introduce a delay in the
response (like an ACK or read) in some specific situations. Not all I2C
peripherals require I2C stretching, and in many cases SCL is only an
input to these peripherals.
Clock stretching is the only situation where a peripheral may drive down
SCL, which technically makes SCL an open-drain with a pull-up like SDA.
However, if clock stretching is not needed, SCL can be configured as an
output removing the need for a pull-up and specially, allowing to use
as SCL GPIO pins that otherwise have a pull-down connected. In
particular, GPIO15 in the ESP8266 requires an external pull-down during
boot for the ESP8266 to boot from the flash.
This patch allows a board to define `I2C_CLOCK_STRETCH` to 0 to disable
clock stretching and allowing to use GPIO15 as SCL.
- Add `WORD_ALIGNED` attribute to potentially unaligned allocations
- Use intermediate cast to `uintptr_t` to silence false positives of
`-Wcast-align`
This is an implementation of the ESP32 SoftAP mode using the
`esp_wifi_ap` pseudomodule.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Declare sched_active_thread and sched_active_pid locally in the ESP code for
now. Once the code is cleaned up to no longer tap into scheduler internals but
use the API instead, those can be dropped again.
- Add libstdcpp feature to indicate a platform is providing a libstdc++
implementation ready for use
- The existing cpp feature now only indicates a working C++ toolchain without
libstdc++. (E.g. still useful for the Arduino compatibility layer.)
- Added libstdcpp as required feature were needed
- Added some documentation on C++ on RIOT
>All of them are features of each ESP SoC and have not to be configured by the
board definition.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
There are common features that can be used by ESP32 as well as ESP8266, for example the `esp_wifi` module. To be able to test for any ESP SoC, feature `arch_esp` is introduced.
Flashing an ESP board first requires the creation of a flash image from the ELF file. This is realized in the `preflash` target. However, the `preflash` target only depends on the variable `BUILD_BEFORE_FLASH` but on the ELF file. Therefore, the variable `BUILD_BEFORE_FLASH` must be set to the ELF file to ensure that when using multiple make processes, the compilation of the ELF file is completed before the flash image is created.
GPIO32 and GPIO33 are used during boot to start an 32.768 kHz XTAL if it is connected to these GPIOs. If the 32.768 kHz XTAL is not connected, these pins can be used digital IO. However, the 32.678 kHz XTAL has to be disabled explicitly in this case. Furthermore, the handling of GPIOs greater than GPIO31 had to be fixed in I2C software implementation.
Due to stability reasons, the SoftAP interface of the WiFi module was always enabled in former versions even if only the station interface was used. Therefore the WiFi modem had to be always active and the SoC could not enter the modem sleep mode. Therefore, the SoftAP interface is only enabled when ESP-NOW is used.
The WiFi interface should be stopped before reboot or sleep. But stopping the WiFi interface disconnects an existing connection. Usually, esp_wifi_netdev tries to reconnect on an disconnect event. However, trying reconnect with a stopped WiFi interface may lead to a crash. Therefore, the stop event has to be handled.
