Useful video if you're interested in how DT applies to Zephyr, such as defining I2C sensors available on your board target: https://www.youtube.com/watch?v=sWaxQyIgEBY
Useful video if you're interested in how DT applies to Zephyr, such as defining I2C sensors available on your board target: https://www.youtube.com/watch?v=sWaxQyIgEBY
Zephyr is chock full of these creature comforts to make Linux developers feel at home but only deliver 50% of the usability. I went back to FreeRTOS.
Some stuff looks like it might be implemented well in these OS's, like using DMA, and suchlike. So they could possibly be fast. And yet, I think the way to bet is that they will be slower. Get comfortable with CMSIS, and your results are likely to be substantially faster.
Maybe throw in a bit of FreeRTOS if you feel you need it. I haven't experimented with tinygo yet, but I wonder if that's the way to go if you want concurrency.
I think that the whole notion of abstracting away the machine is an ill-conceived idea anyway, particularly when it comes to microcontrollers. The whole point of mcus is to use their particular features and strengths, which basically the opposite of abstraction.
I dunno, if something is complicated enough to use Zephyr, then maybe it's complicated enough to just ditch it and use a Raspberry Pi.
I spent a year hacking with a Broadcom-supplied fork of Zephyr to Cortex-A and it was just a mess. It never worked right. Maybe it does now and it's mainline but I wouldn't trust it.
For a project started by WindRiver, taken over by Intel, then released to OSS it's mind-boggling how bad of a state it was in given its age.
Given that FreeRTOS does not deal with hardware at all, I don't see how it is a comparison.
And then you discover you're not getting any of that.
If all Zephyr DT is doing is making a fancy header file for me, I'd rather just build my own and skip the learning curve.