I’m a little confused about the current status of .Net Micro and Visual Studio. I’m currently running GHI SDK Version 2013 R3 (v1.0.6) and VS2012 Express. My fundamental question is
Is any of the new functionality in either the .Net MF or GHI releases worth the risk and hassle of upgrading my systems?
Additional questions include
Does VS2013 Community Edition provide any significant advantages for a plain vanilla .Net MF developer? I’m particularly interested in whether the code profiling and/or itnegrated test functionality will work with .Net MF.
Should I bite the bullet and keep up to date with the latest (or at least the next to latest) .Net MF and GHI releases as a matter of good practice?
[quote]3) Definitely not if using G400! EMX and G120 - maybe; I use them only occasionally, but the impression was they work quite ok when switching SDK.
[/quote]
@ Simon - I use the G400 Raptor almost exclusively. Are you saying I should NOT upgrade from GHI SDK Version 2013 R3 (v1.0.6) implying the newer releases have gotten more buggy?
If so, I honestly have no idea how you survive. 2013 R3 was a very early stuff, G400D was barely working for me back then. Your application must be very, very different than mine. Maybe for you it’s fine.
No, each release was generally better and better. I personally settled down with 2014 R4, as I was unable to keep up with GHI frequent changes to Loader. IFU using a different SDK is still a no-go for G400
@ Simon from Vilnius - why IFU is not an option? Updating the loader is not required, especially if your product uses ifu, meaning you do not use the loader.
Either way, this was a year ago before the sdk became very stable. We recommend the coming 2015 release to you and everyone else. Which is stable like the current 2014 release but with some final tweaks.
@ Simon from Vilnius - no need to update. It will be okay. The need for update could have been the case a year ago if your loader was 4.2 or something major changed. For example, the last change on the loader done months ago was an improvement on usb. This update is completely optional.
Note how everything of a concern is from very long time ago, nothing recent.
If you have a specific version in mind then we can help you determine if an update is necessary or what impact it may have.
@ Gus - Ok, maybe there’s some wrong terms used? I was having TinyBooter in mind. And, running older TinyBooter with newer firmware results in weird problems, like for example, G400 locks up the moment Visual Studio tries attaching the debugger (I’ve reported that but got no attention, as the general recommendation is such cases is “update TinyBooter jeesuschrist”). Not sure now, whether it was R4 Tinybooter with R5 firmware, or R3 tinybooter with R4 firmware, but that doesn’t matter much; I cannot update TinyBooter without disassembling the laser --> I’m stuck with R4.
Maybe I’ll give a try with your 2015 R1 when it is out… Not much to wait.
Correction: I’m sorry but I made a cut/paste mistake. The header at the top of the release notes in C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Libraries\GHI.Hardware.dll is as follows.
Just to make sure I’ve got this right, when I click on the GHI.Hardware reference (for example) in a VS project i get the following info in the Properties window.
@ Gus - I have also such a feeling that there might be some connection/coupling between TinyBooter(in this thread called probably the loader) and firmware(TinyCLR) mentioned e.g. in this thread: https://www.ghielectronics.com/community/forum/topic?id=17975
where John said:
@ mhstr - There are no hard rules for different versions of TinyBooter and TinyCLR. There are times when a change to TinyBooter requires that you update, sometimes not. For 4.3.5, there was a bug that with the serial interface on the G400 that was fixed in 4.3.6, that you saw.
We are working on removing the need of the samba program to update TinyBooter on G400, but we cannot promise anything yet.
As for your original issue, deploys failing in TinyCLR mode are something we are looking into but don’t have a fix for yet.
So could you please confirm(clarify) that if IFU is used for updating firmware(TinyCLR) and application then it is OK not to update also loader(TinyBooter) what is of course not possible by IFU? To simplify it let assume that the Raptor is placed and runs at the customer side without necessity to debug - connect to VS but the customer needs to update the firmware(TuntCLR) and new application by IFU(e.g. through Ethernet).
@ mhstr - here is a simple answer. Always use the latest loader, if there is any. Should you have a product in field and updating the loader is not an option then what loader version are you using? And what symptom are you experiencing?
@ Gus - right now we are finishing our commercial product and we are using last version of loader - 4.3.6.0 (and also some your experimental).
This part of project - IFU - is not finished yet so there is no negative experience but I am just asking because especially the possible combination of loader/firmware versions is not so clear to me and I am assuming also to others.
We have to assume that our customers are normally not aware about things like that so for them is not acceptable to disassemble the final product and activate SAMBA, deploy new loader, firmware, application…
They are able to upload new firmware through e.g. Ethernet(device web pages or by FTP client) and this is the role of IFU so IFU should work without necessity to change the loader and according your answer it is OK change the firmware and application through IFU(without necessity to change loader in most cases) so I am happy about that!
@ mhstr - Once you ship your product, you should freeze the version of the MF SDK that you use. You can ship updates of your program, using IFU, and/or upgrade the firmware within the same MF version (dot release). If you freeze the MF version, you should never have to change the bootloader.
That is true but normally new SDK(new firmware) removes some bugs so one would like to update devices in field to correct e.g. some unexpected behaviour because of some bugs etc.
