OK. I’ll reflash. But I’m wondering how the firmware version on the board could cause the error I’m seeing in Visual Studio. VS doesn’t really know anything about the firmware, at least not until deployment time. So that shouldn’t impact whether or not I can add a reference to a DLL in the project.
I have never seen the error you are getting, you are correct, when ever there is a version mismatch the deployment fails. Are you using the latest 4.2 SDK?
@ taylorza - Reflashed, but no change to the error message.
As far as the version of 4.2 I’m running, I updated my desktop dev box with the bits from http://www.ghielectronics.com/support/dotnet-micro-framework on Dec. 19th.
Is it possible there’s some other bits you have installed that I don’t that make it work for you?
Hopefully either Ian or Architect will get a chance to try it so we can see if the problem is isolated to my machine…
@ taylorza - No, it’s a Gadgeteer project. Not targeting the emulator.
Would it be possible for you to zip your project and make it available for me? I would like to see if I get the same issue, I tried all kinds of things to repo the issue. Targeted 4.1, targeted the emulator etc. all failed, but not with the same issue that you have.
Let me try a Gadgeteer app, I have been testing with a normal .NETMF app.
@ taylorza - FYI, just tried a NETMF app. Same error when trying to add the DLL.
I’ve zipped the Gadgeteer project up, and it’s at:
@ devhammer - Thank you.
Is it the IRCommander_Hydra.zip? If so, I got the project, added the reference to dotnetwarrior.OSHW.Hardware and replaced the OutputCompare class with the SignalGenerator class. I assume that this is just a lift and shift from an older project which used the older SDK GHIElectronics.NETMF.Hardware.OutputCompare since the project itself is a 4.2 project.
Unfortunately, the project deployed successfully to my Hydra.
I am having some issue with this as well:
Here is my code (using Gadgeteer project):
Socket socket = Socket.GetSocket(4, false, null, "Y");
sg = new SignalGenerator(socket.CpuPins[3], false, 10);
sg.Set(true);
Getting an exception during SignalGenerator constructor:
Using mainboard GHI Electronics FEZHydra version 1.2
#### Exception System.NotSupportedException - CLR_E_NOT_SUPPORTED (1) ####
#### Message:
#### dotnetwarrior.OSHW.Hardware.SignalGenerator::.ctor [IP: 000d] ####
#### GadgeteerApp1.Program::ProgramStarted [IP: 0018] ####
A first chance exception of type 'System.NotSupportedException' occurred in dotnetwarrior.OSHW.Hardware.dll
An unhandled exception of type 'System.NotSupportedException' occurred in dotnetwarrior.OSHW.Hardware.dll
@ taylorza - Yes. The IRLEDArray.cs class is the basis from which I’ll be developing the updated driver, and it’s pulled directly from a Gadgeteer 4.1 version of my IR helicopter commander project.
Might there be something that you installed in order to create the firmware that’s needed to allow the managed DLL to be referenced? Kind of grasping at straws, as I’m not sure how to troubleshoot this on my end, given that it works on yours.
@ Architect - But it looks like you were able to reference the managed DLL without the error I’m seeing, correct?
Yes, I have no problem referencing the assembly.
@ Architect - Well I am glad you can at least reference the assembly. I have been trying all kinds of things here to repo the issue @ devhammer is facing.
With regard to your issue, after updating the firmware, did you reset the board? I am sure you did, but this is the only scenario that I have experienced the issue you are facing. That and if the managed DLL does not match the firmware.
@ taylorza - I thought I did Reset it. But I guess I didn’t, because the exception is gone after I have reset it again.
@ Architect - Wew! That is good news. It seems like until you reset the previous firmware is still there, even the device info from MFDeploy show the previous build date etc. This was my biggest issue when I first built the interop code, none of my code worked until I realized that a reset is required after each and every firmware update.
So, did your pin 3 activate?
So far so good!
sg = new SignalGenerator(socket.CpuPins[3], false, 10);
Thread.Sleep(2000);
sg.Set(true);
Thread.Sleep(2000);
sg.Set(false);
@ Architect - I cannot thank you enough for posting that, it is very exciting for me. Now I really need to get a logic analyzer…
If you would not mind testing the SetBlocking I would be grateful. The following should show 1 second high, 1 second lost, 1 second high.
sg.SetBlocking(true, new uint[] { 1000000, 1000000, 1000000 }, 0, 3, 0, false);
I would be interested in knowing how accurate that is.
You are welcome!
Looks very accurate!
sg = new SignalGenerator(socket.CpuPins[3], false, 10);
Thread.Sleep(2000);
sg.SetBlocking(true, new uint[] { 1000000, 1000000, 1000000 }, 0, 3, 0, false);
2.0014400 (2000ms wait)
1.0001200 s (High)
1.0001200 s (Low)
1.0000800 s (High)
@ taylorza - FYI, just tested this on another machine, and getting the same error.
Here’s what I did:
[ol]Removed all GHI packages/drivers
Double-checked that I had NETMF 4.2 RTM (QFE2) installed
Downloaded the latest GHI package from http://www.ghielectronics.com/support/dotnet-micro-framework
Installed the GHI package using the GHI installer
Created a new Gadgeteer 4.2 project and added the Hydra mainboard to the designer
Attempted to reference the managed library from your ZIP, and got the same error as before.[/ol]
I also tried a full reboot, to no avail.
I don’t see step where you load dotnetwarrior firmware using MFDeploy. 