2015-06-04 23:53:26 +01:00
|
|
|
:mod:`micropython` -- access and control MicroPython internals
|
|
|
|
==============================================================
|
2015-03-30 00:32:29 +01:00
|
|
|
|
|
|
|
.. module:: micropython
|
2015-06-04 23:53:26 +01:00
|
|
|
:synopsis: access and control MicroPython internals
|
2015-03-30 00:32:29 +01:00
|
|
|
|
|
|
|
Functions
|
|
|
|
---------
|
|
|
|
|
2017-05-17 15:25:09 +01:00
|
|
|
.. function:: const(expr)
|
|
|
|
|
|
|
|
Used to declare that the expression is a constant so that the compile can
|
|
|
|
optimise it. The use of this function should be as follows::
|
|
|
|
|
|
|
|
from micropython import const
|
|
|
|
|
|
|
|
CONST_X = const(123)
|
|
|
|
CONST_Y = const(2 * CONST_X + 1)
|
|
|
|
|
|
|
|
Constants declared this way are still accessible as global variables from
|
|
|
|
outside the module they are declared in. On the other hand, if a constant
|
|
|
|
begins with an underscore then it is hidden, it is not available as a global
|
|
|
|
variable, and does not take up any memory during execution.
|
|
|
|
|
|
|
|
This `const` function is recognised directly by the MicroPython parser and is
|
2017-06-27 22:37:47 +01:00
|
|
|
provided as part of the :mod:`micropython` module mainly so that scripts can be
|
2017-05-17 15:25:09 +01:00
|
|
|
written which run under both CPython and MicroPython, by following the above
|
|
|
|
pattern.
|
|
|
|
|
|
|
|
.. function:: opt_level([level])
|
|
|
|
|
2017-06-27 22:37:47 +01:00
|
|
|
If *level* is given then this function sets the optimisation level for subsequent
|
|
|
|
compilation of scripts, and returns ``None``. Otherwise it returns the current
|
2017-05-17 15:25:09 +01:00
|
|
|
optimisation level.
|
|
|
|
|
2015-03-30 00:32:29 +01:00
|
|
|
.. function:: alloc_emergency_exception_buf(size)
|
|
|
|
|
2017-06-27 22:37:47 +01:00
|
|
|
Allocate *size* bytes of RAM for the emergency exception buffer (a good
|
2015-03-30 00:32:29 +01:00
|
|
|
size is around 100 bytes). The buffer is used to create exceptions in cases
|
2015-02-09 00:42:08 +00:00
|
|
|
when normal RAM allocation would fail (eg within an interrupt handler) and
|
|
|
|
therefore give useful traceback information in these situations.
|
2015-03-30 00:32:29 +01:00
|
|
|
|
|
|
|
A good way to use this function is to put it at the start of your main script
|
2017-06-27 22:37:47 +01:00
|
|
|
(eg ``boot.py`` or ``main.py``) and then the emergency exception buffer will be active
|
2015-03-30 00:32:29 +01:00
|
|
|
for all the code following it.
|
2017-04-16 07:18:47 +01:00
|
|
|
|
|
|
|
.. function:: mem_info([verbose])
|
|
|
|
|
2017-08-29 07:53:30 +01:00
|
|
|
Print information about currently used memory. If the *verbose* argument
|
2017-04-16 07:18:47 +01:00
|
|
|
is given then extra information is printed.
|
|
|
|
|
|
|
|
The information that is printed is implementation dependent, but currently
|
|
|
|
includes the amount of stack and heap used. In verbose mode it prints out
|
|
|
|
the entire heap indicating which blocks are used and which are free.
|
|
|
|
|
|
|
|
.. function:: qstr_info([verbose])
|
|
|
|
|
2017-06-27 22:37:47 +01:00
|
|
|
Print information about currently interned strings. If the *verbose*
|
2017-04-16 07:18:47 +01:00
|
|
|
argument is given then extra information is printed.
|
|
|
|
|
|
|
|
The information that is printed is implementation dependent, but currently
|
|
|
|
includes the number of interned strings and the amount of RAM they use. In
|
|
|
|
verbose mode it prints out the names of all RAM-interned strings.
|
2017-05-17 15:25:09 +01:00
|
|
|
|
|
|
|
.. function:: stack_use()
|
|
|
|
|
|
|
|
Return an integer representing the current amount of stack that is being
|
|
|
|
used. The absolute value of this is not particularly useful, rather it
|
|
|
|
should be used to compute differences in stack usage at different points.
|
|
|
|
|
|
|
|
.. function:: heap_lock()
|
|
|
|
.. function:: heap_unlock()
|
|
|
|
|
|
|
|
Lock or unlock the heap. When locked no memory allocation can occur and a
|
|
|
|
`MemoryError` will be raised if any heap allocation is attempted.
|
|
|
|
|
|
|
|
These functions can be nested, ie `heap_lock()` can be called multiple times
|
|
|
|
in a row and the lock-depth will increase, and then `heap_unlock()` must be
|
|
|
|
called the same number of times to make the heap available again.
|
|
|
|
|
|
|
|
.. function:: kbd_intr(chr)
|
|
|
|
|
|
|
|
Set the character that will raise a `KeyboardInterrupt` exception. By
|
|
|
|
default this is set to 3 during script execution, corresponding to Ctrl-C.
|
|
|
|
Passing -1 to this function will disable capture of Ctrl-C, and passing 3
|
|
|
|
will restore it.
|
|
|
|
|
|
|
|
This function can be used to prevent the capturing of Ctrl-C on the
|
|
|
|
incoming stream of characters that is usually used for the REPL, in case
|
|
|
|
that stream is used for other purposes.
|
|
|
|
|
2017-06-27 22:37:47 +01:00
|
|
|
.. function:: schedule(func, arg)
|
2017-05-17 15:25:09 +01:00
|
|
|
|
2017-06-27 22:37:47 +01:00
|
|
|
Schedule the function *func* to be executed "very soon". The function
|
|
|
|
is passed the value *arg* as its single argument. "Very soon" means that
|
2017-05-17 15:25:09 +01:00
|
|
|
the MicroPython runtime will do its best to execute the function at the
|
|
|
|
earliest possible time, given that it is also trying to be efficient, and
|
|
|
|
that the following conditions hold:
|
|
|
|
|
|
|
|
- A scheduled function will never preempt another scheduled function.
|
|
|
|
- Scheduled functions are always executed "between opcodes" which means
|
|
|
|
that all fundamental Python operations (such as appending to a list)
|
|
|
|
are guaranteed to be atomic.
|
|
|
|
- A given port may define "critical regions" within which scheduled
|
|
|
|
functions will never be executed. Functions may be scheduled within
|
|
|
|
a critical region but they will not be executed until that region
|
|
|
|
is exited. An example of a critical region is a preempting interrupt
|
|
|
|
handler (an IRQ).
|
|
|
|
|
|
|
|
A use for this function is to schedule a callback from a preempting IRQ.
|
|
|
|
Such an IRQ puts restrictions on the code that runs in the IRQ (for example
|
|
|
|
the heap may be locked) and scheduling a function to call later will lift
|
|
|
|
those restrictions.
|
|
|
|
|
2017-11-12 06:13:45 +00:00
|
|
|
Note: If `schedule()` is called from a preempting IRQ, when memory
|
|
|
|
allocation is not allowed and the callback to be passed to `schedule()` is
|
|
|
|
a bound method, passing this directly will fail. This is because creating a
|
|
|
|
reference to a bound method causes memory allocation. A solution is to
|
|
|
|
create a reference to the method in the class constructor and to pass that
|
|
|
|
reference to `schedule()`. This is discussed in detail here
|
|
|
|
:ref:`reference documentation <isr_rules>` under "Creation of Python
|
|
|
|
objects".
|
|
|
|
|
|
|
|
There is a finite stack to hold the scheduled functions and `schedule()`
|
2017-05-17 15:25:09 +01:00
|
|
|
will raise a `RuntimeError` if the stack is full.
|