I kind of need to pivot a little bit from the original post, but I think it is still really the same topic (SW dev support), so I will keep on this thread.
It’s not intended as a rant, but it’s a long post, so I won’t mind if you (dear reader) just skip it.
I’ve been looking at various Zephyr doco and commentary sites.
IMHO … it seems that:
The interest in Zephyr is only because ARM walked away from Mbed two years ago and Arduino began a transition to Zephyr as a replacement. It’s not necessarily a great step forward, simply one of necessity. Some people like Zephyr, some see bloatware; different tribes.
Good SW dev environments sell hardware. Bad SW dev environments drive developers away (eventually - they only find out how bad tools are after they’ve moved past the promises and tried to use them). It’s in the interests of HW vendors to provide good SW development tools for their own hardware, but it is absolutely against their interests that their tools work for the competition’s hardware. They want HW lock-in - that is they discourage an easy transition to alternative hardware. They also provide relatively cheap debug probes that are restricted to their own hardware. I have half a dozen of them. It is often a rebadged Segger probe, with firmware restrictions. The commercial (non-EDU) Segger probes are universal but expensive.
Now that Qualcomm has bought Arduino, the whole idea of Arduino providing SW portability across different HW is, I think, on somewhat shaky ground. Qualcomm is a chip maker. Anything they do in the Arduino space has to be about them selling more of their chips. They could have just made some Arduino compatible boards and joined the club, but instead they bought control and they will certainly want return on investment.
Good SW tools are expensive to develop and maintain, and there seems to be a gradual migration away from in-house tools towards providing externions to the VScode umbrella. This concentration makes things like the Black Magic debug probe much more viable since it can be a GDB server for a raft of chips. That’s now tricky for the HW vendors because they are damned either way - either maintain their own expensive tools or lose the HW lock-in.
Even Segger have decided to support the VScode environment, but I think that they will struggle against the BM probe unless they seriously rethink their pricing.
These are interesting times.
I imagine that RAK would like to keep SW portability across its various processing HW options because it helps customers choose RAK repeatedly. This requires a significant effort from RAK. I have been hanging around the RAK community since 2020 ( my first order was #4631 - how ironic! ) and I am still frustrated at the SW tools. They are still a mess. I know it’s hard, but it is really important!
To be compatible with future RAK if I need to port my app away from a RUI3 “bare metal” service layer, what API should I be using? Should I still be using the Arduino API, and it’s just Zephyr under the hood rather than Mbed, or is the future based around the Zephyr API directly?
It seems to me that if you want to pick up and retain customers who started with Arduino, then you need to stick with the Arduino API and put real effort into RUI3 - fix the boot loader chaos and provide the BSP that enables debugger support. If you want to pick up customers who already use Nordic Connect SDK or the other equivalent options from STM32 or Ambiq Apollo, then I can’t see the point in going through the Arduino API.
I could well be wrong on various points, but I’m currently trying to work out which is the best way for me to move forwards. I would welcome any feedback from RAK or from any other forum members who read all the way to the end.