2017-01-28 09:08:25 +00:00
|
|
|
:mod:`machine` --- functions related to the hardware
|
|
|
|
====================================================
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
.. module:: machine
|
2017-01-28 09:08:25 +00:00
|
|
|
:synopsis: functions related to the hardware
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2017-01-28 09:08:25 +00:00
|
|
|
The ``machine`` module contains specific functions related to the hardware
|
|
|
|
on a particular board. Most functions in this module allow to achieve direct
|
|
|
|
and unrestricted access to and control of hardware blocks on a system
|
|
|
|
(like CPU, timers, buses, etc.). Used incorrectly, this can lead to
|
|
|
|
malfunction, lockups, crashes of your board, and in extreme cases, hardware
|
|
|
|
damage.
|
|
|
|
|
|
|
|
.. _machine_callbacks:
|
|
|
|
|
2017-06-25 11:30:29 +01:00
|
|
|
A note of callbacks used by functions and class methods of :mod:`machine` module:
|
2017-01-28 09:08:25 +00:00
|
|
|
all these callbacks should be considered as executing in an interrupt context.
|
|
|
|
This is true for both physical devices with IDs >= 0 and "virtual" devices
|
|
|
|
with negative IDs like -1 (these "virtual" devices are still thin shims on
|
2017-04-16 08:14:05 +01:00
|
|
|
top of real hardware and real hardware interrupts). See :ref:`isr_rules`.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2022-10-24 10:28:34 +01:00
|
|
|
Memory access
|
|
|
|
-------------
|
|
|
|
|
|
|
|
The module exposes three objects used for raw memory access.
|
|
|
|
|
|
|
|
.. data:: mem8
|
|
|
|
|
|
|
|
Read/write 8 bits of memory.
|
|
|
|
|
|
|
|
.. data:: mem16
|
|
|
|
|
|
|
|
Read/write 16 bits of memory.
|
|
|
|
|
|
|
|
.. data:: mem32
|
|
|
|
|
|
|
|
Read/write 32 bits of memory.
|
|
|
|
|
|
|
|
Use subscript notation ``[...]`` to index these objects with the address of
|
|
|
|
interest. Note that the address is the byte address, regardless of the size of
|
|
|
|
memory being accessed.
|
|
|
|
|
|
|
|
Example use (registers are specific to an stm32 microcontroller):
|
|
|
|
|
|
|
|
.. code-block:: python3
|
|
|
|
|
|
|
|
import machine
|
|
|
|
from micropython import const
|
|
|
|
|
|
|
|
GPIOA = const(0x48000000)
|
|
|
|
GPIO_BSRR = const(0x18)
|
|
|
|
GPIO_IDR = const(0x10)
|
|
|
|
|
|
|
|
# set PA2 high
|
|
|
|
machine.mem32[GPIOA + GPIO_BSRR] = 1 << 2
|
|
|
|
|
|
|
|
# read PA3
|
|
|
|
value = (machine.mem32[GPIOA + GPIO_IDR] >> 3) & 1
|
|
|
|
|
2015-10-14 11:32:01 +01:00
|
|
|
Reset related functions
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
.. function:: reset()
|
|
|
|
|
2016-04-03 18:40:27 +01:00
|
|
|
Resets the device in a manner similar to pushing the external RESET
|
2015-10-14 11:32:01 +01:00
|
|
|
button.
|
|
|
|
|
2020-01-10 01:22:03 +00:00
|
|
|
.. function:: soft_reset()
|
|
|
|
|
|
|
|
Performs a soft reset of the interpreter, deleting all Python objects and
|
|
|
|
resetting the Python heap. It tries to retain the method by which the user
|
|
|
|
is connected to the MicroPython REPL (eg serial, USB, Wifi).
|
|
|
|
|
2016-04-17 15:40:08 +01:00
|
|
|
.. function:: reset_cause()
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2016-04-17 15:40:08 +01:00
|
|
|
Get the reset cause. See :ref:`constants <machine_constants>` for the possible return values.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2021-04-30 07:55:55 +01:00
|
|
|
.. function:: bootloader([value])
|
|
|
|
|
|
|
|
Reset the device and enter its bootloader. This is typically used to put the
|
|
|
|
device into a state where it can be programmed with new firmware.
|
|
|
|
|
|
|
|
Some ports support passing in an optional *value* argument which can control
|
|
|
|
which bootloader to enter, what to pass to it, or other things.
|
|
|
|
|
2016-05-20 13:31:44 +01:00
|
|
|
Interrupt related functions
|
|
|
|
---------------------------
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2022-04-13 12:32:13 +01:00
|
|
|
The following functions allow control over interrupts. Some systems require
|
|
|
|
interrupts to operate correctly so disabling them for long periods may
|
|
|
|
compromise core functionality, for example watchdog timers may trigger
|
|
|
|
unexpectedly. Interrupts should only be disabled for a minimum amount of time
|
|
|
|
and then re-enabled to their previous state. For example::
|
|
|
|
|
|
|
|
import machine
|
|
|
|
|
|
|
|
# Disable interrupts
|
|
|
|
state = machine.disable_irq()
|
|
|
|
|
|
|
|
# Do a small amount of time-critical work here
|
|
|
|
|
|
|
|
# Enable interrupts
|
|
|
|
machine.enable_irq(state)
|
|
|
|
|
|
|
|
|
2016-05-20 13:31:44 +01:00
|
|
|
.. function:: disable_irq()
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2016-05-20 13:31:44 +01:00
|
|
|
Disable interrupt requests.
|
2016-09-23 04:15:58 +01:00
|
|
|
Returns the previous IRQ state which should be considered an opaque value.
|
2017-06-25 11:30:29 +01:00
|
|
|
This return value should be passed to the `enable_irq()` function to restore
|
|
|
|
interrupts to their original state, before `disable_irq()` was called.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2016-09-23 04:15:58 +01:00
|
|
|
.. function:: enable_irq(state)
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2016-09-23 04:15:58 +01:00
|
|
|
Re-enable interrupt requests.
|
2017-06-25 11:30:29 +01:00
|
|
|
The *state* parameter should be the value that was returned from the most
|
|
|
|
recent call to the `disable_irq()` function.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
Power related functions
|
|
|
|
-----------------------
|
|
|
|
|
2021-04-16 12:18:04 +01:00
|
|
|
.. function:: freq([hz])
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2021-04-16 12:18:04 +01:00
|
|
|
Returns the CPU frequency in hertz.
|
|
|
|
|
|
|
|
On some ports this can also be used to set the CPU frequency by passing in *hz*.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
.. function:: idle()
|
|
|
|
|
|
|
|
Gates the clock to the CPU, useful to reduce power consumption at any time during
|
|
|
|
short or long periods. Peripherals continue working and execution resumes as soon
|
2016-05-03 10:53:57 +01:00
|
|
|
as any interrupt is triggered (on many ports this includes system timer
|
2016-08-01 00:52:00 +01:00
|
|
|
interrupt occurring at regular intervals on the order of millisecond).
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
.. function:: sleep()
|
|
|
|
|
2018-12-15 05:20:18 +00:00
|
|
|
.. note:: This function is deprecated, use `lightsleep()` instead with no arguments.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2018-12-15 05:20:18 +00:00
|
|
|
.. function:: lightsleep([time_ms])
|
|
|
|
deepsleep([time_ms])
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2018-12-15 05:20:18 +00:00
|
|
|
Stops execution in an attempt to enter a low power state.
|
|
|
|
|
|
|
|
If *time_ms* is specified then this will be the maximum time in milliseconds that
|
|
|
|
the sleep will last for. Otherwise the sleep can last indefinitely.
|
|
|
|
|
2020-10-09 22:14:38 +01:00
|
|
|
With or without a timeout, execution may resume at any time if there are events
|
2018-12-15 05:20:18 +00:00
|
|
|
that require processing. Such events, or wake sources, should be configured before
|
|
|
|
sleeping, like `Pin` change or `RTC` timeout.
|
|
|
|
|
|
|
|
The precise behaviour and power-saving capabilities of lightsleep and deepsleep is
|
|
|
|
highly dependent on the underlying hardware, but the general properties are:
|
|
|
|
|
|
|
|
* A lightsleep has full RAM and state retention. Upon wake execution is resumed
|
|
|
|
from the point where the sleep was requested, with all subsystems operational.
|
|
|
|
|
|
|
|
* A deepsleep may not retain RAM or any other state of the system (for example
|
|
|
|
peripherals or network interfaces). Upon wake execution is resumed from the main
|
|
|
|
script, similar to a hard or power-on reset. The `reset_cause()` function will
|
|
|
|
return `machine.DEEPSLEEP` and this can be used to distinguish a deepsleep wake
|
|
|
|
from other resets.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2018-07-18 07:23:34 +01:00
|
|
|
.. function:: wake_reason()
|
2016-05-03 10:15:29 +01:00
|
|
|
|
2018-07-18 07:23:34 +01:00
|
|
|
Get the wake reason. See :ref:`constants <machine_constants>` for the possible return values.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2018-07-18 07:23:34 +01:00
|
|
|
Availability: ESP32, WiPy.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
Miscellaneous functions
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
.. function:: unique_id()
|
|
|
|
|
2016-08-01 00:52:00 +01:00
|
|
|
Returns a byte string with a unique identifier of a board/SoC. It will vary
|
2016-05-03 10:15:29 +01:00
|
|
|
from a board/SoC instance to another, if underlying hardware allows. Length
|
|
|
|
varies by hardware (so use substring of a full value if you expect a short
|
|
|
|
ID). In some MicroPython ports, ID corresponds to the network MAC address.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2020-01-11 06:44:17 +00:00
|
|
|
.. function:: time_pulse_us(pin, pulse_level, timeout_us=1000000, /)
|
2016-05-31 14:06:33 +01:00
|
|
|
|
2017-06-25 11:30:29 +01:00
|
|
|
Time a pulse on the given *pin*, and return the duration of the pulse in
|
|
|
|
microseconds. The *pulse_level* argument should be 0 to time a low pulse
|
2016-05-31 14:06:33 +01:00
|
|
|
or 1 to time a high pulse.
|
|
|
|
|
2017-06-25 11:30:29 +01:00
|
|
|
If the current input value of the pin is different to *pulse_level*,
|
|
|
|
the function first (*) waits until the pin input becomes equal to *pulse_level*,
|
|
|
|
then (**) times the duration that the pin is equal to *pulse_level*.
|
|
|
|
If the pin is already equal to *pulse_level* then timing starts straight away.
|
2016-05-31 14:06:33 +01:00
|
|
|
|
2017-02-05 11:20:17 +00:00
|
|
|
The function will return -2 if there was timeout waiting for condition marked
|
|
|
|
(*) above, and -1 if there was timeout during the main measurement, marked (**)
|
2017-06-25 11:30:29 +01:00
|
|
|
above. The timeout is the same for both cases and given by *timeout_us* (which
|
2017-02-05 11:20:17 +00:00
|
|
|
is in microseconds).
|
2016-05-31 14:06:33 +01:00
|
|
|
|
2021-08-11 07:06:11 +01:00
|
|
|
.. function:: bitstream(pin, encoding, timing, data, /)
|
|
|
|
|
|
|
|
Transmits *data* by bit-banging the specified *pin*. The *encoding* argument
|
|
|
|
specifies how the bits are encoded, and *timing* is an encoding-specific timing
|
|
|
|
specification.
|
|
|
|
|
|
|
|
The supported encodings are:
|
|
|
|
|
|
|
|
- ``0`` for "high low" pulse duration modulation. This will transmit 0 and
|
|
|
|
1 bits as timed pulses, starting with the most significant bit.
|
|
|
|
The *timing* must be a four-tuple of nanoseconds in the format
|
|
|
|
``(high_time_0, low_time_0, high_time_1, low_time_1)``. For example,
|
|
|
|
``(400, 850, 800, 450)`` is the timing specification for WS2812 RGB LEDs
|
|
|
|
at 800kHz.
|
|
|
|
|
|
|
|
The accuracy of the timing varies between ports. On Cortex M0 at 48MHz, it is
|
|
|
|
at best +/- 120ns, however on faster MCUs (ESP8266, ESP32, STM32, Pyboard), it
|
|
|
|
will be closer to +/-30ns.
|
|
|
|
|
|
|
|
.. note:: For controlling WS2812 / NeoPixel strips, see the :mod:`neopixel`
|
|
|
|
module for a higher-level API.
|
|
|
|
|
2018-07-18 07:28:30 +01:00
|
|
|
.. function:: rng()
|
|
|
|
|
|
|
|
Return a 24-bit software generated random number.
|
|
|
|
|
|
|
|
Availability: WiPy.
|
|
|
|
|
2015-10-14 11:32:01 +01:00
|
|
|
.. _machine_constants:
|
|
|
|
|
|
|
|
Constants
|
|
|
|
---------
|
|
|
|
|
|
|
|
.. data:: machine.IDLE
|
2017-02-27 21:38:15 +00:00
|
|
|
machine.SLEEP
|
|
|
|
machine.DEEPSLEEP
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2017-02-27 21:38:15 +00:00
|
|
|
IRQ wake values.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2016-09-08 03:50:38 +01:00
|
|
|
.. data:: machine.PWRON_RESET
|
2017-02-27 21:38:15 +00:00
|
|
|
machine.HARD_RESET
|
|
|
|
machine.WDT_RESET
|
|
|
|
machine.DEEPSLEEP_RESET
|
|
|
|
machine.SOFT_RESET
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2017-02-27 21:38:15 +00:00
|
|
|
Reset causes.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
.. data:: machine.WLAN_WAKE
|
2017-02-27 21:38:15 +00:00
|
|
|
machine.PIN_WAKE
|
|
|
|
machine.RTC_WAKE
|
2015-10-14 11:32:01 +01:00
|
|
|
|
2017-02-27 21:38:15 +00:00
|
|
|
Wake-up reasons.
|
2015-10-14 11:32:01 +01:00
|
|
|
|
|
|
|
Classes
|
|
|
|
-------
|
|
|
|
|
2018-07-20 06:58:18 +01:00
|
|
|
.. toctree::
|
2017-02-13 02:06:51 +00:00
|
|
|
:maxdepth: 1
|
|
|
|
|
|
|
|
machine.Pin.rst
|
2017-05-14 21:12:06 +01:00
|
|
|
machine.Signal.rst
|
2018-07-20 06:58:18 +01:00
|
|
|
machine.ADC.rst
|
2022-01-21 11:29:11 +00:00
|
|
|
machine.ADCBlock.rst
|
2021-04-30 07:42:51 +01:00
|
|
|
machine.PWM.rst
|
2017-06-03 12:50:54 +01:00
|
|
|
machine.UART.rst
|
2017-02-13 02:06:51 +00:00
|
|
|
machine.SPI.rst
|
2017-06-03 12:50:54 +01:00
|
|
|
machine.I2C.rst
|
2021-12-15 00:49:22 +00:00
|
|
|
machine.I2S.rst
|
2017-06-03 12:50:54 +01:00
|
|
|
machine.RTC.rst
|
2017-02-13 02:06:51 +00:00
|
|
|
machine.Timer.rst
|
|
|
|
machine.WDT.rst
|
2017-06-03 12:50:54 +01:00
|
|
|
machine.SD.rst
|
2019-05-31 08:04:32 +01:00
|
|
|
machine.SDCard.rst
|