Since the announced partnership between Mountaineer group and GHI electronics, we’ve been working hard to bring the new Mountaineer boards to our catalog and distribution channels. Both USB and the Ethernet versions, are now on our catalog.
What make these board special is their small size and on-board voltage regulators. Similar to FEZ Cerbuino Bee, these mainboards are ready to run using a USB cable. The Ethernet version is the first .NET Gadgeteer compatible mainboard to include a built-in Ethernet. The “Internet of Things” was never easier. Add one or more modules and you have a low-cost solution at a very affordable price.
That is a good question. While we work on the core firmware with the Mountaineer group, I am not sure if they will take our libraries and add to their firmware, like SD support and RLPLite. The good news is that we have agreed on using the same crystal so you can run the Cerb-family firmware on the mountaineer board if you like.
Note we just started shipping these so I am sure there will be more info from mountaineer group.
Simply answer, do not do it! More detailed answer, this will cause a reverse voltage to the regulators. Some regulators are okay with this but some get damaged. It is a bad practice anyway unless we get a confirmation from Oberon that this is safe.
If the USB cable is [em]not[/em] connected, then it is safe to supply the system with 5 Volt through any socket, i.e., any add-on module.
There’s a caveat, however. [em]Only[/em] 5 Volt may be supplied. The mainboard then generates the necessary 3.3 Volt out of the 5 Volt supply as well.
This means that you should not attach a normal red Gadgeteer module, as it provides both 5 and 3.3 Volt, which would mean that two 3.3 Volt voltage regulators work in parallel. This could lead to stability problems.
Our first and foremost goal at this time is still to create a highly robust, open, and “industrial strength” hardware/software base platform that stays as close as possible to the Microsoft standard for .NET and NETMF. As the saying goes: “soon ripe, soon rotten”. To make the platform as bomb-proof as possible just takes a lot of (very unspectacular and barely visible) work. As our manpower resources are constrained, we will therefore usually lean towards “less is more”. In practice, this means a subset of the standard NETMF feature set, suitable for headless Internet gateways.
Steve Jobs often said that even Apple, now the world’s most valuable company, can only do a few things at a time really well. This is true even today, and so much more so for a smaller company.
Yet sometimes a customer “forces” us to go even beyond the existing NETMF feature set, by paying money This happened recently when a long-time customer needed analog output, which is not a standard feature of NETMF. So we submitted an API proposal to the .NET Micro Framework Core Tech Team for review. As a result, starting with NETMF 4.2 QFE2, analog output will be a standard feature of NETMF and we are again happily within the standard feature set.
I am glad, however, that it should also be possible to use GHI’s more extensive libraries on our hardware. Together with the community contributions it can add a lot of value to a project for which additional capabilities are needed, e.g., RLPLite.
PS
To make this possible was one of the main reasons for open-sourcing our [em]NETMF for STM32[/em] port at all. Another one was of course: more eyeballs can help finding defects earlier.
Neither Normal train from Zurich to Chur, from there with the Glacier Express to Brig, from there back again to Zurich with a normal train. Unfortunately we didn’t have time enough to go all the way to Matterhorn
