我假设这个问题取决于操作系统或平台。
它是在我使用端口音频库在 Windows 上编写 C++ 代码时出现的。
它在文档中声明不要在我的回调函数中编写太多代码，这些代码将被传递给端口音频引擎，因为根据系统，它可以从 ISR 和另一个论坛上的阅读中调用，说明它可能导致堆栈溢出。
我不是在这里询问任何特定于端口音频的事情，但我想知道如果在 ISR 中编写的代码比在主函数中编写的代码更多，为什么会出现堆栈空间问题。
我希望从回调中调用几个不同的函数。如果这个回调实际上是从 ISR 调用的，那么从 ISR 调用更多函数是否有问题？
当我调用每个函数时，这是否会允许我额外的堆栈空间，因为每个函数都有自己的最大堆栈大小？这我觉得有点混乱。
我一直认为函数和 ISR 可以使用尽可能多的堆栈堆栈空间，直到完整分配的堆栈。这是否意味着主函数比其他函数拥有更大的堆栈部分。
提前谢谢了。
I was wondering why would there be an issue with stack space if more code is wrote in an ISR than in the main function.
Stack space is probably not the primary concern for an ISR. An ISR should be as simple and fast as possible in order to minimise latency, so it shouldn't need a large stack anyway. If you have to do any non-trivial processing, your ISR should enqueue a task to run on a regular thread later to complete the job (sometimes called top-half and bottom-half). This could be achieved with a condition variable, semaphore, or message queue (to name a few IPC mechanisms). So if an ISR is using a lot of stack, it may be an indication that it's trying to do too much processing during a timing-critical scheduling period.
Also, many systems (e.g. RTOS) require you to declare the stack size for threads and ISRs.
I wish to call a few different functions from the callback. If this callback is actually called from an ISR, is calling more functions from the ISR a problem?
Only in so far as calling other functions from an ISR should be minimised as discussed above. You can call other functions, but you should defer as much as possible to run after the ISR has returned to the kernel scheduler (and unmasked interrupts!).
Also - beware of race conditions! Careful use of mutexes is necessary to protect shared state.
As I call each function, will this allow me extra stack space because each function has its own maximum stack size? This I find a bit confusing.
No - a function doesn't have its own stack size - threads do. For ISRs, it depends on the OS. Calling each function will consume more stack space though (based on the call nesting level).
I always thought that functions and ISRs can use as much stack stack space as they like up to the complete allocated stack.
Yes, but the stack is per-thread, not per-process like the heap. Using a large amount of stack space could be a sign of a design issue: allocating large objects on the stack rather than the heap, too many nested function calls, etc.
Does it mean the main function has a larger portion of the stack than others.
No, since the stack is per thread. A main function will be at the bottom of the application's call stack, but it may consume a small or a large amount of stack, depending only on its local variables.
Some good reading:
如果这个回调实际上是从 ISR 调用的，那么从 ISR 调用更多函数是否有问题？
它可能是。ISR 有多种风格，在许多情况下使用，一些组合为 ISR 提供了相当有限的堆栈空间。堆栈空间由（至少）ISR 自己的参数和局部变量以及它直接或间接调用的每个函数使用，函数调用有一些开销。该空间被重复用于顺序函数调用，但当一个函数调用另一个函数时它是累积的。
当我调用每个函数时，这是否会允许我额外的堆栈空间，因为每个函数都有自己的最大堆栈大小？
不，一般不会。ISR 很可能会使用自己的堆栈空间来调用，与与其关联的任何程序的堆栈空间分开，但这是一种特殊情况。函数通常使用与其调用者相同的堆栈，但 ISR 没有传统意义上的调用者。
我一直认为函数和 ISR 可以使用尽可能多的堆栈堆栈空间，直到完整分配的堆栈。这是否意味着主函数比其他函数拥有更大的堆栈部分[？]
ISR 可以尽可能多地使用提供给它的堆栈空间。该空间通常与关联程序的主堆栈分开，这对于在触发 ISR 时避免干扰主程序的状态很有用，并且在 ISR 是异步的时是必不可少的。分开时，ISR 的堆栈通常要小得多。
进程（主）堆栈的大小取决于系统，有时取决于可执行文件；它在main所有直接或间接调用的函数之间共享main。在单线程程序中，main 确实可以访问比任何其他函数更多的堆栈f，但主要原因是main（通常）调用链中的每个函数 from mainto占用无法使用的f堆栈空间。f
它是在我使用端口音频库在 Windows 上编写 C++ 代码时出现的。
请在 ISR 中尽可能少做，并排队 DPC 以调用您的所有功能。甚至 DPC 也受到或应该受到资源限制，因此请考虑工作线程为 DPC 提供服务的设计。无论您做什么，都不要考虑在 ISR 中获取任何互斥锁。采收率。
老实说，我不会相信“另一个论坛”。
文档没有说明使用太多堆栈空间。它谈到了太多的代码，并且在 ISR 回调的上下文中，这意味着在 ISR 中花费了太多时间。
ISR（包括回调）在中断被阻止的情况下执行。现在中断不会累积；控制器只能说中断是否处于挂起状态。如果 ISR 执行时间过长，则执行期间引发的中断将丢失。
堆栈空间也可能是一个问题，但最重要的是，让你的回调速度更快。