Blog

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:

.\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!

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
{
    [Attribute1]
    [Attribute3]
    public void MyMethod1(int i)
    {
        return;
    }
    [Ignore("I'm ignoring you!")]
    public void MyMethodToIgnore()
    {
    }
    private readonly int _myField;
    [Ignore("I'm ignoring you!")]
    public int MyField => _myField;
    [Max(0xDEADBEEF)]
    [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!

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!