In Asynchronous Fractional baud rate mode, the baud rate can not be
greater than the source frequency divided by the oversampling (8, 16).
Currently we are always using 16x oversampling.
This makes it impossible to e.g. set a 2 MHz UART baud rate on the 16 MHz
`saml10-xpro`.
With this change, the oversampling is automatically reduced to 8x which
allows us to set 16 MHz / 8 -> 2 MHz baud rate.
Unaligned accesses on x86(_64) are allowed, but slow. However, some host systems
might not be that forgiving. Aligning the stack to sizeof(uintptr_t) should be
a pretty safe safety measure.
And with this done, all casts of the stack pointer that increase alignment
requirements are now intermediately casted to `uintptr_t` to silence
warnings from -Wcast-align - after all the stacks are now manually aligned.
Make sure in `_usbdev_new_ep()` that `usbdev_ep_t::buf` is always aligned to 4
bytes. With this in mind, add intermediate casts to `uintptr_t` before casting
`usbdev_ep_t::buf` to `uint32_t *` to silence `-Wcast-align`, as we now manually
enforced correct alignment.
The IRAM is much faster, while the IROM is much slower and can only be accessed via a cache, which is also sometimes disabled, e.g. by the WiFi module or when writing to the flash. Therefore, time-critical code as well as code that has to work even when the cache is disabled must be placed in the IRAM.
The functions of the `esp*/freetos` libraries must be placed in IRAM because they can be called when the IROM cache is disabled. While the functions implemented in `cpu/esp8266/freetos/*.c` are already placed in IRAM, the functions implemented in `cpu/esp_common/freetos/*.c` are not placed in IRAM. The reason for this is that the object files of these files are created in the `esp_freertos_common` directory, which is not included in the `esp.riot-os.ld` file because the library is named `esp_freertos_common`.
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/
```
Checksumming flash is not supported on xtensa platform:
Warn : not implemented yet
make: *** [.../RIOT/examples/saul/../../Makefile.include:796: flash] Error 1
https://github.com/espressif/openocd-esp32 is needed.
Example config (when compiled from source):
export OPENOCD="~/esp/openocd-esp32/src/openocd -s ~/esp/openocd-esp32/tcl"
The xfa.ld script is incompatible with binutils > 2.35.2 and results
in firmwares that wont boot. Sadly, I couldn't figure out an elegant
way to fix the issue. Instead, I modified the linker script provided
by binutils to also include XFA.
core_panic() doesn't expect the message to be in program memory, but
in data memory. Bad things will happen on AVR when the address is
interpreted as being in data address space, but the allocation is
done in program address space.
