arduino/esp8266
1
0
Fork 0
mirror of https://github.com/esp8266/Arduino.git synced 2025-04-19 23:22:16 +03:00
Code

Correction on Heap API available from ISR (#8708)

Browse Source 
* Correction on Heap API available from ISR

* Expand reason for avoid realloc/free
This commit is contained in:
M Hightower 2022-11-04 06:07:31 -07:00 committed by GitHub
parent 3d9aeeff2d
commit 3a2fe9ff0f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
doc/reference.rst
View File

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