Blog

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

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

SonarCloud is on nanoFramework repos!

Code quality is something that is high in our priority list at nanoFramework.

Though, being on the list is not of much use, it must be measurable and comparable against an accepted standard.

For this reason, since last week we’ve been busy adding the awesome SonarCloud tool to all our class libraries repositories on GitHub.

SonarCloud is an analysis tool that checks code for issues and defects that aren’t caught by the compiler but are problems none the less. These can be for many reasons, like code that hides an unintended behaviour, a potential security breach, a violation of the .NET principles and good practices, unit test coverage and many others. These are grouped into bugs, vulnerabilities, code smells, coverage and duplications. A global classification of the project is then computed into a score.

The SonarCloud folks are supporting Open Source projects by offering their tool free of charge. Nice!

It’s setup is straightforward and takes only a few minutes per project. SonarCloud provides an Azure Pipelines task which is great for nanoFramework and it allows us to analyse PRs as they are submitted. The same goes for commits that show the various scores and metrics right after being built.

This has already pointed a few code smells and bugs that were luring in our code.

All in all, we are in very good shape! Just check it out! Most of our repos have their quality gate showing a green “pass” and score “A” in most of the categories. We do have some Cs and Ds, mostly because of code complexity, which is something that can be improved, but nothing serious.

One area that we are not performing that well in (and to be completely honest, are not performing at all) is code coverage. Our class libraries are still lacking unit tests. Mostly because we still haven’t worked out a sufficient way of running tests and collecting results when they require deployment to real hardware, But we’ll get there (feel free to contribute)!

 

WE ARE HIRING! 😉 make sure you join our Discord community

Deployment image generator

nanoFramework Visual Studio extension (both VS2017 and VS2019 versions) just got a new improvement: the ability to generate a “deployment image”. And what the heck is a “deployment image” you ask? Let me explain with a bit more detail.

To run a C# application a nanoDevice must have on its storage (which is a flash memory on all current target platforms) the following bits:

  • The nanoBooter responsible to perform the cold boot of the CPU and provide a mean to perform updates and a safe place when the CLR is messed up for some reason. This is valid unless the platform has to use it’s own, which is the case with ESP32 and the recently added TI CC32200SF.
  • The nanoCLR which comprises the IL execution engine, the CLR and the native parts of all the class libraries that the device has support for.
  • The configuration block. Optional and only required for devices that are network enabled to store network related stuff. Specifically, network configurations, certificates and Wi-Fi profiles.
  • The PEs (portable executable) of the managed application and the assemblies it references, like class libraries or others.

All those are made available in different occasions and flashed using different tools.

  • nanoBooter and nanoCLR are made available after compiling the nf-interpreter or by downloading them from our Bintray repository. These are flashed using the appropriate tool for the platform. This would be the nanoFramework flasher tool for ESP32, ST-LINK Utility or DfuSe for STM32 and Uniflash for TI.
  • The configuration block is written by the C# application itself or by using the Network Configuration dialog box available in the Visual Studio extension.
  • The PEs of the managed application (and referenced assemblies) are available upon a successful build of a Solution in Visual Studio. Those are deployed to the nanoDevice when hitting the “Deploy” option for the C# Project or when starting a debug session on Visual Studio.

If one is using nanoFramework to deploy stuff on a couple of boards the above is quite all right and works perfectly. Now, if you need to commission several boards on a production run or for a field test using a few dozen boards, things start to get complicated and time consuming. You’ll need to, at least, use a couple of different tools and possibly connect and disconnect each board a couple of times.

There is already a very handy feature which is the generation of a binary file with the bundle of all the PEs (application and referenced assemblies) that can be used to flash the “application” on a target that has already been loaded with the nanoBooter & nanoCLR. Yes, that’s the .bin file with the assembly name that you can find on the project output folder after a successful build.

nf-app-binary

We the recent improvement this was taken to the next level: generating a complete deployment image. Yes, you read it correctly, COMPLETE. With all the above: nanoBooter, nanoCLR, PEs and configuration block.

The nanoBooter, nanoCLR and configuration block are dumped from the connected target flash and cached (because that’s a lengthy operation). When the deploy operation occurs (and the PEs are generated and made available) the Visual Studio extension cooks everything together and spits a nice binary file with the full package.

nf-deployment-image-bin.png

This is working right now for STM32 targets only. Support for other platforms where this programming approach is suitable will follow.

The binary file can be flashed into the device using ST-LINK Utility or, if you’re working with an mbed enabled ST board (which all recent DISCOVERY and NUCLEO boards are), you can just drop it at the disk drive that shows on Windows Explorer and that’s burned in the flash in a couple of seconds. How cool is this?

Enough technicalities let’s see this working! 🙂

Enable the deployment image generation in the (new) settings dialog available in Device Explorer.

nf-enable-deployment-image-generator.png

You can optionally include the configuration block coming from the “seed” device. If you don’t, the region corresponding to the configuration block will be flashed with an empty content.

Just bellow this, you can find the configurations about the flash dump files cache. The options are: caching to the project output folder (which is the default) or in a location that you can specify.

All the above settings are persisted in you Visual Studio user account.

When you hit deploy or start a debug session, the magic happens, and the image is generated.

Something worth noting: the flash contents need to be dumped when they are not available on cache and this can take a few seconds before it completes. So be patient and know that this will happen only once for each device.
If you have a lot of devices and work on several projects at the same time, it’s probably wiser to use a central cache…

Now that we have the deployment image, let’s check it out.

Fire up ST-LINK Utility and connect the board. I’m using a STM32F769I-DISCO for this example.

nf-st-link-utility-connected

The board is already flashed with nanoBooter and nanoCLR and a debug session has been started previously with the Blinky application (meaning that the required PEs are there too). So, it has everything needed to blink the LED. Which it’s doing.

[wpvideo JCaz3qT8]

Next let’s load the file with the deployment image binary.

nf-st-link-utility-open-file

ST-LINK Utility has a nice comparing tool that we’ll use to compare the contents of the deployment image binary and what’s in the device flash.

nf-stlink-compare.png

We need to compare all the flash content so we’ll enter the flash start address next, which is 0x08000000 for this device.

nf-stlink-compare-start-address.png

The file contents are loaded next and the compare operation starts. I’m guessing that ST-LINK is very thorough on this because the operation takes a lot of time to complete.

nf-stlink-compare-progress.png

And voilà, if there were any doubts, the machine outputs it’s conclusions and confirms that both contents are identical!

nf-stlink-compare-success

Last test with this: use the disk drive flashing method.

Start by wiping the flash content using the “Full Chip Erase” command in ST-LINK Utility toolbar.

nf-stlink-full-chip-erase

After this you can disconnect the device.

Open Windows Explorer and locate the drive.

nf-mbed-disk-drive.png

Now open the folder where the deployment image file is located (that should be the project output directory) and simply drag and drop it on the drive representing the connected target. The upload will take a few seconds. After that operation is completed the MCU is reset, nanoBooter loads nanoCLR and finally the managed application is executed.

[youtube https://www.youtube.com/watch?v=jPheVSzfxu0&w=560&h=315]

This can be useful in many situations, like in production runs to load a test application, testing a bunch of boards, keeping a snapshot of a deployment, etc.

If you have an idea on how any of this can be improved, let us know, just send us a Tweet or join our Discord community. 😉

Have fun with nanoFramework!

nanoFramework ready hardware?

A quick blog post about a survey we are conducting about nanoFramework ready hardware.

We get it that there is already a bunch of hardware out there that one can choose to start with or develop an embedded systems project on top of. But we’ve been giving this some thought internally and we are inclined to believe that we can add something to this. Moreover, having readily available hardware that includes dedicated nanoFramework support and continuously up to date images ready to flash on the devices would be something positive for the project.

Right now we are just evaluating this. No promises. 🙂

It would be very helpful if you could spare 5 minutes of you time and let us know your thoughts about this.

You can find the survey here.

 

Welcome TI and CC3220!

The MCU family is growing larger by the day and it is time to celebrate a new vendor!

Today we are adding TI CC3220SF LaunchPad™ to the growing list of nanoFramework reference targets. Yes, we’ve seen new boards added before, so why all the fuss about this one? Looking closely and it is more to it than “just” a new target. Check this out:

–        We are adding a new chip vendor to the supported list: Texas Instruments.

–          A new HAL/PAL comes along with it: support for the TI SimpleLink™ platform is now available which means that more TI parts can be easily added.

–          There is now another option for a 100% standalone wireless (Wi-Fi) MCU.

This means that there are now more options for people to choose from, and opens a variety of paths to follow. This is a clear sign of nanoFramework’s vitality and that it’s making its way to be seriously considered as a viable option for both commercial and makers.

Let’s now look closely at the TI CC3220SF MCU.

It is a true wireless standalone MCU with a Arm® Cortex®-M dual-core architecture. One (M4 running at 80MHz) is dedicated to run the user application and the other (M0) acts as the Wi-Fi network processor. Both are highly integrated and live on the same chip.

This come along with a generous 256kB of RAM and 1MB of executable flash and external serial flash on ‘SF’ models.

All the usual hardware peripherals are there: GPIO, SPI, I2C, PWM, serial, I2C, timers, SD card, ADCs. There is also support for a camera and an LCD.

The Wi-Fi capabilities have everything that one can ask for: 802.11 b/g/n, station and access point modes, IPv6 all the WPA2 personal and enterprise security, hardware crypto engine, secure sockets (up to TLS1.2).

The chip (and the companion modules) are Wi-Fi Alliance® certified, which is something huge if you are considering this for a commercial product.

Speaking of commercial products, the MCU and the SimpleLink™ SDK provide some very interesting features that set it apart from it’s competitors: unique device identity, secure key storage, file system security, software tamper detection, cloning protection and secure boot with integrity and authenticity of runtime.

The radio characteristics are pretty good. Check this out.

Wi-Fi TX Power:

  • 18.0 dBm at 1 DSSS
  • 14.5 dBm at 54 OFDM

Wi-Fi RX Sensitivity:

  • –96 dBm at 1 DSSS
  • –74.5 dBm at 54 OFDM

As the power management are, which is something that TI parts are very good at.

Advanced Low-Power Modes:

  • Shutdown: 1 µA
  • Hibernate: 4.5 µA
  • Low-Power Deep Sleep (LPDS): 135 µA (Measured on CC3220R, CC3220S, and CC3220SF With 256KB RAM Retention)
  • RX Traffic (MCU Active): 59 mA (Measured on CC3220R and CC3220S; CC3220SF Consumes an Additional 10 mA) at 54 OFDM
  • TX Traffic (MCU Active): 223 mA (Measured on CC3220R and CC3220S; CC3220SF Consumes an Additional 15 mA) at 54 OFDM, Maximum Power
  • Idle Connected (MCU in LPDS): 710 µA (Measured on CC3220R and CC3220S With 256KB RAM Retention) at DTIM = 1

Looking at low level development, the landscape also looks nice: JTAG, sJTAG and SWD debug interfaces are available.

For applications where it makes more sense to use an existing module, instead of designing a board from scratch, TI has you covered as it offers a Wi-Fi certified module with this chip. With or without antenna included.

The CC3220SF LaunchPad™ development board, which is something developers used to TI parts are familiar with, is available for only 49,99 USD. It has everything that you can expect of a development kit: plenty of exposed pins, LED’s, buttons, sensors, jumpers to test with and debugging interface exposed through an USB connector.

So, what are you waiting for?! Grab one and start having fun with nanoFramework! 🙂

To deploy, or not to deploy, that’s the question…

nanoFramework class libraries are composed of a managed part (written in C#) and the respective counterpart (written in C/C++) that is part of the firmware image that runs on the target.

As part of the usual development cycle there are improvements, bug fixes and changes. Some of those touch only the managed part, others only the native and others both. If the interface between them is not in sync: bad things happen.

In an effort to improve code quality and make developer’s life easier, two mechanisms have been implemented along the way. One was to have version numbers on both parts (that have to match) and the another was an improvement introduced on the deployment workflow that checks if the versions of the assemblies being deployed match the ones available in the target device. Pretty simple and straightforward, right?

Despite the simplicity of the mechanism, it has some draw backs. Occasionally it gets confusing because of apparent version mismatches caused by the fact that the develop branch is being constantly updated and the versions are bumped. Also, because the preview versions of the NuGet packages are always available in nanoFramework MyGet feed and not always on NuGet.

The other aspect that is not that positive is the need to have the versions in sync, which means that whenever the class library assembly version changes the native version must be bumped too. And that requires flashing the target device again. Most of the time without any real reason except that a version number was changed.

This is changing for better!

As of today, the native version number is independent of its managed counterpart. Meaning that it will change when it makes sense and not just because it has to mirror the managed version. Some of you are probably thinking right now that this will be a step back and has the potential to cause trouble with obscure version mismatches and deployment hell. This won’t happen because of something else that we are introducing on all class libraries (and base class), an Egg of Columbus, actually. There is new assembly attribute on all of those that declares which native version is required. Simple but effective.

This is will be used from now on by the deployment provider to validate if the target has all the required assemblies and versions to safely deploy the application.

Because these introduce several breaking changes, make sure you update the VS extension (2017 and 2019 versions available) and the NuGet packages on the Solutions you’re working for a smooth transition.

Happy coding with nanoFramework!

Support for Visual Studio 2019: check!

Last week we’ve published nanoFramework extension for Visual Studio 2019. Right on time before the official launch event on April 2, 2019. 😉

Being Visual Studio a corner stone in nanoFramework development experience, we wanted to show not only our commitment to our growing community by enabling them to keep up with Visual Studio release schedule, but also our appreciation to the Visual Studio team for providing us such an awesome tool.

With the release of the VS2019 version the extension for VS2017 will enter in maintenance mode. This means that we won’t be adding any new features to it. Only bug fixes and we’ll port also any fundamental changes that are required to keep up with new features that cause breaking changes.

As for the VS2019 extension, lots of good stuff is on the queue. We have plans to improve network configuration dialog, provide target updates right from Visual Studio and support for Unit Test.

Now go watch the launch event, install nanoFramework extension as soon as you get your VS2019 setup and stay tuned for exciting developments.

Follow us on Twitter, subscribe our YouTube channel and rate the extension on the marketplace. Do send your comments and suggest new features.

To wrap up, the usual punch: feel free to contribute with code, samples or any productive work to help the project and the community.

Have fun with the new VS2019 and nanoFramework!