|
7 | 7 | Functions |
8 | 8 | --------- |
9 | 9 |
|
| 10 | +.. function:: const(expr) |
| 11 | + |
| 12 | + Used to declare that the expression is a constant so that the compile can |
| 13 | + optimise it. The use of this function should be as follows:: |
| 14 | + |
| 15 | + from micropython import const |
| 16 | + |
| 17 | + CONST_X = const(123) |
| 18 | + CONST_Y = const(2 * CONST_X + 1) |
| 19 | + |
| 20 | + Constants declared this way are still accessible as global variables from |
| 21 | + outside the module they are declared in. On the other hand, if a constant |
| 22 | + begins with an underscore then it is hidden, it is not available as a global |
| 23 | + variable, and does not take up any memory during execution. |
| 24 | + |
| 25 | + This `const` function is recognised directly by the MicroPython parser and is |
| 26 | + provided as part of the `micropython` module mainly so that scripts can be |
| 27 | + written which run under both CPython and MicroPython, by following the above |
| 28 | + pattern. |
| 29 | + |
| 30 | +.. function:: opt_level([level]) |
| 31 | + |
| 32 | + If `level` is given then this function sets the optimisation level for subsequent |
| 33 | + compilation of scripts, and returns `None`. Otherwise it returns the current |
| 34 | + optimisation level. |
| 35 | + |
10 | 36 | .. function:: alloc_emergency_exception_buf(size) |
11 | 37 |
|
12 | 38 | Allocate ``size`` bytes of RAM for the emergency exception buffer (a good |
@@ -35,3 +61,56 @@ Functions |
35 | 61 | The information that is printed is implementation dependent, but currently |
36 | 62 | includes the number of interned strings and the amount of RAM they use. In |
37 | 63 | verbose mode it prints out the names of all RAM-interned strings. |
| 64 | + |
| 65 | +.. function:: stack_use() |
| 66 | + |
| 67 | + Return an integer representing the current amount of stack that is being |
| 68 | + used. The absolute value of this is not particularly useful, rather it |
| 69 | + should be used to compute differences in stack usage at different points. |
| 70 | + |
| 71 | +.. function:: heap_lock() |
| 72 | +.. function:: heap_unlock() |
| 73 | + |
| 74 | + Lock or unlock the heap. When locked no memory allocation can occur and a |
| 75 | + `MemoryError` will be raised if any heap allocation is attempted. |
| 76 | + |
| 77 | + These functions can be nested, ie `heap_lock()` can be called multiple times |
| 78 | + in a row and the lock-depth will increase, and then `heap_unlock()` must be |
| 79 | + called the same number of times to make the heap available again. |
| 80 | + |
| 81 | +.. function:: kbd_intr(chr) |
| 82 | + |
| 83 | + Set the character that will raise a `KeyboardInterrupt` exception. By |
| 84 | + default this is set to 3 during script execution, corresponding to Ctrl-C. |
| 85 | + Passing -1 to this function will disable capture of Ctrl-C, and passing 3 |
| 86 | + will restore it. |
| 87 | + |
| 88 | + This function can be used to prevent the capturing of Ctrl-C on the |
| 89 | + incoming stream of characters that is usually used for the REPL, in case |
| 90 | + that stream is used for other purposes. |
| 91 | + |
| 92 | +.. function:: schedule(fun, arg) |
| 93 | + |
| 94 | + Schedule the function `fun` to be executed "very soon". The function |
| 95 | + is passed the value `arg` as its single argument. "very soon" means that |
| 96 | + the MicroPython runtime will do its best to execute the function at the |
| 97 | + earliest possible time, given that it is also trying to be efficient, and |
| 98 | + that the following conditions hold: |
| 99 | + |
| 100 | + - A scheduled function will never preempt another scheduled function. |
| 101 | + - Scheduled functions are always executed "between opcodes" which means |
| 102 | + that all fundamental Python operations (such as appending to a list) |
| 103 | + are guaranteed to be atomic. |
| 104 | + - A given port may define "critical regions" within which scheduled |
| 105 | + functions will never be executed. Functions may be scheduled within |
| 106 | + a critical region but they will not be executed until that region |
| 107 | + is exited. An example of a critical region is a preempting interrupt |
| 108 | + handler (an IRQ). |
| 109 | + |
| 110 | + A use for this function is to schedule a callback from a preempting IRQ. |
| 111 | + Such an IRQ puts restrictions on the code that runs in the IRQ (for example |
| 112 | + the heap may be locked) and scheduling a function to call later will lift |
| 113 | + those restrictions. |
| 114 | + |
| 115 | + There is a finite stack to hold the scheduled functions and `schedule` |
| 116 | + will raise a `RuntimeError` if the stack is full. |
0 commit comments