Hi,
As i wait for my gadgeteer devices to arrive…i wanted to ask about the required software
What exactly does “GHI NETMF v4.2 and .NET Gadgeteer Package Sep. 14, 2012” download from here: http://www.ghielectronics.com/support/dotnet-micro-framework
include?
I’ve already installed MF4.2 and i’ve downloaded and installed the .NET Gadeteer Core from here: http://gadgeteer.codeplex.com/releases. What else is required besides these?
Does each board require additional installs?
Follow the install steps (in order) from the Support page. I’d recommend uninstalling anything you’ve already installed if you have not followed this order to ensure you have no problems.
http://www.ghielectronics.com/support/dotnet-micro-framework
Im actually reading that page…but a bit confused as to why there appears to be GHI specific version of .NET MF if this is all suppose to be open source? sounds somewhat proprietary if each device can only work with the manufacturer’s software or drivers…no?
i would think all you would need is the gadgeteer core and .net mf. that doesn’t seem to be the case and i guess i want to understand what does the “GHI” specific software do or support?
[quote=“ISuck@ Starcraft2”]
Im actually reading that page…but a bit confused as to why there appears to be GHI specific version of .NET MF if this is all suppose to be open source? sounds somewhat proprietary if each device can only work with the manufacturer’s software or drivers…no?[/quote]
No. Each board has chip specific firmware that has to be developed. GHI does all of this and combines all the code you will need to make their boards work with NETMF into one package for your convenience and to ensure everything works from day one in most cases.
You may want to read up on the NETMF Porting Kit to understand better what all is involved in making NETMF & Gadgeteer work on a specific MCU.
my confusion comes from this i guess…
with arduino, with any arduino compliant hardware, i can develop against these using the same core software.
i would think the same would be true with gadgeteer…my initial thought, after seeing the GHI specific software requirements was that the ghi libraries only make it simpler to work with their hardware, but that you could still achieve the same result with the .net gadgeteer libraries (just more work).
So is ghi software the firmware for the chipset only or is it actually a functional layer(i.e. api) on top of .net gadgeteer that is REQUIRED to work with the hardware they build?
If its for the chipset, i get that…if the latter however, i sort of feel that takes it way from the “open source” aspect of the platform.
with any hardware built on top of the open source framework, i should be able to purchase from any manufacturer and prgram it using either .net mf and/or .net gadgeteer (its the choice of the manufacturer if they want to provide their own api which makes it easier or quicker to build apps, but it shouldn’t be a requirement).
Arduino is not like netmf, lets get that out of you as quickly as we can 
Arduino, really, is a single atmel chip type. They all basically have the same features, the same instruction set, and the same software is easy to run on the slight different variations.
Netmf is so flexible that there are huge variations of chip used, hugely different memory footprints, hugely different attached # of peripherals (CAN, UART, SPI, I2C etc), and this means that each company/individual who builds a firmware based on NETMF for a chip or a board will largely be different to others. The one example where we’re starting to see convergence of ports is the STM32F4 port that is now in use on several different boards.
Think of it this way.
For a hardware platform, you have a bootloader layer (specific for the board) and you then have a firmware, also specific to the chip/board. The firmware contains the features of netmf that “fit” on the device, and it also will contain any additional features that the port provides, for example the GHI “Premium” ports have many additional features that their firmware will provide.
Then on your PC, you need an IDE (Visual Studio), you need the core netmf SDK components, then the specific hardware support SDK from the vendor of your board (multiple board vendors may mean multiple SDK layers), and then potentially you might need a separate driver pack for devices you have.
And the final thing is that the SDK version you have must match on your PC and your device, which is why you’ll always hear people ask to confirm what firmware version is on your device and what SDK you have installed.
Hmmm…not sure how I feel about this…yet.
hopefully this doesn’t mean there will be issues with modules from diff manufacturers communicating w/ each other…as the platform and itas adopters grow.
it feels like the platform should define chipsets choices and provide the necessary software in the gadgeteer layer to work with them.
while it may sound limiting…its not if u have a fairly active committee…and does solve the issue of needing all these additional layers from manufacturers…
Truly removing and decoupling ur software from the board.
You only have to visit the “manufacture” public forum or ask around here. Do not worry, companies that do not do their job right will be knows as the community is open and always share feedback. This helps you make better decisions and help manufactures like us in making better products and in improving existing products.
I like to add that NETMF and gadgeteer is used commercially a lot more than arduino or any other similar developer-friendly platform.
Note also that the differences in firmwares should not impact capabilities at the module level. The NETMF/Gadgeteer layer is mostly the same on all devices and as long as the mainboard has the needed socket type for the module then the module and code you write for it are the same regardless of the mainboard/chipset. If there is something unique about a module that causes it to only work with certain mainboards then this should be noted in the module description.
The netmf platform offers up the ability to connect to pretty much any sensor/device. You don’t need to be concerned about that.
The platform defining chipsets is counter-intuitive. That’s restricting opportunities to grow and develop. The core netmf is the same on any hadrware platform, which means you get code portability. Where you will have less than portable code is where you use a specific vendor’s “additions” or where a particular chip doesn’t have a specific feature that you rely on - say for instance CAN bus was important to you but a chip from someone didn’t support a CAN bus, that platform isn’t the right choice for you. Here’s another example, you need a datalogger, you can choose a device that offers a lot of on-board memory so you don’t need to do that heavy lifting yourself and you don’t need to worry about adding support for an external memory chip yourself, the hardware integration the vendor has done allows you to simply use the core netmf memory allocation processes against that larger memory (look at the Fez Hydra for example).
In this way, the ecosystem can continue to flourish and companies like GHI have an opportunity to contribute to their commercial customers as they see fit and also the wider netmf codebase. Remember that the netmf is only “recently” moved to a community model, and the community of core contributors is small, whereas the community of users is much larger (as you’ll see here).
Good stuff…thanks for the clarifications all!