You can add a list of boards you tested, furthermore there are several “plug in compatibles” that should work too. What is missing is the (optional) disabling of interrupts as the protocol is time sensitive and can (will) be corrupted if there are interrupts during the data exchange. (see my DHTNEW library).
Hi Rob,
thank you very much for your feedback — I really appreciate it, especially coming from someone with your experience in this area.
At the moment I’ve only tested the library on an Arduino UNO with a DHT11 and DHT22. My goal is to expand it and make it as reliable and portable as possible. I’ll add optional interrupt disabling as you suggested.
I’m planning to test the library on more boards and with more compatible sensors once I get access to them, but until then I prefer not to assume anything I haven’t directly verified.
In the meantime, I wanted to ask something:
Do you have any recommendations or best practices for implementing interrupt handling in a clean, portable way across different MCU families (AVR, ESP8266/ESP32, RP2040)?
Since each platform behaves differently, I’d like to design the solution in a way that remains consistent and safe regardless of the hardware.
That is good, however at some point you will learn that there are dozens, no hundreds of boards so you will have to put trust in the community if they report it working or not.
If you stick to the Arduino framework, my advice is to use “global” interrupt handlers which react on the interrupt by setting a flag indicating the interrupt has happened. Optional record a timestamp or read / write some digital pins, but the interrupt handler should be as short as possible. No serial prints, I2C, delay’s or code that uses interrupts under the hood.
In the main loop the flag is checked as often as possible (or needed) and the handling of the interrupt is finalized (and the flag is reset). The flag is typical a bool but it can be a counter too (interrupt increases the counter, main loop decreases the counter).
Finally variables used (set) in the interrupt that are accessed in the main loop, should be handled with care in the main loop. E.g. if you set a multi-byte variable (struct) in the interrupt handler, the main loop must disable interrupts when accessing that variable as technically it is possible that it gets updated while the main loop accesses it. Good practice is to make a local copy of the value so the disabling time is as short as possible.
There are other frameworks e.g. RTOS where interrupts are at the core of the OS. I would advice to invest in a good book describing the details of how to handle interrupts as those have way more points of attention.
Thank you for the detailed explanation, it clarified a lot for me.
I see your point regarding the need to rely on community feedback; given the wide variety of available boards, this is ultimately unavoidable.
Keeping interrupt handlers minimal and using flags or counters makes perfect sense. I’ll follow that approach and make sure any shared data is handled carefully in the main loop, with short interrupt-disabled sections and local copies where appropriate.
For now, I’ll stay within the Arduino framework and focus on getting these fundamentals right before looking into RTOS-based approaches. I’ll also take your advice and invest time in learning more about proper interrupt handling from dedicated resources.
Thanks again for taking the time to share your experience — I really appreciate the guidance.
Hi @tonimatutinovic. Something you can do to get some level of validation without doing actual testing with the hardware is to compile the library's example sketches for each of the target boards as a "smoke test".
A successful compilation is not a guarantee of correct runtime behavior, so this is of course not a comprehensive validation. However, a failed compilation is a sure sign of a problem, so this does have value. And this is something that can be automated.
Arduino provides a GitHub Actions action that facilitates setting up your GitHub repository to run such an automated compilation of Arduino sketches on every push and pull request made in the repository:
This is used in all the official Arduino library repositories, as well as by many community members.
For example, here you can see the GitHub Actionsworkflow workflow that uses the action in the "Servo" library's repository:
Thank you so much for pointing this out! I didn’t know that this GitHub Actions workflow existed, and it’s really helpful to learn about a way to do a “smoke test” without needing all the hardware. It seems like a very practical approach for catching issues early.
I really appreciate you taking the time to share this resource!