Exactly! You would be prompted to do the update as soon as it was available after you opened VS. Also, I think it’s very likely that the need to remove/add references on projects after an SDK upgrade would go away also due to the Nuget update process. I’m not an expert on Nuget internals… More importantly, though, if a bug was found and fixed in a driver it could be released the same or next day. GHI is promising longer release schedules which is quite opposite of the rest of the software world. That makes sense when it’s a PITA to uninstall/reinstall the SDK in it’s current form but with this model it would literally take one mouse click.
I’m new Gadgeteer, some of these may not be applicable…
[ol]Make the process of supporting newer versions of Visual Studio simpler. Microsoft is moving to annual release cycle for their products. By the time Gagdeteer 4.3 comes out, we will be closer to the release date of the next VS than the date for VS 2012.
A roadmap for which mainboards will get updated firmwares
Support multiple editions of the SDK on the same PC.
Use Nuget for module installation and updates. That would make it easy to update or use alternate module drivers.
Being able to turn off power to pins 1 and/or 2[/ol]
As much as the visual designer is a really cool thing, I would give it up in a second if that allowed for a faster release cycle. Or make it optional
Gadgeteer is only a wrapper around native and the designers are only there to automatically enumerate the hardware capabilities and, therefore, assist you in connecting the hardware correctly; if you don’t need their assistance, don’t use them. The designer is only generating the code to instantiate a mainboard object, which populates itself from a predefined list of Sockets with capabilities applicable to that model of board. Most Gadgeteer classes are inheritable, as well, so, if you don’t like how some part of it works, create your own that inherits from the Gadgeteer module and tweak it. Or download the source and completely rewrite the driver for your specific needs. So many options…
You may also manually instantiate any and all gadgeteer stuff directly from Main(). On non-gadgeteer mainboards, you can create a Gadgeteer Socket and route it directly to any GPIO pins you want, i.e. Daisylink using SoftwareI2C. I wanted to run DaisyLink using hardware I2C and reliably avoid fixed-address hardware I2C devices on my non-gadgeteer motherboard (Domino). Done, (pretty) easy.
You just need to be ready to deal with hardware at a lower level when you ditch the designers since it won’t know if you have overlapping pin functionality.
That is, essentially, the whole and only point of the designers/gadgeteer.
Are you wishing to power down a module? If so and Gadgeteer doesn’t expose that functionality, you may scan the datasheet for the chip for the register map. Most (all?) of them have a power state register that you can use to reboot and/or sleep the module.
This was for a custom bit of hardware that I put together. If that functionality is not available, I can add that myself and toggle it with a GPIO pin.