In a coming release we would like to make some improvements in our NETMF SDK. We would like your feedback on things that you feel are broken, could otherwise be improved, or should be added to our SDK, particularly the libraries. Keep in mind that we cannot promise that all or any of the suggestions made here will make it in to the SDK. Thank you.
make it Write once and deploy everywhere… give us a clean API that I write once and deploy to any device Premium or not…
one library for all device and try to control the premium features in your firmware instead of the having multiple libraries… and different APIs 
Start with Networking… do the assign Network calls in the backend for example when it comes to Premium… I mean how many people have actually created an Application that used more than one Network module… hell I can’t even get one stable enough to actually want to use more…don’t get me wrong it’s a great feature but it does limit code portability and frankly adds more complexity than it’s worth. because just to start a network application I have to read the docs over and over and that is not a way to develop if one would have to reply on the docs all times. just a thought…
2 Likes
@ John - Non-volatile setting storage on the CPU. Use one or two of the 16k sectors on the STM32F4 and integrate into the Visual Studio Project Settings page. I am doing this now (without the VS integration) and it is working great.
Integrated support for Battery backed SRAM in the STM32F4
Support for Time zones and better integration of the RTC. So if the RTC is set, the device should just boot up with time and time zone already set. And, the TimeZone support does not have to implement the official TimeZone class. It could just be a variable for the timezone offset that is stored in the battery-backed RTC memory and an enumeration or something. And the value is applied when you retrieve the local time. Also, Daylight savings time. Again, keep it simple and have an enable/disable and variables for the 2 days when the time goes forward and back.
Integrated Watchdog support for Cerb. That might just be integrating one of the examples from codeshare.
I have all of the above items in my code base, but it would make things easier for new people if they were simpler/integrated.
Use NuGet to distribute module drivers. That’s been a consistently popular proposal since Ian suggested it. Allows you to update drivers without having to package, release, and install an SDK.
1 Like
Low Power Modes and proper hibernate please. This should take uAmps.
I need that too.
We need to maintain multiple FW versions in parallel.
Installing only one version does not work for us.
Currently we have 2 FW versions in the field. For minor fixes we do not want to update the FW on them.
For new things we would use the 2014 R1, but we currently avoiding it because that would add a 3rd used FW.
In my case I need that only for plain NETMF, not Gadgeteer.
If you could provide a NuGet Package for each FW, hex files for each FW and a standalone downloadable installer for FEZConfig then I’m happy.
No need to install the SDK anymore.
Just installing MS NETMF SDK and FEZConfig.
Then add GHI dll’s by NuGet, switch versions with NuGet, … ;D
And no, I don’t want to maintain extra computers or VM’s for each FW.
I would need to have these VM’s on everyone’s laptop, so they could use it at customer places if needed. :snooty:
That could get a bit tricky, since for G120 you could use ENC28 or WiFi or none (Like Cobra II does).
How should the firmware know which networking module is connected :think:
They should fix that, they were going to at one time have only ONE fw instead of two, Ethernet and non Ethernet, not sure why they haven’t fix it yet, the current solution was supposed to be temporarily.
@ Jay Jay - You talking about Cerb, … FW right?
For premium devices there is only one FW.
You then init your network device at beginning of main, then it’s all the same.
the network initialization code of the premium board is not the same as cerb family and mountaineer… and it shouldn’t be that way… I have all those boards and it’s a pain to do when you switch around boards, and yes I do like o test my code on different boards, and NETMF is all about porting the same code to any board made by any manufacturer, without any changes… and they’ve broken that with their own boards.
so my suggestion is to think simple, make the code as generic as possible… and push all that is complex to the back, for example the network assign shouldn’t be in the front at all it should all be handled in the back, it should be handle the same exact way we handle multiple LED modules for example. you have multiple LED you get multiple objects, simple… the network should work the same way, multiple network module should give multiple object and any switching should be handle behind the scene.
I hope this makes sense…