Hello,
in our firmware development department, we are migrating from nRF5SDK to nRF Connect SDK. So we learn Zephyr and so on. Previously we used SES Nordic Edition. But now we see that Nordic actively evolve VS Code and plugins for it. So the question is, which IDE is more perspective for Nordic? Will you continue to develop SES Nordic Edition? What is Nordic's plan in this regard?
Thank you.
SES is head and shoulders better than VS code environment even now (late 2023). There has been a lot of cleanup on the integration and it's getting better BUT there is a very long way to go papering over the atrocities of Zephyr.
DeviceTree replacement still needs vast amounts of work to make it even sort of sane. The basic problem here is that Zephyrs fundamental view of hardware is flat wrong for embedded programming -- they are big iron people attempting to do small iron and failing miserably at it.
Hello,
When I first made the move from SES to VSC roughly two years ago unequivocally I shared your sentiment about SES being miles better, but as I have got familiar with VSC and Zephyr I am now of the complete opposite opinion - if I may say, the nRF Connect SDK is now definitively a large step forward from the nRF5 SDK.
I will admit that it at first was very daunting to familiarize with Zephyr and the devicetree, but once you overcome this initial hurdle I think you too will appreciate all that the nRF Connect SDK brings to the table for developers.
I would also like to emphasize that we, Nordic, are among the primary contributors to the Zephyr project, and I like to think that we are pretty well-versed in 'small iron' things, if this means close-to-metal embedded application development. However, we also recognize that as our SoCs are getting more complex developers will benefit from not having to take a bare-metal approach, which is why we have taken steps to advance our SDK in this direction.
Is your primary issue with the nRF Connect SDK related to Zephyr being the foundation of the SDK, or with how source control is implemented in the SDK?
Best regards,
Karl
This is a two part problem for me so let me comment on this in two parts: On the Zephyr side, I haven't been able to look inside the kernal yet so I can't say anything about the structure of it really. My beef is about it's world view.
First off, let me posit this: if you aren't deeply concerned about the hardware you are running on, you aren't doing embedded code.
From that my opinion is that the entire hardware viewpoint of zephyr is clearly big iron. The idea that you're going to move a design from board to board precludes the above posit. Just doesn't happen without changes to the application structure itself. If you don't deeply care about what you're running, you aren't doing embedded code.
So let's take this deeper: I don't give a rats ass about how many boards Zephyr supports; it doesn't support my board. Therefore, there are no deltas from some other board, there is only my board. Zephyr idea that everything is deltas from some reference board (or worse from a set of boards) is an indication of this big iron take.
Further, since I deeply care about what hardware I'm on, I want to keep ALL my configuration tightly controlled with my source code (basically AS PART OF my source code, even conceptually). Hardware deeply matters! Code is an extension of hardware.
Also, if you take a look at good IDEs concerning hardware, device tree is awful. My Gold Standard for IDEs is Cypresses (not Infineon) PSoC Creator 4.4.. hands down THE best there is in the embedded space. Shows all the CPU configurations available and allows you to set it up correctly there along with showing you things that conflict. Peripherals are all set up the same way. You generate all the configuration files (.h and .c) this way and it places them into the make directory for you. Simple. Simple.
Edits to drivers are easily made from there and the generator respects those and it's all in the source tree.
Another is MCUexpresso along the same lines although not quite as good. Renesas E2Studio is similar although it goes a little deeper adding threads and some other upper layer configurations and is actually too cooked in the drivers for my taste (if you do too much in a driver, then it is likely that the driver isn't going to work in your application exactly). The mark of good code is when it is used in ways that the creator never envisioned.
Device tree is basically an intermediate configuration file that is missing the upper layers of IDE. Nordic is starting to get there with the device tree editor in VScode but has a long ways to go yet to get to this level of good.
I'll wait for it, but the status quo is terrible yet.
From what I can see about the SDK itself, yes, things are getting better BUT a person should note that sometimes it's a lot easier to just configure things from the init() call.
And, since you're involved in Zephyr I'll note that in most applications a person sets things up and runs that way BUT I've got applications where I change the configuration of the hardware on the fly depending on context of what's going on at the time. Again, if you don't deeply care about the hardware you're on, you aren't doing embedded code.
That's the difference between little iron and big iron. It's not the size of the iron, it's the seamless transition from iron to firmware. (I particularly like to inhabit microcode myself)...
This is a two part problem for me so let me comment on this in two parts: On the Zephyr side, I haven't been able to look inside the kernal yet so I can't say anything about the structure of it really. My beef is about it's world view.
First off, let me posit this: if you aren't deeply concerned about the hardware you are running on, you aren't doing embedded code.
From that my opinion is that the entire hardware viewpoint of zephyr is clearly big iron. The idea that you're going to move a design from board to board precludes the above posit. Just doesn't happen without changes to the application structure itself. If you don't deeply care about what you're running, you aren't doing embedded code.
So let's take this deeper: I don't give a rats ass about how many boards Zephyr supports; it doesn't support my board. Therefore, there are no deltas from some other board, there is only my board. Zephyr idea that everything is deltas from some reference board (or worse from a set of boards) is an indication of this big iron take.
Further, since I deeply care about what hardware I'm on, I want to keep ALL my configuration tightly controlled with my source code (basically AS PART OF my source code, even conceptually). Hardware deeply matters! Code is an extension of hardware.
Also, if you take a look at good IDEs concerning hardware, device tree is awful. My Gold Standard for IDEs is Cypresses (not Infineon) PSoC Creator 4.4.. hands down THE best there is in the embedded space. Shows all the CPU configurations available and allows you to set it up correctly there along with showing you things that conflict. Peripherals are all set up the same way. You generate all the configuration files (.h and .c) this way and it places them into the make directory for you. Simple. Simple.
Edits to drivers are easily made from there and the generator respects those and it's all in the source tree.
Another is MCUexpresso along the same lines although not quite as good. Renesas E2Studio is similar although it goes a little deeper adding threads and some other upper layer configurations and is actually too cooked in the drivers for my taste (if you do too much in a driver, then it is likely that the driver isn't going to work in your application exactly). The mark of good code is when it is used in ways that the creator never envisioned.
Device tree is basically an intermediate configuration file that is missing the upper layers of IDE. Nordic is starting to get there with the device tree editor in VScode but has a long ways to go yet to get to this level of good.
I'll wait for it, but the status quo is terrible yet.
From what I can see about the SDK itself, yes, things are getting better BUT a person should note that sometimes it's a lot easier to just configure things from the init() call.
And, since you're involved in Zephyr I'll note that in most applications a person sets things up and runs that way BUT I've got applications where I change the configuration of the hardware on the fly depending on context of what's going on at the time. Again, if you don't deeply care about the hardware you're on, you aren't doing embedded code.
That's the difference between little iron and big iron. It's not the size of the iron, it's the seamless transition from iron to firmware. (I particularly like to inhabit microcode myself)...
