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 also 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:

.\Initialize-VSCode.ps1

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!

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:

https://pkgs.dev.azure.com/nanoframework/feed/_packaging/sandbox/nuget/v3/index.json

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:

http://vsixgallery.com/feed/author/nanoframework/

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!

NuGet, assembly and native versions

nanoFramework C# class libraries are distributed as NuGet packages to be consumed by projects. This has been like this since day one. NuGet packages are practical, easy to distribute, easy to consume, easy to update.

But they had a …minor… problem. Actually, make that two… 😉

One was that the dependency between the managed assembly version and the corresponding version of the native end. The initial approach on this (inherited from .NETMF) was that the native version numbering had to follow the managed version. The main reason being that, at deployment time, there is the need to check if the device has support for what is about to be deployed to it. Nothing against this check that is perfectly reasonable. But – and this is a big but – this check is too strict. A detailed explanation on this has already been provided in this other blog post. Basically, what happened was this: even if the native code hadn’t any change whatsoever, it was forced to “change” just because the version had to bump in order to follow the managed one. This led to a consequence that is kind of severe in our context: forces to update the firmware on the target devices, which is something to be avoided at all costs!

This was improved a few weeks ago with the addition of the AssemblyNativeVersion attribute to our class libraries. This attribute is there to decouple the version numbers in the managed assembly and the native implementation. With it, the check on the required version on the target device at deployment time is possible and, by decoupling it from the managed version, made it possible to keep improving and changing the manged assembly as needed without forcing the native one to follow. Only when there is a real need to change the native part it’s version will have to be bumped

The second problem was that, because of that strict versioning dependency, whenever the version of an assembly changed all the dependent ones had to follow. The consequence is that this required massive and cascading updates that are time consuming and force everyone and everything to follow upon. If the version of mscorlib changed, guess what? All other class libs had to change along just to follow it!!

This too has been improved. Because of all the above, there is no need for this strict dependency anymore. The native versions have been bumped to a high number to make it clear to developers that the versions do not need to be matched. So, please, no more attempts to match these, OK?

Along with this, the NuGets have been updated too and the dependencies are not strict versions anymore. Check bellow what is showing in Visual Studio package manager for a NuGet package before and after.

Another improvement in the NuGets is that the required native version is now showing on the NuGet description. Making this visible removes the obscurity behind it and this can be checked visually and programmatically.

This native version is what the target device has to have support for. The native version available can be checked in the Device Explorer in Visual Studio. Bellow you can see the device capabilities of a target that has support for the above NuGet.

Every class library is now free from this slave dependency and, from now on, will have its version bumped only when there is a real need to.

The outcome of all this is that now we can start dealing with nanoFramework NuGets like we usually do with any other NuGet package: consume as needed and update when needed, not because we are forced to.

Trust all this will make everyone’s life easier and remove a lot of the friction that was around nanoFramework NuGets.

Have fun! 🙂

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”! 😉