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!

New preview feeds for nanoFramework!

Until now nanoFramework has been using MyGet as its NuGet feed provider to host preview and test packages.

MyGet is a decent provider but only offers 100MB storage on their free trier. Actually they offer 2GB to OSS projects (which is great) and for which we’ve applied, but it turns out that setting up the account for the OSS offer is an absolute pain! After more than two weeks and dozens of emails exchanged with their support we’ve decided to just move.

We already run most of our infrastructure on Azure DevOps and support for public feeds in Azure Artifacts were recently announced at Microsoft Build 2019. This has support for NuGet packages and the offer includes 2GB of storage. Considering all this, we’ve decided to move everything there.

How does this impact you as a C# developer consuming NuGet packages? Not much! It’s only a matter of editing the NuGet package source in visual studio to point to the new feed and you’re done.

The URL for the new feed is:

This impacts the VS extension preview versions too. We are now publishing those on the Open Vsix Gallery. Likewise, if you are eager to get the latest and greatest, and you’re already subscribed to the preview feed, you have to update the URL to:

For a detailed description on how to setup all this in Visual Studio, please read the earlier blog post here.

Have fun with nanoFramework!

Oil tank telemetry with nanoFramework

The first commercial products with the “nanoFramework inside” label (a shameless copy of the old Intel® logo) are out in the wild! Literally.
They were built to perform in a demanding industry and deployment scenarios: oil fields! These devices have been developed and built by OrgPal, a leading remote-monitoring manufacturer and solution provider for the oil and gas industry.

OrgPal entered the market in 2013 and since then, the company has designed three generations of remote monitoring equipment, providing solutions to many oil and gas companies across North America. The solution is called PalThree.

Energy field services and operations require regulatory compliance as well as accurate and frequent monitoring. For oil and gas companies the challenge is finding a cost-effective, reliable system and not all telemetry systems are created equal.

Zan Gligorov, CEO of OrgPal Telemetry, has explained to us the reasoning behind their choice.

“Our objective was to create a modern, simple, easy-to-install and use device that could easily integrate with the hundreds of sensors from the most modern to already existing across oil fields in North America. Our hardware met those goals, but we needed a great firmware platform to match it, and nanoFramework made that possible.

Many solutions use different components from many manufacturers to integrate a solution, leading to a costly solution and even more costly maintenance option. The technology is not compatible by design and given that they are deployed in distant hostile environments with limited or no access to terrestrial communications – and no electrical power supply – maintenance becomes very costly over time.

Because nanoFramework is so feature rich yet easy to use, has small footprint (it fits on tiny MCU’s), our solution is efficient with the lowest power consumption in the industry. We were able to use a very high power STM32 MCU, integrate a complete satellite receiver with antenna, on board flash/file system, USB, cellular support, RTC and more for a very powerful remote measurement system, with low energy footprint.

The resulting PalThree based solution is a game-changer for the industry.”

Checkout some photos from the real thing.

Tanks in staging area
Close up on tank with PalThree
Tank fitted with PalThree deployed in the desert
Solar panel powering PalThree
Palthree in product enclosure

Cool isn’t it? 🙂

Are you using nanoFramework on a commercial product too? Please let us know and join the club here!

nanoFramework Open Collective is here!

Today we have an important announcement to make: nanoFramework is now accepting donations!

In the spirit of the openness and transparency that we have been following since day one, an Open Collective has been setup in order to manage these affairs.

Why do we need donations you may ask… Well, let us take a moment to explain.

PayING for infrastructure costs

Yes, there are infrastructure costs. Like the domain registration, the web site hosting, Azure functions on which our nfbot lives and some features in Azure DevOps that are outside of the free tier that nanoFramework is entitled to as an Open Source project.

CONTINUE public relation activities to EXPAND OUR USERBASE

The saying “out of sight, out of mind” is so true! What good is it to have an awesome framework like nanoFramework if it’s not known in the embedded systems industry, hobbyist communities and academia?! To overcome this, we need to continue to drive a PR effort and to do it properly, money is required to do this. For example, press releases go to a much wider audience and are generally better received when they are written by a professional and sent to the correct media and agencies. Most of us are engineers or folks that just like to code and we are better at coding than writing…

Organizing events like hackathons, or even speaking at conferences to demo the framework and what can be accomplished with it is another way of getting the project known. These have costs involved and sponsorship is welcomed!

Support maintainers and contributors that invest a large amount of time in the project

Most of the core team members and contributors are embedded systems enthusiasts, passionate about coding and people that like challenges. The work on nanoFramework is done mostly in their free time. Some of the core members also happen to work in companies that heavily sponsor nanoFramework already, offering their work time to implement features that they need, but also what the community are crying out for! Compensation for some of this work is an added incentive.

No one ever wants a project to fail, especially the team of developers that spent an extortionary amount of time to bring this project to fruition. With all the will in the world, everyone needs an incentive to continue, otherwise they will move onto the next “big thing” with a great loss of expertise’s and experience. Perhaps name your bounty on a feature that you would like to see, or just point the contribution towards a particular member for previous hard work.

Support projects that nanoFramework depends on

nanoFramework is Open Source and free to use. Free, like in free speech, not like free beer. That won’t ever change . We depend on other projects which are also Open Source and free, and we depend on them to provides us with the tools or components that make nanoFramework possible. Our core team members strive to be involved and contribute back code and fixes whenever possible.

Produce documentation, tutorials and other content to support US

We’ve all been there, and it is one of those matters that doesn’t get many disagreements. Good documentation helps a lot! The same goes about tutorials, videos and even training material. Producing all of this requires time, but most importantly, should be done by people who know what they are doing. Again, most of us are engineers or folks that like to code and we don’t always rank that high in design and communication skills. We can probably accomplish something mildly acceptable in a moment of inspiration, but it will most likely take us a serious amount of time to do that. This is one of those areas that if nanoFramework wants to gain critical momentum and grab the attention of more developers, needs to be done properly. We are either lucky and there is a designer out there that stumbles on the project and volunteers to produce content for it, or we must outsource these works. This all costs money.

We trust this blog post has listed enough reasons for why nanoFramework requires donations and how we plan to spend them. The ultimate goal is to make the project thrive, grow the community and attract more people willing to contribute with their skills.

Like the fellow with the pointy ears used to say, “live long and prosper”! 😉

High Level Programming Languages for Embedded Projects

Industry expert Mark Harris just published an article on its Altium blog about “High Level Programming Languages for Embedded Projects“. The article includes a thorough analysis on the topic on which .NET nanoFramework plays a key role as an excellent framework for embedded projects.

Follows a copy of the original article published in June 2019, for your convenience.

«In today’s vastly growing market, employees of small businesses, small divisions of larger companies, and especially freelance engineers are being asked to fill more roles than ever as part of their job responsibilities. Often, an electronics engineer will not only design the schematic and circuit board, but also may be required to develop embedded firmware for it, and build computer, web, or mobile software. On the other hand, there are web/mobile/desktop developers who branch out into designing and programming hardware because they are passionate about electronics.

With the additional responsibilities, there can be a substantial shortage of time needed to complete projects punctually. With low volume or prototype projects, this might be two-fold to keep the total project costs down. C and C++ are fantastic programming languages, but if they’re not your primary skill/role, they aren’t necessarily the fastest languages to use for developing firmware. Embedded development can have a significantly steeper learning curve than desktop, web or mobile software development, especially when interacting with hardware peripherals and setting registers. For complex projects, C/C++ can get intricate quickly, making debugging and maintaining code expensive components of the total project cost.

The rise of open source hardware abstraction layers and libraries such as Arduino, MBed, and even vendor specific libraries such as LPCOpen has made developing embedded systems a lot easier. These libraries can be utilized instead of an expensive toolchain, which offers a compiler and an extensive range of libraries, such as Keil or IAR. Keil, IAR, and other commercial tools have fantastic compilers; however, for a startup or a small business, they might be out of their initial budget before the project has become profitable. These abstraction layers and libraries can substantially speed up firmware development, however, for a new or infrequent firmware developer, these still have the considerably steep learning curve of C/C++. Furthermore, they may lack sufficient debugging features, such as stepping through the code line by line with an attached debugger with full state inspection, as they are web-based or use a limited development environment.

Getting a product to market quickly can significantly impact sales volume. Conversely, if you’re only building a one-off or doing a minimal production run, every hour spent developing firmware can dramatically increase the cost-per-unit of the device. The same goes for making a proof-of-concept device you might take to an investor, to upper management or, as a freelancer, to your client. The longer you spend writing firmware, the higher the cost and project risk become.

Running a high-level language such as C#, Java, Python, LUA, or even JavaScript can markedly reduce development time for both simple and very complex projects. Higher level languages handle memory management and protection (overflow of arrays, for example), and some languages, like C#, provide an incredibly comfortable debugging experience. Not to mention, finding tutorials for the general language features of these languages is typically easy given their extensive user communities. Debugging capabilities are especially important for an inexperienced embedded developer, as debugging a project could be more time consuming than actually writing the code if the debugging tools are sub-par.

ARM Cortex processors are incredibly powerful at economical prices and come with plenty of RAM, flash space, and high clock speeds. You can pick up an ARM Cortex M0+ which runs code at around three times the speed as the old (23 years!) ATMega AVR that is popular with the Arduino community for about a third of the price at the same volume. These characteristics have led to their enormous popularity in the industry and amongst hobbyists alike. While ARM Cortex-based processors can be much easier to debug than older devices, potentially offering tremendous time savings, they can be more complex to write code for, even with libraries like MBed and Arduino’s ARM ports.

If you spend a little more money on the microcontroller (just a couple of extra dollars), you can get some truly powerful systems that are more than capable of running higher level languages like Java, C#, Python, LUA, and Javascript. These languages are likely to be more familiar and simpler to use, and therefore offer shorter development times for inexperienced or non-embedded developers. Looking back to the low volume/prototype use case, an extra $1 to the per-device cost won’t break the budget, as it could be much cheaper than even a single day of additional firmware development time. With the slightly more expensive microcontroller, you can run .NET nanoFramework and develop in C# with the full Visual Studio debugging experience, complete memory management, and ultra powerful language features that notably reduce the amount of code to be written (and debugged!)

There are some drawbacks to running a high-level language on a microcontroller or microprocessor compared to writing C/C++ code. Depending on your project, these drawbacks could be a significant problem or have no impact at all.

  • Execution Speed: High-level languages will typically run on an interpreter rather than compile to native code. If you’re building a real-time system or need incredibly exact timing, then this rules out high-level languages from the start. However, this won’t be an issue if you consider a five to ten millisecond response time acceptably fast. Some languages support running native C, C++, or assembly code along with the high-level language code, which may mitigate this issue almost entirely.
  • Code Size: Because you need to include the interpreter and potentially a large number of library functions and features, the code size can be substantial before you even blink an LED. Compiled code size typically won’t be an issue as a microcontroller variant with more flash space is not much more expensive.
  • Memory Usage: Again, because of the interpreter you’re likely going to be using much more memory than the same functionality implemented in a language which compiles down to a native format. Also, a processor variant with more memory isn’t much more expensive.
  • Hardware Features: You’re limited to the hardware peripherals on your device that the community or project team have implemented for the platform you’re running. If your device has Bluetooth hardware, but the language and libraries don’t support Bluetooth, you might not be able to use it at all.
  • Supported Microcontrollers: Only specific microcontrollers/microprocessors are supported by each platform, as the platform code generally needs to be ported to each new target. You probably need to decide on a programming language before you start hardware development to know which processor you’ll be using in the project.

That being said, there are some considerable advantages to running a high-level language on a microcontroller too.

  • Development Time: The time to write an application will typically be shorter, especially for an inexperienced developer. The amount of code that needs to be written is reduced, making it easier to maintain.
  • Debugging Experience: This doesn’t apply to all platforms/languages, but those that do support debugging over USB will typically offer a good developer experience. This allows the developer to inspect variable values, step through the code line by line, and control execution. You can do this with C/C++ on an ARM Cortex processor using a hardware debugger (Single Wire Debug – SWD), but you’ll need to be using Eclipse or another desktop IDE rather than Arduino, MBed or any web-based IDE.
  • Memory Management: Correctly managing memory can be difficult, especially in complex projects. High-level languages take care of this for you.
  • Software Feature Availability: In contrast to the lacking hardware features, software features such as graphics on a screen or networking might be very well supported, linking back to Development Time.
  • Code Sharing: If you’re developing a web service to work with the embedded device in the same language, you can probably share code for objects and business logic between the two.

If you’re new to embedded development or don’t have any programming experience and feel as though you have been thrown in the deep end, a high-level language can save your project. Those languages are easier to pick up, get the job done faster, and allow for fewer bugs. The tutorials available for them running on a desktop environment are usually wholly applicable to the embedded environment, so there is no shortage of educational material.

I feel C# via the .NET nanoFramework (.NET nF) is one of the most powerful languages you can run on a microcontroller. This is the community successor to Microsoft’s .NET Micro Framework, which is no longer maintained. The .NET nF allows interop, which means you can run native code on the microcontroller for processor intensive or real-time functions.

Currently, the cheapest and most resource-constrained microcontroller that .NET nanoFramework runs on is the STM32F091, at a bit under US$2.50@100qty depending on your distributor and exact model. That gives you a 32bit 48MHz processor with 128kB of flash and 32kB of RAM. By comparison, an ATMEGA328 will set you back around $1.10 to $1.25 depending on package and distributor for an 8bit 20MHz processor with 32kB of flash and 2kB of RAM. Compared to the Arduino IDE, Visual Studio has the highest market share of any development environment and is incredibly powerful. The .NET nF integrates fully with Visual Studio, including the free community edition, so you can have the full debugging experience over USB, allowing you to catch exceptions, step through code and inspect (and change!) object values.

C# is one of the top five programming languages in use today, and arguably the most used in professional environments in all of web, desktop, and even mobile. So there’s an excellent chance a developer on your team has more experience with C# than with C or C++. You can likely use data classes written for a web or desktop application directly in an embedded project if they are both written in C#.

While certainly not lacking in features, the .NET nanoFramework doesn’t have the complete functionality of the ‘full’, ‘standard’ or ‘core’ Common Runtime Language (CLR). The heavily constrained resources of a microcontroller relative to a full computer mean some features are not feasible to implement. The .NET nF community is primarily working to implement mscorlib and the Universal Windows Platform (UWP) features. In addition to the aforementioned, some language/library features that I feel will save a large amount of time in an average project are:

  • Very easy string manipulation and handling.
  • Parsing and building XML and JSON.
  • Accessing device storage (SD card and flash memory devices)
  • Networking (direct sockets, web requests, etc.)
  • WiFi (with external modules, or directly on an ESP32)
  • Hardware ‘drivers’ and other libraries available via NuGet

Using a language like C# via the .NET nanoFramework can greatly accelerate project development for IoT devices, sensors, wearables, and many other devices. While you couldn’t build a three-phase brushless motor controller with C# due to the timing constraints, the vast majority of projects can benefit from its rapid development pace. 

Upcoming projects on this blog will make good use of the .NET nanoFramework and serve as getting started guides and real-world project examples. While it’s a fantastic high-level language to use, there are many other languages you can run on a microcontroller. If you’d like to see some projects or articles focusing on them, let me know in the comments below!»

Check it out and join our Discord community for discussion.

Setup Visual Studio to access preview versions feed

(updated on 2019-08-21)

If you are one of those developers that like to have access to the shiny and newer versions of the components you use, this post is for you.

It also applies if you are testing a PR for one of the class libraries or one of the experimental develop branches.

A bit of background information first to put you in context.

All the official (or labelled stable) releases of our Nuget packages are distributed through Nuget. The same goes for the Visual Studio extension. It’s distributed through the Visual Studio Marketplace.

All the above works just fine with the default Visual Studio configuration and settings. So nothing particularly thrilling so far…

Now, if you’re after the good stuff you’ll want to setup your Visual Studio to access nanoFramework’s developer feed. This feed hosted in Azure Artifacts from our Azure DevOps account.

Actually, there are two different feeds: one for the Nuget packages and another one for the Visual Studio extension.

Azure ARTIFACTS Nuget feed

If you want to add this feed to your Visual Studio, just follow the following steps.

1.       Open Visual Studio Options window (available in Tools menu).

2.       On the Options window navigate on the left-hand toolbar to Nuget Package Manager – Package Sources.


3.       Click on the add button (the big green plus sign on the top right) and enter a name for the package source along with the following URL: 

4.       Click on the Update button otherwise your changes won’t’ be effective.

5.       That’s all. From now on this feed will be included on the searches and update checks on the Nuget Package manager.

Note 1: Make sure that you have this new source selected in the Package Source filter in the Package Manager (top left corner), otherwise it won’t be included in the search.

Note 2: in case you are looking for a Nuget package of a PR you are testing, for example, you’ll find those with the alpha suffix. If there is more than one, check the release date for disambiguation.

Open VSIX Gallery

1.       Open Visual Studio Options window (available in Tools menu)

2.       On the Options window navigate on the left-hand toolbar to Environment – Extensions and Updates.


3.       Click on the Add button at the right and enter a name for the gallery source along with the following URL:

4.       Click on the Apply button otherwise your changes won’t’ be effective.

5.       That’s all. From now this gallery will be included on the searches and update checks for your Visual Studio Extensions and Updates.

And that’s all folks! Now you can easily access the fresh new packages as they get out of our Azure Pipelines builds.

Build, build, build…

Here’s a quick overview on one of the key aspects of any software project: the build. nanoFramework is no different and we all know how critical this is, so we’ve put a lot of attention and care on this matter.

The goal was to make it highly configurable (because there are a lot of features and components that a developer may want to include or leave out of a particular image) and, of course, being very easy to setup.

The choice was to use CMake a well-known and proven build system (available for Windows, Linux and MAC).

Another reason for it is that are a couple of nice extensions that make it very easy to work with CMake on VS Code. Why is this relevant? Well, because we’ve been using VS Code as the official IDE for developing the native side of nanoFramework.

The only pre-requisites for running a build are the GNU ARM Embedded Toolchain and CMake.

There is a document in our GitHub repo detailing all this: how to setup it up and how to start the build.

To prove that this is really easy (and that it works!) know that even a machine can do it. Yes, that’s true! 😉

As part of our QA and DevOps each pull request commit and merge commit into the master branch goes through an automated process that builds the image for each of the reference target boards. Only after an “all green” condition the commit is merged or accepted. We are using Travis CI for running these automated builds (a big “thank you” for the folks at Travis CI for providing free accounts for Open Source projects).

To make my point here (about how easy it to setup and run the build) let’s take a brief look on what happens on each of those builds:

  1. Travis CI spins up a virtual machine with a clean image of Ubuntu
  2. GNU ARM Embedded Toolchain is installed
  3. CMake package is installed
  4. nanoFramework sources are pulled from GitHub
  5. ChibiOS sources are pulled from GitHub
  6. A build starts for each of the reference target boards

See? If a machine can do it so can a human. 🙂

The same can be done “manually” right from VS Code. We’ve tried to make that very easy by providing templates for the configuration files required by the CMake Tools extension.

So, after this (and if you haven’t done it already) what are waiting? Go and setup your machine to run a nanoFramework build. Next, who knows, you’ll be making your way into the code and submit some pull requests…

I’m Framework, nanoFramework

You’re probably thinking: “what the heck is nanoFramework?”

Our vision for it is to be a platform that enables the writing of managed code applications for constrained embedded devices. Developers can harness a familiar IDE such as Visual Studio and their .NET (C#) knowledge to quickly write applications without having to worry about the low level hardware intricacies of a microcontroller.

Now you are probably thinking: “hum… this sounds familiar… isn’t there already a framework like this?”
Well, you are correct! There is one: the .NET Micro Framework (NETMF).

Your next – probably – obvious question would be: “if there is already one, why are you doing this? Don’t you have better things to do with your time?”

On this, we beg to differ… 🙂

NETMF was a great move from Microsoft to bring the ease and simplicity of managed .NET coding (C#) to the embedded world. The potential of this concept was (and still is) incredible and immensely powerful!
It started as a closed source, licensed product and later it moved to an open source model with a CodePlex repository.
Along it’s journey NETMF began to receive less and less love from Microsoft until it reached the point of being completely abandoned. The community around it was never what we would call a strong and thriving one. Along the way several attempts were made to revive the project and put it under the community management. Unfortunately without success…

Given this, nanoFramework emerges from the combination of several aspects:

  • The frustration of seeing the incredible potential of NETMF misunderstood.
  • Contemplating the waste of work and effort over many years by letting NETMF stay abandoned.
  • The firm belief in the concept and how it can fulfil such a vast amount of use case/scenarios such as: a learning platform, rapid prototyping system or even a fully fledged framework capable of powering a commercial product.

A group of like minded people gathered around these ideas and decided to take the matter into their own hands. We started by shaping our vision for it should look like and what would be the ideal experience for working with and developing using it. We Identified what the short-comings of NETMF were and what aspects were worth keeping or should be improved. We then drafted a plan of action before rolling up our sleeves and started testing ideas and validating proof of concepts.

Without trying to be exhaustive here’s our initial “whish list” for nanoFramework:

  • a decent and working build system
  • improved PAL (Platform Abstraction Layer)
  • easy porting process
  • ability to go through the full development cycle for native code
  • leveraging an existing RTOS for embedded systems
  • core code hardware agnostic and to ease port
  • easy process for developing a nanoFramework board (NETMF Solution)
  • architected to make it easy to add new features
  • provide enough documentation to allow newcomers and veterans to understand the code and the design decisions behind it

We are currently making all this to happen by:

  • working on a revised CLR (Common Language Runtime) and interpreter
  • working on a build system based on CMake (proof of concept already validated)
  • working on a reference implementation based in ChibiOS (proof of concept already validated)
  • providing a full development cycle experience (coding to debug, including build) without leaving VS Code (freely available)

The goal is to have a minimal working nanoFramework in the coming weeks. This will allow to accomplish two objectives:

  1. To show a working example that fully validates the approach.
  2. To reach a point were any willing person can start contributing code and other work.

We would very much like to be able to create a thriving community around this project! There are a lot of ways that one can contribute to the project and coding is not the only one. Writing documentation, reporting issues and bugs, testing features, making suggestions, working on the web site and many others are just as valuable to us. Even just mentioning/promoting nanoFramework on social networks/forums can help towards improving the visibility of the project, so please, spread the word!

Feel free to take a look at our GitHub repo and/or join the Slack community here.

Welcome to nanoFramework and looking forward to your contributions!