Instead of checking each callback (currently storage and dma) explicitly
for each SysTick IRQ, use a simple circular function table indexed by the
lower bits of the millisecond tick counter. This allows callbacks to be
easily enabled/disabled at runtime, and scales well to a large number of
callbacks.
This is a good board to demonstrate the use of Mboot because it only has a
USB HS port exposed so the native ST DFU mode cannot be used. With Mboot
this port can be used.
If a custom bootloader is enabled (eg mboot) then machine.bootloader() will
now enter that loader. To get the original ST DFU loader pass any argument
to the function, like machine.bootloader(1).
Don't exclude the Timer instance 1 entry from machine_timer_obj[] when
using soft PWM. The usage is already checked when creating the Timer,
so just create an empty entry.
If needed these parameters can be added back and made functional one at a
time. It's better to explicitly not support them than to silently allow
but ignore them.
Python defines warnings as belonging to categories, where category is a
warning type (descending from exception type). This is useful, as e.g.
allows to disable warnings selectively and provide user-defined warning
types. So, implement this in MicroPython, except that categories are
represented just with strings. However, enough hooks are left to implement
categories differently per-port (e.g. as types), without need to patch each
and every usage.
With clock bypass enabled the attached SD card is clocked at the maximum
48MHz. But some SD cards are unreliable at these rates. Although it's
nice to have high speed transfers it's more important that the transfers
are reliable for all cards. So disable this clock bypass option.
This way the UART REPL does not need the MicroPython heap and exists
outside the MicroPython runtime, allowing characters to still be received
during a soft reset.
Auto-detection of the crystal frequency is convenient and allows for a
single binary for many different boards. But it can be unreliable in
certain situations so in production, for a given board, it's recommended to
configure the correct fixed frequency.
Configuration for the build is now specified using sdkconfig rather than
sdkconfig.h, which allows for much easier configuration with defaults from
the ESP IDF automatically applied. sdkconfig.h is generated using the new
ESP IDF kconfig_new tool written in Python. Custom configuration for a
particular ESP32 board can be specified via the make variable SDKCONFIG.
The esp32.common.ld file is also now generated using the standard ESP IDF
ldgen.py tool.
When the ESP IDF builds a project it puts all separate components into
separate .a library archives. And then the esp32.common.ld linker script
references these .a libraries by explicit name to put certain object files
in iRAM.
This patch does a similar thing for the custom build system used here,
putting all IDF .o's into their respective .a. So a custom linker script
is no longer needed.
ISR's no longer need to be in iRAM, and the ESP IDF provides an option to
specify that they are in iRAM if an application needs lower latency when
handling them. But we don't use this feature for user interrupts: both
timer and gpio ISR routines are registered without the ESP_INTR_FLAG_IRAM
option, and so the scheduling code no longer needs to be in iRAM.
The new compile-time option is MICROPY_HW_USB_MAX_POWER_MA. Set this in
the board configuration file to the maximum current in mA that the board
will draw over USB. The default is 500mA.
The new compile-time option is MICROPY_HW_USB_SELF_POWERED. Set this
option to 1 in the board configuration file to indicate that the USB device
is self powered. This option is disabled by default (previous behaviour).
It can be that LSEON and LSERDY are set yet the RTC is not enabled (this
can happen for example when coming out of the ST DFU mode on an F405 with
the RTC not previously initialised). In such a case the RTC is never
started because the code thinks it's already running. This patch fixes
this case by always checking if RTCEN is set when booting up (and also
testing for a valid RTCSEL value in the case of using an LSE).
One can't use pthread calls in a signal handler because they are not
async-signal-safe (see man signal-safety). Instead, sem_post can be used
to post from within a signal handler and this should be more efficient than
using a busy wait loop, waiting on a volatile variable.