I fork your project and create esp-ir for ESP8266_RTOS_SDK 3.2. I find inline functions critical and can help increase the stability in ESP8266_RTOS_SDK version. I think this change may help in esp-open-rtos too.
Although in esp-open-rtos, the default configuration will inline it. Just in case to provide inline keyword for the compiler because some compiler with other options won't inline these and will cause a call overhead. What's worse, when this happened, this function is not in IRAM so the overhead is significant.
In my forked library I even use __attribute__((always_inline)) inline instead of regular inline because if you use menuconfig to build in "Release" mode, the compiler is in "optimization for Size -Os " hence sometimes compiler tries to override any inline keyword, leading to worse performance compared to Debug mode.
In my forked version of ESP8266_RTOS_SDK, with this little change, my air conditioner accept the IR signal with 100% rate. (originally ~95%) without this change.
I fork your project and create esp-ir for ESP8266_RTOS_SDK 3.2. I find inline functions critical and can help increase the stability in ESP8266_RTOS_SDK version. I think this change may help in esp-open-rtos too.
Although in esp-open-rtos, the default configuration will inline it. Just in case to provide
inline
keyword for the compiler because some compiler with other options won't inline these and will cause a call overhead. What's worse, when this happened, this function is not in IRAM so the overhead is significant.In my forked library I even use
__attribute__((always_inline)) inline
instead of regularinline
because if you use menuconfig to build in "Release" mode, the compiler is in "optimization for Size-Os
" hence sometimes compiler tries to override any inline keyword, leading to worse performance compared to Debug mode.In my forked version of ESP8266_RTOS_SDK, with this little change, my air conditioner accept the IR signal with 100% rate. (originally ~95%) without this change.