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 getting long so let me break this up just a tad..
In my second example of something being too cooked here, the vendor in question had support for 2 chips, both of which obsoleted. That they had any support for those chips is odd but there you go. That being a silicon vendor I shouldn't expect that they had any support for anything at all, so writing my own drivers for a chip they didn't support was to be expected. In this particular case the chips that I had to use eventually were a lot dumber than the ones they originally used so I had to do some interesting things to simulate what was required of the rest of the stack. But this example is a simple one. It's pretty linear and well defined.
Now suppose I have an accelerometer. You can get those in 2,3,6 and 9 degrees of freedom. You can get those with al kinds of capabilities of how much the can process the data stream before talking to you (and even how they talk to you) and there are those devices that can talk to another stack of devices to come up with extra data to play with.
The combination is, for all purposes, infinite. Furthermore if any of that changes on the board, it's very likely that the structure of the upper layers will have to change depending on exactly how the hardware processes things and under what conditions.
Therefore, the idea that it's even possible to run drivers for exactly what combination of chips and configurations is rather a bit overreach.
To put a finer point on it, to my way of thinking the OS shouldn't even care about peripherals other than things like the clock tree and the NVIC operation.
That said, if there are people who want to have drivers for something, that's fine. Standards are what it important there so that things work pretty much the same way more or less (unless they just can't or shouldn't -- I'll cover that in another section here).
I don't expect that someone would have what I'm after so I just assume I'll have to write whatever I need. Not a big deal as long as I have the underlying drivers for the SoC peripherals there.
Which brings me to the other major point here (continued)
Let me talk about PSoC creator:
This is a special chip that functions more like a gate array with an ARM code in it. That tool won't run on anyone else's SoC because, well, there aren't SoCs anything like it other than e.g. Xlinix. I can do things on that hardware that flat can't be done on other Hardware. The idea that you're going to be able to take and change vendors on an SoC and keep on trucking strikes to the heart of my assertion that this is a Big Iron viewpoint: again, if you don't deeply care about the hardware you're on, you aren't doing embedded. What you are doing is headless desktop code and that's completely different.
Let me give you a historical example: Digital Equipment Corp (DEC). We always used to quip that their OSs proved that they were a hardware company. DEC hardware (PDP11 series) could do some really cool things. Really cool things. The OSs never dealt with it so that was completely wasted on it. Oh, sure Unix could run very nicely on it, but doing real time was something else. I *did* see someone doing a LEM simulator with one that was mighty impressive that was obviously not using DEC OSes to run it.
My point here is that just because some SoC has an ARM core in it doesn't mean that the SoC from vendor A is anything like the SoC from Vendor B. And the nature of that is what drives the application structure and therefore code. I select Nordic because of the crosspoint switch kind of interconnects and because of the very low power it does. Some of the peripherals that are on there are better done in other vendors and therefore, if I need what another vendor does on a particular peripheral, I'll need to use that other vendor to implement things. There is no changing SoC in that kind of code that relies on the underlying hardware (see previous note on embedded).
The other point here is that there is a level of having too cooked a driver that impacts embedded stuff. If there is too much overhead in the driver that isn't needed *for the application* then that driver might be taking too long to do things when I've got time critical things to do.
Take a simple pin toggle: That aught to be at clock speed, not a call to some driver to play with the pin. This should take nS, not uS. Same for pin state checking. These need to be implemented as Macros for the SoC that is being used (different SoCs use pin differently), not as a function call at all.
The same can be said for my I2C example above. If I need response times that are measure in uS, then having all the other crap in there is a problem. Many years ago (like 50), I was taught this lesson using DEC hardware; what they labeled as an RTOS (for those of you who remember RT-11) wasn't responsive enough in the application the engineer was attempting.
The same goes here: Simple is better; Adding complexity removes you from real time eventually. And with 1500 people working on a project, you'll get there real fast.
" We don't want our customers to have to spend time re-inventing the wheel when they switch between different vendors. We wish to 'compete on level ground' with other vendors instead of contributing to creating hardware/software lock-ins for companies and developers because we believe our products are better suited for their needs."
Again, this is a Big Iron viewpoint. Every vendor has a different take on the SoC architecture and peripheral sets. If you're code isn't taking advantage of it, you probably aren't doing embedded. The idea that you can take an application and move it to another architecture (the CPU isn't all that important at the same bit depth) defeats your argument that Nordic (or any other chip vendor) wants to compete on a level playing field. If it was truly level, then the technology under it would be meaningless and so a commodity. They only thing you'd have to compete on would be price and delivery; a losing proposition unless you're the 800# gorilla in the space.
There isn't any such thing as moving one vendor to another without lock in. Doesn't happen in reality. Moving is always a pain because the entire intrinsic structure of the application depends on the underlying hardware architecture. If it doesn't, then you aren't doing embedded, you're doing headless desktop,
Which some of these applications, in fact, are. Don't get me wrong. But that's a Big Iron application, not a Small Iron application. Don't confuse those. Again, things that attempt to be all things to all people generally don't succeed in either.
Best Regards,
rjl
Hello rjl,
Randy Lee said:I don't expect that someone would have what I'm after so I just assume I'll have to write whatever I need. Not a big deal as long as I have the underlying drivers for the SoC peripherals there.
but this is still also an option within the nRF Connect SDK - you can use the nrfx drivers directly, just as you would have previously. In fact, when using Nordic devices (compatible with the nrfx drivers, as configured in their devicetree) you will be using the nrfx drivers 'under the hood' of your application, behind the first layer of abstraction. This topmost level of abstraction is also the one that would let you change out the hardware part and underlying driver in one change to the devicetree, without having to make these same changes to your application as well.
Randy Lee said:I can do things on that hardware that flat can't be done on other Hardware. The idea that you're going to be able to take and change vendors on an SoC and keep on trucking strikes to the heart of my assertion that this is a Big Iron viewpoint: again, if you don't deeply care about the hardware you're on
I would argue that you can both deeply care about the hardware you are on, and also appreciate the opportunity to quick and simply be able to change out some of its parts if the need arises.
It is of course still the developers responsibility to make sure that the part they are changing to can still fulfill the needs of their application, which means that you still have to care greatly and have a thorough understanding of what you part is doing - unless you have ample redundancy in your device - for the project to succeed.
Randy Lee said:Take a simple pin toggle: That aught to be at clock speed, not a call to some driver to play with the pin. This should take nS, not uS. Same for pin state checking. These need to be implemented as Macros for the SoC that is being used (different SoCs use pin differently), not as a function call at all.
I am not quite seeing the point you are making here, because with the nRF Connect SDK(or nordic devices in general, I should say) you can have it both ways through either the function call, or through setting up your hardware tasks to be triggered directly by another hardware event, directly through PPI without any CPU intervention.
Of course if you make use of this latter functionality then you will need to make sure that the part you are switching too also supports this functionality (if you were to change out the part), but that would ultimately still be the responsibility of the embedded engineers.
Randy Lee said:Many years ago (like 50), I was taught this lesson using DEC hardware; what they labeled as an RTOS (for those of you who remember RT-11) wasn't responsive enough in the application the engineer was attempting.
The same goes here: Simple is better; Adding complexity removes you from real time eventually.
Again I would argue that some of this added complexity is a necessity, not a luxury, to be able to make real-time guarantees, which is one of the huge advantages of an RTOS based SDK compared to the older bare-metal one.
Randy Lee said:If you're code isn't taking advantage of it, you probably aren't doing embedded.
Just to make sure that we are on the same page, what is your definition/delimitation of what 'doing embedded' is?
Randy Lee said:The idea that you can take an application and move it to another architecture (the CPU isn't all that important at the same bit depth) defeats your argument that Nordic (or any other chip vendor) wants to compete on a level playing field. If it was truly level, then the technology under it would be meaningless and so a commodity. They only thing you'd have to compete on would be price and delivery; a losing proposition unless you're the 800# gorilla in the space.
I did not mean that we would like to compete on a completely level field across all aspects, and I think you know that - we would like to compete on the things that actually matter, like device capabilities, performance, price, and power consumption. The aspects that I was referring to are those who typically previous have been arbitrary barriers to make it harder for developers to change from one vendor to another, such as the ones mentioned.
Randy Lee said:things that attempt to be all things to all people generally don't succeed in either.
I agree that this is pitfall we must be wary of, but I think we here should be judged on our wide range of SoCs (which is our actual products) covering the different product ranges and product markets rather than the scope of the Zephyr project.
Best regards,
Karl
I want to take care here to separate out my critique here between the various bits involved and not conflate them. Explicitly I'd like to state that I quite like Nordic SoC architecture. It's very good. Very good. Rather unlike a lot of other SoCs and taking advantage of it commit me to Nordic parts which is fine. When one creates something, it is created in a context and a change of context changes the creation. More on that below.
Secondly, all of my projects so far have been with SDK5 and it works for me; I don't have a significant problem with it in structure other than the configuration of it. I would be shocked if nrfConnect SDK was worse than that.
I use FreeRTOS on my projects because it works for me just fine and, yes, there are a number of things that having an RTOS under you makes easier, particularly as we get more complexity in stacks like WiFi or BLE. A person really needs that extra complexity when dealing with the extra complexity. I prefer to do things bare metal, but the reality of things forces change. I do have it instrumented with things like RTT and SystemView hooks so that I can see what's going on really. Coupled with directly looking at bus traffic, I can do what I need to do with it just fine (oh, and I've frozen the version to before Amazon got ahold of it).
What I would like to confine my criticism to is Zephyr and its world view of hardware as being a necessary evil. The fundamental marketing materials of Zephyr pushes this hardware independent view of things; it's easy to change things out and is all based on incremental change from known boards.
Again, this is what I mean by embedded: Firmware is a next layer up from iron (well, not exactly, the next layer up is microcode which I love but no one lets you play in that anymore). It is an extension of the iron. Part and parcel thereof. Zephyr treats it (in it's marketing materials at least) as just so much stuff that has to be there. That's a big iron viewpoint of the world. Basically no different than running off your desktop or a server or something. This is a viewpoint that is widespread these days and wrongfully labeled "embedded" programming. What is, really, is headless desktop programming. I would coin the term "captive programming" to differentiate this from actual embedded which is hardware centric.
That particular thing isn't a Nordic issue, so I don't fault Nordic for it. I wish Nordic had taken a better approach to which RTOS they picked up than they did, but there you go. What's done is done so now your task it to make is usable (easily).
Device tree, as I mentioned, is an abomination. That requires UI over the top of it to replace it entirely (by making it an unseen intermediate file). You want that I should be able to change out bits and pieces easily? No problem: hardware configuration should all be done point, click and build. SDK configuration I'd rather do in code as configuration macros or something (whatever have it well documented which leaves out Doxygen). Leverage the compiler as much as possible and reasonable.
So my charge to Nordic here is to obsolete all the advice that Zephyr prosits about device tree and go to a UI based one, obsoleting everything they have to say about it. Don't get caught up in the marketing hype because it's flat wrong (as marketing often is)...
I want to take care here to separate out my critique here between the various bits involved and not conflate them. Explicitly I'd like to state that I quite like Nordic SoC architecture. It's very good. Very good. Rather unlike a lot of other SoCs and taking advantage of it commit me to Nordic parts which is fine. When one creates something, it is created in a context and a change of context changes the creation. More on that below.
Secondly, all of my projects so far have been with SDK5 and it works for me; I don't have a significant problem with it in structure other than the configuration of it. I would be shocked if nrfConnect SDK was worse than that.
I use FreeRTOS on my projects because it works for me just fine and, yes, there are a number of things that having an RTOS under you makes easier, particularly as we get more complexity in stacks like WiFi or BLE. A person really needs that extra complexity when dealing with the extra complexity. I prefer to do things bare metal, but the reality of things forces change. I do have it instrumented with things like RTT and SystemView hooks so that I can see what's going on really. Coupled with directly looking at bus traffic, I can do what I need to do with it just fine (oh, and I've frozen the version to before Amazon got ahold of it).
What I would like to confine my criticism to is Zephyr and its world view of hardware as being a necessary evil. The fundamental marketing materials of Zephyr pushes this hardware independent view of things; it's easy to change things out and is all based on incremental change from known boards.
Again, this is what I mean by embedded: Firmware is a next layer up from iron (well, not exactly, the next layer up is microcode which I love but no one lets you play in that anymore). It is an extension of the iron. Part and parcel thereof. Zephyr treats it (in it's marketing materials at least) as just so much stuff that has to be there. That's a big iron viewpoint of the world. Basically no different than running off your desktop or a server or something. This is a viewpoint that is widespread these days and wrongfully labeled "embedded" programming. What is, really, is headless desktop programming. I would coin the term "captive programming" to differentiate this from actual embedded which is hardware centric.
That particular thing isn't a Nordic issue, so I don't fault Nordic for it. I wish Nordic had taken a better approach to which RTOS they picked up than they did, but there you go. What's done is done so now your task it to make is usable (easily).
Device tree, as I mentioned, is an abomination. That requires UI over the top of it to replace it entirely (by making it an unseen intermediate file). You want that I should be able to change out bits and pieces easily? No problem: hardware configuration should all be done point, click and build. SDK configuration I'd rather do in code as configuration macros or something (whatever have it well documented which leaves out Doxygen). Leverage the compiler as much as possible and reasonable.
So my charge to Nordic here is to obsolete all the advice that Zephyr prosits about device tree and go to a UI based one, obsoleting everything they have to say about it. Don't get caught up in the marketing hype because it's flat wrong (as marketing often is)...
Hello,
I'm glad to read that you are happy with our SoC's architecture, and the nRF5 SDK! :)
Randy Lee said:there are a number of things that having an RTOS under you makes easier, particularly as we get more complexity in stacks like WiFi or BLE. A person really needs that extra complexity when dealing with the extra complexity.
This is a good way of thinking of it - and also to remember the benefits that comes with it, which it seems you are well aware of already!
Randy Lee said:confine my criticism to is Zephyr and its world view of hardware as being a necessary evil.
I would not have phrased it as strongly, but I definitely recognize your sentiment here.
Randy Lee said:this is what I mean by embedded: Firmware is a next layer up from iron (well, not exactly, the next layer up is microcode which I love but no one lets you play in that anymore). It is an extension of the iron. Part and parcel thereof. Zephyr treats it (in it's marketing materials at least) as just so much stuff that has to be there. That's a big iron viewpoint of the world. Basically no different than running off your desktop or a server or something. This is a viewpoint that is widespread these days and wrongfully labeled "embedded" programming. What is, really, is headless desktop programming. I would coin the term "captive programming" to differentiate this from actual embedded which is hardware centric.
Thank you for clarifying on this - I think this has been part of difference in perspective, and by separating the approaches into 'embedded' and 'captive' programming I think we bridge this gap in the understanding. I dont have any qualms in agreeing that the Zephyr approach to the development is moving towards the edge of what you previously would associate with embedded programming, since hardware is becoming a smaller part of it, but I would also still like to argue that since it still does come down to 'you are developing a hardware product, both by designing the hardware (even though the 'care and efforts' necessary to do so is arguably less now) and the firmware to go with it', it is still quintessentially 'embedded programming'.
Randy Lee said:What's done is done so now your task it to make is usable (easily).
Yes, and I hope you see that we are hard at work in doing just that - not just making it 'usable', but making it a much better development experience that more easily leverages the performance of our SoCs.
Randy Lee said:So my charge to Nordic here is to obsolete all the advice that Zephyr prosits about device tree and go to a UI based one, obsoleting everything they have to say about it.
I cant speak to any future releases or roadmaps, nor that we would make the manual configurations of the devicetree obsolete, but on a general note I think our visions for a UI based option aligns here! :)
Best regards,
Karl
