The Modern .NET Show

S06E12 - nanoFramework: Unleashing the Power of C# in Embedded Systems and IoT with José Simões

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S06E12 - nanoFramework: Unleashing the Power of C# in Embedded Systems and IoT with José Simões
The .NET Core Podcast

S06E12 - nanoFramework: Unleashing the Power of C# in Embedded Systems and IoT with José Simões

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In the rapidly evolving landscape of embedded systems and IoT development, the .NET nanoFramework emerges as a powerful platform that empowers developers to create applications for resource-constrained devices. This stripped-down version of the .NET Framework offers a lightweight and efficient solution, providing a familiar coding experience while abstracting away the complexities of working with microcontrollers. In this article, we delve into the insights shared in an episode of The Modern .NET Show, where experts discuss the capabilities and advantages of .NET nanoFramework.

Net nanoFramework is a specialized platform designed specifically for embedded systems and IoT development. With its ability to align closely with the full .NET Framework API, .NET nanoFramework enables developers to write code for microcontrollers with limited Flash and RAM capabilities. By dividing the framework into various NuGet packages, developers can selectively choose the components they require, ensuring optimal usage of memory and storage space.

One of the standout features of .NET nanoFramework is its ability to boost productivity and facilitate code reusability. The platform employs the same project system as traditional .NET, allowing developers to leverage their existing knowledge and skills. This enables them to quickly transition from desktop development to coding for embedded systems with just a few days of training. Additionally, the framework’s layered approach ensures that the upper layers of the application remain consistent, even when migrating between platforms. This leads to significant productivity gains and minimizes the need for extensive code modifications.

Embedded systems and IoT devices often operate under stringent resource constraints, such as limited memory and processing power. .NET nanoFramework acknowledges these limitations and offers a set of efficient tools and functionalities to address them. While the lack of support for Async Await may seem unconventional, it aligns with the nature of embedded systems, where quick request handling and efficient task management take precedence over complex multi-threading. Instead, developers can utilize multithreading to achieve similar results and optimize their code for improved performance.

.NET nanoFramework emerges as a game-changer in the realm of embedded systems and IoT development. Its ability to provide a lightweight and efficient platform, coupled with a familiar .NET coding experience, empowers developers to overcome resource constraints and build robust applications. With its focus on productivity, code reusability, and hardware compatibility, .NET nanoFramework paves the way for rapid innovation and development in the embedded systems landscape.

Episode Transcription

Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, I spoke with José Simões about the .NET nanoFramework, a powerful platform for embedded systems and IoT development. I was incredibly impressed when José spoke about just how quickly you can get started with .NET nanoFramework and an ESP32:

You grab a breadboard, you stick an ESP 32 module onto it, and you plug an LED or a sensor or wherever, and in half an hour, you have a proof of concept of something that you are building or just having fun with. And this is great not only for learning to code, but to come up with a proof of concept that you want to show to a customer.

If you want to do that in C, I dare you to do that. On the same time, you won’t be able to. Meaning that with that code and that proof of concept, then you can evolve, you can keep working on it, and then you can easily migrate that to a production grade system because you will be using the same code. You don’t have to change much to get it working.

- José Simões

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : Hello, hello, hello!

Welcome to the show. Oh, my goodness. We’ve been working on this episode for a while. We got chatting at MVP Summit back in April of 2023, because I’m not sure when this is going out. I’m hoping for a November release, but it will depend. It’s been a while. My goodness. Welcome to the show.

José : Oh, thank you, Jamie. Very excited to be here, and thanks for having me.

Jamie : Not a problem, my friend. Not a problem. I’m always interested to talk to interesting people, and you’ve got some very interesting stuff to talk about today because I know - we’ll come on to it in a minute - but I know next to nothing about the .NET nanoFramework, and I know almost nothing about IoT. All I really know about IoT at this point when we’re recording, is it’s something to do with Raspberry Pi’s perhaps?

José : A bit more than that and a bit less than that. So I guess we’ll cover that in a moment.

Jamie : Cool. Okay. So I guess before we get started, though, would you mind giving the listeners a bit of a brief introduction to yourself? Maybe a quick, like, an elevator pitch or how you got started in Dev, something like that?

José : Oh, sure. My name is José Simões, and I started coding when I was a teen within ZX Spectrum. So that gives you pretty much an idea on my age. I’m CEO of Eclo Solutions, a company that works with monitoring solutions for a bunch of markets like cold chain info, agriculture, industry, and all that. We’ve been lately working with consulting and engineering services around nanoFramework, and we also work with the embedded systems development from hardware to production. I’m three times MVP on developer technologies and IoT, and I guess this is me.

Jamie : Excellent. That’s a lot of stuff. I do remember one of my first programming gigs was working on some ZigBee stuff, which I take to be embedded rather than IoT, but I don’t know all these names for stuff. Right. There’s too many names.

José : It touches both, so no worries.

Jamie : There you go then. So maybe I should put that on the resume, right? I’m an embedded IoT .NET developer.

José : Yeah, I guess that won’t work. It will hurt.

Jamie : Absolutely. I mean, we all know that as soon as you have 30 seconds of experience with something, you become the expert in it, right? You’re the expert in the team or whatever.

José : You’re right on that.

Jamie : Excellent.

So I guess before we talk about .NET nanoFramework, mainly because I was a little confused coming in, is there a difference between embedded and IoT? And is it more of a personal difference for you, or is it like an industry difference? Like, if somebody was to come to me and say, “hey, Jamie, I want to be an embedded engineer, like an embedded systems engineer,” am I telling them, go get nanoFramework? Am I telling them, Go get a raspberry pi am I telling them, go do some ZigBee stuff. We’re not sponsored by ZigBee or anything like that. It’s just something that I have experience with. What is the difference? If there is a difference between embedded software engineering and IoT based software engineering.

José : Yeah, there are differences, and they also touch. IoT stands for Internet of Things, so that’s things connected to Internet, and that can be an embedded system. But also an embedded system does not necessarily need to be connected to the Internet. If you have a board sitting there, like an evaluation board for a component sitting on your bench on which you connect something and you try a component or a chip or whatever, that’s an embedded system there, and it’s not connected to the Internet, you can find embedded systems pretty much everywhere. From your controller on the boiler, your Garage controller, your set top box that’s connected to the Internet. And wherever you find a board, an electronic board or a printed circuit board, you have an embedded system there. So I guess this is basically it.

Jamie : Okay, so I think we were chatting just before we got started, and I was talking about how I use a hardware recorder. So I run a cable from my microphone into a box called a Zoom H4N, which I’m guessing from your description, makes it an embedded system because it’s an electronic system that is running some software that is not connected to the Internet. Maybe that’s one of those. Cool.

Does that mean that perhaps a power supply is also an embedded system, or are we talking just something that runs a rudimentary operating system?

José : Yeah, it depends on how complex it will be. If you have a display there and you have maybe some current control going on there, I guess that will classify it as an embedded system because there is some sort of computation going on the and you’ll find there a microcontroller inside, so that makes it an embedded system.

Jamie : Okay, cool. All right, so maybe like, perhaps a capture card. So I have a capture card, a USB capture card sitting on my desk, a HD60s+, which allows me to capture the footage going towards an HDMI display and send it via USB down to my computer, so that I can maybe make video based on something I’m showing on screen. That could possibly be an embedded system. Right? Because that’s got some computation going on.

José : Yeah, I agree with you.

Jamie : Cool. Okay, so there’s literally embedded systems all around us, like you said, right?

José : Oh, yes, everywhere. Pretty much everywhere, from the most simplest to the most complex ones.

Jamie : Okay, excellent. And so how does .NET nanoFramework fit in with that then? Because obviously we’re going to have to talk a little bit about .NET nanoFramework as well, because that’s the topic of the show. But how do I go from IoT embedded to .NET nanoFramework? And what is it?

José : Yeah, great question. And .NET nanoFramework fits into pretty much all those because being .NET; and for the folks familiar with it, you have your project system, you have your solution, and then you start adding NuGet packages to do whatever you need to do. And this is exactly the same because this is .NET. So if you need to connect your device to IoT Hub, the Cloud, or whatever provider you are working with, you bring in the network NuGet - possibly the wrapper for the IoT provider that you connect to - and you start coding with it. Instead, if you are just having fun and making a controller for your Sprinkler system, you don’t need any of that because I don’t know if you want to connect that to the Internet. And assuming you don’t, you bring in just the basic stuff with GPIOs and that’s it. So this is how it works in a nutshell.

Jamie : Okay, from what you’re saying there, we’ve only touched on it slightly, a little bit there, but I can use .NET nanoFramework to do some kind of - we’ll talk about what kind of programming in a minute - some kind of programming using my embedded hardware, let’s say, because I know what one of them is. Let’s say I’ve got one of the Raspberry Pi’s, right? Like a Raspberry Pi Zero or something. That’s one of the really small ones, like a proper embedded chip. And I don’t know whether it runs on it, but let’s pretend I can run nanoFramework on there and let’s pretend I want to make some kind of rudimentary server that I can just poke at and say, “give me some data.” I could do that with nanoFramework, right?

José : Yes, you can do that with nanoFramework. Going back to the example I was trying to describe a moment ago, you bring in the NuGet package with a web server and you set up your thing pretty much in an ASP .NET fashion on which you define the endpoints that you are connecting to. Hopefully this is something kind of modern and you’ll have a REST API on it and with a couple of attributes and sprinking some methods there on your classes. You’ll be up and running your web server on which you can connect to and start pairing it and possibly sending data, requesting sensor data or wherever data it’s generating. Just like you do on a traditional .NET application with a REST API.

Jamie : Cool. Okay, so from a 10,000 foot view, I’m using .NET nanoFramework, pull in a NuGet package, I do dotnet new nanoframework webapplication - I’m not sure what the name would be, but something along those lines. And then I hit run and guess what? I’ve got a web server sitting on my embedded device. That’s pretty cool.

José : Yes, that’s about it. The only thing that’s different from your description is that you don’t do dotnet new because we are not in the same page as the .NET tooling. We are still using the old project system, but that’s only a nuance. On this you go to Visual Studio, you go to the project templates and you’ll have there the class template, the application template, as you are used to, just like any other C# application.

Jamie : I just do - in my head, I do dotnet new because I spend a lot of time on the command line., And I’ve told this story several times. The listeners will be bored of me telling the story. But in the intro to every episode, I say dotnet new podcast, because I used to actually spin up new episodes of the podcast recording and all the ephemera that comes with it by doing a .NET podcast in the command line. Because you could do almost anything with the new templates, right?

José : Makes sense. The concept is exactly the same.

Jamie : Cool. Okay, so are we talking .NET Framework? Are we talking .NET Core? .Net 5/6/7 - What I’m calling modern .NET? What is it? Right, like I said, is it .NET Framework with bits removed? Is it .NET core? Is it? Modern .NET. How does that bit work then?

José : Your description with the .NET with bits removed? It’s pretty much a good description for it; because as you can imagine on a small microcontroller with the limitations of Flash and RAM there, you can’t possibly have all the APIs that you have on a full desktop or server computer. So it has to have something removed from there.

What we do, we try to align as much as possible - and that’s been accomplished so far - with an API, which is the same that you find on the full net, let’s call it this way. And then you bring in NuGet packages. And we have this pretty much splitted and various NuGet packages for the simple reason that when you’re building your embedded system or your project nanoFramework project, if you will, and because the flash and RAM are usually sparse, you just bring in the absolute minimum that you need so you don’t go past those limits of the available memory and flash storage.

That said, we have an alignment as much as possible with [the .NET] API. The only difference that you’ll notice is that we don’t have support for generics yet, but that it’s in the works. And the other most obvious thing, we don’t have also the async and await pattern there, although we have multithreading and all that stuff, we can do pretty much the same, just that we don’t have the async/await pattern. Apart from that, all the basic stuff from mscoree.lib, like string manipulation, byte arrays, encoding, whatever you have there, math library, all the same API as you have on the system.NET for networking, sockets, all that stuff, it’s there and it’s the same.

You can follow that mantra from .NET, “you compile once and you run everywhere.”! It’s pretty much the same, although our execution engine is different, because it has to run on a microcontroller. But basically this is it. You can port your code from a desktop application, you can share code from your desktop application and nanoFramework, project all that is possible and everything that the .NET ecosystem allows you to do, you can do it with .NET nanoFramework.

Jamie : Okay.

I mean, that makes sense, right? Like the current lack of async/await makes sense because you were saying earlier on about how it is you’ve got an embedded system, you’ve got very small amount of memory to play with. You don’t necessarily want to have to deal with setting up the whole task management and the finite state machine and awaiting things. I’m imagining an IoT or embedded system situation where you don’t really want to be hyperthreaded, you don’t really want multiple threads. You want to be able to take a request and deal with it, send the response out straight away. You don’t want to have to take a request, put it on a thread, fire up a new… put it onto all sorts of stuff. You’re not doing multi user, you’re not really aiming for millions of people sending requests all at once. You’re likely aiming to deal with maybe, I don’t know - I’m going to just pull a number out the air, I’m going to be way off - but like maybe ten requests every second rather than a million requests every second, right?

José : Yeah, on that aspect you are correct. If you need a system which is performant enough to deal with hundreds of maybe hundreds, it can deal with that. But if you need a device capable of handle millions of requests, .NET nanoFramework is not the thing for you, but from all the rest, that is basically correct.

On the need for having async/await, you can replace that with what we have, which is multithreading, and you will be using here the API of I would say the 4.7 or 4.8 network, which is the new thread. Start that thing because you can have as many threads as the amount of available memory allows you to. So you can split things between threads just like you would do on a desktop application. Because for example, you can have one thread or timer pulling a sensor reading every 30 seconds and then storing it on wherever storage you have. You can have another thread which is responsible for dealing with the LEDs, giving you the visual output on the system or even a display on where you want to output a sensor reading. And you may want to have another thread which is dealing with the network connection and sending the telemetry or maybe connecting to IoT Hub. So all that is possible and you can have pretty much the same, and equivalent stuff on what you get with async/await, but just with I would call it the old .NET patterns with around system thread.

Jamie : Sure. And again, that totally makes sense, right? Because my understanding from my one or two projects with the embedded system that I mentioned earlier in the episode is that it’s a completely different paradigm for software development. Right. I’m used to building web apps or maybe server-side based apps where you can guarantee you have enough RAM to be able to do things like reflection, and to use generics, and to rely on the fact that I can just spin up a new thread whenever you want. I can say, “async/await this because I’m running on a modern operating system on pretty powerful hardware.” Perhaps in the cloud, perhaps on my computer. So I can rely on that. Whereas I guess with embedded systems, with IoT, it’s a completely different paradigm. Right?

José : Yes, again, you are correct. We have support for reflection. So you can even load an assembly on the fly and do whatever you want with it. Do the type crawling and all that stuff. It’s available.

On the other aspect. Yes, you have to deal with the differences and that can be something that kind of improves your skills as a developer because you have to be very careful with the memory usage because it’s short, it’s cast, and you just don’t go and declare a byte array of one mega because you don’t have enough room there. And you have to be careful on you don’t want to declare your variables and having them around just because you have to be wise on all that. And you have to be careful with everything that relates with memory. So it’s kind of a nice exercise as a developer to do some coding in nanoFramework because you have to mind about all those things that you don’t when you have a bunch of RAM and storage space and everything that you are used to when you are coding for desktop.

Do you have a WPF application and want to take it to macOS or Linux? Avalonia XPF, a binary-compatible cross-platform fork of WPF, enables WPF apps to run on new platforms with minimal effort and maximum compatibility.

With a few tweaks to your project file, your WPF app and all its dependencies are ready for testing on new platforms.

Start your app transformation journey with a 30-day free trial.

Head over to http://avaloniaui.net/themoderndotnetshow to get started today.

Jamie : Sure, yeah. There was someone I was talking to a few days ago who was talking about extreme performance at the edge and this is back to web development, but he talked about how we’re kind of spoiled as developers, right? We have these incredibly powerful, perhaps laptops, perhaps desktops with Oodles of RAM, right. We have more RAM, CPU, and hard drive space than we have ever had in our lives. And we can store all of the data in RAM, we can store all of the requests in RMA. We can store everything. We can run an entire operating system in RAM. This isn’t exactly how it works, but if you’re doing docker based stuff, that’s kind of how that’s doing it. So you’re running an entire operating system and your application and all of the debugging tools all in RAM, which is just mad.

Whereas, like you were saying there, the IoT paradigm means we’re going to strip all of that away. Strip all of that back to perhaps back to the style of programming that people did in the 70s and 80s where it was like, “no, we have to do precisely just what we need and nothing more.”

José : Exactly. And to me, that makes you a better programmer because you are aware of the system resources and limitations, and you need to make your way through that.

Jamie : 100%. No, I agree completely because I’ve seen a whole bunch of projects where the answer to, “how do we solve this performance bottleneck?” was, “we’ll just throw more resource at it, just have more CPUs, more RAM, more hard drive space,” and it’s like, “well, yeah, but what about when you run out of CPU hard drive space or RAM?” Right. If it’s already happened, it’s going to happen again.

José : Indeed. And then you either throw more CPU and RAM there, or you go and find wherever it’s causing it on the code and fix it there where it’s supposed to be fixed.

Jamie : Sure. Or indeed, as happens in my experience, you keep running it until it all falls over and the entire system comes crashing down around you. Then you hire someone like me to figure out why your code is running so slowly.

José : There we go.

Jamie : Okay, then. So let’s say I’ve got a hold of .NET nanoFramework, and I’ve got a whole bunch of devices laying around me. Can I just run .NET nanoFramework on any of my devices? Let’s say I’ve got like Raspberry Pi and I’ve got a couple of Arduinos and a bunch of different boards that have different sort of CPU architectures on it. Is there a version of .NET nanoFramework that runs on all of those, or do I have to get a specific version? Let’s say I’m using an Arduino. Do I need to get Arduino flavor, I guess, of .NET nanoFramework, or do I need to just get a generic thing?

José : No, you can’t use a generic because every microcontroller out there, it’s different. And it’s not just the architecture, it’s different on the way the pins are mapped, how the clock works, the internal flash, and RAM. All that stuff is different from microcontroller to microcontroller. So you have to grab the firmware, which is specific to the microcontroller that you’re using.

And expanding a bit on this. On Raspberry Pi. You can go with the full net. There is the IoT core that you can run there on a Raspberry Pi. So it doesn’t make much sense to run on ananoFramework there. You’ll be running .NET, but not just nanoFramework. nanoFramework targets more resource constrained smart controllers, meaning that the all famous ESP32s out there and the likes STM 32s, NXP, Microcontrollers, Silicon Labs, Giant Jackals, a couple of microcontroller series from Texas Instruments, NXP. I already mentioned that there are firmware specifics for all those. So you have an idea.

The absolute minimum requirement in terms of storage to run on nanoFramework, it’s a microcontroller with 32 bits, and 128K’s of flash, and 64Ks of RAM. If you have more than that, it will run, and you can have a C# application there.

What you need beyond that, it depends on how complex your application is or how fast you want to or how performance you want the computation to work. So that’s the minimum requirement to run .NET nanoFramework. Am I making sense?

Jamie : I was saying to myself whilst you were listing all of those things, right, that the computer I’m using to talk to you with today is like billions of times more in capacity than what the nanoFramework allows you to do. And yet nanoFramework has… it’s targeting, you were saying they’re the bare minimum. So obviously anything less than this, it will not run. And when you’re talking bare minimum, I’m guessing it won’t run brilliantly, but it will still run. Right? But like what you were talking about there, what sounded very much like the very first computer I ever had.

Whereas I’m sitting here talking to you using a MacBook Air that has 24GB of RAM and 8 cores of some weird new CPU architecture that no one’s ever heard of. Well, I mean, they have heard of it, it’s an M2, but you know what I mean. It just boggles my mind, the difference in system requirements, right? Like I said, I’ve worked on, I’ve consulted on applications that are sitting on boxes, like servers, very expensive servers that are about as powerful as this Mac Air M2, which was top of the line when I bought it, that can’t handle more than 200 requests coming in a second. And you’re saying, “yeah, it’s fine, I mean, just go get yourself an ESP32 with teeny amounts of RAM and guess what? We’ve got a system running.”

José : Yeah, that’s the thing there. And it’s kind of that mantra, “just take what you need, and not more than that.” I mean, you could have one of those beef machines sitting on your garden and reading a soil moisture sensor and then sending out a signal to turn on or off the sprinkler system. You could do that, but it’s a complete waste of power, of CPU, of RAM, of everything. When you can do that with a tiny microcontroller that can run on a battery for years and years, or even not even a battery, a solar panel, which can make it run to the end of the world. And you cannot do that with the desktop system because you need it connected to the power plug and it will consume energy, which is expensive and so on.

Jamie : Yeah, it boggles my mind. Just like, yeah, my first computer was around as powerful as these devices you’re talking about. You can plug a solar panel into and run forever. And run effectively .NET on. I’m going to take a moment internally and just think about that. Right?

José : Yeah, you do that. And that’s the thing.

And that’s one of the key things of the .NET nanoFramework proposal, that you can have a regular desktop developer and you can have it coding for embedded systems in a very short time. And a very short time is just a few days training. Because everything which is complicated on embedded systems development - and this is complicated, don’t get me wrong. It’s abstracted by the nanoFramwork and the firmware that you have it because when you are coding for it, you just need to be made aware of how you connect to that chip using that bus and the GPIOs - which are the inputs outputs on the microcontroller - work, which is something that, with just a few explanations, you will understand that right away. And that makes you productive.

And considering what you have to pay these days to a specialized developer on C, on C++ and how much more common and C# developer is, you can see where this is going. You can even have people coding in the morning to embed the system in the afternoon to the cloud API that’s running on Azure, and the same person can handle that. But if you want to change that to a C/C++ programmer, you won’t be able to do that. And not to mention all the productivity gains that you have on coding with a managed language like C# is. If you code in C, you know that it can be painful to deal with pointers. You have to deal with memory management. You have to allocate memory. You have to deallocate memory. If you have a byte array, it will happily overrun it and start doing bad things and you have to be aware of that. And that can cost you time if you do a bug around that and you have to find it and you have to fix it. If you are using a managed language like C#, all of that goes away and you can just focus on your task at hand.

It’s a breeze to work with string manipulation, which is hard in C. You don’t have to worry whatsoever with memory management. The garbage collector will do that for you happily. And you just have to code. And this is something huge in terms of efficiency. And if you are a company, you are obviously worried with time to market and being efficient and the customer comes up with a bug and you can find it very easily, you can come up with the fix and you do a new release. Everything, it’s much easier when you are coding in C#.

Not to mention the coding experience. You have the Visual Studio IDE to work with, you have IntelliSense just like you have on a desktop project. You have all those helps from GitHub Copilot if you are lucky enough to have it. With everything that we are spoiled as developers when coding in Visual Studio, you just need a new USB cable to deploy to your nanoFramework board. You hit F5, you are running the application right on the board with just a plain, simple USB cable, as compared to… and if you go into the debug session, you can set breakpoints, you can go with the code back and forth. You can inspect locals, you can change the variable contents, everything that you are used to and all that. Or most of that doesn’t happen, or it’s not available, or it’s much harder if you are doing it with C or C++ on one of those wacky IDEs that are out there for embedded system developers.

Jamie : Yeah, there’s something you said there I hadn’t even thought of, so thank you for bringing that up. And it leads into my next question. And that would be like, there’s two parts to this one, so I totally appreciate that we’ll need to cover both before you can answer, so I hadn’t even thought about that. There are two parts to this question. Right, I hadn’t even thought this far ahead. There’s a second part that we’ll need to cover in a second, but we’ll need to cover both. So you can answer, I guess, but you could go to an assistive technology thing like ChatGPT or any other large-language model, and you could presumably say something along the lines of, “supposing I have an ESP 32 and I’m using .NET nanoFramework. How do I initiate a web request?” versus, “I’ve got an ESP 32, I’m writing in C++, how do I do web requests?” Right. The answers will be dramatically different.

José : Yeah, absolutely, you can do that and you can even go even further because this is C# and we have our APIs pretty much aligned. The differences are minimal. You can ask or you can even use every C# coding skills that those tools have and take advantage of it. Like you go with Microsoft Learn Portal, or you go to Stack Overflow, or GitHub; everything that you found out there, which is C# and which is a lot you can use on another framework because at the end of the day, this is .NET C# that you are coding with.

Jamie : Yeah, that makes total sense. And the second part of that would be like supposing I’m using something like an ESP32 or some off the shelf hardware, presumably whatever I want to do, there’ll be a NuGet package for it, or a NuGet package that gets me most of the way. Right. Like I said, there Right, I’ve got an ESP32. I’m running .NET nanoFramework. I want to read something over, I don’t know, some thing over the GPIO port. Yeah, some sensor over the GPIO port and then send it out using HTTP over the web.

Well, I’m guessing I could use WebClient, or if we’re lucky enough, HttpClient, either way. But reading from the GPIO port, I’m guessing there’s probably a NuGet package for whatever I’m reading over the GPIO port. Right, I’m going to say, right, I need to read pins one, two and three. I need to read four bytes of data done right? Whereas with C++ it would be like interrogate these individual memory addresses for this much time and then format the answer. I feel like a lot of .NET devs don’t realize just how much effort there is.

José : You are correct on that. I’ll start with a hard approach.

If you want to do that on C or C++ you have to go through the data sheet or the manual for your microcontroller. You have to find the address for the register that’s holding the contents for those GPIO ports that you want to read. You want to know which byte exactly it matches the GPIO that you want to read and you need to read that register and then you need to parse it and see if it’s high or low.

With C# and nanoFramework, as you were saying, you just reference the system device, GPIO NuGet package, and depending on the encoding of the microcontroller you’re using, “hey, I want to read bit two from port C,” and that’s it. You get a pin value object which is high or low depending on the state of the object and that’s it.

Because on… getting back to the C#, to the C description that I was giving a moment ago before that and for the GPIO to work you have to find also the registers that configure the GPIO to behave the way that you want; and if you want them to be input output and if they are transitioning states, if you want to be aware of transition high to low, low to high or both, blah, blah, blah and you have a bunch of stuff which you don’t even have to think about it when you are coding with nanoFramework because all that is abstracted from you and you just need to focus on the task at hand. “Hey, I want to read the state of pin two on port C,” and that’s it. One line of code.

Jamie : Wow. Obviously I’m a huge fan of .NET anyway, so I know that on a standard desktop application or on a server, for instance, opening a port and opening a connection sorry, to a web server and saying, “hey, can I have this information?” In .NET is a trivial task in C a non-trivial task.

José : Yes.

Jamie : I hadn’t even thought that far down about like, “in order to enable GPIO, I need to tell it what mode to be in and then I need to tell it if it becomes a,” so for folks who are maybe listening to this and don’t have the background that I’m guessing you have, that I also have. I tinkered a lot with electronics and learned digital electronics from that. When we say a low value, that’s a voltage level of maybe zero up to maybe 1.25 volts, depending on your system, and when we say a high value, that might be 3.75 or 4 volts up to 5 volts. So that’s your 0 and that’s your 1 of binary, right? You’re literally working in binary. And so if you’re telling the GPIO port in C through some registers that configure it, “hey, I want you to read every this much data and when it flips from being 0 to 1, let me know and I want this much maybe byte two, byte four on a regular basis or whatever.” That’s just like setting all of that up like you said, would take perhaps a couple of hours.

José : Yes. Because especially if you are not familiar with that microcontroller that you are using, you have to chase the data sheet and you have to chase the manual. You have to find all that stuff and the you have to make sure that because microcontrollers, even on the same device, have different packages the encapsulations that you see on the PCBs that pin two on port C could be on different pins, even on the same microcontroller, just because the package is different. And you have to chase that. And you have grabbed the schematic off the board, and so that can take you a lot of time. And you are not being productive with that. .NET nanoFramework helps you be more productive because it abstracts most of the complications. Of course you still need to know which pin you want to talk to, but that’s easy to get that information usually.

Jamie : Sure. And we didn’t even talk about the biggest complication, which is when the project manager goes, “actually it would be prohibitively expensive for us to use that particular sensor on the GPIO port. So we’ve changed it and you’ve got like an hour to change the code because we’re sending devices out tomorrow.”

José : That’s exactly it, because it abstracts the complication from you if you want to switch devices. And for example, if this is connected to an SPI (serial peripheral interface) bus, you just have to come up with all that is there. You reference the SPI NuGEt which brings you the connection to a SPI buses and you just have to configure a this is connected to this and this pin and you can start sending commands and reading data from the sensor. If that was a sensor that you use a few projects ago, you still have the code around on a class, hopefully, and you just bring in that code file with that class and it will be working in no time. You can do something similar with C, but it’s not as easy as it is when you are doing it with C#.

A Request To You All

If you're enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I'd really appreciate it if you could indeed share the show.

But if you'd like other ways to support it, you could:

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let's get back to it.

Jamie : Sure. Yeah, just like that. Like you were saying, the productivity, the ease of use when you need to change something because it’s all abstracted away. Makes it so much simpler. I really like that.

José : Yeah.

Jamie : Okay, so let’s say I’m listening to this conversation and I’m like, “that’s it, I’m getting .NET nanoFramework, I’m going to buy one of these microcontrollers.” What can I build? We talked a lot about sensor readings. I mentioned a couple of times about maybe being a web server or supplying some data on demand. I’m going to use the Bunny quotes here they come, is that “all” you can do? What are some of the sort of killer apps of the .NET nanoFramework and IoT with .NET?

José : Like we’ve talked about on the beginning of our conversation, you can do pretty much everything that you want to do on embedded systems with nanoFramework. This is not meant to replace embedded system development on C and C++, because there are limitations for this. If you need to be really tight control on timings and if you need the response times on the system [in] the microseconds, this is not for you and you have to go with the traditional C and C++. But I would dare to say that for the vast majority of the systems out there, you can do exactly the same and be much more productive using .NET C# for embedded systems development. Okay?

And so, having said that, the productivity, we already covered that. And the fact that you can have regular desktops developers using it, it’s also a plus. And regarding the usage fields, let me give you a couple of examples. One of the largest projects that we’ve just wrapped up a couple of months ago is for a customer on the US, which is Skyworks. They are a silicon manufacturer and we’re working with their timing division. They were for a long time a .NET shop, but they use .NET for coding the desktop applications. There are applications on which you configure the various parameters on the timing devices and here on timing devices, these are chips that generate clock signals and they are used from satellites to regular cellular devices and everything that needs timing, which is pretty much everything on embedded systems. And you have those desktop applications that were coding in C#. And the EBs - which stands for “Evaluation Boards” for the various components - were coded in C and C++.

They choose to switch that to nanoFramework in order to use .NET C# from the microcontroller up to the production line, which they now have, meaning that they are reusing code and classes across these different applications. They have the EB’s running firmware, which is nanoFramework. They have the desktop application which is connected to the EB through a USB cable running net, but the full .NET. They have C# .NET applications on the production lines doing the QA on the devices on the boards when they are developing. The have huge test rigs with a bunch of wires connected to the boards. And they have temperature chambers to evaluate the stability of the chips across the temperature range that they work with. It’s a very complex system. Everything runs around .NET, and with nanoFramework they manage to reach the last mile if you want to be able to do that on the pods. And that’s a typical usage for nanoFramework.

And then you have other customers that are using this on boards which run telemetry system for oil fields, which are deployed out there in the desert. You have a small box which is powered by a solar panel, and the device sits there every hour or so. It wakes up, reads a bunch of the sensors that you have there from the simplest, “what’s the level on the oil there? What’s the temperature?” And a bunch of others. It composes a package with all that telemetry data. It sends that telemetry data through a satellite connection, which will go into IoT Hub, and then get back to sleep. On the next couple of hours, it will wake up again. It will do the same thing. And this is over and over and over.

So this is kind of two, I would say, opposite fields, applications on embedded systems running nanoFramework. One of them is highly connected to the cloud, to the Internet of things. And the other one, it’s not. It’s a desktop application, if you will, because it’s not even connected to the Internet because it doesn’t need to.

Jamie : Cool. Okay, yeah, I like those because it’s making all of that so much simpler to get started. We’ve said it hundreds of times, right? It’s all about getting started very quickly and getting to, I guess, from zero to production, right?

José : It is.

And now, in C#, you know that you can be very productive and you can code pretty much everything very efficiently, which makes this a great platform. You grab a breadboard, you stick an ESP32 module onto it, and you plug an LED or a sensor or wherever, and in half an hour, you have a proof of concept of something that you are building or just having fun with. And this is great not only for learning to code, but to come up with a proof of concept that you want to show to a customer.

If you want to do that in C, I dare you to do that [in] the same time, you won’t be able to. Meaning that with that code and that proof of concept, then you can evolve, you can keep working on it, and then you can easily migrate that to a production grade system because you will be using the same code. You don’t have to change much to get it working. And even if you change platform, if you go, for example, your proof of concept is on an ESP32 device and that you have on your breadboard. Okay, that’s working. You have your project in C#. All good. You need to move to production. But for some reason, you are not using an ESP32, you are using an NXP microcontroller. That’s good.

You just grab the code on that other device that will go, and that will be your production platform. And everything works. You may have to adjust a couple of GPIOs which are not in the same location, but the 99% of the code will just work. And despite you have changed the platform because the firmware has abstracted all the hardware intricacies from you and you can do that if you were doing it with C, you could not do that ever. You have to change everything because you are on a different platform, you have a different vendor, you have a different SDK, you have different APIs, you have a different architecture on the processor, possibly you have different GPIOs, all that. And it’s not going to work, at least easily.

Jamie : Sure.

I don’t think it’s possible for us to downplay just how non-trivial it is to swap out hardware for a system that you’ve written in C or C++. My first bit of actual academic programming, I guess you’d use the phrase, when I was at college or whatever we were doing assembler on a Motorola 68k and this was part of - I’ve said it in other episodes as well - it was part of a development kit, a hardware development kit called a Flight 68k. So it was a Motorola 68k with loads of different bits plugged into it and you could swap them out, you could, “now I want the LEDs,” and then you take that out and then you’d say I don’t think it used GPIO. I can’t remember what he used, but he didn’t use that. And then you could plug in loads of different sensors.

And one of the tasks that I was given was calculate how fast a bullet travelled. They had to get a technician to build using an air rifle to build the hardware that I could plug into the board to measure the speed of the it was an air-soft bullet, but yeah, it was still a bullet, right? And that took a couple of days for them to put together, and I had made loads of assumptions about how it would work and where it would plug in and what the registers would be for my bit of code that would read this and the they presented me with this. Essentially it was a rifle glued to a piece of wood with two sets of crocodile clips that I could put sheets of tin foil in. I’m not sure what the cross country name of tin foil is, but just sheets of thin metal that I could put in between them and then I could replace those. But then they went through into individual cables that were bundled together that I had to then plug into the board and all of my code had to be rewritten. I’d say about 90% of my code had to be rewritten completely because I had assumed, “oh, it’ll be register one or it’ll be register two.” And it wasn’t. It was like I was messing with individual memory addresses. So I don’t think it can be underplayed just how much messing around is required when you’re writing in C, C++ or Assembler and the hardware changes.

José : Absolutely, yeah. Because the thing, as you were describing, changing a platform or changing a microcontroller really changes everything. And if you have this on a very layered approach, which is what we are doing with nanoFramework, all the upper layer on the application, all the layers that are on the application will remain the same because it’s up to the firmware on the lower layers to map this to whatever registers is different on that platform. But all that is abstracted from you. So you can see the mass productivity gains that you can just swap platforms and you can reuse code with the library that you have for another device, for another project. And you can bring that in and you can simply just move from one more controller to the other with the minimal changes on your code, which is something huge.

Jamie : Sure. Okay, so let’s say I’ve got myself some bits of hardware. I’ve used .NET nanoFramework to build something and I’ve gone proper, like evil genius mode and I’m like, “okay, I’ve bought 50,000 of these chips and I want to deploy to all of them.” Is the some kind of automated way that I could do that? Can I use things like GitHub actions or is it just a case of hit F5, plug it all in, hit F5, unplug it, plug the next one in. F 5, unplug it, plug the next one in.

José : Yeah, that would be painful. But everything is available to use this at professional level. Not only hobbyist or if you are a student on a school bench, this is production grade and you can do this commercially. There are available command lines that you can use on which you don’t need Visual Studio, you can use MSBuild and the command stuff. And at the end of the build pipeline, which can be a GitHub action by the way, you will have a binary file, which is what’s going to be deployed or flashed on the microcontroller. And then you can use those CLIs to do that on a very automated fashion.

And you can even have some interaction with the devices. Meaning that you can have a firmware which is running the production test, which will be the very first application that will be deployed and run on your board. And you can do the usual stuff that you can find on QA electronic production line. You can see the LEDs blinking on some pattern. If you have a display, you’ll see those messages with the various tests that the system is running into. If it’s connected to the network, it will connect to some service and will get some reply. Everything will be tested with that application. Then you can just use the same command line to deploy the final application that will go into the field and deploy it in the real device. So you can do all that.

And speaking of professional tools, you have also on nanoFramework other tools that help you develop a better product and be sure on what you are doing. For example, we have a framework with unit tests, just like you have on the full .NET, meaning that if you want to get crazy with unit tests, which you should be, you can do that on our framework, and that’s available. If you want to do integration testing, you can do that also with a variation of the unit test that can run on the device. And we’ll take care of just the code, but the hardware interaction. We have libraries for doing benchmarking and logging. You can log to a file on SD card, you can log to a network service that you are connected to through sockets, you name it. All those advanced tools that you find on the full .NET and that you have on a desktop or on a cloud project. You have pretty much the same equivalents on nanoFramework to make sure that you are delivering a quality product and that your code is good, and that you can be as much sure as you can be on anything that is software.

Jamie : Cool. Okay, I like that because like you said, it would be painful to have to boot Visual Studio, hit F5 deploy; boot Visual Studio, hit F5 deploy. I like that. I’m all for unit tests whenever I can put them in place. So that’s also really good that you’ve thought about that.

So then how do I get started? With .NET nanoFramework? Is it just go to the website and there’s maybe a “Hello, World” or something that I can copy down and figure out?

José : Yeah, you have the “Hello, World” as the project template on Visual Studio.

So basically you need two things: One, you fire up your Visual Studio, you go to the extension marketplace and you search for nanoFramework. It will show you the Visual Studio extension, which the name will be nanoFramework. Not very surprising. And you install that. With that you have all the debugging stuff that’s required for Visual Studio to work, and build, and deploy the project system and the templates. Because when you do File>New project, you’ll find under a C# nanoFramework folder, a class library template and standalone application template. And that one is exactly an “Hello, World,” which will give you a console write line Hello World from nanoFramework. And you can see that on the output pane on Visual Studio. And that’s it.

The second thing that you need, you have to install the nanoFramework Flasher, which is a CLI application. It’s a .NET tool, so you can run it everywhere that .NET runs. You install that with dotnet tool install -g nanoff. And then you have a very simple command, which is kind of nanoff –update –platform ESP32 –port com11, which is wherever your ESP32 is connected to, and the the tool will connect to the device, will find out exactly what’s the series and the model, will grab the correct firmware and will flash it, and that’s it. On the next minute, you will have the device being discovered and listed on Visual Studio, and you can start coding with it for that “Hello, World” application. And that’s it. On five minutes, you are up and running.

Jamie : Excellent. And so if I’m new to the .NET nanoFramework whole thing, is there like a support place that I can go? Maybe like a slack or a discord or something like that, where I can say, “hey, I’m brand new. I’d like to learn a few things?” How do I do that?

José : Yes, we have a lively and friendly discord community around nanoFramework on which you can go. And there are a bunch of channels with different topics. So you’ll go to the welcome Channel and say, “hello,” if you want. And then you can just go and choose the channel that it’s most suitable for the question that you have, and you’ll find there a helpful community, as I was saying that will answer your questions and will guide you through to make sure that you are up and running in no time.

Jamie : Cool. Awesome. What about can folks get in touch with you? Or would you prefer they go through Discord and ask folks there instead?

José : I’m available, of course, and that’s one of the things that I spend a lot of time with, is helping people there. So I’m available there and also on Twitter, on LinkedIn, a number of channels that you can get hold of me.

Jamie : Excellent. Excellent. Well, I mean, I’ve really enjoyed our conversation today, and I’ve come away with much more appreciation for the oodles of hardware that I have in any one of my machines. And I’m really looking forward to grabbing a couple of different pieces of embedded hardware and seeing what I could come up with. So I really appreciate you coming on the show. So thank you for that.

José : It was a pleasure and having all this conversation with you, Jamie.

Jamie : Amazing. Thank you very much.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest, José Simões, for graciously sharing his time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, or join out discord server at dotnetcore.show/discord - all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places