I guess that's depends on the application. What I had was a series of wireless DAQ devices with a common application core but different sets of sensors (and hence drivers). Some are as simple as "read and I2C value and put in into uplink queue" and that's where I often made the mistake to assume I could rely on stock drivers. Other are fully driven from the MCU's analog guts. Once the application core was there on one board I quickly found myself spending 50% of my time fighting against DTS.
FreeRTOS is much less reusable, but that means you are confidently pessimistic about schedule risk. That's an RTOS and that's it. The rest is on you and you know it. With Zephyr you get tons of support infrastructure, but you also risk finding that it doesn't fit too late in the process. E.g. the flash chip power management issue was quite bad - we ended up dropping the features that required an external flash altogether.
Then again, Zephyr is the best we have got, but I feel it's due to the Zephyr team's dedication to details - and in spite, not thanks to, the general approach.
The thing with Zephyr drivers is: sometimes you need to do something very special and exact to the hardware, and sometimes you just want to use it in the most generic and braindead way possible.
FreeRTOS is much less reusable, but that means you are confidently pessimistic about schedule risk. That's an RTOS and that's it. The rest is on you and you know it. With Zephyr you get tons of support infrastructure, but you also risk finding that it doesn't fit too late in the process. E.g. the flash chip power management issue was quite bad - we ended up dropping the features that required an external flash altogether.
Then again, Zephyr is the best we have got, but I feel it's due to the Zephyr team's dedication to details - and in spite, not thanks to, the general approach.