| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Signed-off-by: Vdragon <mail@massdriver.space>
|
| |
|
|
|
|
| |
Add docs for PWM support.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Updates the Zephyr port build instructions. The CI is updated to use
Zephyr docker image 0.27.4, SDK 0.17.0 and the latest Zephyr release
tag.
Tested on max32690fthr and frdm_k64f.
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
Signed-off-by: Detlev Zundel <dzu@member.fsf.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
|
| |
|
|
|
|
|
|
|
| |
Updates the Zephyr port build instructions and CI to use the latest
Zephyr release tag.
Tested on frdm_k64f.
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
|
| |
|
|
|
|
|
|
|
|
| |
Zephyr v3.2.0 deprecated the devicetree label property as a base
property, which had been used as the device name string for
device_get_binding(). The device name string is now the devicetree node
name appended with its unit-address. Update Zephyr port documentation
to reflect this change.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
|
| |
|
|
| |
Signed-off-by: Damien George <damien@micropython.org>
|
| |
|
|
| |
Signed-off-by: Damien George <damien@micropython.org>
|
| |
|
|
|
|
|
|
|
| |
- Update guide for extending built-in modules.
- Remove any last trace of umodule in other docs.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
| |
|
|
| |
Signed-off-by: Damien George <damien@micropython.org>
|
| |
|
|
| |
Signed-off-by: enriquezgarc <enriquezgarcia.external@infineon.com>
|
| |
|
|
|
|
|
|
|
| |
Updates the Zephyr port build instructions and CI to use the latest Zephyr
release tag.
Tested on frdm_k64f.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
|
| |
|
|
|
|
|
| |
Updates the Zephyr port build instructions and CI to use the latest
Zephyr release tag.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
|
| |
|
|
|
|
|
| |
Updates the Zephyr port build instructions and CI to use the latest
Zephyr release tag.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Anywhere a module is mentioned, use its "non-u" name for consistency.
The "import module" vs "import umodule" is something of a FAQ, and this
commit intends to help clear that up. As a first approximation MicroPython
is Python, and so imports should work the same as Python and use the same
name, to a first approximation. The u-version of a module is a detail that
can be learned later on, when the user wants to understand more and have
finer control over importing.
Existing Python code should just work, as much as it is possible to do that
within the constraints of embedded systems, and the MicroPython
documentation should match the idiomatic way to write Python code.
With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users
can consistently use "import foo" across all ports (with the exception of
the minimal ports). And the ability to override/extend via "foo.py"
continues to work well.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
|
Includes an introduction to using the Zephyr port on MicroPython. The
quickref details examples of how to use each module the port currently
supports. The tutorial provides additional details for Zephyr specific
modules.
Signed-off-by: Julia Hathaway <julia.hathaway@nxp.com>
|
