将“this”作为参数传递给 ISR 注册有什么问题吗？

如何解决将“this”作为参数传递给 ISR 注册有什么问题吗？

我正在用 C++ 为 esp32 编写固件，我发现在注册 ISR 时将对象引用作为参数传递非常棒，因为我可以简单地将 ISR 的工作委托给特定对象（此中的一个资源） case），直接从类管理资源属性和功能。但是，我不确定在使用这种技术时要注意什么。

1. 它有什么本质上的问题吗？
2. 如果没有，在做的时候应该注意什么？

解决方法

将“this”作为参数传递给 ISR 注册有什么问题吗？

没有

它本身有什么问题吗？

没有

如果没有，在做的时候应该注意什么？

对象生命周期。编译器优化。资源共享。锁定。原子访问。特定的硬件语义。此外，esp32 是一个两核平台。这个列表可以继续下去，有很多关于 esp32 编程的书籍，关于在并行环境中编程以及在代码的主要部分和中断例程之间共享资源。应该了解所有此类与编程相关的主题以及良好的代码约定、命名和 C++ 语言。

,

我可以简单地将 ISR 的工作委托给特定对象（在本例中为资源），直接从类管理资源属性和功能。

这已经是错误的了。如果您确实为特定硬件外围设备以类的形式编写驱动程序，那么 ISR 应该作为静态成员函数在该类中。或者至少与 static 函数位于同一个翻译单元中，但这违背了使用类的初衷。

如果你这样设计程序，那么确保你可以传递对该类的引用。

它本身有什么问题吗？

除了上述之外，是的，这必须是具有静态存储持续时间的单例对象。并且在嵌入式系统中使用 C++ 类的静态存储持续时间对象本质上是错误的，因为这些将在微控制器启动期间被 CRT 调用。这反过来又会导致所有此类 C++ 程序的启动速度比等效的 C 程序慢。

但同样在这种特殊情况下，如果需要从上电复位点及时启动中断，那么 C++ 对象初始化将无法提供必要的实时性能。这使得 C++ 类不适用于看门狗、低电压警告、时钟监视器、CPU 异常和其他关键硬件中断等中断。

如果没有，在做的时候应该注意什么？

在 ISR 和调用程序之间进行通信时出现的常见重入问题。这种重入机制可以封装在类中。

和往常一样，这其中涉及的变量可能需要 volatile 限定以防止错误的编译器优化，具体取决于您的编译器的愚蠢程度。这与重入无关。见Using volatile in embedded C development。