@@ -27,15 +27,22 @@ and have several limitations:
27
27
or use a scheduled function (which will be called outside of the interrupt
28
28
context when it is safe) to do long-running work.
29
29
30
- * Memory operations can be dangerous and should be avoided in interrupts.
31
- Calls to ``new `` or ``malloc `` should be minimized because they may require
32
- a long running time if memory is fragmented. Calls to ``realloc `` and
33
- ``free `` must NEVER be called. Using any routines or objects which call
34
- ``free `` or ``realloc `` themselves is also forbidden for the same reason.
35
- This means that ``String ``, ``std::string ``, ``std::vector `` and other
36
- classes which use contiguous memory that may be resized must be used with
37
- extreme care (ensuring strings aren't changed, vector elements aren't
38
- added, etc.).
30
+ * Heap API operations can be dangerous and should be avoided in interrupts.
31
+ Calls to ``malloc `` should be minimized because they may require a long
32
+ running time if memory is fragmented. Calls to ``realloc `` and ``free ``
33
+ must NEVER be called. Using any routines or objects which call ``free `` or
34
+ ``realloc `` themselves is also forbidden for the same reason. This means
35
+ that ``String ``, ``std::string ``, ``std::vector `` and other classes which
36
+ use contiguous memory that may be resized must be used with extreme care
37
+ (ensuring strings aren't changed, vector elements aren't added, etc.).
38
+ The underlying problem, an allocation address could be actively in use at
39
+ the instant of an interrupt. Upon return, the address actively in use may
40
+ be invalid after an ISR uses ``realloc `` or ``free `` against the same
41
+ allocation.
42
+
43
+ * The C++ ``new `` and ``delete `` operators must NEVER be used in an ISR. Their
44
+ call path is not in IRAM. Using any routines or objects that use the ``new ``
45
+ or ``delete `` operator is also forbidden.
39
46
40
47
Digital IO
41
48
----------
0 commit comments