Can’t find method GHI.Premium.Hardware.Configuration.DebugInterface.GetCurrent() in 4.2, any idea?
It was removed in 4.2
Thanks… we did not like it anyway
How to get this information in 4.2.
MassStorage etc. will still crash if we do not check the current DebugInterface!
The problem is that it has to be hardwired and for custom pcb we can’t reaffect IO for each release of the SDK. Therefore switching to 4…2 is in some cases not possible…
So, if one is working with USB Devices:
Use COM1 as debug interface.
And attach USB VBUS to an IO pin… for USB detection.
And forget what is done until 4.1.
Are you kidding !!! I recognize the huge work of GHI and netmf team on codeplex. However being in a small company where I am the only HW designer and SW developper at the same time, the delay between idea and final product can take a year and the bad news is that switching to the up to date SDK involves features that disappear, hardware that needs to be reroute. This can not be done for all small companies that are especially the target of GHI. We need stablility and upgrades that enhance behavior of our platform…
@ nsb all the 4 com port and ethernet are already used in my application debugging with one would involve to remove one peripheral which is not possible.
why is the topic for this thread “…”?
It’s not a bug. Text is all one word and too long to fit. CSS is trimming it to be …
I understand why it is happening and it doesn’t really bother me, but GHI.Premium.Hardware.Configuration… would be a more user friendly trimming then just …
Then don’t upgrade to 4.2? Continue to use 4.1 instead. NETMF is actually relatively stable compared to most RTOSs I’ve worked with.
People want to think of NETMF like a desktop operating system – where you always upgrade to the new version (new is always better, right?) and everything still works. That’s not true here, though. Features come and features go. Welcome to embedded software development. This is the nature of the beast.
If something gets removed, it usually means it was poorly designed in the first place so it was hard to maintain, or it didn’t work well.
Correct ans very true. Upgrading from one SDK to another within “NETMF 4.1” would mean you will have the same set of features, maybe few more, but when there is a major update, like from 4.1 to 4.2 things can drastically change. Like OutputCompare was renames with SignalGenerator, TCP/IP stack was completely changed (thousands and thousands of new lines of code), TCP debugging was removed, custom heap is fixed, IFU was completely redone…and more.