I’m pretty sure that everyone knows there is a pile of horsepower currently addressing some networking issues ( https://netmf.codeplex.com/SourceControl/list/changesets ) so I think we can safely assume networking is going to be great, but the question now is what should be next on the hit list? Maybe tightening up the deploy debug process as I think pretty much everyone has run into this issue occasionally, or are there bigger pain points or new features that make sense right now.
Yes, I am sure there is a list of bugs with beards on codeplex. Addressing these would be nice.
1 Like
@ DukeMission - Hmm, your short term memory seems to fail. Too many beers with the other MVPs. I guess the LOOOOOOOOOOOOOOOOOOONG thread running a few months back should adress that question. ( https://www.ghielectronics.com/community/forum/topic?id=15465&page=1 )
But I guess the bugs are priority #1 as Architect points out. 
Any that need to be squashed sooner then the others? Any that are holding up .NetMF based projects? I know for myself the networking thing has been like a giant billboard that I couldn’t see past, but its soon to be behind me, so I have to start thinking about what the next issues might be as its time to switch from being reactive to proactive, at least for myself.
@ Duke Nukem - I would start with getting the list of the reported bugs and sorting them out by the number of votes. If further prioritization is needed I will take into consideration some other factors. Like for example how many times the issue has been brought up on forum(s) or “frustration” level. Slow down in Release vs Debug is very annoying for example, but may be not as voted as some other issues.
Deploying speed and how quickly vs latches to the hardware is the most critical thing in my opinion and can only be fixed by Microsoft as this is part of the visual studio plug in.
When you are working in a commercial project, you are deploying hundreds of times daily, every second counts.
When networking is solid and I can deploy in two seconds, I am asking for a complete rework on graphics to make it simpler. We want netmf on a single chip, which we have already but graphics kills available resources.
As for the bugs, these will be resolved automatically once there are few people working on netmf, I am not worried.
1 Like
Looking at the task tracker everything is ranked as minor or lower is that really true?
@ Duke Nukem - I was more thinking about codeplex not task tracker here.
@ Gus - I don’t know how the NETMF team works internally, but dedicating a couple of hours a certain day(s) a week just for bug fixing would clear that list quickly.
The worst bug that is bugging me at the moment is the slow down due to Debug.Print() when USB is connected, but no debugger is attached:
https://www.ghielectronics.com/community/forum/topic?id=13412
Our system has an NETMF device and a Windows PC to which we can connect by remote.
We also can control LDR pins and reset by digital outputs from the PC.
If we could leave USB connected, we would have a good fallback plan for updates, including the boot loader.
But this bug does not allow us to have USB connected all the time.
In terms of optimization:
Any general performance enhancement would be appreciated.
Available memory was a limiting factor once, but at least for some devices this is not true anymore (G120, G400, …)
Features:
Using the network stack with multiple network connections in parallel would be great.
Also multiple IP addresses/subnets on one physical connection would be great.
And finally:
I personally do not care about the Gadgeteer SW framework. I use plain NETMF always, even for prototyping.
But I have to admit that the Gadgeteer plug and play hardware is really nice for prototyping.
Those issues are ours to fix.
@ Reinhard Ostermeier - about your note on gadgeteer. I think there should be a simpler gadgeteer that is built right into netmf, not a whole new framework. I was thinking of doing this myself but I rather see others interested and providing input.
@ Gus - I have built some kind of framework for our commercial projects, which allows me to initialize subsystems like networking, tracing, FTP, … with a single line each.
An application with networking, tracing, access basic features over Ethernet like reboot, time sync, reading device info and features, IFU is about 10 or 20 lines of code directly in the Main routine, and a couple of XML files on SD.
It’s not very streamlined, and has absolutely no documentation, but it works.
Unfortunately I can not share my whole core library, but parts of it can be found in code share.
In terms of gadgeteer: Personally I don’t need a visual designer. I’m more a code guy: a bit of C# and a lot of xml on SD card makes up my plumbing of all modules (or services) I have implemented. I even write all my XAML for WPF in code editor only. The designer is just a preview for me.
For future gadgeteer module drivers I would think that it is a good idea, if there is always a plain NETMF driver, which is wrapped then by the Gadgeteer interface.
By this the module drivers would be usable way better, whithout the need to rip the gadgeteer stuff out of them (every time an updated version of the driver is released).
If they are improving networking, that’s great.
Support Ping methods.
Support Windows Notification Services with a DLL
Support Azure Mobile Services with a DLL
I’d really like to see a way to just remotely update a single assembly. Given the limited flash constraints, it has always made more sense to me to be able to do that. Add Async method options for some methods (with events). Add timeouts as optional arguments where applicable.
Sometimes, when I have very little RAM, I really wish I could create a kind of read-only reference object that represents s portion of an already existing array.
Don’t bloat the framework to add anything. Make it so we can continue to pick and choose by adding assemblies as needed.
Contrary to popular belief, generics are not so necessary, IMHO, if it increases the RAM required.
A simple .NET Managed DLL to flash a device that would allow for easily developed applications to repair or update with a PC. Maybe this already exists, but the last time I tried, there were COM objects and I couldn’t make it work. Maybe I’m just asking for a wrapper on something that already exists…
Better debugging tools. I am certain there is a memory leak in the InterruptPort class. I had to build custom firmware just to enable the debugging for what’s in memory. I took me 2 months to trace it to that class. I don’t know what the circumstance were that made it misbehave, but I will never touch that class again.
Fix the Debug.Print so that it does not execute in Release mode. Also, make the namespaces more consistent with the regular .Net Framework. Maybe add System.Diagnostics.Debug class.
Give us methods to determine if the Internet is available, the same way it’s done on Windows PCs using http://www.msftncsi.com/ncsi.txt
Support DNS, mDNS, and LLMNR for local name resolution. I should be able to set the device name and any browser should be able to resolve the name of my device.
Also, I want a network attached device to be easily discoverable by a windows PC with an option to serve the PC a web page from the device AND/OR specify a Universal (an never expiring) Application Identifier. So on a PC, if a user does a device discovery in the charms or wherever, it pops up with the name and type of my device and prompt the user with opening the device page or installing the app.
Better watchdog support. Maybe even a low level software Watchdog implemented in .NET MF.
Better RTC support. The GHI RTC implementation is ok, but I know if the crystal does not stabilize, you never know.
Oh yeah, and exceptions SUCK. They are very uninformative! We need better+more informative exception messages and Exception types.
Intellisense sucks because the comments for the methods and parameters are just not there. Most of them can just be copied from the regular .NET Framework.
Settings! Support settings just like with regular .NET via the Project Properties tab and persist to the config sector. Note: this might require multiple sectors to do it, but it can and should be done.
Add TotalSeconds, TotalMinutes, TotalHours, etc, to the TimeSpan class.
Add the ability to save files as Content in the project and deploy to the device and be accessible from code at runtime.
When I drop an html file into the solution tree, I want to be able to edit and preview the page in a designer. I want to be able to develop my html side-by-side with my embedded web server and deploy the files right to the flash on the mcu.
A good device emulator would be nice, but that seems difficult to really make useful without a defined set of hardware like gadgeteer.
The BitConverter methods are not very good. For embedded systems, we need control over endianess and it’s incredibly useful to have an offset parameter (allowing me to pluck a single integer out of a byte array). See the Blitter methods here: http://cc3100.codeplex.com/SourceControl/latest#WifiCC3100/Extensions.cs
A firmware builder app would be nice. Maybe it just puts modules together to assemble the firmware. It has to be simple though.
A gzip class?
I am very tired and if any of the above doesn’t make sense… that is why.
-Valkyrie-MT
6 Likes
I have one more:
Generics.
But only if it does not bring any performance penalty.
Additionally I agree with most of the things @ Valkyrie-MT posted above.
I agree with @ Reinhard Ostermeier
Generics would be cool.
Everything sounds good.
Hope dies last.