In-field update [WIP]

New features and bug fixes are bread and butter in the software industry and embedded systems are no exception. These are made available in releases, which all need to be published and deployed. Quite often, the last step is the most challenging of all given that the capabilities and available resources of the device subjected to the update process decrease, the difficulty increases inversely.

To be fair, it is not usually a big deal when you have the device sitting on your desktop bench, connected to a cable and just need to type into a command line tool to get the new imaged flashed, or (even better!) using a GUI tool.

But what about when you have the device sitting in a hard to reach (remote) location? Or when there are a bunch of them spread geographically apart? Or devices that maybe using a spotty and/or intermittent network connection. Or even not connected at all because there is no network available or it is too expensive. And what happens if the update process hangs? Or if there is a power glitch? Or if the image gets corrupted? There are a thousand ways that can make remote updates on micro-controller scenarios head south…

Nevertheless, being able to remotely update a device deployed in the field is a feature that most likely will be high placed on the “must-have-feature-list” of a company evaluating an embedded system framework.

Currently .NET nanoFramework is missing this feature, but that is about to change!

The specification and design of the in-field update (that’s what we’ll be calling it because the update can reach the target device not only over the air, but though a wired connection or a storage device) is mature and closed, ready to be coded.

Despite being what could be easily classified as a premium feature, it will be (just like everything else in nanoFramework) made available to everyone for free, in full.

Being a high value and commercially relevant feature, it’s more than fair that especially commercial users, contribute monetarily to the development effort. For this purpose, a sponsoring campaign is being launched through GitHub Sponsors program here.

Feel free to jump into the conversation about this topic, ask questions, get updates, and provide feedback. All that will be happening in the #in-field-update channel at the .NET nanoFramework Discord community.

.NET nanoFramework has joined the .NET Foundation!

We have some great news to share: .NET nanoFramework has reached an important milestone by joining the .NET Foundation!

This is kind of a “return home” for the project. Despite being, undoubtedly, connected to .NET because of its roots, the programming language, and the tools it uses, it was not exactly part of the family. Now it is.

The .NET ecosystem has grown a lot. From desktop to cloud, AI, IoT, and smaller devices, it is now virtually everywhere. Even though there are “official” solutions for embedded systems (from Azure Sphere to, more recently, Azure RTOS and friends) those are somewhat “out of ecosystem” in the sense that developers have to keep using the traditional C/C++ in order to code for such devices. If one wants to code in C#, the smallest you can aim to reach out to is a Raspberry PI.
.NET nanoFramework extends .NET’s ability use to really small and constrained devices. Yes, there are a couple of similar offers out there, but none are Open Source. And none of those allows coding for Expressif ESP32; or ST Microelectronics STM32F0/L0/F4 (to name just a few); or Texas Instruments CC3220 and CC1352; or NXP MIMXRT1060 EVK; or any other new target device that can easily be added.

It is our expectation that this will boost the project in many ways. Such has:

  • Visibility. This is one is kind of obvious, right? Considering that this is one of the goals of the .NET Foundation, more developers will become aware of the project, will start to use it and, hopefully, in the good spirit of Open Source, will give back to the project, ultimately allowing us to move faster and increase the overall quality.
  • Easier access to the .NET teams that we depend most upon, or that have impact on the project. These are Visual Studio, VS extensibility, .NET project system and such. Every now and then we bump into bugs/changes that break stuff and being able to report and discuss things quicker and easily is invaluable. Being able to pass along our suggestions and “needs” can only be positive for the continuous grow and overall quality of the project.
  • Tighter integration with the .NET ecosystem. As it is now, .NET nanoFramework is perfectly usable and integrated in the key aspects and tools including Visual Studio, libraries available through NuGet etc. But we, admittedly, have some pain points that could easily go away providing that such integration can happen. Starting with the Project System, having a dedicated target framework identifier would make our life so much easier. Extend Unit Testing framework so that we can have it on our projects and finally unifying APIs. We have already started walking down this path with conversations with the .NET Core IoT team, so the first visible changes are due shortly.

A thank you note is due to all the people that paved the way and made this possible. When .NET Micro Framework was launched a long time ago and showed that writing C# code for microcontrollers was possible. And, of course, open sourced it! .NET nanoFramework sure is a lot different from what was .NETMF back then, but we are standing on the shoulders of giants and we owe a lot to those very smart and talented people.

All in all, it is a positive event that can only bring good things for the project. We are very happy that it is happening, and it sure feels like a recognition for all the immense effort that a handful of people have poured into .NET nanoFramework for the last 4 years.

A lot of great achievements are ahead of us for sure. Let’s make that happen!

PS: We hate to see wasted talent and positive energy! Join our Discord community. Fork our samples repo. Grab open issues. Fix bugs. Contribute with new features. Write a project for Have fun with .NET nanoFramework!

Changing licensing to MIT

As some of you may have noticed: we have changed the licensing terms of some of our repositories.

Until yesterday, there were two licenses across our repos: Apache 2.0 and MIT. The oldest ones were under Apache 2.0 and newest ones under MIT.

Being both the “permissive ones” and, in practice, without much difference between them we thought on making it simpler for everyone (both hobbyists/personal users and companies/commercial users) and unify them.

We have decided to go with the MIT one because of its simplicity and openness, which is in the spirit of what has been done since the .NET nanoFramework project started.

No big deal, most will say, but we hope that this is another step on consolidating the project’s organization and openness.

Have fun!

Improvements on build system

The build system for all (preview) target images have just been updated to reduce complexity and aid interoperability. These changes are particularly relevant for those interested in local builds and debugging of the interpreter.

Until this change, the following applied:

  1. The CD-CI pipeline (based on Azure Pipelines) was self-contained and completely autonomous.
  2. Local builds relied on developers following a recipe to download and install all the required tools. ESP32 developers where luckier than the rest as there were some PowerShell scripts that downloaded and installed some of the required tools.

The above lead to situations where developers struggled to follow the setup and configuration instructions, and became frustrated in their attempts to match between the scripts used by Azure Pipelines and the automated install scripts. Not to mention the build instructions/guides in the documentation continually falling behind.

Considering that we want to keep using the powerful Azure Pipelines (which is able to consume PowerShell scripts), the path seemed quite obvious. We should have a common base of PowerShell scripts, that are consumed by either Azure Pipelines or locally by the developer if needed.

Of course, there will still be variations on all this, mainly because the Azure Pipelines build agent already includes some pre-installed tools and the locations to download are different between the agent and a local machine where a developer has full control of where the tools should be installed. All of this can be factored into the PowerShell scripts and the various Pipelines yaml documents.

So what has changed?

Some wrapper scripts have been added to deal with differences in the required tools for the various target platforms.

New scripts were added to install ALL the required tools. This is now real (except for Visual Studio Code).

Also, a new script was added to wrap the calls to CMake providing a true “fire-and-forget” experience for those who prefer to build locally without having to worry about anything at all.

On top of this, bringing the build system a couple of notches up, there are now launch and build configurations per target living in each target folder. To make this really useful and developer friendly, a new script is now available to fully setup VS Code. This script sets all of the required entries in settings.json, composes the launch configuration and CMake variants by grabbing the individual configurations from the various targets. And I really mean ALL because the tool paths are also updated with the setups/install from the previous step.

The build guides have been updated to reflect and describe all this, But I will summarize it here to give a concise overview.

For example, to install all the required tools to build an ESP32 image in a specific location:

.\install-nf-tools.ps1 -TargetSeries ESP32 -Path 'Z:\my-nftools'

To build an image for the STM32 F429 Discovery board:

.\build.ps1 -Target ST_STM32F429I_DISCOVERY

To setup Visual Studio Code:


Hopefully this is an important step forward in what concerns the setup stage. So, there are no more excuses to not setup a local build system and even debug it.

What are you waiting for? Go get it and have fun with .NET nanoFramework! 😉

Stable releases are out!

Today we have completed the publishing of our latest stable releases. This includes all of the firmware images and class libraries.

This happens after deep rework on some key components, like the metadata processor (which is responsible for processing the .NET IL and make usable by the .NET nanoFramework CLR & execution engine) and the Visual Studio extension.

The Visual Studio extension is now much more stable and all of those nasty crashes and hangs when interfacing with a device in Visual Studio are now gone.

The firmware updater tool (nanoff) is now able to update STM32 targets with both JTAG and DFU connections, along with the new TI XDC targets.

Too many features were added and bug fixes made to list them all, but the full list can be found in the check-in history on out various repos. The following lists some of the highlights:

  • ESP32 RMT and Gpio​Change​Counter,
  • New platforms and targets like the TI CC1352 and NXP MIMXRT1060_EVK,
  • Several fixes and improvements deep on the execution engine and CLR,
  • ESP32 moved to IDF 3.3.1,
  • TI CC3220 SimpleLink move to 4.10,
  • Output of target boot and assembly details are shown at Visual Studio output window,
  • Start of debug sessions are now smoother on all targets and platforms,
  • A completely new Json C# library with improved and new features.

It is worth mentioning that since the last stable release, some of the community involvement has been excellent. There were a few outstanding collaborations that has made it possible for some of this releases features and improvements to happen. A big thank you to those developers!

For the next iteration, the plan is ambitious:

  • Improving nanoff to allow updates over USB,
  • Release a C# unit test framework,
  • Improve general QA by adding unit tests to native and managed code,
  • Add IFU capability to all platforms.

And who knows what other goodies we can pick up along the journey…

The .NET nanoFramework project is growing and becoming more feature rich. The stability and overall quality is increasing too. All this requires a lot of effort and time from the maintainers. We sure could use more people coding, reviewing stuff, writing documentation and creating walk-through guides along with answering questions from developers and help with the daily chores with Azure Pipelines, GitHub, CD/CI.

Have fun with .NET nanoFramework!

Custom attributes with constructor

Yes, you read that correctly!

nanoFramework just got support for these. You can now have custom attributes with a constructor and access the value on the constructor.

Let’s see some code to illustrate this.

Consider these two classes defining attributes.

public class AuthorAttribute : Attribute
    private readonly string _author;
    public string Author => _author;
    public AuthorAttribute(string author)
        _author = author;
public class MaxAttribute : Attribute
    private readonly uint _max;
    public uint Max  => _max;
    public MaxAttribute(uint m)
        _max = m;

Now a class using the above attributes on a given field.

public class MyClass1
    public void MyMethod1(int i)
    [Ignore("I'm ignoring you!")]
    public void MyMethodToIgnore()
    private readonly int _myField;
    [Ignore("I'm ignoring you!")]
    public int MyField => _myField;
    [Author("William Shakespeare")]
    public int MyPackedField;

And finally reaching those attributes.

var myClass = new MyClass1();

var myFieldAttributes = myClass.GetType().GetField("MyPackedField").GetCustomAttributes(true);
Debug.WriteLine($"\nThe custom attributes of field 'MyPackedField' are:");

MaxAttribute attMax = (MaxAttribute)myFieldAttributes[0];
Debug.WriteLine($"MaxAttribute value is: 0x{attMax.Max.ToString("X8")}");

AuthorAttribute attAuthor = (AuthorAttribute)myFieldAttributes[1];
Debug.WriteLine($"AuthorAttribute value is: '{attAuthor.Author}'");

The above code will output something like this:

The custom attributes of field 'MyPackedField' are:
MaxAttribute value is: 0xDEADBEEF
AuthorAttribute value is: 'William Shakespeare'

Looks pretty simple and trivial doesn’t it? And can be very useful too!
Get the full project on our samples repo here.

And what are you waiting for? Go write some code and have fun with nanoFramework! 🙂

PS: make sure you join our lively Discord community and follow us on Twitter.

Welcome TI CC1352R

Today we have a great announcement to make: we are adding support for Texas Instruments SimpleLink™ multiprotocol and multi-band wireless MCUs.

The first ones to get onboard are the CC1352R and the CC1352P.

These SimpleLink MCUs open a myriad of new possibilities as they bring along support for a bunch of radio protocols (not to mention the possibility to implement your own proprietary system). Check these out:

  • Thread
  • Zigbee®
  • Bluetooth® 5 Low Energy
  • IEEE 802.15.4g
  • IPv6-enabled smart objects (6LoWPAN)
  • Wireless M-Bus
  • Wi-SUN®
  • KNX RF
  • SimpleLink™ TI 15.4-Stack (Sub-1 GHz)

Like all the TI SimpleLink wireless MCUs these follow the same design approach: an Arm® Cortex®-M dual-core architecture. One (M4 running at 48MHz) is dedicated to run the user application and the other (M0) acts as the radio protocol processor. Both are highly integrated and live on the same chip.

They have 352kB of executable flash and 80kB of RAM. Quite enough to load any serious application that you can think of.

If you’re interested in developing near the metal that’s OK too as all the parts in the family offer 2-Pin cJTAG and JTAG debugging.

For ready to use modules there are several TI partners offering all possible variants.

Regarding managed API we’ve started by adding the managed class library for EasyLink. Others will follow.

Again, just like with the other SimpleLink counterparts, you can find LaunchPad development boards for these MCUs starting at 39,99 USD.

There is an image ready to flash for the CC1352R1 Launchpad and, if you’re looking into reaching greater distances, there is another one for the CC1352P1 Launchpad which has a built in PA.

To complete the starter package we’ve added a sample pack with two C# projects demoing how easy it is to build a radio link between two of these. One its a simplified node and the other a concentrator. Grab them from our samples repo here.

So, what are you waiting for? Go get your LaunchPad board and hit the radio waves with nanoFramework!

Stable releases published

Today is a great day: we’ve just published stable releases for all nanoFramework class libraries and firmware images.

A lot has changed since the last stable release! Along with many new features, this release brings along a proven history of stability that many of our community have been providing feedback through our preview releases, so we thought this would be a great opportunity to rubber stamp it.

To name a few of the features added since the last stable release:

  • Network improvements like TLS and HTTP Client and Server libraries.
  • New class libraries like Json.NETMF, AMQPLite, MQTT, 1-Wire, CAN and DAC.
  • Storage class libraries with support for USB mass storage devices and SD Cards (target dependent).
  • New CLR features and improvements over the existing ones.
  • Custom managed events.
  • Deployment image generator.
  • nanoFirmwareFlasher tool to easily update images on target boards.
  • Increased communication speed in Visual Studio extension allow quicker deployments and smoother debug experience.
  • Increase QA with SonarCloud and CD-CI moved to Azure DevOps.

More good stuff is on the queue so stay tuned.

By the way: nanoFramework needs you! There are a bunch of ways to contribute to the project besides coding. To find out what you can do take a look here.

Have fun with nanoFramework!