The laptop was rebooted a few times (because of the time difference and the posts comming in helping me to fix my issues, I was almost a sleep, so I needed to start up my laptop again to do some test as Gust described :-))
Now my SDCard is working perfectly, the events are triggering with small delay in debug. And the relais also keep working. Now that I flashed my Hydra with the Ethernet Enabled Firmware, I couldn’t wait to start creating a socket between pc and Hydra. But when I add the GHI.NETMF.Net the deployed program crashes in startup:
Do you mean that I can only use this GHIElectronics.OSH.NETMF.Hardware?
Because there is nothing in there for network. only Analog, FezHydra, PWM, SoftwareI2CBus and StorageDev.
The new firmware worked perfectly for me - tinybooter updating, pinging and updating from MFDeploy, and deploy/debug an application. I had the original issues with deploying from MFDeploy - Windows 7 x64 quad core i7-2630QM laptop, 16Gb memory.
I’m trying to get the sockets to work with the ENC28 module on Hydra using:
Windows Console app:
using System;
using System.Net.Sockets;
using System.Text;
using System.Threading;
namespace ConsoleApplication6
{
class Program
{
static void Main(string[] args)
{/**/
using (var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
{
socket.Connect("192.168.0.180", 80);
if (socket.Connected)
{
var send = socket.Send(Encoding.UTF8.GetBytes("testje!"));
socket.Disconnect(false);
}
}
Console.ReadKey();
}
}
}
And in Hydra:
NetworkInterface[] interfaces = NetworkInterface.GetAllNetworkInterfaces();
if (interfaces != null && interfaces.Length > 0)
{
NetworkInterface networkInterface = interfaces[0];
networkInterface.EnableStaticIP("192.168.0.180", "255.255.255.0", "192.168.0.1");
networkInterface.EnableStaticDns(new[] { "192.168.0.1" });
}
var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
var ipEndPoint = new IPEndPoint(IPAddress.Any, 80);
socket.Bind(ipEndPoint);
socket.Listen(1);
while (true)
{
// Wait for a client to connect.
Socket clientSocket = socket.Accept();
clientSocket.Poll(1000000, SelectMode.SelectRead);
var buffer = new Byte[50];
clientSocket.Receive(buffer);
clientSocket.Close();
var text = Encoding.UTF8.GetChars(buffer).ToString();
Debug.Print(text);
}
It seems that the Hydra only let me use port 80 to listen to, any other port does nothing.
and when the socket.Accept() is executed it never returns, but when I debug my Console app in Windows. I do see that it gets connected and that it transfered 7 bytes.
Accept() never returns…
Someone has an idea?
I also reversed the process and created a Windows Console app with a Socket server and made the Hydra the socket client, but on connect the Hydra gets stuck…
The issues that my laptop couldn’t deploy I fixed with using a USB 2 port (not a USB3 port) and Reflashed the firmware again. I think sometimes my code gets stuck on the Hydra, but just clearing the data space is not enough, after reflashing the firmware, I can deploy from VS back to the Hydra
Firewall is disabled and both are on the same switch.
I even connected them directly together with cross cable and still only port 80 work partial.
I’m unable to send receive data.
What I also noticed is that not always the LEDs on the ENC28 are burning. Sometimes I need to re-insert the Network Cable a few times before they are led properly
Even if I try to use DHCP, everything keeps empty except the dns address is set top 208.67.222.222, which is openDNS…
DHCP is working correctly in house for my 2 laptops, iPad and Window Phone 7, so I think there must be something wrong with the Ethernet Interface?
What I noticed is that the gadgeteer sample only speak of gadgeteer.webclient and gadgeteer.webserver. I hope that webrequests and responses are not the only working features?
I also noticed the following project on Codeplex: http://gadgeteernetworking.codeplex.com
When browsing the source code they use the same functions as I do.
Just out of curiosity, is using mfdeploy to erase the firmware any different than the ways described in the updater application (sdcard, jp1 etc)? If not, wouldn’t it be possible to put the erase firmware function from mfdeploy directly into the updater itself?
After going into sam-ba mode via mfdeploy the updater worked fine without problems.
When I use mfdeploy plugin/debug/erase firmware I’m in sam-ba mode and get the virtual com port.
Then when I run TinyBooterLoader.tcl it erases the Dataflash (DATAFLASH::EraseAll) which should be where TinyBooter is located. The updater application seems to do the same thing. So TinyBooter should be completely renewed at the end of that procedure (I could check by loading a previous TinyBooter if I find any for this board).
I don’t want to sound like a wiseass who thinks he knows better than you guys who are the pros… but if there happens to be an easier solution than cross-connecting pins or soldering a jumper if you don’t have the sdcard… wouldn’t it be worth it?
P.S. Here is my logfile from updating TinyBooter after going into sam-ba mode from mfdeploy: http://dl.dropbox.com/u/21323188/logfile.log so I’m pretty sure that TinyBooter is actually updated with this method.
No not really (and it’s not even a question, more like a suggestion):
I don’t have the SDCard module (yet), so according to the wiki I have this option to update my Hydra board:
There is also the thing with the jumper but since it’s a simple 0Ohm resistor it would be a pita to remove and replace it all the time, unless there is something to replace the resitor by a real jumper.
I simply believe that the same can be accomplished by using mfdeploy using the “plugin/debug/erase firmware” option. I found out that using this will put the Hydra into sam-ba mode (with a virtual com port). I would even believe this to be faster and easier than loading up the boot.bin file on the SDCard and wiping the board that way.
If you agree with me, you could implement the same thing mfdeploy does to erase the board (or at least put it into sam-ba mode) into your updater and it would be a lot easier to update the Hydra than any of the methods currently presented.
You can not erase the device using mfdeploy. Mfdeploy can erase the firmware bit tinybooter and bootstrap. In future when tinybooter is stable and doesn’t change then you can skip the first step. For the next few months, this is required.
I’m not sure we understand each other… I tried both methods (the mfdeploy method and the one with connecting the pins) and they both put the board into the exact same mode: sam-ba mode with a virtual com port.
I need to do the exact same thing each time, that is run sam-ba to erase the dataflash and to load the latest TinyBooter and Bootstrap binaries (or run the new updater application that comes with this package which also ensures that tinybooter+bootstrap are updated before loading the new CLR). I don’t skip any steps using either method, it’s actually not possible to skip the tinybooter update if you run the “erase firmware” command from mfdeploy.
But don’t worry I won’t mention it again after this post. You can either try it to see for yourself or ignore it.
