Update docs/library/espnow.rst to add:
- guidance on using WLAN.config(pm=WLAN.PM_NONE) for reliable
espnow performance while also connected to a wifi access point;
- guidance on receiving encrypted messages;
- correction for default value of "encrypt" parameter (add_peer());
- guidance on use of ESPNow.irq(): recommand users readout all messages
in the buffer each time the callback is called.
Signed-off-by: Glenn Moloney <glenn.moloney@gmail.com>
The code that handles inplace-operator to normal-binary-operator fallback
is moved in this commit from py/objtype.c to py/runtime.c, making it apply
to all types, not just user classes.
Signed-off-by: Damien George <damien@micropython.org>
So that user types can implement reverse operators and have them work with
str on the left-hand-side, eg `"a" + UserType()`.
Signed-off-by: Damien George <damien@micropython.org>
This adds a unary_op implementation for the dict_view type that makes
the implementation of `hash()` for these types compatible with CPython.
Signed-off-by: David Lechner <david@pybricks.com>
As per https://bugs.python.org/issue408326, the slice object should not be
hashable. Since MicroPython has an implicit fallback when the unary_op
slot is empty, we need to fill this slot.
Signed-off-by: David Lechner <david@pybricks.com>
Since converting to variable sized slots in mp_obj_type_t, we can now
reduce the code size a bit by removing mp_generic_unary_op() and the
corresponding slots where it is used. Instead we just implement the
generic `__hash__` operation in the runtime.
Signed-off-by: David Lechner <david@pybricks.com>
When the network module was first introduced in the esp8266 port in
ee3fec3167 there was only one interface (STA)
and, to save flash, the WLAN object was aliased to the network module,
which had just static methods for WLAN operations. This was subsequently
changed in 9e8396accb when the AP interface
was introduced, and the WLAN object became a true class.
But, network.WLAN remained a function that returned either the STA or AP
object and was never upgraded to the type itself. This scheme was then
copied over to the esp32 port when it was first introduced.
This commit changes network.WLAN from a function to a reference to the WLAN
type. This makes it consistent with other ports and network objects, and
allows accessing constants of network.WLAN without creating an instance.
Signed-off-by: Damien George <damien@micropython.org>
Previously when using --via-mpy, the file was compiled to tests/<tmp>.mpy
and then run using `micropython -m <tmp>` in the current cwd
(usually tests/). This meant that an import in the test would be resolved
relative to tests/.
This is different to regular (non-via-mpy) tests, where we run (for
example) `micropython basics/test.py` which means that an import would be
resolved relative to basics/.
Now --via-mpy matches the .py behavior. This is important because:
a) It makes it so import tests do the right thing.
b) There are directory names in tests/ that match built-in module names.
Furthermore, it always ensures the cwd (for both micropython and cpython)
is the test directory (e.g. basics/) rather than being left unset. This
also makes it clearer inside the test that e.g. file access is relative to
the Python file.
Updated tests with file paths to match.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Building the Pico-W needs the MICROPY_PY_NETWORK_CYW43 flag to be set in
order to include building the CYW43 Wifi driver. But then mp_hal_get_mac()
handles the MAC assignment for all nics the "CYW43 way", copying the real
MAC provided by the WiFi hardware. This will fail for all other NIC types,
resulting in an invalid MAC address.
The solution in this commit is to add a check for the NIC type parameter
idx and handle the MAC address respectively.
Convert to an absolute path to always reliably locate manifest.py. This is
already done in Makefile, but is also needed in CMakeLists.txt if cmake is
invoked directly.
Signed-off-by: Phil Howard <phil@pimoroni.com>
Currently rp2.StateMachine.exec(instr_in) requires that the instr_in
parameter be a string representing the PIO assembly language instruction
to be encoded by rp2.asm_pio_encode(). This commit allows the parameter
to also be of integral type. This is useful if the exec() method is
being called often where the use of pre-encoded machine code is
desireable.
This commit still supports calls like:
sm.exec("set(0, 1)")
It also now supports calls like:
# Performed once earlier, maybe in __init__()
assembled_instr = rp2.asm_pio_encode("out(y, 8)", 0)
# Performed multiple times later as the PIO state machine is
# configured for its next run.
sm.exec(assembled_instr)
The existing examples/rp2/pio_exec.py and examples/rp2/pio_pwm.py that
exercise the rp2.StateMachine.exec() method still work with this change.
Signed-off-by: Adam Green <adamgrym@yahoo.com>
FSP v4.4.0 refers to CMSIS V5.4.1, and __COMPILER_BARRIER() is used in bsp.
On the other hand, lib/cmsis is V5.1.0 and the macro is not defined.
Therefore, compile error happens.
As the workaround, the macro definition is added.
If lib/cmsis is updated in the future, this addition can be removed.
Signed-off-by: Takeo Takahashi <takeo.takahashi.xv@renesas.com>
This modifies the windows port Makefile to use += for QSTR_DEFS and
QSTR_GLOBAL_DEPENDENCIES so that variants can add additional files if
needed (similar to stm32 port).
Signed-off-by: David Lechner <david@pybricks.com>
This modifies the unix port Makefile to use += for QSTR_DEFS and
QSTR_GLOBAL_DEPENDENCIES so that variants can add additional files if
needed (similar to stm32 port).
Signed-off-by: David Lechner <david@pybricks.com>
This documents when MPY v6.1 was released.
Also add some clarification on how the version is encoded in the header.
Signed-off-by: David Lechner <david@pybricks.com>
This does not align with the other pre-commit jobs with are local custom
code but it should run accurately and quickly.
Signed-off-by: Christian Clauss <cclauss@me.com>
It was treated as an error before. The error surfaced when using the
NINAW10 drivers for WiFi support. Even if this is a bad behavior of the
NINA driver, machine_spi can be forgiving in that situation.
Separate low level flash access from mimxrt flash driver object. Allows
better abstraction from hardware for testing and reuse in other areas (e.g.
bootloader).
Signed-off-by: Philipp Ebensberger <philipp.ebensberger@3bricks-software.de>
Changes in this commit:
- Add MICROPY_GC_HOOK_LOOP to gc_info() and gc_alloc(). Both of these can
be long running (many milliseconds) which is too long to be blocking in
some applications.
- Pass loop variable to MICROPY_GC_HOOK_LOOP(i) macro so that implementers
can use it, e.g. to improve performance by only calling a function every
X number of iterations.
- Drop outer call to MICROPY_GC_HOOK_LOOP in gc_mark_subtree().
For esp32 and esp8266 this commit adds:
- a 'pm' option to WLAN.config() to set/get the wifi power saving mode; and
- PM_NONE, PM_PERFORMANCE and PM_POWERSAVE constants to the WLAN class.
This API should be general enough to use with all WLAN drivers.
Documentation is also added.
All ports that enable MICROPY_PY_MACHINE_PWM now enable these two
sub-options, so remove these sub-options altogether to force consistency in
new ports that implement machine.PWM.
Signed-off-by: Damien George <damien@micropython.org>
Changes in this commit:
- Limit duty_u16() to 65535 and duty_ns() to the period duration.
- Return 0 for pwm.freq() if the frequency has not been set yet.
- Return 0 for pwm.duty_us16() and duty_ns() unless both frequency and
duty cycle have been set.
- Initialize the pin to PWM at the very end of the constructor, to avoid
possible glitches on the pin when setting up the PWM.
This adds the freq and duty_u16 keyword settings to the constructor, and
sometimes other details in the PWM section.
For mimxrt a clarification regarding the PWM invert argument was added, and
for rp2 a few words were spent on PWM output pairs of a channel/slice.
This adds support for freq/duty_u16/duty_ns keyword arguments in the PWM
constructor, and adds the PWM.init() method. Using init() without
arguments enables a previously deinit-ed PWM again.
Further changes in this commit:
- Do not start PWM output if only duty was set.
- Stop all PWM slices on soft-reset.
- Fix a bug when changing the freq on a channel pair with duty_ns set.
The PWM.init() method has been added. Calling init() without arguments
restarts a PWM channel stopped with deinit(). Otherwise single parameters
except for "device=n" can be changed again. The device can only be
specified once, either in the constructor or the first init() call.
Also simplify get_pwm_config() and get_adc_config(), and shrink the PWM
object.
And also fix/improve the following:
- Simplify the duty handling a little bit.
- Allow duty_u16(65536), which sets the output high.
- Rename machine_pwm_start() to mp_machine_pwm_start(), in preparation for
a possible start/stop method pair.
When a tuple is the condition of an if statement, it's only possible to
optimise that tuple away when it is a constant tuple (ie all its elements
are constants), because if it's not constant then the elements must be
evaluated in case they have side effects (even though the resulting tuple
will always be "true").
The code before this change handled the empty tuple OK (because it doesn't
need to be evaluated), but it discarded non-empty tuples without evaluating
them, which is incorrect behaviour (as show by the updated test).
This optimisation is anyway rarely applied because it's not common Python
coding practice to write things like `if (): ...` and `if (1, 2): ...`, so
removing this optimisation completely won't affect much code, if any.
Furthermore, when MICROPY_COMP_CONST_TUPLE is enabled, constant tuples are
already optimised by the parser, so expression with constant tuples like
`if (): ...` and `if (1, 2): ...` will continue to be optimised properly
(and so when this option is enabled the code that's deleted in this commit
is actually unreachable when the if condition is a constant tuple).
Signed-off-by: Damien George <damien@micropython.org>