Original post at José Simões personal blog here.
nanoFramework has been recently discovered by the technology enthusiast GoJimmyPi who has been actively using it on one of it’s projects. He recently wrote a blog post describing it’s experience and how it’s been using it on a Radiona ULX3S development board.
Check it out and join our Discord community for discussion.
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!
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!
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.
Cool isn’t it? 🙂
Are you using nanoFramework on a commercial product too? Please let us know and join the club 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”! 😉
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 nanoFramework plays a key role as an excellent framework for embedded projects.
Check it out and join our Discord community for discussion.
(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…
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.
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.
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:
- Travis CI spins up a virtual machine with a clean image of Ubuntu
- GNU ARM Embedded Toolchain is installed
- CMake package is installed
- nanoFramework sources are pulled from GitHub
- ChibiOS sources are pulled from GitHub
- A build starts for each of the reference target boards
See? If a machine can do it so can a human. 🙂
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…
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:
- To show a working example that fully validates the approach.
- 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!
Welcome to nanoFramework and looking forward to your contributions!