I'm using both NilRTOS and ChibiOS for some of my Arduino's and have some troubles where I can't find the right solution for.
The question centers around the preemption of a thread using existing libraries (for instance Adafruits DHTx lib) that where never made for this, but also other libraries that are using software SPI/I2C bit-banging.
In some libraries I see that interrupts are disabled/enabled around certain timing-critical points. Still I run into troubles using some libraries (again: the DHTx lib).
What is this the right solution while using an RTOS for these time-critical bit-bang libraries?
Disabling interrupts is a bad idea with or without an RTOS, I would question the usefulness and the generality of such a library.
In general, you can put threads requiring critical timings at the highest priority, other threads would not preempt them. Another possible approach is to raise the priority before calling the critical function then return to the previous level, this does not apply to NilRTOS.
Protocols like I2C and SPI should not be affected by preemption because their synchronous nature, in those specific cases libraries should work regardless the RTOS, timings should not be critical.
I dove a bit deeper into some of the DHTx libraries. Some do use cli/seo, others just don't.
Those who do, do this around a read-modify-write cycle of an atmega port to change a pin from input to output mode or vice-versa.
This seems logical to me as if just after the read, an interrupt/task switch occurs and another pin on that same port is changed, the rst of the modify-write cycle will overwrite the port configuraion again.
Furthermore, the DHTx code measures the time in microseconds (20-80 micosec) a pin is high or low to read 0 and 1 bits. Again, as the DHTx sensor keeps sending data will fail if this process is interrupted.
I think the last one could be made RTOS-proof by using an interrupt routine to 'read' and measure (the mickroseconds since the last interrupt) the incoming data. In that case the can simply sleep for say 500msec, and then check if there is valid data.
I use the same method for receiving data from those 433MHz receivers.
I see however no simple alternative for the RMW port cycle.
Spi and I2C use separate lines for reading and writing data, so these protocols don't need to change the direction of the pin.
My test setup btw is using 4 DHT22 sensors which are handled by 4 different threads. Not the usual setup of course, but done to see how this behaves using both NilRTOS and ChibiOS.