This commit adds generic support for mutable module attributes on built in
modules, by adding support for an optional hook function for module
attribute lookup. If a module wants to support additional attribute load/
store/delete (beyond what is in the constant, globals dict) then it should
add at the very end of its globals dict MP_MODULE_ATTR_DELEGATION_ENTRY().
This should point to a custom function which will handle any additional
attributes.
The mp_module_generic_attr() function is provided as a helper function for
additional attributes: it requires an array of qstrs (terminated in
MP_QSTRnull) and a corresponding array of objects (with a 1-1 mapping
between qstrs and objects). If the qstr is found in the array then the
corresponding object is loaded/stored/deleted.
Signed-off-by: Damien George <damien@micropython.org>
All variants now use extmod/moduos.c as their uos module implementation.
In particular this means they all have MICROPY_VFS enabled and use VfsPosix
for their filesystem.
As part of this, the available functions in uos become more consistent with
other ports:
- coverage variant gets uos.urandom
- minimal and standard variant get: unlink, chdir, getcwd, listdir
Signed-off-by: Damien George <damien@micropython.org>
From RFC 1950 section 2.2: "CINFO is the base-2 logarithm of the LZ77
window size, minus eight (CINFO=7 indicates a 32K window size)"
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
Ensure the symmetry of PWM: the duty rate of X and Q channels was not 50%,
when it should have been. That is evident at high frequencies, like 15Mhz
or 37.5 MHz. At low frequencies the deviation mattered less. The A/B
channels were fine.
Also round up or down non-integer division factors. Before, always the
floor value was used.
That caused Ethernet to lock up at high data rates after ~200MByte data
average in a row. Tested now with data bursts up to 10 GByte and overall
data rates of ~8MByte/s at the Eth100 port.
Sometimes frames could not be sent immediately because the controller was
still busy with previous frames. Then, an error was returned to lwip.
This fix adds a limited number of retries for this busy state, waiting
100µs before the next attempt. Typically the transmit succeeds now at the
second attempt.
Second change: Reset the controller for a clean state after soft reset.
OCOTP_Init() has been removed from mphalport.c. The library files are
missing for the MIMXRT1015, and for just reading the OCOTP the Init is not
required.
The disk_access header was moved to a different path in Zephyr v2.6.0.
The old path was deprecated for two releases (v2.6.0 and v2.7.0) and
will no longer be supported after Zephyr v2.7.0.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
This adds the "Not relevant" designation to PEP 486 since it has to do with
the Python Launcher for Windows and not the Python language itself.
Also fix a typo while we are touching this line.
Signed-off-by: David Lechner <david@pybricks.com>
If setting the frequency to a value used already by an existing timer, this
timer will be used. But still, the duty cycle for that channel may have to
be changed.
Fixes issues #8306 and #8345.
If MicroPython threads are enabled, loops waiting for an incoming event
should release the GIL and suspend, allowing other tasks to run while they
wait.
Prior to this commit, the problem can easily be observed by running a
thread that is both busy and regularly releases the GIL (for example a loop
doing something then sleeping a few ms after each iteration). When the
main task is at the REPL, the thread is significantly stalled. If the main
task is manually made to release the GIL (for example, by calling
utime.sleep_ms(500)) the other thread can be seen immediately working at
the expected speed again.
Additionally, there are various instances in where blocking functions run
MICROPY_EVENT_POLL_HOOK in a loop while they wait for a certain event/
condition. For example the uselect methods poll objects to determine
whether data is available, but uses 100% of CPU while it does, constantly
calling MICROPY_EVENT_POLL_HOOK in the process.
The MICROPY_EVENT_POLL_HOOK macro is only ever used in waiting loops, where
(if threads are enabled) it makes sense to yield for a single tick so that
these loops do not consume all CPU cycles but instead other threads may
execute. (In fact, the thing these loops wait for may even indirectly or
directly depend on another task being able to run.)
This change moves the sleep that was inside the REPL input function to
inside the MICROPY_EVENT_POLL_HOOK macro, where the GIL is already being
released, solving both the blocking REPL issue and the 100% CPU use issue
at the same time.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
The stack (and arg) of core1 is itself a root pointer, not just the entries
in it. Without this fix the GC could reclaim the entire stack (and
argument object).
Fixes issues #7124 and #7981.
