This new beta release replaces Beta 2 and Beta 1. Besides a bug fix that affects Gadgeteer programs on Ethernet mainboards, it is a first in supporting Microsoft’s official [em]MFUpdate[/em] mechanism for firmware updates in the field - one of the gems hidden in NETMF until now!
[em]MFUpdate[/em] is a highly flexible and surprisingly light-weight framework for software updates in the field. It provides a simple API that gives you the tools to implement your own update strategy. For example, you could push a new firmware image over the Internet to a Mountaineer board using whatever protocol you like, use your own firmware encryption scheme if you like, etc. The update mechanism supports application updates, firmware updates, and combinations of both (important for example if you need to update some native code along with its C# interop code).
If you have already installed Beta 2, you only need to replace the [em]firmware[/em], using MFDeploy (replace the ER_FLASH.hex file containing the firmware image).
Our special thanks go to Mark Munte, whose investigations made it possible for us to successfully integrate Microsoft’s update mechanism into [em]NETMF for STM32[/em]. Thanks Mark!
Cuno
PS
There is one caveat: Microsoft’s code contains a bug that leads to an update failure after about two dozen updates. Please add your vote for fixing the bug here on Codeplex: https://netmf.codeplex.com/workitem/2236
When I asked, GHI said that the MFUpdate framework is way more complicated to implement/use then their own system.
I think that it also has something to do with binding customers to their product by making it more painful to switch to something else. And if someone uses all the nice features which are Premium lib only, then it’s really not that simple to switch to something else. That’s why I usually put an additional layer of abstraction around such features.
[quote=“Reinhard Ostermeier”]
MFUpdate framework is way more complicated to implement/use[/quote]
Yes and no. It was certainly not as well documented as we would have liked when we started looking at it, and not all elements have the same level of maturity. Thus our big kudos to Mark Munte, who did all the necessary research and paved the way. All in all, it turned out that MFUpdate is quite a small framework and gives a lot of flexibility.
I forgot to mention one thing: once we’ve reached the final release for the [em]Mountaineer[/em] firmware, we will publish the source code on our [em]NETMF for STM32[/em] Codeplex site, as we did with earlier releases of our port. This will include the MFUpdate stuff.
How could I use your firmware with Cerb40, for example? I’m interested in USB Host feature. Are there any how-to’s and code samples about porting the project from GHI’s firmware to Mountaineer’s?
@ toxsedyshev -
MFUpdate is so far only supported on Mountaineer firmware, so it’s not a matter of porting from GHI to Mountaineer, but the other way around.
USB Host has nothing to do with MFUpdate. There is limited USB Host support for STM32 in the non-open-source Mountaineer Prime firmware, but not in the standard firmware.
@ toxsedyshev -
Our firmware is strongly focused on the standard NETMF API, so we do not use GHI extensions in it.
Providing alternate firmware versions for GHI hardware would be possible, but it still would require work - in particular after the release, when all the tech support questions would inevitably land in our lap. It makes more sense for us to invest our highly limited time budget for NETMF in other areas.
Eventually we’ll publish our firmware as open source, so GHI can integrate it into their firmware if they like. As Mark Munte has published his contributions in the MFUpdate branch of NETMF for STM32 years ago, this has actually been possible for quite a while.
Very strange, when I try to use a class in the project with onewire, I have permanent errors. In mountaineer firmware implemented this only in 4.3, that thought. Please, help me find reference to the class or use example on 4.2.
P.S. Sorry for my bad language, I am from Ukraine )
In 4.2, GHI supports onewire for all products, include Cerberus which has STM32F4 same as STM32F4 Discovery board. (just discovery board may has more pins than Cerberus)
Show me your code and we can try to correct for you.
Cerberus 4.3 is not ready yet but it is on the way.