GHI Electronics NETMF SDK 2015 R1 Pre-Release 4

Press Announcements
1

Today we are excited to announce the final pre-release for our NETMF SDK. We made improvements to the G400 firmware including improving networking speed and serial handshaking reliability. We also included the 4.1 installer, however neither the 4.1 or the 4.2 SDKs will be installed by default anymore. Minor improvements were made to Gadgeteer and PPP. Also included in today’s release is a fix to EMX, where the EMX may lockup when exposed to extreme heat.

We highly recommend that you try this SDK release as this may be the last pre-release depending on any major issues that may be found. Any feedback is very much appreciated as we are getting close to the final 2015 NETMF release and we want to make sure it is as stable and bug free as possible.

SDK: https://www.ghielectronics.com/support/netmf/sdk/37/ghi-electronics-netmf-sdk-2015-r1-pre-release-4

7 Likes
2

So, you want bugs? :slight_smile: Here is one. [em]ReservePin[/em] method is not working for Cobra II. It could be that it is not working for other boards as well, I have not tested them all.

Sub Main()
	Thread.Sleep(4000)

	Dim pinTest = GHI.Pins.FEZCobraII.Socket4.Pin7
	'Dim pinTest = GHI.Pins.FEZRaptor.Socket1.Pin6
	Port.ReservePin(pinTest, True)
	Dim pinOut As New OutputPort(pinTest, False)        ' Cobra II: no exception; Raptor: exception
	Debug.Print(pinOut.Read.ToString())
End Sub
3

It throws a System.Exception on the Raptor using the latest SDK 2015_R4 for me. I have not tested other boards either.

4

@ scardinale - Yes, it does do that for Raptor, but does not do that for Cobra II.

5

I’m glad you fixed the high temperature lockup.
I’ve been running my boards up to 60C on a test bed and eliminating any that fail.

I’ve just run a test and it appears the problem with IO17 PWM failing to resume after a hibernate is still there.
[url]https://www.ghielectronics.com/community/forum/topic?id=19614&page=7#msg194716[/url]
so working 4.2 code can’t be safely ported to 4.3 yet.
Any ideas what is behind this, and if it is likely to impact other IO lines?

6

Release notes does not indicate that low CPU performance of G80 was addressed. Any updates on this issue?

7

This is a major update internally and will be resolved on the next major release. This only effects floating point math but otherwise performance is where it should be, right?

8

@ C-Born - we were able to reproduce it, but unfortunately the fix will not make it into this SDK.

@ iamin - we’ll be taking a look at ReservePin on Monday.

9

@ C-Born - maybe we can work together on a work around using register class to touch the internals manually. You really need to switch to 4.3

10

@ Gus - Do you know the cause of this problem?
If it is something known and specific to this IO, then adding workaround code to release and reopen the IO on coming out of hibernate would be a simple matter until a fix is in.
On the other hand if the cause is unknown then it may be a buffer overflow, memory allocation error, etc which could cause problems with other IO lines or manifest itself in other ways depending on the build, run-time events, available memory, etc.

11

And the next major release will be available after 1 year? If so, I am not sure if it is good or bad news.

The Pi test has also produced some strange results when Panda III and G80 Dev boards were compared. Yes, I know that they both use the same SoC, but somehow time difference was about 30%.

12

@ iamin - quality comes first, sorry we are going to have to wait.

13

@ C-Born - I am not familiar myself. You can work worth John directly or give me an example code and I will give you a work around.

14

@ Gus - The example code is here, and John has reproduced it: [url]https://www.ghielectronics.com/community/forum/topic?id=19614&page=7#msg194716[/url]

The problem isn’t with a workaround for this specific instance, which is pretty simple, just release and recreate the port after return from hibernate to get it going again.
The real issue is that such a regression against what was working in 4.2 may be indicative of a host of possible problems that may come up on other IO, at other times, or in other circumstances. Unless the root cause can be pinned down to something very specific which only effects this IO at this time then the whole build must be suspect.

15

@ C-Born - I will get with John and discuss.

16

I find it very annoying that it takes 60 seconds for G80 board to signal VS that the code has fully executed.

To replicate:

  1. Create a new Micro Framework Console Application project.
  2. Paste this simple code:
Sub Main()
	Debug.Print("Done!")
End Sub
  1. Deploy.
  2. Observe how it takes 60 seconds until you can deploy again (you cannot modify your code in the meantime as well).

If you do the same with G120, you will not need to wait for 60 seconds. Has someone left an unnecessary 60 second delay in the code? :slight_smile:

17

I have never seen this before but, according to an internal discussion with Microsoft, the next VS plug in improves speed drastically.

Meanwhile, we will see if we can do something about it.

18

@ Gus - I have not seen this behavior with any other board except G80, so I tend to believe it is not MS fault.

19

@ iamin - I think I wasn’t clear. Thanks for the feedback, we will look into it.

1 Like
20

@ iamin - I was able to reproduce your ReservePin behavior going back to at least the latest 4.2 firmware. Since it’s been around for a while, it’ll be fixed for the 2016 SDK.

I was also able to reproduce the 60 second delay on the G30, G80, and Cerberus on 4.3 and 4.2 (for the Cerberus). Since you can manually stop debugging and it isn’t a new issue, this will be fixed for the 2016 SDK as well.

At this point in the SDK release, we will only fix critical issues like SPI not working at all on a board.