Most pin I/O can be done just knowing the pin number as a simple
integer, and it's more efficient this way (code size, speed) because it
doesn't require a memory lookup to get the pin id from the pin object.
If the full pin object is needed then it can be easily looked up in the
pin table.
Qstr auto-generation is now much faster so this optimisation for start-up
time is no longer needed. And passing "-s -S" breaks some things, like
stmhal's "make deploy".
The L4 MCU supports 40 Events/IRQs lines of the type configurable and
direct. But this L4 port only supports configurable line types which are
already supported by uPy. For details see page 330 of RM0351, Rev 1.
The USB_FS_WAKUP event is a direct type and there is no support for it.
__GPIOI_CLK_ENABLE is defined in hal/l4/inc/Legacy/stm32_hal_legacy.h
as __HAL_RCC_GPIOI_CLK_ENABLE, and that latter macro is not defined
anywhere else (because the L4 does not have port GPIOI). So the test
for GPIOI is needed, along with the test for the CLK_ENABLE macro.
Use the machine.deepsleep() function to enter the sleep mode. Use the
RTC to configure the alarm to wake the device.
Basic use is the following:
import machine
# configure RTC's ALARM0 to wake device from deep sleep
rtc = machine.RTC()
rtc.irq(trigger=rtc.ALARM0, wake=machine.DEEPSLEEP)
# do other things
# ...
# set ALARM0's alarm to wake after 10 seconds
rtc.alarm(rtc.ALARM0, 10000)
# enter deep-sleep state (system is reset upon waking)
machine.deepsleep()
To detect if the system woke from a deep sleep use:
if machine.reset_cause() == machine.DEEPSLEEP_RESET:
print('woke from deep sleep')
Flash size as seen by vendor SDK doesn't depend on real size, but rather on
a particular value in firmware header, as put there by flash tool. That means
it's user responsibility to know what flash size a particular device has, and
specify correct parameters during flashing. That's not end user friendly
however, so we try to make it "flash and play" by detecting real size vs
from-header size mismatch, and correct the header accordingly.
E.g. for stmhal, accumulated preprocessed output may grow large due to
bloated vendor headers, and then reprocessing tens of megabytes on each
build make take couple of seconds on fast hardware (=> potentially dozens
of seconds on slow hardware). So instead, split once after each change,
and only cat repetitively (guaranteed to be fast, as there're thousands
of lines involved at most).
If make -B is run, the rule is run with $? empty. Extract fron all file in
this case. But this gets fragile, really "make clean" should be used instead
with such build complexity.
When there're C files to be (re)compiled, they're all passed first to
preprocessor. QSTR references are extracted from preprocessed output and
split per original C file. Then all available qstr files (including those
generated previously) are catenated together. Only if the resulting content
has changed, the output file is written (causing almost global rebuild
to pick up potentially renumbered qstr's). Otherwise, it's not updated
to not cause spurious rebuilds. Related make rules are split to minimize
amount of commands executed in the interim case (when some C files were
updated, but no qstrs were changed).
A port which uses lib/utils/pyexec.c but which does not enable garbage
collection should not need to implement the gc_collect function.
This patch also moves the gc_collect call to after printing the qstr
info. Since qstrs cannot be collected it should not make any difference
to the printed statistics.
Paul Sokolovsky