micropython.rst 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137
  1. :mod:`micropython` -- access and control MicroPython internals
  2. ==============================================================
  3. .. module:: micropython
  4. :synopsis: access and control MicroPython internals
  5. Functions
  6. ---------
  7. .. function:: const(expr)
  8. Used to declare that the expression is a constant so that the compile can
  9. optimise it. The use of this function should be as follows::
  10. from micropython import const
  11. CONST_X = const(123)
  12. CONST_Y = const(2 * CONST_X + 1)
  13. Constants declared this way are still accessible as global variables from
  14. outside the module they are declared in. On the other hand, if a constant
  15. begins with an underscore then it is hidden, it is not available as a global
  16. variable, and does not take up any memory during execution.
  17. This `const` function is recognised directly by the MicroPython parser and is
  18. provided as part of the :mod:`micropython` module mainly so that scripts can be
  19. written which run under both CPython and MicroPython, by following the above
  20. pattern.
  21. .. function:: opt_level([level])
  22. If *level* is given then this function sets the optimisation level for subsequent
  23. compilation of scripts, and returns ``None``. Otherwise it returns the current
  24. optimisation level.
  25. The optimisation level controls the following compilation features:
  26. - Assertions: at level 0 assertion statements are enabled and compiled into the
  27. bytecode; at levels 1 and higher assertions are not compiled.
  28. - Built-in ``__debug__`` variable: at level 0 this variable expands to ``True``;
  29. at levels 1 and higher it expands to ``False``.
  30. - Source-code line numbers: at levels 0, 1 and 2 source-code line number are
  31. stored along with the bytecode so that exceptions can report the line number
  32. they occurred at; at levels 3 and higher line numbers are not stored.
  33. The default optimisation level is usually level 0.
  34. .. function:: alloc_emergency_exception_buf(size)
  35. Allocate *size* bytes of RAM for the emergency exception buffer (a good
  36. size is around 100 bytes). The buffer is used to create exceptions in cases
  37. when normal RAM allocation would fail (eg within an interrupt handler) and
  38. therefore give useful traceback information in these situations.
  39. A good way to use this function is to put it at the start of your main script
  40. (eg ``boot.py`` or ``main.py``) and then the emergency exception buffer will be active
  41. for all the code following it.
  42. .. function:: mem_info([verbose])
  43. Print information about currently used memory. If the *verbose* argument
  44. is given then extra information is printed.
  45. The information that is printed is implementation dependent, but currently
  46. includes the amount of stack and heap used. In verbose mode it prints out
  47. the entire heap indicating which blocks are used and which are free.
  48. .. function:: qstr_info([verbose])
  49. Print information about currently interned strings. If the *verbose*
  50. argument is given then extra information is printed.
  51. The information that is printed is implementation dependent, but currently
  52. includes the number of interned strings and the amount of RAM they use. In
  53. verbose mode it prints out the names of all RAM-interned strings.
  54. .. function:: stack_use()
  55. Return an integer representing the current amount of stack that is being
  56. used. The absolute value of this is not particularly useful, rather it
  57. should be used to compute differences in stack usage at different points.
  58. .. function:: heap_lock()
  59. .. function:: heap_unlock()
  60. Lock or unlock the heap. When locked no memory allocation can occur and a
  61. `MemoryError` will be raised if any heap allocation is attempted.
  62. These functions can be nested, ie `heap_lock()` can be called multiple times
  63. in a row and the lock-depth will increase, and then `heap_unlock()` must be
  64. called the same number of times to make the heap available again.
  65. .. function:: kbd_intr(chr)
  66. Set the character that will raise a `KeyboardInterrupt` exception. By
  67. default this is set to 3 during script execution, corresponding to Ctrl-C.
  68. Passing -1 to this function will disable capture of Ctrl-C, and passing 3
  69. will restore it.
  70. This function can be used to prevent the capturing of Ctrl-C on the
  71. incoming stream of characters that is usually used for the REPL, in case
  72. that stream is used for other purposes.
  73. .. function:: schedule(func, arg)
  74. Schedule the function *func* to be executed "very soon". The function
  75. is passed the value *arg* as its single argument. "Very soon" means that
  76. the MicroPython runtime will do its best to execute the function at the
  77. earliest possible time, given that it is also trying to be efficient, and
  78. that the following conditions hold:
  79. - A scheduled function will never preempt another scheduled function.
  80. - Scheduled functions are always executed "between opcodes" which means
  81. that all fundamental Python operations (such as appending to a list)
  82. are guaranteed to be atomic.
  83. - A given port may define "critical regions" within which scheduled
  84. functions will never be executed. Functions may be scheduled within
  85. a critical region but they will not be executed until that region
  86. is exited. An example of a critical region is a preempting interrupt
  87. handler (an IRQ).
  88. A use for this function is to schedule a callback from a preempting IRQ.
  89. Such an IRQ puts restrictions on the code that runs in the IRQ (for example
  90. the heap may be locked) and scheduling a function to call later will lift
  91. those restrictions.
  92. Note: If `schedule()` is called from a preempting IRQ, when memory
  93. allocation is not allowed and the callback to be passed to `schedule()` is
  94. a bound method, passing this directly will fail. This is because creating a
  95. reference to a bound method causes memory allocation. A solution is to
  96. create a reference to the method in the class constructor and to pass that
  97. reference to `schedule()`. This is discussed in detail here
  98. :ref:`reference documentation <isr_rules>` under "Creation of Python
  99. objects".
  100. There is a finite stack to hold the scheduled functions and `schedule()`
  101. will raise a `RuntimeError` if the stack is full.