Netduino competes with our cerbuino, which is our lowest end product. When comparing both, cerbuino has more software, like RLP to loaf naive code, support native graphics on N18 display and had gadgeteer sockets.
Thanks for these helpful and prompt replies gents, really helps. André - yes you’re correct I do of course mean .Net MF and I’m eager to get my hands on this soon.
What hardware do GHI offer for Bluetooth or NFC and what degree of support does .Net MF provide for these technologies?
Also what issues arise if I want use the latest release of .Net MF on these boards? Is it ‘just’ a matter of installing this into the board (presumably its held in Flash?) or are there other considerations?
I meant what kinds of issues arise if one tries to use a later version, what issues do GHI have to face when they consider upping their support? Regression testing no doubt, but are there technical limitations?
I’m not sure what you’re getting at. The person/team that does the building of a firmware is the one that has to tackle those challenges. This task is “porting” the netmf codebase to a specific hardware platform. Then, their additional software layer is added - and in GHI’s case, their significant Premium libraries (closed source) are compiled into the firmware.
The framework version that your C#/VB code targets must match the framework version source that is used to build the firmware. With a 4.2 firmware (as all GHI’s offerings are, and excluding the community built 4.3 firmware for Cerberus) you can only target 4.2 framework in your app.
So if you wanted to use the latest framework, you would have to port the netmf core over to the device, work typically done by someone else; the only exception is the 4.3 community build of the Cerberus family firmware which you can use.
And just a further reminder, if you’re using Visual Studio 2012, you install the netmf4.3 SDK which is backward compatible with all the 4.x family frameworks. You then create your project and make sure it targets the correct framework version (for a current GHI board, 4.2).
Thanks this is helpful. I was unclear on why GHI don’t (apparently) provide systems that work with .Net MF 4.3 - I think I understand that now.
I wasn’t aware that “Porting” was something a customer might tackle (I assumed GHI did that as they see fit for their own product needs) but it seems from what you say that we (anyone) could take the core software (CLR or whatever) and build test that to work against .Net MF 4.3 and then use that compiled runtime as the firmware on the mainboard.
Clearly GHI have already done a port for 4.1 and 4.2, so is a port to 4.3 something they plan to do eventually?
GHI will support 4.3, but not at a schedule that you can control or influence (and I don’t think they have talked publically about what that timeframe might be). There are still some outstanding known issues on the 4.2 builds so they are working on that before 4.3.
The netmf core software is open so anyone can take the porting kit and develop a port for a particular microcontroller. In the past that has been the remit of larger teams of people but there are more and more community-driven contributions - in particular the STM32F1 and F4 ports that Oberon/GHI have collectively worked on and opened to the public are great starting points on a family of processor that is expanding and very friendly for more enthusiast level work