FEZ Hydra test firmware

Ok I have tried to build it.

  1. First issue:

NETMF 4.1 Firmware\DeviceCode\DeviceCode\GHI_OSH_Drivers

has to be one level up

NETMF 4.1 Firmware\DeviceCode\GHI_OSH_Drivers

  1. Second issue:

[b]MicroFrameworkPK_v4_1\DeviceCode\GHI_OSH_Drivers\libraries\GHIElectronics.OSH.NETMF.Hardware\Native[/b]

missing 6 files:

<Compile Include="GHIElectronics_OSH_NETMF_Hardware_GHIElectronics_OSH_NETMF_Hardware_AnalogIn_mshl.cpp" />
<HFile Include="GHIElectronics_OSH_NETMF_Hardware_GHIElectronics_OSH_NETMF_Hardware_AnalogIn.h" />
<Compile Include="GHIElectronics_OSH_NETMF_Hardware_GHIElectronics_OSH_NETMF_Hardware_AnalogIn.cpp" />
<Compile Include="GHIElectronics_OSH_NETMF_Hardware_GHIElectronics_OSH_NETMF_Hardware_PWM_mshl.cpp" />
<HFile Include="GHIElectronics_OSH_NETMF_Hardware_GHIElectronics_OSH_NETMF_Hardware_PWM.h" />
<Compile Include="GHIElectronics_OSH_NETMF_Hardware_GHIElectronics_OSH_NETMF_Hardware_PWM.cpp" />

Thanks a bunch for testing it.

I have fixed and uploaded missing files. Try again please.

The long path was a problem for windows and for every software I used! It should be good now.

Did that.

Then went to “Devices and Printers” to get COM port. This is all I see. I tried running “UpdateFEZHydra com2” but that didn’t work… Here’s my log.


-I- Waiting ...
-I- TCL platform : Windows NT
-I- SAM-BA CDC 2.10  on : windows
-I- Retrieved arguments from command line :
-I- argv 0 : com2
-I- argv 1 : at91sam9rl64-ek
-I- argv 2 : TinyBooterLoader.tcl
-E- Connection com2 not found
-E- Connection list : com11

What COM port should I be using? COM11 is not the Hydra. It’s an FTDI cable I have plugged in.

It is still showing as netmf device. You didn’t do the steps correctly.

0 Errors (GCC4.2.3) :clap:

Great thanks a bunch. But note the the scatter file for GCC is not correct. We have been using RVDS to test both. You need to open the RVDS scatter file and see how memory is mapped then do the same on GCC.

Ok, thank you.

Gus:

I removed JMP1, as you requested, when I was having trouble getting the Hydra to load the required driver. It is still out.

The instructions above can mean that after I have powered up the Hydra without the jumper, and the PC has recognized the device as a GPS Camera Device, I should solder JMP1 on the powered device, and then install the new firmware.

Is this correct, or does this mean power up without the jumper, install the firmware, power down, and then resolder the jumper?

You need the jumper on to install the firmware so remove jumper, power up the board, check that you see new COM port in device manager, put jumper back while board is running and finally load firmware.

Everyone, I like to add that this will be a lot more user friendly when we are done with it.

So, I need to do BOTH #1 & #2 above? I thought those were my “2 options”…

I did only option #1 and it worked flawlessly. I had a GPS camera on com12 :wink:

No! one or the other.

Ah… I didn’t recognize that the first go-around. Thought it was my webcam. It seems that it worked this time. Thx.

Turkey day is over and I’m testing Hydra now…

First thing… I started a new Gadgeteer project and it gives me a warning that the “template is from an untrusted source” warning. This may or may not be expected. Not sure if you intentionally didn’t code sign this release.

One general Gadgeteer suggestion - it would be really cool to be able to rotate the board & modules in the designer to match the layout on my table.

I added a button to socket #2 and two Extender modules on sockets #4 & #7 then added code to do a simple Debug.Print(“Button pressed.”) when the button is pressed. Ran it and it runs fine but the following errors/warnings show in the Output. Is this normal?


 Invalid address 203005a0 and range 4 Ram Start 31000000, Ram end 35000000
 Invalid address 20300600 and range 4 Ram Start 31000000, Ram end 35000000
The thread '<No Name>' (0x2) has exited with code 0 (0x0).
Using mainboard GHIElectronics-FEZHydra version 1.0
Program Started
 Invalid address 20307728 and range 4 Ram Start 31000000, Ram end 35000000
Button pressed.
Button pressed.

Pin #4 of socket #4 doesn’t appear to work as DigitalOutput when using an Extender module. I tried the following on two separate Extender modules. Worked fine in socket #7 but not in socket #4. I used an LED to confirm.


var pin4 = extender4.SetupDigitalOutput(Socket.Pin.Four, true);
Thread.Sleep(1000);
pin4.Write(false);

Then I moved to socket #3. Everything worked except pin #4 was a weaker than others. No problem. Then I tried moving to socket 8 and things got real interesting…

All “Y” sockets are supposed to have 7 available I/O pins right? Note at this point I was using Extender modules on sockets #7 & #8 and a Button on #12.

This morning I created a new Gadgeteer project and for some reason none of the USB modules (including UsbClientDP) appeared in the toolbox. After I closed all VS instances they came back but still weird.

An “issue”(?) that I just noticed is that when assigning a socket to the usbClientDP module, it offers up the second port on the Extender modules as options. This doesn’t seem like it would ever be a good idea to plug in a red module there.

I think it’s “by design”, in fact. The extender is able to connect (to) everything in theory, so socket D is not different, in this way.
So the designer has no way to tell that what you want to do could be dangerous.

One solution would be to remove the D socket from the list of compatible sockets for the extender. But I’m not sure it’s a good idea as well ???

What if you need a long cable for power? Use the extender cable.

This is not ideal but you may need it.

Wouldn’t it be wiser to use a longer power cable, instead ?

Another solution for ianlee74 could have been to use a different connector for this particular module, for example a 6 pins only connector. This would leave USB and power functionnal, while only removing 3 IO pins.
I don’t know if the Gadgeteer specs do allow this, though :think:

So, ianlee74, to summarize you have to be careful :wink:

Seems like a bit of a reach… :wink: