Blog

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);

Console.WriteLine($"\nThe custom attributes of field 'MyPackedField' are:");

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

AuthorAttribute attAuthor = (AuthorAttribute)myFieldAttributes[1];
Console.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!

nanoFirmawareFlasher is here!

The nanoFramework toolbox just got a new addition: nanoFramework Firmware Flasher.

This new tool is a CLI provided as a .NET Core Global Tool.

And why is this so special you may ask!

A .NET Core Global Tool is a special NuGet package that contains a console application. It gets installed on the developer’s machine in the default location and is made globally available in the command prompt.

The install is made with a simple call to the dotnet CLI and updates are provided through NuGet (just like any other NuGet package we are used to).

Check out how easy it is to install:

dotnet tool install -g nanoFirmwareFlasher

How cool is that! 😊

It supports targets for both ESP32 and STM32 platforms (the remaining ones will be added shortly).

Now, let’s drill down into the tool functionalities.

With it, one can update the firmware image right from the official Bintray repositories. This is valid for all development, stable and community targets. The fw version can be specified, or the latest available package can be used. Just like this:

nanoff --update --platform esp32 --serialport COM31

Along with the firmware package that includes both the nanoCLR and nanoBooter (except for ESP32 targets that have their own bootloader) it can also include a deployment package (C# program). This means that the full programming of a device can be easily be accomplished for example in a production environment. Because this is a CLI tool, the full process can be completely automated!

It also allows the backing up the deployment area for ESP32 targets (support for other platforms will be added).

Restoring a deployment image is also possible for all targets.

Specifically for STM32 targets, it works with both JTAG and DFU connected devices. One can even list the connected devices on any of these options. Again, this can be handy for production environments.

As usual let us know if you find any glitches and what features you’re missing.

If you haven’t done so, make sure you join our Discord community and follow us on Twitter.

Have fun with nanoFramework!

PS: we are “hiring”! If you like to develop for embedded systems join our team.

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! 🙂