What if I told you there was a way to use the full .NET library to code for microcontrollers and other embedded devices? It’s called Meadow, was created by former Xamarin folks, and is developed in the open by Wilderness Labs.
My background is in embedded real time development, and I like to consider myself as somewhat representative of this population of developers. Embedded development has been done for a long time now using C/C++, and the evolution of embedded development tools and languages is slow and the many attempts at using modern languages, frameworks and developer tools have not yet reached production level.
Don’t let Wilderness Labs mascot Wummit’s cuteness deceive you, Meadow is changing the game!
Embedded development is still hard
If you are an embedded developer, you can skip this paragraph as it only explains what you already know about embedded development with C/C++.
At the risk of sounding like an old, scratched record: embedded development is not easy and the barrier to entry can be steep for developers who are not familiar with C/C++: direct interaction with hardware through registers, GPIOs, SPI, I2C, Serial, and all the other low-level APIs, dealing with drivers, selecting and configuring compilers are all part of the day-to-day embedded developer’s life. And don’t even get me started on the embedded build chain and other development tools! Some still have to use printf traces over a serial port for debugging their code when they don’t have expensive ICE or JTAG adapters and going to production with an embedded device can be long and tedious considering any code change often means a full firmware flashing + full re-test on dev device, then on production hardware…
Even though we have seen considerable progress over the last couple of decades in the domain of microcontrollers, their nature is to have limited resources to allow for low energy consumption, lower cost, and custom form-factors. And resource limitation means less code, smaller frameworks, middleware, and abstraction layers.
When you code for a PC, a smartphone, a server, or even better, for the Cloud, you can take advantage of high-level languages and frameworks, modern development tools, and a broad ecosystem of software libraries and middleware stacks that make you more productive, make your code more robust, secure, and efficient.
And even though there are solutions out there that aim at modernizing and democratizing embedded development, such as Arduino, PlatformIO, or libraries optimized for embedded development such as Qt, Boost or TensorFlow Lite, you still have to know C/C++, understand lower level concepts like physical/virtual memory, multi-threading, hardware registers, GPIOs, compilers, remember to de-allocate your resources, etc. Things that they don’t even teach in IT engineering schools anymore!
There have been attempts to bring higher level languages and frameworks/middleware’s to embedded devices, but they have always been different, smaller, and limited versions of their big siblings: .NET microframework (R.I.P.) and MicroPython both have “micro” in the name, .NET nanoFramework has “nano”, DeviceScript supports a (tiny) subset of Javascript… Nearly all of these frameworks also run interpreted on device which makes them too slow for most production needs and generally relegates their use to hobby projects.
Introducing Meadow: full .NET for professional IoT development on embedded devices
Besides sporting pretty cool retro sci-fi graphics on their (new) website and presenting a smooth and straight to the point developer portal, which already says something about the team’s mindset, Wilderness Labs made it their mission to bring the full .NET runtime + framework to embedded development, allowing you to not only code with your preferred language, be it C#, F#, VB.NET or any other .NET programming language.
If you are a .NET developer, I bet you are getting excited, and it won’t take much to convince you to read on and try it out for yourselves.
If you are an embedded developer, I can hear you from where I am, starting to enumerate all the reasons why you think this can never work: the full .NET runtime will never fit on a microcontroller powered device, things will lag, non-compiled code is a non-starter, this thing has a garbage collector which will take over at any time and compromise some critical task… I know because I had that exact same skepticism when hearing about it for the first time and having experienced the many previous failed attempts. And I suppose I need to bring up actual arguments to convince you to continue reading and then consider trying it out for yourself.
If you need a little more convincing and before I get into the details of why I believe you should care about Meadow, I invite you to check out this episode of the IoT Show with Scott Hanselman sharing his excitement about it:
Is Meadow a path towards modernizing IoT development?
To make the conversation objective, let me try and list the criteria and requirements for a development language/framework/middleware (a.k.a. “software”) to be considered viable for professional embedded development.
Reliability: embedded devices power critical systems and/or final customer facing systems (think kiosks, controllers …). Running on limited resources, and with a thin (if no) margin for error, code has to be reactive, behavior should be deterministic (you don’t want a code error to cause a critical factory floor conveyor belt to stop an entire production line) and priority should be given to the right software tasks (I am sure you have experienced lagging kiosks and understand what I mean here).
Size: microcontrollers have limited resources and that’s by nature. Contrary to common perception, compute power and memory are not cheap (at least not at the embedded board bill of material level).
Power consumption: embedded devices should also have low power consumption and long battery life. And the one determining how available power is used (or saved) is the software.
Scalability: when developing an IoT solution, you need to plan for the future, as some systems will have to live on for many years or even decades. You will need a software stack and tools that allow for updates and reconfigurations in production, often across many locations.
Security: Embedded devices are physically accessible, and when participating in an IoT solution, they are connected to some form of network and eventually to the Internet. Securing your IP and data must be top of mind and embedded deeply into the software stack.
How does Meadow fair as an IoT/Embedded platform on paper?
On paper Meadow seems to be checking a lot of the boxes.
✅ Reliability
.NET is not a new thing and best practices for developing robust and reliable code with .NET are well known. It offers a rich and consistent set of libraries and frameworks that provide common functionality and abstractions for various domains and scenarios, such as data structures, collections, networking, cryptography, serialization, reflection, threading, and more that are all used in enterprise scenarios and have been tested and vetted.
Managed runtimes such as .NET also add critical memory reliability. Two thirds of all security breaches are due to the kinds of memory bugs that aren't even possible in memory-checked languages and runtimes such as .NET or Rust.
At the end of the day, it is your responsibility to write proper reliable code, but because Meadow supports full .NET and its different languages and tools, you benefit from all the features you need to write good efficient and reliable code, such as exception handling, code analysis tools, CI/CD, performance analysis tools, and more.
✅ Memory footprint
Meadow is built on top of Mono, an open-source and cross-platform implementation of the .NET framework. Remember, that’s what is at the core of Xamarin. Mono lets Meadow run on various embedded hardware platforms, such as the STM32F7 microcontroller, the ESP32 Wi-Fi module, the Raspberry Pi, and more.
Mono comes with a flexible and extensible linker that can reduce the size of the .NET assemblies and optimize them for the target device, by removing unused code and metadata, and applying other transformations. Looking at the Meadow F7v2 board, specs indicate it sports 64MB of Flash, with only 4MB reserved system space, which means the Meadow footprint is less than 4MB.
✅ Power consumption
When it comes to power consumption, Meadow is designed to run on Microcontrollers and to give you an idea of what we are talking about, you can check out the specs of the F7 Feather board which indicate that the nominal power budget for the onboard functionality (MCUs, RAM and flash) should be around 400mA while running full out, which, if powered with 5V is 2W. If you add peripherals, you get to 2.5W average in nominal use. For reference, this is what a Raspberry Pi 4 consumes … in idle mode!
Meadow also has a low power mode that can reduce power consumption by up to 90%, bringing it down to 0.25W. This means that when running on an MCU, Meadow can be powered by battery and/or a small solar panel, enabling evergreen remote deployments.
✅ Scalability
One of the key features of Meadow is the ability to perform Over-the-Air (OtA) updates, which allow you to push new versions of your Meadow applications to your devices in the field over the network. Out of the box, you can provision your Meadow device with a unique ID (see details below) that allows it to communicate securely with the Meadow.Cloud, then you can enable the update service in your Meadow application by adding some configuration and event in your main program.
You can also automatically monitor the health, logs, and events of your devices, automate crash-reporting, and send commands and messages to them via the Meadow.Cloud.
Additionally, you can integrate your devices with other cloud services and enterprise backends, via webhooks and integrations, to Azure EventHub, Datacake, and more.
✅ Security
With Meadow, security is literally at its core: for each device, Meadow tools will generate a private/public keypair, the private key is stored into secret storage (more on this one below), and then the public key becomes a unique, cryptographic ID for the device. When you register the device with the cloud during provisioning, you register the public key. This means that the cloud can encrypt data and OtA payloads using the device's public key, and only the device (with its private key) can decrypt. When the device talks to the cloud, it can encrypt data with the cloud keys and sign with the device's public key. Ensuring end-to-end encryption and impossible to spoof identity!
Meadow devices support secure boot, ensuring that only trusted firmware and applications can run on the device.
They also support secure storage, which allows you to store sensitive data such as keys and credentials in a protected area of the flash memory.
When it comes to Cloud connectivity, you get all you would expect: unique ID secured encrypted connection over TLS/SSL, OtA updates, remote monitoring and management through Meadow.Cloud, RBAC and OAuth 2.0 support in Meadow.Cloud, and more.
➕ Other things Meadow has, that others don’t
Portability: IoT Devices come in many forms and shapes, and being able to reuse code across platforms can be extremely beneficial. Meadow is based on Mono which has been invented to allow for .NET portability across mobile platforms (you might have heard of Xamarin, right?). Meadow can run on microcontrollers as well as embedded-Linux devices, supports Windows, Linux, macOS, and more… Even better, you can run the same app on all three: MCUs, SBCs and Desktop/Server! Chris Tacke put together an interesting article about this.
Simulator: Thanks to the above, there is a simulator you can use to do most of your development without the need for hardware.
Ecosystem/community: the .NET community is already huge, but Wilderness Labs extends it to the world of IoT making hardware simpler for .NET developers. Furthermore, the objective being to be relevant for enterprise and industrial applications, the Wilderness Labs team strives to offer integrations with industrial standards and solutions. Here is a great example of an integration with Modbus.
… and more! But I’ll leave this to future articles.
A series of articles to verify all that
I plan to put together a series of articles while testing out Meadow and investigating what it has to offer for IoT solutions development. The questions I’d like to answer are:
Is Meadow going to democratize IoT for professional non-IoT developers familiar (and proficient) with .NET?
Is Meadow a path towards modernizing IoT/Embedded development and should “traditional” embedded developers pay attention?
Stay tuned!