Author: José Simões

Welcome TI and CC3220!

Posted on by José Simões in CC32xx, TI, Wi-Fi

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…

Posted on by José Simões in Nuget, tools, Visual Studio, VS Extension

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!

Posted on by José Simões in C# managed code, Visual Studio

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!

Welcome Json.NetMF

Posted on by José Simões in json, Nuget

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.

 

All systems green! (again)

Posted on by José Simões in CD, CI, tools

After the release of v1.0 we turned a page and that is true on what concerns our GitHub repositories history. Release means tagging a point in the repository commit history. And suddenly after that all hell breaks loose on our versioning system!

Continuous deployment and continuous delivery are great, but we must make sure that all that actually works… Specially all by itself and not requiring constant baby-sitting and tweaking. This was not happening with this…

To give you an insight: we are using AppVeyor as the build platform (a big thanks to them for making it available for Open Source project such as nanoFramework) and (until last week) on GitVersion to figure out the next version that will be used when running a build. Out of nothing GitVersion went nuts and suddenly wasn’t able to compute the next version on some PRs and specially on git tags! After an insane number of hours spent trying to reach to the root cause of it (including AppVeyor support, asking for help on the project page – help that never came – and looking at other projects using it) it was decided that the best course of action was to switch to a better alternative. Switching tools carries a degree of uncertainty and the need to change stuff that was working, so it’s not something to be taken lightly… 😕

Surprisingly a quick search didn’t reveal much options. At least that looked credible and reliable. One option popped tough: Nerdbank.GitVersioning. Digging a bit deeper it seems that this is the tool that Microsoft is using lately on some of their major repositories. MSBuild included. So, if it’s good enough for taking care of MSBuild it should be suited to our modest requirements… 😎

Since you ask, between nf-interpreter, debugger and class libraries there are now 27 repositories. That’s a lot to maintain!! 😯

Moving forward and up to climb the learning curve that comes along with each new tool!

After making the required adjustments and tweaking on Yaml, PowerShell, config files and VS projects we (finally) have all system green again.

Now, back to coding which is a lot more fun!! 😉

nanoFramework v1.0 is official!

Posted on by José Simões in Uncategorized

Today we are proudly announcing the first official release of nanoFramework.

What a journey we’ve made… for over two years now a lot of code has been written, tested, and rewritten. A lot of ideas were discussed, tested, reviewed, implemented and even scraped. We won’t bother you with statistics on the number of commits or code lines as these are in plain sight within the repos. All in all, we have a lot to be proud off, including:

  • Working and usable images for 14 targets (STM32 ARM Cortex-M and ESP32 SoC).
  • A Visual Studio extension providing device management, project system and debugging capabilities.
  • NuGet packages with the various class libraries making it very easy for developers to consume and update their projects.
  • A fully automated CI and CD pipeline for all of our repositories.
  • A modular approach to our GitHub organization with a collection of 30 repositories.
  • A set of software utilities that make developers life easier.
  • A working support system based on GitHub issues.
  • A fully fledged and ever improving amount of documentation available online.
  • A friendly and thriving Discord community where developers can ask for help, assist other fellow developers, make suggestions, chime in on discussions about future developments and interact with other developers.
  • A Website, YouTube channel and Twitter account.
  • A platform hub on Hackster.io to showcase projects.

What exactly does this official release mean? That we are done? Not even close. We are just getting started!!

This is more like a mandatory milestone that’s kind of expected by any project in order to move forward. So this is it!

There is still a lot to come and nanoFramework is poised to grow at the same rapid pace as we have always strived for.

We are expecting that more people get to know and embrace the framework. That companies start to look at us and seriously consider nanoFramework a viable option when they are choosing a framework for their next embedded project.

There is our roadmap, or should we say, to-do list organized in our GitHub organization projects.

What is expected in terms of releases? Our current plan is to follow a continuous integration and continuous delivery strategy, meaning that you’ll see frequent releases. Not so much bound to a certain cadence but rather to usefulness and opportunity. Whenever it’s a good time to release we’ll kick another one.

Wrapping it up: it’s been fun so far and it’s our belief that nanoFramework has fulfilled (most) of the initial plan and expectations.
It would be great to see more people contributing, not only by coding but posting projects, working on examples, writing documentation, and answering questions from other developers… all that would be expected to happen in a thriving and prosperous Open Source project as we are.

nanoFramework: live long and prosper!

Obfuscation? We have an app for that!

Posted on by José Simões in C# managed code, obfuscation, tools, Uncategorized

If you are in the .NET world for long enough, you’ve probably have come across with the term obfuscation at some point.

In a nutshell and paraphrasing Garry Trinder: “is the process of scrambling the symbols, code, and data of a program to prevent reverse engineering.”

As most of us are aware there are several tools available to decompile a .NET assembly and expose the code inside. nanoFramework assemblies, being .NET, are no exception.

Why is this a concern? Well, if you are a company and own IP that you don’t what to share publicly (for example a super-secret algorithm that took you years to fine tune) this could be of interest to you.

The main purpose of an obfuscator is precisely… obfuscating… the code so that it makes unreadable or at least very hard to understand. There are several techniques on how to accomplish this and some are more effective than others.
Just to name a few: symbols renaming, overloaded renaming, cross assembly renaming, inline value and array encryption, control flow obfuscation, resource encryption. But that’s enough as these details are beyond the subject of this blog post. Check the pictures bellow so you can have an idea on how this looks.

Before After
obfuscation_before obfuscation_after

We’ve worked together with the good folks of babelfor.NET to add support for nanoFramework on their .NET obfuscation product: Babel Obfuscator. Early this week v9.0 of this tool was released being the first (and only!) obfuscation tool supporting nanoFramework.

So, if you have a commercial interest in nanoFramework and sharing your IP was preventing you from moving forward, you don’t have an excuse any more!

Network capabilities in nanoFramework: check!!

Posted on by José Simões in AMQP, MQTT, networking, Nuget, SSL, TLS

As they say: better late than never! This post is a belated announcement of networking capabilities being added to nanoFramework. Some of you may already have noticed that during last week networking capabilities were officially added to our development branch.

With this, nanoFramework has – definitely – reached a major milestone. I’m sure we are all in agreement that providing network connectivity is a must have for any decent framework out there that aims to compete in the IoT space.

A lot has already been accomplished and know that we are just getting started! 🙂
Let me guide you on a tour of what’s available today.

Managed class libraries

The Nuget packages nanoFramework.System.Net, nanoFramework.Networking.Sntp and Windows.Devices.WiFi include already a ton of methods that allow developers to accomplish a lot. Without trying to be exhaustive, one can find there: interface management, DNS services, SNTP service, Sockets, Secure Sockets, Cryptography and Wi-Fi network management (this one for ESP32 targets only).

Security

This is probably one of the paramount features that are requested when embedded developers ask about networking. Yes, we’ve made it 😎 (and we are very proud of it)!
Support for SSL v3.0, TLS 1.0, 1.1 and 1.2 is available right now!

Supported targets

We provide ready to burn images including network support for the following reference targets: ST NUCLEO144 F746ZG, ST STM32F769I DISCOVERY and (of course!) ESP32 DevKit C.

Sample projects

Some work has been done here too. There are available samples showing how to connect to a SSL server; using a client certificate and validating the server certificate; resolve an address by querying a DNS service; adjust the RTC from an SNTP server; scan Wi-Fi networks in range and a couple of others.

Last but, by far, not the least we are working closely with the AMQPNetLite project to add support for nanoFramework and, very soon, an official Nuget package with this library will be published. Feel free to give it a try now, just go ahead and fork our fork.
A PR is also imminent to Paolo Patierno MQTT library. Same goes with this one: feel free to give it a try and do so by forking our fork.

 

How cool is all this? And we are just getting started!! HTTP client and server, web sockets and others are queued up to add more network capabilities to nanoFramework.

What are you waiting for? Go get all this, connect your device and start coding your next networked project! 😉

We are moving our chat to Discord

Posted on by José Simões in Uncategorized

After many discussions we’ve decided it is within the best interest of the project to move our chat platform from Slack to Discord.

Why are we doing this? Since initiating the project we’ve been using Slack, which has proved more than adequate for the task at hand. However, Slack uses a freemium model, which is fine but the free plan is limited to only the last 10k messages, 5 service integrations and an unmentioned limit on the number of users!

All these might not seem a big deal, especially for a small team or project, but they have started to affect us in a negative manner as our user base and message traffic has grown. For quite some time now we are losing critical knowledge every day that goes by as we have reached the 10k limit for a long time. Every time anyone sends a message (no matter how big or small) the 9.999th one gets lost in cyber space. At the time of writing there were 36k messages lost!

The search history is also limited by that number and it is not feasible to collect messages before they are lost and provide a search tool for such an archive.

Upgrading to a paid plan at a cost of 7.25 USD per user is simply not economically viable for this project, or for that matter, any Open Source project (but this is just my humble opinion).

Considering that we are keen to maintain a chat-like experience(*) for our community (which has proved a great option) we started looking at other similar platforms.

From all the alternatives that were considered (and presented to the community members for voicing their opinion) Discord seemed the best available alternative.

It’s free (really free it seems!); has no limits on users or message history; provides chat and voice messages; it’s hosted on secure servers; has a tremendous user base which proves their claims on responsiveness and robustness; allows integrations with our own bots and has a bunch of client apps for all the major platforms.

So here we go: farewell Slack, long live Discord! Join the community.

Important links:
– Client apps all the major platforms
– Windows 10 UWP apps (MobileDiscord and Quarrel seem to be the best ones)

(*) Being chat-like experience the opposed to a traditional forum-like experience that feels too static and slow to the modern standard.