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!

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!

Welcome Json.NetMF

If you come from the .NETMF age and at some point worked with json, you’re probably familiar with Matt Weimer‘s library: Json.NetMF.

Making a bit of history: that library started as a modification of Mike Jones’s JSON Serialization and Deserialization library. It was available as NuGet for .NETMF v4.2 and v4.3. It was never brought up to date with v4.4. Now it is.

Despite doing what was expected from it, the library never got any improvements and has been stalled for years.

Well, this is bound to change! Matt has decided to transfer the library to under the nanoFramework’s umbrella and since last week, that’s where it now is .

The plan is to keep the .NETMF NuGet package available and also provide an additional one for nanoFramework. The work to make this happen has been completed then nanoFramewotk version is available here.

It seems unfair to leave this nice tool inaccessible to other C# embedded developers so, at some point in the future, we could be seeing a NuGet for TinyCLR and another one for Meadow. Who knows?…

As for improvements: lets’ hear from the community, tackle the open issues and see where all this takes us. Of course, being open source, everyone is welcome to contribute!

Thank you Matt for your work on this. Rest assured it’s in good hands and we’ll be taking good care of it.

 

Build, build, build…

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.

The only pre-requisites for running a build are the GNU ARM Embedded Toolchain and CMake.

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:

  1. Travis CI spins up a virtual machine with a clean image of Ubuntu
  2. GNU ARM Embedded Toolchain is installed
  3. CMake package is installed
  4. nanoFramework sources are pulled from GitHub
  5. ChibiOS sources are pulled from GitHub
  6. A build starts for each of the reference target boards

See? If a machine can do it so can a human. 🙂

The same can be done “manually” right from VS Code. We’ve tried to make that very easy by providing templates for the configuration files required by the CMake Tools extension.

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…