In this project a simple RTOS might have been a huge timesaver. But we also had to have timer interrupts and serial I/O interrupts and I am not aware of how easily RTOSes can fit with those. If it is possible to weave RTOS features into your own needed I/O hardware support, that could be helpful but also could get a bit complex.
My concern would be: is the RTOS granular so we only need to use what fits our case, and can it co-exist with I/O device interrupt handlers?
A good RTOS allows independent interrupt handlers. The three systems I ported to AVR/ARM Arduinos can be used as simple kernels with all I/O from the Arduino core or custom libraries.
I am starting to write optional I/O libraries that are integrated with the RTOS. Many existing Arduino I/O functions just do busy loops so putting a thread to sleep and waking it with an I/O done interrupt is more efficient.
If you need a highly optimized ISRs, systems like ChibiOS are designed to allow your ISR to run with no interference from the RTOS.
On ARM this works very well with priority interrupts. ChibiOS is designed to allow "Fast interrupts".
On some architectures ChibiOS supports a special class of “Fast Interrupts”, such interrupt sources have a higher hardware priority than the kernel so it is not possible to invoke system APIs from there.
The invocation of any API is forbidden here because fast interrupt handlers can preempt the kernel even within its critical zones in order to minimize latency.
The only hardware resource I uses is access to a timer interrupt for the system tick.
I piggyback on sysTick on ARM since both Teensy 3.0 and Due will have a hook. So no new hardware is used on ARM.
On AVR I am using the timer 0 compare A interrupt. I did this so no Arduino core code needs to be changed. I will release an optional patch to piggyback on the timer 0 overflow interrupt. This is already used for delay(), millis(), and micros(). Then not new hardware will be used on AVR.