Embedded - 458: Fiddling, DIY, and Cursing

Episode Date: August 31, 2023

Trond Snekvik spoke with us about developing VSCode extensions and Bluetooth meshes. Trond is a Staff Software Engineer at Nordic Semiconductor. Nordic’s Visual Studio Code Extensions include device tree and kconfig support for the Zephyr project as well as tools for nRF Connect.  Trond’s github page: github.com/trond-snekvik In 329: At Least 32-Bits, Thank You, Kate Stewart of the Linux Foundation spoke with us about Zephyr in 2020  Transcript Thank you to Christopher for providing a picture of what may (or may not) be a troll.

Hello, and welcome to Embedded. I am Alicia White, alongside Christopher White. Our guest this week, BLE expert, VS Code experts, troll expert, possibly. We have Tron Snekvic on the show. Hi, Tron. thanks for joining us today. Hey, thanks for having me. Could you tell us about yourself as if we met at lunch at, I don't know, Electronica? All right, yeah. My name is Trond Snekvik. I lead the Visual Studio Code team at Nordic Semiconductor. There's a bunch of TypeScript in my current work, but I'm actually

an embedded developer. I've worked for Nordic for nine years now, and I spent the first seven of them on the Bluetooth Mesh team, where we made the Bluetooth Mesh part of the NRF5 SDK, and then later the NRF Connect SDK. So when I transitioned to working on the new SDK, I started making some small VS Code extensions as a way to get familiar with the new languages and concepts, and I ended up publishing them on the Visual Studio Marketplace. At the same time, Nordic had a lot of internal developers

who were a bit unhappy about the current tooling situation, so we started pushing for Nordic to publish an official VS Code extension. We eventually got our way. And after splitting my time between Bluetooth Mesh for a while and VS Code, I'm now leading the VS Code team. And I've transitioned out of C programming altogether. All right. So that covers the Bluetooth mesh and the VS Code. Now let's talk about Trolls.

Are you ready for lightning round? Yes. What's the coolest place to visit in Trondheim? Ooh, I think it's our cathedral, probably. We have the northernmost cathedral in the world, which we're very proud of. But if you go to Norway, you should go and see the nature. All cities have some unique thing that they're proud of, but the nature is really the thing to see in Norway. You are named Trond, and you live in a city called Trondheim.

Yep. Are you the only person there? Yes, I am. It's me and two other Tronds. Is the city named after you? I don't think I can claim that. The

Trond actually means a person from this region of Trondelag, where Trondheim is the capital. So yeah, proper local guy. Have you ever seen a troll? I'm afraid I'm not allowed to talk about that. Okay. Have you ever seen the Aburra Borealis? Yes, we have that a few times every winter here in Trondheim.

But if you go further north, it's much more intense. I really recommend it. Have you gone intentionally out to see it? Yes, we do. It's great. What is the best wireless protocol? I have to say Bluetooth Mesh, don't I? You don't have to, no, you really don't have to. It's just us, you can tell us the truth. This will never air. Oh, right, okay, then it's something else, yeah. No, I think it depends a lot on what you do. I think Bluetooth Mesh is the best one for

a certain use case. If you could teach a college course, what would you want to teach? I think in general universities spend a bit too much time on theory and computer science when what we really need is engineers. So I think some practical hands-on development course because they're always fun as well. I'm going to go with

the old standby. Favorite fictional robot? The right answer is R2D2, isn't it? No, no, no. No one will be mad. No, you can say BB-8 as well. Oh, I was actually going to say the mouse droids then. Oh, yeah. Okay.

Yeah, the RC cars with lunchboxes on them. They're nice. Do you have a tip everyone should know? Yeah, I think no one knows that you can select a piece of code in VS Code in your editor, and then there's a command that will stage it in your source control. And every time I do that, people are surprised. But it's such a great little feature, and no one knows about it. So that's one.

Select some text, and then you can buy the keyboard shortcut to just stage it in Git and it's off. Oh, so it will add the file or will it make a commit for that? No, just to code you selected. So it'll do essentially a Git add I suppose, but yeah.

Oh, okay. Okay, I'm going to have to try that. Okay, so you just add the part you selected and nothing else. Okay. I can see that. That would be kind of cool. Yeah. That would actually be really cool.

Especially for comments. I was thinking more for files that, if people have different hardware, you don't have to check in the whole file. It's true. I think for me i i get easily distracted and i will as soon as i see something that it's not really the stuff i'm working on but i should just fix this really quickly i'll go and do that and then uh my commit

looks messy if it's like 10 things i thought i should fix this in addition. So very, very handy if you struggle with focus like I do. You said that BLA mesh was probably your favorite protocol. What cases does it work best under and what cases is it not good for? By far the best case, which is really what this was designed for, is controlling lights and reading sensor data from a network. So Bluetooth Mesh doesn't have a structured network in the same sense that ZigBee does, for instance. So all the devices can listen to anything around them and repeat it. so messages travel really fast and it's very reliable in that fashion because if some node goes down it's not going to be the center of a

cluster or anything it's just uh your message can just go through some other place and it's going to do go through your network in the quickest path possible so that's easy to set up and it doesn't break just because you swapped two light bulbs around or anything like that. So for light and light control, I think it's excellent, and I don't think any of the other protocols can beat it for performance or usability. I'm pretty ignorant on BLE mesh.

Is it BLE mesh or Bluetooth mesh? I think officially it's Bluetooth mesh, but it's built on top of BLE mesh or Bluetooth mesh? I think officially it's Bluetooth mesh. Yeah, but it's built on top of BLE. How long has it been around? How long has it been functional? Well, I have several dumb questions that I'm stacking. How long has it been around? And is it something that rides on top of existing Bluetooth

and it's just like, we need this firmware, or is it a completely new radio setup and all of that? I think it's just a new stack, but I'll let him answer. I'm asking. Yeah, I think development was started in 2014 or 2015, but it didn't go public

until, I want to say 2018. Don't quote me on that. So it's been around since then. And it was designed to work with existing hardware. So if you had a BLE device in the field, it could do mesh just with its existing capabilities. So it introduces nothing new below the gap layer, as they call it. So it's all

advertisements and scanning. And that's all it's ever doing. And everything fits inside an advertisement packets. And every device is both an advertiser and a scanner at the same time. With Zigbee, if you don't have it set up, you end up with cascades of messages going in circles. How do you prevent that? So it has two mechanisms for that. First, it's time to live, which I think every protocol like this probably has. Yeah.

It also has a network cache. So by best effort, the devices will keep a cache of the latest N number of messages that they've seen. And if they see N message again, they will not relay that one. So all in all, the loops are super rare. And if you get any loops like that, at the worst, it'll die when the TTL is used up. but nothing else. It usually means that you should have spent those extra 30 bytes on your network cache.

But BLE was always intended to be a low-power protocol. Yeah. But Mesh is an always-on thing. It is. Oh, it's for lights. Lights. Plenty of powerful lights. Yeah.

Compared to, I think, classic Bluetooth, it's still low power, but it's definitely the... I don't think you could find a way to make BLE use more power than you do with Bluetooth mesh. Because scanning and advertising, even though it's rx and tx it uses about the same amount of current um in the radio peripheral anyway so it's basically on all the time and you're drawing uh with modern parts somewhere between two and five milliamps just constantly uh so it fits well with lightning like that's that's nothing if you put it in a light bulb.

But there are modes to put low power nodes in as well, where if you have a light switch that's on battery or even on some sort of energy harvesting device, it can send messages without scanning continuously. And it can elect something they've officially named a friend node in the network, which is very cute. So your friend will take care of the incoming messages for you, store them in a queue. And then when you feel you have the energy, you can ask your friends to give you all the messages

it has received for you for a while. So it's like having your neighbor keeping your mail for you. For firmware update, do you go over the mesh? Yes, and this is something that's on its way into the specification now. So it's public that it's on its way in. I think right now it's still not ratified, like an official spec is done, stamped and gone through the organization. But yeah, there's an official DFU service type of layer on top of it where you can organize

it with having devices spread the DFU around in your mesh. So you can set up a device to quickly receive the update from your phone or your connected device somehow. And then it can spend all night just making sure all the other devices have them. And then you can trigger a simultaneous upgrade on your entire network. Does this mesh protocol run anything like spanning tree

or any sort of routing protocol to kind of establish the graph of the mesh and find loop-free routes? Or is it kind of just a free-for-all and we send things everywhere? It can't be free-for-all. Well, you know. That's true.

That would be my first naive implementation was broadcast free-for-all. Stars to stars. Yeah, it is pretty naive. There is a routing-like mechanism that's also coming in. So I'm actually

kind of backed out of the mesh work before I got to see how that actually works. But as far as I know, it's pretty similar to the routing in 15.4, where devices will figure out a small list of routes where they know whether they're about to send something up the tree or down the tree. Okay. One of our listeners, Thomas, says hi and asks, how many mesh stacks have you written now oh i know who this is yeah thomas and i worked

on uh worked on the mesh team for the uh with the nrf5 sdk i think uh and the answer is i think four i uh i wrote uh i actually did uh the topic of my master thesis before I joined Nordic full-time was Bluetooth mesh as well. So I made two proprietary network protocols with Bluetooth as part of that. And one of them is very naive, but it kind of works. And we published the source code for it. And it's actually gone into real products. But I think now that Bluetooth Mesh has Bluetooth Mesh proper, it's more of a curiosity and a nice little demo.

There are many naive ways to create Mesh networks, mainly because it's a really hard problem. Are there two or three things that, as you learned them, mainly because it's a really hard problem. Are there two or three things that, as you learned them, you really wish you'd known at the beginning? All the time, really. I think, especially with the ones that I did myself for my thesis, the first one was naive and the second one was overly complex and it just uh

did all kinds of clustering and all kinds of stuff that kind of works until you poke it uh so going back to the more naive of just everyone sees everything and can forward if they choose to uh and seeing that actually working and it doesn't matter if it's not super power efficient or anything uh that was uh almost a disappointment for me because i spent so much time trying to solve problems that didn't actually need solving uh one more dumb question for me uh is bluetooth mesh, or is that something else? That's something else, yeah. Okay. So Thread is 15.4, so it's like ZigBee, but not quite ZigBee.

So Bluetooth Mesh is an entire different thing on its own, and it doesn't operate with the same IP address system that those protocols do. Okay. I have devices that have Bluetooth, but I guess they also have thread radios or something. Okay. How many of these competing IoT mesh radio protocols are there now? Yeah, good question. There's way too many. And companies like Norik need to try and do all of them

until we figure out who's coming out on top. So we're not that competitive internally, but there is definitely the Zigbee team, there's the Thread team, and there's the Bluetooth Mesh team. And we all wanted our stuff to win. And for a while there, like five years ago, it looked like we were in a race. And by the end of 2019,

there's going to be one protocol to rule them all. And it turns out the situation is more like that XKCD. There's no one protocol to rule them all. It's just now there's 15. Yeah. Bluetooth Mesh and ZigBee can run on the same radio. So it's the same hardware, right? It is in Nordic devices, but it's not automatically the same way

because the frequency modulation scheme is different between the two. So we have two versions of the NRF52 out. One is the 52-832. The other is the 840, which came a bit later. And it's only the 840 that can do both of these. The 832 can only do the

Beely frequency modulation. Okay, I have a whole bunch of questions about Bluetooth, but I think we invited you on the show to talk about VS Code. We've got plenty of time. I know, but I want to get back to the VS Code because otherwise I'm going to get lost in Bluetooth because I really do have a ton more questions. Okay, we can come back to that. You said you made some tools for yourself. You put them on the... Extension store.

Extension store, Microsoft's thingy-bob. And then Nordic said, hey, that thing you're doing off work time, we want it to come ahead this team. Is that kind of how it happened? Kind of, yeah. So, yeah, I did this in

the evenings. I think it was really I wanted to learn TypeScript and I've always been fiddling with the IDE configuration. I used to work in Vim and I learned VimScript and

fought the uphill battle that is trying to add extensions in Vim and I learned Vim script and fought the uphill battle that is trying to add extensions in Vim but yeah so I ended up doing them partly partially because it was a fun project that was very got quick results especially compared to doing C development languages like TypeScript you can just see results on such a different timeframe. That was very inspiring. So yeah, I ended up doing this. And then at the same time, we were several, we actually found in the office

that none of the developers internally were actually using the tooling we were telling our customers to use. And that's really, it's not unexpected. I think everyone, well, I'm going to fire

some shots here, but everyone who's tried to use some sort of Eclipse clone thing handed out by their software vendor will eventually say, these guys have never actually felt this pain, have they? I want to cough and say a bunch of names, but I would have too many names to say

and I can't cough for that long continuously. Yeah. And Nordic was kind of, we were one of them. We weren't any better. We didn't use the tools ourselves. A big part of that was because the tools were centered around application development and we did SDK development. So normally you wouldn't, like you'll build it with an application, but the application isn't the point. So we weren't in the target demographic for the tooling itself. So we saw that everyone was actually using VS Code. We could walk around the office and just on the screens,

there would be perhaps 10% would be in some sort of terminal Vim or Emacs thing. And then another 10% would actually be using the tooling we told our customers to use. And then the rest would be in VS Code or Sublime. So we saw that and said, this is nonsense. We're all spending a bunch of time setting up, fiddling with the VS Code configuration. And probably our customers are as well. So we went to product management and they said yeah in the feedback we're getting from customers they're basically saying the same thing you guys are seeing here. A lot of people will

only call the command line API for the vendor tooling. That's not just with the stuff we provided, but any tooling. And then they edit the stuff in VS Code, and they'll go into the editor, whatever it is, and hit compile, look at the errors, and then go back and edit it in VS Code. I do this, yes. Well, you can have a little shell in VS Code, so you're still in VS Code. Mm-hmm. Mm-hmm, mm-hmm. I do this, yes. Mm-hmm. Well, you can have a little shell in VS Code, so you're still in VS Code. You just have your command line, you know, in a little panel, right?

So that's an IDE, isn't it? It's integrated. It's embarrassing to swap between STM32, Cube, IDE, and VS Code always. And they have separate key commands commands and it's just irritating. But yes, okay, so everybody else is irritated and you have solved the problem. Well,

that's, well, I wouldn't go that far. The extensions I've added for myself were device tree and kconfig. So they're the configuration languages used in zephyr for configuring software which is the kconfig one and then configuring the hardware or software's view of the hardware itself which is device tree and i hadn't spent like i'm

i i've never been interested in like rebuilding the the Linux kernel or any of this. So both of these were unfamiliar to me. I hadn't touched them before, so I thought I'd try making extensions to do syntax highlighting for them first. And then I found that even with the syntax highlighting, I struggle to write this. So I'll add some verification errors as well and get some error squiggles

if I fail to use the exact syntax device tree needs to write out the number. So it just evolved from there, but it was always just those two languages. And then the actual, the bigger problem is managing your builds and making sure that IntelliSense works and knows about your application and setting up debugging.

So there was still a ton of stuff missing when I'd done my thing. But luckily, we had managed to get the project running internally to just make a prototype of what an extension like that would look like where you manage your builds and you set up debugging automatically there's less fiddling less diy and cursing so that is really the centerpiece and the extensions i made they are uh they're now absorbed into the group of extensions that we offer, but they're not center stage. They're just supporting extensions.

And we spend most of our time on what started out as just a small prototype project and turn into the orchestration of the configuration, which is really the centerpiece of the extensions today. But you were a Vim guy. And there were wars. I mean, I remember the great battle of, I don't know, I need to make something up here about Emacs and VIM, and I'm not going to. Emacs won.

Fix this one later. So, how did you, how did VS Code work? I mean, it comes from Microsoft. How did Vim people go to VS Code? Did they? Well, I did. Okay.

I actually, I found that the stuff I wanted Vim to be, I wanted Vim to be, I wanted Vim to be an IDE. That's what I actually needed. The shortcuts are cool. The ergonomics of Vim is just far superior to VS Code, even when you do VS Code properly

with using multiple cursors instead of search and replace and all these things, just moving around in the code, I think I still prefer Vim. I actually write my commit messages in a Vim instance in the terminal in VS code. I thought everybody did that.

It's good to hear. Yeah. For some reason, I only use Vim for any commit messages. That's the only use I have for it. Alicia was, her eyes were boggling at some of the things you were saying there, multiple cursors and things. I think there's a class of developer like myself and maybe Alicia that, you know, we get a window and some arrow keys and we're pretty much okay. And we don't think much beyond that.

Maybe we learn a few keyboard shortcuts. Well, because I don't like to use a mouse, but yeah. But then there are these super beings who learn all the esoteric features of editing and they can integrate their mind into the IDE. I don't even know what multiple cursors means. And I've been doing this for 40 years. No, not 40. How long?

You know, you can actually start saying 40 as long as you don't count the unpaid time for the first 10 years of unpaid time. Anyway, but to derail slightly, I'm going to boil that to a question. Are there things that we should know about in editors that we really aren't using? It's hard not to say multiple cursors right now. Okay, that's fine. I don't know what that is. Tell us about multiple cursors. Okay, sure.

Yeah. So if you select a word, you can press control D, I think, in VS Code. And if you keep pressing control D, it's going to find the next word that's the same thing. Okay. And that will add it as a cursor. And then if you have like four instances of a function name in the same file, you can rename the function this way. Okay.

I think I've accidentally used this. Yes. Yeah. I've definitely used it. I didn't. Okay. Yes. But I just thought of it as some fancy search and replace sort of thing.

It can be that. And then you can start, like if you have a massive array of structs or something that you need to add a prefix to all of them, you can start doing stuff like that. So it is really a fancy visual search and replace everything. But you can also insert it at multiple places, so it's not just search and replace. Once you search, you can insert, yeah.

Yeah, true. And you can add, I think if you hold down Alt, the Alt key, and click around, you'll add a cursor at every place you click as well. See, that's cool. So, yeah. Now you can have 10 cursors and write code 10 times faster. That's it. I'm a 10x developer.

This is it. I've done it. All right. Back to the extensions. I'm sorry. All right. I think I've forgotten where we were. I know that a lot of people make a color theme as the very first VS Code extension. That seems to be the hello world of just getting something into the Microsoft extension world. How hard is that? It's not terribly hard, but you need to do it. Actually, the color themes are fairly easy. They're a massive JSON file.

Then you just look in their documentation and it'll say, this, a function name in C is defined by this ID. Then you just put in that ID in the JSON file and give it a CSS style color thing and you're done. Like now all your function names are pink or blue or whatever you want. So those are static and fairly simple, but they're completely separate from the other mechanisms that you would add in extensions. So you have those and then you have the syntax highlighting. So that's where I started, really, with trying to make syntax highlighting for kconfig.

And for a GCC map file. Yeah, true. Yeah. So that as well is just, that's a series of regex just over in Oregon with nested scopes and everything. That one's a bit, it's easy to do something at first and then you have to fix all the corner cases that you missed. And people will keep making issues on your GitHub repo

for years and years about these corner cases that you miss. So I'm still fixing those. The map files are very, they're not bad. So the ones I made for map files, I don't think I've updated that in like two years now because map files are proper, good and proper. They look the same every time. And they have some sections that basically look the same

as long as you made them with GCZ. And they always look horrible. Yeah, they do. I mean, even with highlighting, what I really want is something more graphical, but I need to do that myself. Yeah, ideally it would output in YAML or some format like that so that you could process it through something and present it and filter it the right way. But it doesn't seem, it's not going to happen. I think it's pretty safe to say. Because what these highlighters are, are text to text.

It's just, you're highlighting text. You're not making pictures out of things. Yeah, true. So it's all about identifying scopes and everything, but obviously with languages like C or even worse, C++, it's all contextual. Like the bracket left in C++ can both be the start of a template definition and the start of a shift left operation.

And a less than. Yeah, that's true. That's the simpler one. Yeah. So it's all done with regex as well, and then it's nested stuff. So those can get pretty complex eventually, but getting some color in there and having some basic syntax highlighting is not too hard. And you don't have to do any TypeScript or any of the other massive realms of development is what it feels like from the outside. And you have an RST highlighter, which is restructured text or something like that. I mean, I found it recently as something that was kind of competing with Markdown and I frowned at it because Markdown's awesome.

Yeah. Why have something else? Yeah, I know we're right. Making that one as well, I think since I made this syntax highlighting thing for it, I'm close enough that I'm allowed to say that that's not a great language. Well, good.

When we have Markdown, I get that you would choose to use this. There's some nice macro syntaxes and some nice ways of structuring tables, but why would you not use Markdown? Okay, so those are the easy ones. Those are the ones that if somebody was motivated, they could make their own theme

and put up a couple of highlighters pretty easily because those are files you can find online and copy and edit and do what you want. And then as soon as things get complicated, you can just throw it to the shocks and run away. And it's descriptive, it's not code. Right. And at any time. It's not code. Right. And at any time, what you're looking at

is the output of what your thing is doing. You're not compiling and changing things. And you're not telling people to install other things. True, yeah. Okay, the device tree, this is something Zephyr-specific, right? Well, it actually came from linux so uh they found i think i'm i like i said i'm not i don't haven't done a lot of linux stuff but my impression is uh before device tree uh you would write all these board support packages for linux

that would be basically a bunch of the same drivers. It was a big mess. And then they found that what if we make a description language for hardware? And then if your hardware has an SPI bus at this address, you will describe it in device tree instead of compiling a library over again with a different address from the one you stole it from. So it's description of hardware from the software perspective. And in Linux, it compiles into this little binary that goes into the runtime. And when the SPI driver initializes, it'll figure out that the hardware address it needs to talk to is at this address

and then a bunch of other details about it. And it'll do that at runtime. So you can use the same driver compiled once, but use different configurations for different hardware underneath to a certain degree here. And in Zephyr, it's almost the same, but to save space, it's static. So it'll generate all these static variables for you, or actually their preprocessor defines.

And then you will use a macro system to reference the nodes through this. So the drivers are structured this way where you can define, if you have two nodes on an SPI bus and they're both environment sensors, for instance, you can add them to your device tree code and Zephyr will have a driver for it most of the time.

And it'll just instantiate two instances of the driver with each of the, in the SPI bus case, it'll take the enable pin and map it to the right one automatically based on this static configuration. When working with microprocessors, not Linux, is this device tree more about the processor and where it puts the spy bus or more about the board and what's on the board like a humidity sensor

i think it's it's in the middle uh so it's the board as seen from the processor so it won't know about your uh what size capacitor you've put uh to to reduce noise on the on the peripheral that you have there uh but it'll know exactly what wires are connected to the peripheral because that's goes straight into the processor and you'd actually it's it's like you're you're standing on the board with a flashlight and you can shine a light on all the peripherals that you can see from the processor, but whatever is behind them is hidden from you and you don't really need to know it most of the time. Okay, maybe I'm going to ask that again.

Some pins have alternate functions that they can be used as GPIO or SPI pins or clocks or whatever. Does the device tree know how to set up those pins so I can just say, connect me to this spy driver to this humidity sensor? Or do I have to do all of the pin configuration and then... And then device tree. And then the device tree does the higher level stuff. No, you'd actually define the pin configuration stuff in device tree, aesthetically. There's a concept that arrived last year, which is pin control. There were variations of pin control in Cephyr for a long time,

and they're vendor-specific. So they tried to standardize this into pin control where you can have multiple states for each pin. So say that you have an SPI bus, but sometimes it's an I2C bus or something on the same pin, and you control it with some chip-enabled pin, then you can define that in pin control as well and set up these states too, if you want.

So if your pins are asleep most of the time, you can set up a sleep state where your pins are disconnected from any sensing input, and then you can at run time switch between the states that are defined statically, but swappable while your code is running. And this is for Zephyr, which is an RTOS, which I guess we probably should have noted long ago, but if you are still here and you made it through that first discussion of BLE Mesh, we're going to assume that Zephyr was on your list anyway. Anyway, is this only for Zephyr?

Has Nordic gone full Zephyr? You didn't always need Zephyr to run the Nordic chips. That's true. Nordic actually is full Zephyr now. Okay, cool. Yeah, well, you can still download the nrf5 SDK. And I think the distinction we're making is if you're making a new design, don't use the nrf5 SDK. But if you've already spent a bunch of time and you have a design and it's already running on the nrf5 sdk but if you've already spent a bunch of time and you have a design and it's already running but i finally learned the nrf5 sdk no sorry go ahead yeah so uh yeah so we're

uh all the new chips we'll be putting out will be uh on the nrf connect sdk and it's based on zephyr so it's not quite not quite technically a fork of Zephyr with a bunch of stuff on top, but we keep the fork pretty closely integrated. And then with Zephyr's Quest management system, you can combine multiple Git repositories into one system that isn't defined by Git submodules. And

we extend it through that, really. So, from the outside, Zephyr looks like it's baked into, it's like the foundation of the NRF Connect SDK. But really, the NRF Connect SDK is a fairly, like, code-wise,

it's organized as a separate repository that depends on Zephyr. Was that a big shift? I mean, it sounds like a huge shift because, yes, but was it? Or had you already been creeping towards Zephyr for years? No, it was a huge shift. It was engineer-driven, the whole process. So we were, I think,

in 2018 when we started, when we made the NRF Connect SDK repo and set everything up. We already had NRF 51 and 52 in its two variants, and we were going to add more hardware at the time.

We now have the NRF 53 and the NRF 91 as well. And we saw that we spent a bunch of effort trying to get hardware support for all of these in the NRFP5 SDK. So we looked around and saw we need some common code base here,

some way to abstract this. Otherwise, we will have to triple our software department every time we add a new chip. And for us, Zephyr seems like the answer. It's run by the Linux Foundation. It was already well underway. It wasn't quite that 1.0 when we started contributing to it. But yeah, we genuinely think this is going open source like this

and having a collaborative project like that will benefit not just Snorriq, but our customers as well in the long run. We've done a couple of shows on Zephyr, so we'll put those in the links if people want to learn more about it. Yeah, they were older shows. We should do a new show on Zephyr sometime soon, because it's changed a lot. I feel like they were within the last year, but my sense of time has probably ceased to be accurate. I think that's really cool. I think getting away from what a lot of vendors have done historically with just very proprietary stacks all the way from the IDE down to the HAL.

It can only be good for everybody. I think so. I think we're... I'm seeing this from the software tools perspective of the organization, but we're trying to be more open, I think, especially with the IDE situation. Vendors have generally used IDEs as a way of getting luck in,

thinking that if you spend enough time in an Eclipse clone, you will be unable to write code in another environment. Well, you will be unable to write code in another environment. Well, I might be unable to write code anywhere. What happens to me? Yeah, that's success, yeah. So the overall idea, as seen from my perspective in the Visual Studio Code team here, is we are trying to be open,

and we're trying to make Z're trying to make sephir the best artist and environment for for uh completing your products out there and at the same time we're trying to make uh nordic the the best vendor for sephir so both of those approaches means that we're going to, we're spending all our effort doing stuff that's aligned with what our customers actually want. We're pulling in the same direction. We're not trying to force you into some lock-in by making it hard for you to leave. We're trying to make you want to stay with us because we're actively trying to help you. Again, I want to cough a long list of names

for people I'm looking at, but no, no, we'll be good. One of the really hard problems with tooling teams is that you have multiple different kinds of users. You have your internal users, which we've mentioned tend to not always use the external user customer interfaces because they want different things. But then you have external users who want access to everything, whether they need it or not. You shouldn't be touching that. And then you have the other users that are just like,

I am developing a product and it's hard enough and I don't want to know anything that I don't need to know that involves this processor. I just want to work on my algorithm. Leave me alone with the microprocessor. I want to install this ID and it already knows my board exists and I want to click on the board and you have it all set up.

And I miss IAR and I'd be willing to pay for it because it was nice to just click on something and be done and not have to dork around with launch files and tasks dot JSON. Or being able to cut and paste debug information or use more than one CPU core.

Not having to look at the gdb command and wonder how to get rid of all of that random text that just keeps flowing by. I'm sure we're leading to a question here. Oh, yes. Sorry. You end up with a wide range of people who use your tools. And that range is hard to satisfy. How do you prioritize the different kinds of users? Do you identify them differently? Do you curse them differently? I don't know. Yeah, we do identify them differently. And I think you've covered the identities that we have used here. So definitely the internal developers, it's the same as the problem

that I said earlier, where the tooling is made for developing applications and the internal developers are making an SDK. We still have that problem, but we are able to support them a lot better now. First of all, because we understand the problem. My entire role in this project is defined by I was frustrated when I tried to develop SDKs

with the tooling that we had. Now I'm here. So we tried to mix that background that we have where when I was trying to add this API, it really annoyed me that I couldn't do this net. So I'm going to add a feature that helps with this net. But then obviously we, at

Nordic, I think we're 1,600 employees now, so our user base is like 99% is going to be our customers. So for that, we try to

prioritize the customers none of the stuff we do actually matters if our customers aren't shipping code faster or getting their product out the door that's the entire point of the software department so we try to prioritize them but it's a lot harder when we're not customers ourselves so uh we try to get around that by having workshops we uh recently uh hired a new developer on the vs code team and uh he just finished his application project which uh he did where he was basically

assuming the role of a customer and making a little product. In his case, he made just a sensor device that would, over Bluetooth, tell a device with a servo to wave when the accelerometer waved. So super simple project, but seeing the stuff he struggles with

and really using the tool ourself and feeling that pain well that to me that that feels like the only right way to do this uh along with of course listening to feedback from from the users we used to call that dogfooding in Cisco. Yeah. I don't really like the term. It's a bit gross, but yeah, we've called it that as well. And I think it's like we

when I was making developing for Bluetooth Mesh, we were making APIs and APIs are kind of similar. There are so many levels of control a user might want, and you'll never be able to satisfy all of them without confusing the rest. And then I think nothing like that

where you're designing for a user, especially a developer, nothing like that where you're designing for a user, especially a developer, nothing like that is really finished until you've tried it and failed and fixed the problems that you experienced while trying it. You have people on your tools team now, and you're the lead of the tools team, partially Because this started out as something you did external to Nordic. But you also did a thesis on BLE mesh and deep embedded code over many years. How's it going being in charge of a tools team and not playing with the microprocessor. Yeah.

Ideally, I would immediately say that I miss C and I miss some of the development and everything about it. But ironically, the tooling for a language like TypeScript is very nice. It doesn't miss us at all. I do. I miss some of it. Hey, I've been doing Python for two years. Don't look at me. Oh, yeah. So, yeah, I think the...

Well, for me, on the Bluetooth Mesh project, we were able to help some customers bring their product to life in a way that's closer to where I am now. But I also feel like I'm able to help more people because the stuff I do now isn't just for the users of the Bluetooth Mesh stack. Which is a significant part of our customers working towards that. But now we've made it so that they all have to use our VS Code extensions to a certain degree, or at least they have to see if they're going to use it or ignore it. So, so uh i'm um yeah along with a just more pleasant development environment of not having to flash your device to try the thing you just did and spending a week writing a feature and fixing memory bugs uh that that really uh is very i actually enjoyed a lot to do this.

And I try to not lose contact with the embedded stuff. And I can still imagine myself going back to embedded development later in my career. Could you get together with Uri over at Walkway and make a Nordic simulator that runs in VS Code for me? Oh, I really want to. It's really great. So yeah, we would like to. I think that's all I've got right now. So having that running and if you can run that, even if we could get to a point where you don't have to wait for two weeks for DigiKey to ship you the development board, you can start

trying out our SDK right now. I think that's that would be a good place for us to be. But yeah, it's a cool project and I think there are several cool projects almost like it. I would like to try and integrate with them, especially if this is something where it helps developers

and you can write code faster by doing it. Closing the gap between the niceties of application development and all the tools they get and where embedded has historically been, that would be so great. The last 10 years have been great. They've been so much better.

The last 10 years have had more progress than I think has ever happened in the embedded development world. But still, there's still a gap. There's still a gap. Yeah, there is. So, yeah, I mean, we're all using, well, it's possible to use C11 now, which is, that's progress.

It's 2023. We shouldn't be saying C11 is progress. Hey, C99 was progress for some people in 2020. I have a couple of listener questions. Benny says, functions such as BLE mesh tend to be complicated to use. That's kind of an understatement. Nordic provides samples, but it isn't easy to adapt these into another code base. Do you have some best practices or recommendations for trying to integrate these functionalities into my project?

Could you summarize everything I need to know in about 45 seconds? Yeah, great. No. Where do we get started? I think the samples are the place to get started in R SDK and any SDK like it. This is actually something we're actively discussing with the VS Code extension and Nordics SDK in general, because this is one of the hardest problems to deal with, because you have to deal with them early

before you're super comfortable with everything about the environment and the SDK. And there's never any, like, no one makes the, I don't know, environment sensor device, and all it's doing is talking to that single API in the driver and printing it to the screen. Like the samples are all like that, but no products are like that. But the samples need to be like that because it's a complicated system.

You need to simplify it down to something I can understand. But Benny's right. If I can understand it, it's probably not what I'm really building as a product. If I can understand it, it's probably not what I'm really building as a product. If I can understand it, it's probably too simple. Exactly. Yeah, so the samples need to be like that.

And I think often the harder, especially with more complex samples where you pull in the network stack and stuff like that, You need to do so much other stuff before you get to the core of the thing the sample wants to show you. So if

you're with Bluetooth Mesh for instance, you would need to provision the device because it doesn't have a non-secure mode. Its security is enforced. You have to add keys to your device. You have to add it to your network, there's an authentication procedure. And all this stuff has to go into every sample in order to get to the point where the sample shows you, oh, if you send this blink the LED message,

it's going to blink the LED. And if you're not with with the apis you'll have such a hard time just wading through all the code in there just to get to the stuff you actually want to see and filtering that out is is daunting so even even the simple samples for a complex enough system they'll they'll be hard uh hard to understand as well and then you first you have to find two samples that do almost the stuff you want to do and then you have to figure out all the stuff that it's doing that you don't actually care about and mentally at least filter that out and then start combining it and yeah it gets complex and it's something we uh ideally we'd like to be better at this at nordic because it's it's it's a friction point like it's something we ideally would like to be better at this at Nordic

because it's a friction point. It's a point where new users especially get into trouble. And you just can't get around it either. You have to dive into it like this. So we don't really know fully how to fix it and perhaps it's not a fixable problem but at least we can try and make the experience as pleasant as possible. It is a really hard problem.

I mean, I haven't used the Nordic products for a few years, like five, seven, sort of. Maybe only four. But I've used the TI, ZigBee, and BLE stack recently. And so I'm going to slag on them them but I do recall Nordic having similar problems in that I had the example that did what I wanted to do with modifying the GATT then I had the example with the DFU

and they actually were both pretty good examples but when I combined them they had been written by different people at different times with slightly different approaches. And so combining them led to weird problems with what parts of the SDK I was using. And of course, as a user coming into this not knowing what is important, I have to support both of these because I can't tell which one is crucial. And it's like you want to keep around your old examples because it's important that people see the old examples and not everybody's going to be on the latest.

But you also want all of your examples to be self-consistent all the time. And I don't see how you can solve both those problems. Yeah, it is tricky. I think one thing that helps a bit from our perspective here is trying to classify different types of applications that we show the customers. So samples will typically demonstrate

some very specific concepts, and we put those in the samples folder. We also have a different demo. Here's a big project. We just call them applications. So we have an asset tracker application that shows basically a full product. It's going to fit on the dev kit

or one of our more fun boards. But in the end, it's like a full, here's how we integrated the Bluetooth and the sensor API together. You would get the callback from the sensor saying I have data, and then you'd put that into the Bluetooth API that says

store this data in the get table we think there might be room for more well there might be other types of applications we could do here where i'm i'm curious about like template applications and having starting points which aren't a demo. They're not printing to the console. They're not trying to blink something. They're just starting points. And they'll enable advertising in Bluetooth, but they won't start sending dummy battery data over it. They're just blank starting points saying, this is the stuff you need. You don't have to delete

anything. You don't have to filter it. Yeah. So I think we can still improve on this from the SDK's perspective. We're trying to see if we can do something

about that. It's a tough problem. Okay, let's see. More user questions. Listeners. Yes, listener questions. We don't have users. Jonathan

asks, what it's like to be a software developer working at a chip company with the majority of other folks writing firmware? He also says that you're great and you're very helpful on the Nordic DevZone and Zephyr Discord. Oh, thanks. Yeah, I think actually most of Nordic is still a hardware company and I always sell this

hardware. And even being a software developer working on the sdk you're still in a minority in a in a silicon vendor type company so the difference going to tooling isn't that big except my uh users or yeah i don't have listeners i have users so i i meet my users at the at the coffee machine sometimes and they'll uh they'll tell me, like, yeah, I tried your debugging thing that you just made, and it doesn't work. Man, please, please fix it.

So I think that's the biggest difference from when we're in a department that is in the minority anyway. The biggest difference transitioning into tooling is that my users are at the coffee machine, and if'm lucky they'll tell me what's broken. If I'm not lucky they'll just say hello and then walk away saying oh that guy doesn't, he should have gone with Vim instead. You had a question for us I I think, about development setup. Yeah, because you guys are working as consultants. I'm sure you have way too many development environments. How do you deal with that as consultants?

So most of the time for most of the clients I've had, unfortunately, I work on Macs. I like Macs as computers. But unfortunately, even though GCC and everything and JTAG servers, all the stuff you need to do embedded development works on Macs, most clients tend to not be set up that way with their tool chain. So most of the time I've got a whole collection of VMs running Windows or sometimes Linux with the tool chains running on those. And I will, depending on my mood, have VS Code running natively in there or VS Code on my Mac and do file sharing stuff.

Less often than that. VS Code SSL is awesome. Yeah, VS Code Remote SSH. Thank you. We'll often use that for various uses. Lately, since I've been doing Python stuff, that is more friendly for Mac, but the targets I'm using tend to be high-powered embedded devices still, so I'm doing Remote SSH into there.

So it's kind of a mess, like you might expect. My wish is that more stuff could be done natively, or that more companies support more client companies, not vendor companies. More client companies would support Mac toolchain natively, because it would make

my life easier. But it's not that big a deal. And the VMs tend to be fine, even though I have to use Windows. We're there to support them. Well, I don't care. They'd feel better if they were using Macs. So, you know, it's better for them, too. I, however, am a native Windows

user. And I will add, most of the client companies are using Macs. And they're all using Macs. Yes. They're also using Windows VMs because nobody wants an actual Windows laptop. And, I mean, I don't use VMs as much. I tend to just go ahead and use my system, which, I mean, has problems if I need Python 2, which I always do. And I use WSL on Windows a lot. But I also have a lot of hardware these days and different programmers.

So I have a Seger, I have an infinite variety of ST links, CCS, whatever, T-I-X-D-S something. Black magic. Cypress had their own thing. Cypress had their own thing. That was small. It wasn't too bad. And then I have what I feel like is every wireless dongle that is made.

I think I have two different Nordic ones, but I don't know if they actually do different Nordic things. I think one is just very old. And I keep three boxes of dev boards near my desk, and that doesn't count the Garage Horde, which has more dev boxes. Although those are all getting pretty old. I think those are, yeah, those are mostly Z80s at this point.

I did order an NRF Thingy 52 to play with. Yep. That looks pretty cute. And most of my other new dev boards are STM M4Fs of one variety or another. Oh, I got a bunch of M0s too, M0 pluses, for a low power thing. Do you find that the hardware, the communication with the hardware works okay from a virtual machine setup,

or does that even more complexity to this matrix? Yeah, I've never had a problem. I have had a problem, which is why I run natively. I've never had a problem. I have had a problem, which is why I run natively. I've never had a problem. I still have a problem. I still have a problem with WSL and GDB sometimes, so that's fun. Or

ST-Link WSL is unhappy, so I end up using VS Code to compile in WSL and Windows to load my... Oh my god. But now that it's in VS Code, it's just two

buttons and once I get it set up, it's fine. Once you get it set up, it's the key. Yeah. But it was pretty irritating to try to, you know, ST link, how do I do the command line? I don't... I still don't really... I end up opening the ST stuff to erase the chip when I need to do a full erase

because I don't know the command line for that. I don't really care. I say I haven't had a problem, but that's because I use Parallels on Mac for virtual machines, and it's excellent. I have tried VirtualBox. I've seen you try to use VirtualBox, and I don't know.

That thing doesn't work very well. It works pretty well, just don't mess with the USB very much. VMware used to work until about five years ago, when I think they sold most of, or got rid of most of the developers, and it has not been good. So there's only really one good VM platform. Let's sell developers. You know, who knows what happens these days. Or users, or listeners. Anyway, to answer your question, it's a mess.

Yeah, okay. That's to be expected, I suppose. Let's see, what compilers do you have installed these days? We both have Cypress. I have Modus Toolbox

and the old one. Oh, I don't. That client is over, so I installed all that stuff. You uninstall these things? Yeah, I take that virtual machine, and I move it to an external hard drive, and then I put it in the Raiders of the Lost Ark warehouse, and then I never see it again.

That makes sense. Yes. All right. Wow. I only have GDB stuff, I think, and maybe STM Cube right now. I have Code Composer and the Cypress stuff. I have VS Code set up to do STM things and Python things for different clients. I have a ROS set up.

Why? You need to learn to delete stuff. Because someday, somebody else is going to want me to use Robot Operating System, and I'll go back to Gazebo, and it'll be fun. But the install you have is eight years old now, by then, and you'll have to install it again anyway. Back to our guest. Ross Kinetic forever, man.

Okay, back to our guest. It's been wonderful to have you. Do you have any thoughts you'd like to leave us with? Yeah, I think for companies like Nordic, our success is really just depending on the success of our customers. So if you guys don't ship your devices on time, we don't make any money either. And the software department that we have and our tools department only exists to make sure that our customers are able to ship products. So if we're doing something that's getting in your way or really annoying you, I think we much rather want to hear about it

than you guys just giving up and then taking whatever editor, for instance, that you'd rather use and not telling us. Like, even if the feedback is this, this is all garbage and you should start over, tell us instead of not telling us, but telling yourself this and muttering to yourself about it. So yeah, we really just want to get feedback

because we don't develop applications ourselves. We make the SDK and we're busy making the SDK. So we really rely on feedback from our actual users using the stuff we're putting out to feedback into that and improve it. So we're really grateful to hear any positive or negative feedback like that. Well, folks, you've heard it here. Quit your muttering and tell all your problems to Trant. Yes.

Our guest has been Tron Snukvik, staff software engineer at Nordic Semiconductor. If you want to look at these extensions, you can find them at Nordic Semiconductor under the Marketplace part of Visual Studio.

There'll be links in the show notes, of course. Thanks, Tron. Thanks. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their questions. And of course, thank you for listening. You can always contact us at show at embedded.fm or at the contact link on Embedded FM. We might pass along some of your notes to Tron. Probably, especially the nice ones.

But now a quote to leave you with. From Henrik Ibsen. It's a liberation to know that the act of spontaneous courage is yet possible in this world. An act that has something of unconditional beauty.