We are wrapping up 4.2 and moving to 4.3 in future.
Do you have some wishes for gadgeteer? On GHI’s end? On microsoft’s end?
No BSODs under any condition!
Oh, and of course VS2012…
SignalGenerator as a core NETMF function would be really nice.
4 Likes
Stop using 4 bytes for BMP data that doesn’t support alpha or start using alpha 
Direct mod access to BMP pixels in byte array
I’ll think of some GHI stuff too 
4 Likes
Fix the goofy SerialPort issue of having to open the port before subscribing to events.
2 Likes
Full support for VS2010 at least to the end of the year, or better mid of 2014.
Can’t switch to VS2012 now because of the need to support .NET4.0 with WPF on Win XP and we don’t want to do double testing.
3 Likes
Continued support for VS2010
Support for 16 bit bitmaps would also be nice, this is because alot of screens us 16 bit color. The ability to load and transfer these directly without having to convert them would save valuable processing time :o)
Paul
2 Likes
Guys, the question is for gadgeteer not netmf
-
Better alignment with NETMF, e.g., add no new features that require non-standard extensions to NETMF.
-
Every module works with every mainboard (sockets and RAM-size permitting), no mainboard-dependent drivers.
-
More efficient handling of bitmaps, so that it’s more practical to use a small display with a Cerberus, Cerbuino Bee, or Mountaineer mainboard.
Unfortunately, even some of these wishes would have an impact on NETMF itself, not just on the Gadgeteer libraries.
Cuno
2 Likes
As Andre.M said
network connections simultaneously would be GREAT!
Automatic calibration of GHI sold displays (startup/on user request)
As Bodwad said
Continued support for VS2010
Graceful exit (NO BSOD or Sudden/Unexpected restart of PC) Auto disconnect of USB without crash ?
@ GUS,
Some things :
-
YES for the network connections, and also 2 wired at the same time would be GREAT ! (low level based),
-
a G120 Mainboard for Gadgeteer ! And then Add the touch over the HDR R/G/B,
-
Comply Serialization between NETMF and normal Framework,
-
Debug MFSVCUTIL.exe,
-
XAML Support for interfaces (not only Glide).
1 Like
+1 for 1. and 5.
About: 2.: I think it’s not too far away. Gus show some something shortly
@ Reinhard Ostermeier - Heard about it
Gus, how about my issue that I reported on codeplex about too many references included in the Gadgeteer template?
Like the Touch reference that should actually be included in a touch capable display. Things like that?
This will help the Cerberus free up some ram…
A lot of what has come up is definitely netmf not Gadgeteer specific, so it’s the wrong wishlist to post those into. I like GMod’s diet suggestion, there’s great momentum in the STM32F4 space and to maximise that we need to be frugal with resources and trim out those that are not needed because of the modules connected etc.
Is it really possible to separate the two? 
Wasn’t there a problem with not being able to release modules in Gadgeteer? That sounds like an important one.
I know it would require some pins but it would be really cool to be able to totally power off a module via the mainboard software. That would open up some interesting possibilities and would be good for power hungry projects. Imagine if you could store up data all day and then power up the ENC28 module once a day to upload the data to a server then power it back down.
Nothing prevents module designers to do that now. But the lost pin and/or the extra cost makes it prohibitive…
I was thinking more in terms of a Gadgeteer standard way of doing it. In reality, I’m reaching at straws. I don’t really have any Gadgeteer specific complaints. Just trying to think where it could go in a next major version.
So here is our list! There are couple more but those were sent directly to Microsoft for initial discussion and will add to codeplex when appropriate
http://gadgeteer.codeplex.com/workitem/1453
http://gadgeteer.codeplex.com/workitem/1454
http://gadgeteer.codeplex.com/workitem/1455
http://gadgeteer.codeplex.com/workitem/1456
http://gadgeteer.codeplex.com/workitem/1457
http://gadgeteer.codeplex.com/workitem/1458
http://gadgeteer.codeplex.com/workitem/1459
Gus, all those look good.
A big issue for me, but apparently very few others, is how the SPI initialiser works in Gadgeteer.
The Gadgeteer spec defines a CS pin. If you don’t specify a CS pin for the SPI initialiser then the CS pin should be assigned, instead no pin is assigned. This has caused me and a few others a lot of headaches that was only solved after digging in the Gadgeteer core source code, which should not be required…
And how can this be improved?