BitFlipper

Hi BitFlipper - thanks for replying, that's useful information anyway.

My issue sounds possibly related to yours. I've a sensor sending 43 bits of information, and the Netduino only picks up around 30-40 - I've found that it "loses" interrupts in the middle of the signal.

I'll keep looking for a solution

Thanks again,
Jeremy

Jeremy, it sounds like your issue is a bit different. In my case I simply needed to know about the last transition, whereas in your case, you need to know about every transition. I'm sure if the issue was fixed, it simply did something like check at the end of each notification that was sent whether the last value that was notified matched the actual pin state. If not it would send a new notification to get everything back in sync (and keep doing it until the actual pin state matches the last sent value). Such a fix won't handle your case properly where a series of fast intermediate transitions will still get lost.

Your results sounds reasonable and pretty much what I expected, just wanted to make sure we were talking about the same thing here.

Btw, what toolchain etc. did you use for native C programming on the Netduino? I've been meaning to do a little native stuff for some time now but never actually got around to do so.

Well, that whole project ended up going into a completely different direction. Now remember that most of this was done as a pet project just to see whether it could be done or not, so it might not make sense why I did it this way...

The first idea was to have a .Net decompiler that recompiles the .Net IL into C++. First it would do a static code path analysis so it only decompiles the code that is actually used by your application, then create the equivalent C++ headers and source files based on that IL. It includes a garbage collector and everything else you need that makes it "managed". The only thing it didn't do was reflection. This actually worked quite well and I was getting very encouraging performance results. But this was always on my desktop computer, not on a microcontroller. The idea was that once reliable C++ code could be created, that a standard ARM C++ compiler could then be used to compile that code to native ARM code.

But after looking into C++ ARM compilers, I realized that was a bad idea. Most were really expensive and the cheap/free ones were not worth the setup/maintenance headaches. I then started looking into compiling the .Net IL code into native ARM code. This project also progressed well and I ended up making a .Net decompiler, ARM compiler and ARM emulator. So basically I could take any .Net assembly (it didn't even needed to be a MF assembly, it could be the a full .Net assembly, as long as it didn't use things like WCF, WPF, etc), and this would then be decompiled to IL, re-compiled into ARM assembly and then executed by the ARM emulator. This also worked quite well but I got stuck on a particularly difficult to track down bug, and like most pet projects, before I could complete it, another shiny object attracted my attention. I still plan to get back to it at some point and turn it into something really useful.

What made this complex as well is that while it could cross-compile a lot of the full .Net classes into native ARM code, as soon as any of those methods make a native call, all bets are off. For instance, combining two strings in the .Net framework is not done in C# code by the String class, but it does a PInvoke to native code. So I had to add special checks for any IL code that makes native calls, and throw an error. Since many of these classes are critical to most applications, I had a system where there would be specially created substitution classes that do implement the full functionality in either C# or in "inline" ARM code. So if the decompiler came across a String.Concat(string, string) method, it would know to substitute it for the explicitly implemented one.

That was probably more info than you wanted to know, so to answer your actual question... I never ended up using any ARM C++ compilers.

EDIT: I just realized you were talking about the native vs C# performance results. Well, I never did that testing myself, but someone else posted performance results of toggling the pin with C/C++ code and then with C# code. So I base the "100 to 1000 times" values on results I have seen from other people's tests.

Hi BitFlipper

Could you confirm if the fix in .NET MF4.2 for issue 1073 (http://netmf.codeple...m/workitem/1073) actually solved the problem for you?

I'm coming across a similar InterruptPort issue myself and just wanted to check if your issue was resolved by the change.

Thanks!
Jeremy

Jeremy, to be honest, I don't believe I ever tried the version where this bug was marked as fixed. The polling loop ended up working well enough for my purposes so I never tried the later version.

Were these tests made on equivalent hardware and regardless of that, which hardware(s)?

I don't remember the details but yes, it was the same hardware. I think it was on a Netduino. IIRC the test was to see how fast a pin could be toggled in C vs C#.

In my own tests a while ago, I determined that the C# code runs roughly 100 to 1000 TIMES slower than the equivalent C++ code. The bottom line is that it is very slow but you get an excellent development environment and a managed language that makes coding up complex tasks much easier and faster, as long as you don't need super fast execution. Not sure whether that helps or not.