I recently tried to use Zephyr on an nRF9160 and looked into the MQTT example. I was pretty disappointed. Its C only, the examples are littered with #ifdefs, because for some reason they forced support for 28 different platforms in the same example file and I couldn't really grasp it in a short time.
On the other hand, when I tried the same thing with Embedded Rust, I was up and running quicker, but am now missing a no_std MQTT library.
I had high hopes for Zephyr, and maybe I have to give it a fair chance again, but as of now, I don't feel it.
In the context of FPGAs: better tooling for that would be pretty dope. Coming from software dev, it is quite hard to get used to all the proprietary tools and weird workflows. I successfully got around ever using vendor tools for microcontrollers, but for FPGAs, that is still very hard.
I'm hoping that LLHD and CIRCT within the LLVM project really take of, to get some language and tooling innovation going in the space[*].
[*] or rather _open_ innovation -> I think there is some quite impressive proprietary stuff, but the open ecosystem is lacking behind the software world.
On the other hand, when I tried the same thing with Embedded Rust, I was up and running quicker, but am now missing a no_std MQTT library.
I had high hopes for Zephyr, and maybe I have to give it a fair chance again, but as of now, I don't feel it.
In the context of FPGAs: better tooling for that would be pretty dope. Coming from software dev, it is quite hard to get used to all the proprietary tools and weird workflows. I successfully got around ever using vendor tools for microcontrollers, but for FPGAs, that is still very hard.
I'm hoping that LLHD and CIRCT within the LLVM project really take of, to get some language and tooling innovation going in the space[*].
[*] or rather _open_ innovation -> I think there is some quite impressive proprietary stuff, but the open ecosystem is lacking behind the software world.