I think that you might be mixing two things. Your latest Netduino code is still trying to connect to it self. Do you want the PC to connect to the Netduino or vice verca? Lets assume, you want the Netduino to be server, and the PC to be a client. First, you have to listen on your netudino. Create a socket, make it listen on IPAdress.Any, and a port, 44818? It should NOT connect, only listen. Then on the PC, you want to establish a connection to the Netduino. Create a Socket and connect to the Netduino IP and the specified port, 44818? Then you can begin doing your stuff. I can upload a code sample, of how to make an FTP server. That should get you started (TCP listening, processing requests, response). It's not complete, tested through or anything, but you can give it a shot, it will be up in 10 minutes. edit: The code is now uploaded at http://ntools.codeplex.com/ - you can see it under the "Source" tab. But notice, it's not done, it's not really tested, but it can give you an idea of how to do what you want

Don't give up yet

No matter what, you cannot use the localhost address to connect to a remote device. You can use the localhost address to connect a device to it self. That includes "localhost" hostname (otherwise changed, but you wouldn't wan't to do that), and the IP 127.0.0.1.

When connecting the PC to the Netduino you have to specify the Netduino's IP-address. That would be the address configured with MFDeploy or in the code on the Netduino. (You shouldn't use 127.0.0.1). If you don't know the exact address range on your local network, including subnet and gateway addresses, I recommend you to use DHCP.

To determine the IP-address of your device, execute this code as the very first on your Netduino:

while (Microsoft.SPOT.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()[0].IPAddress == "0.0.0.0")
{
   System.Threading.Thread.Sleep(10);
}
Debug.Print("Device IP: " + Microsoft.SPOT.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()[0].IPAddress);

The use that IP-address to connect the PC to the Netduino.

Hope this helps you a little.

Hi Mark,

We looked for EU distributors early on when we launched our Go! modules. Unfortunately, UK distributors who have responded so far wanted a very high cut for their services, to the extent where it was not sustainable for us. Outside of the UK, I would recommend checking out http://shop.microfra...gue.aspx/nwazet who resells Nwazet products in the EU and asking them for the Nwazet Go Pro kit.

I hope this helps.

Cheers,
-Fabien.

The only problem about shop.microframework.eu is that they are very, very slow. Bought from them twice:

The first time, it would probadly have been faster to just buy all the stuff at nwazet... waiting for more than two weeks!!

Second time took about 6 days... where as 3-4 was spent, waiting on the packet to be shipped. It was packed and stuff, just not shipped.

Honestly, I doubt that I would use them again... the have good boxes through...

You can get the GoBus and GoBusSerialTransport DLL's from the attachment here

You can only grab hold of a pin once. So the second instance of MyClass will fail as the first instance is still referencing A0.

Regards,
Mark

Hi Mark

Thanks, but it's not.. I've simplified the code by removing parameters and replaced pin variable with actual value.

Hi

I have problem creating an AnalogInput on the Shieldbase...

using AnalogInput = SecretLabs.NETMF.Hardware.AnalogInput;
namespace MyNamespace
{
    public class MyClass : MyBaseClass
    {
        private AnalogInput input;

        public MyClass(NetduinoGo.ShieldBase shieldbase)
            : base(shieldbase)
        {
            this.input = new AnalogInput(this.shieldbase.Pins.GPIO_PIN_A0);
        }

The abowe throws ArgumentException. The code is exceuted immediately after another instace of "MyClass" is created with digital pins. The Pin has value 1014.

Running Netduino Go firmware 4.0.0.2.

Thanks in adavance

Hi Nicky,

Are you okay with switching to the new NETMF AnalogInput class? Then instead of the shieldBase.Pins enumeration, you can use the shieldBase.AnalogChannels enumeration.

Nice! Works like a charm!

I actually tried using it, and deleted the using AnalogInput in the top, but apparently VS didn't change the reference. using AnalogInput = Microsoft.SPOT.Hardware.AnalogInput did the magic.

1st question: No and yes. Netbios naming is not supported by default, but it can be implemented somehow. I know that Netbios naming is a part of mIP-library, but it won't run side by side with the LwIP-stack without modifications. mIP can be found at http://mip.codeplex.com/ 2nd question: I know that .NET Micro Framework Toolbox (http://netmftoolbox.codeplex.com/) has some WiFly, but if thats what you need I wouldn't know - nor if it works.

Hi

During work on my Netduino Go, I've been working using a Netduino Plus for SD and network support. I thought this might could come handy for some (a little bit late maybe), so I have made a Codeplex project for it.

It only contains the operations and classes that I have needed this far, so you might have to add some. Read the notice on the front page, before using it.

I have only tried connecting the Netduino to Socket 1.

To use the Netduino, simply create a new instance as a regular module, and use the included classes instead of System.IO.File etc.. You will still have to use enumerations from the framework when needed.

I will put some more stuff in the library, as it gets done.

For wiring, see Fabiens article: http://channel9.msdn...y-Netduino-Care - I did like he explained, when in this case, the display would be the Netduino Go. The only difference is, that you also have to connect the two UARTs.

There might be some unused stuff somewhere in the code from the rest of my project - it should all be gone, but if it's still there, just ignore it.

Any feedback would be awesome... if anyone wants to contrib, I can add you on Codeplex.

I'm running a Plus on socket 1, RGB Led (or used to until it started messing up) on Socket 2, nwazet display on Socket 3, and finally a Shieldbase on Socket 5

The link was already there, but perhaps not visible enough http://ntools.codeplex.com/ The code is under the "Source" tab.

If someone got the display module from nwazet, could u please do me a favor and test it with this firmware? My application hangs when initializing the module. edit: still having trouble deploying to the Netduino Go..

I haven't tested the [nwazet gear on my Netduino Go yet, but it should work. There are a few exceptions which we accidentally suppressed in earlier firmware which were fixed in code review of the new firmware... If you have any troubles, we'd be happy to help [nwazet diagnose the issue.

I can confirm (as mentioned earlier), that the display module is broken with this firmware.

Btw, is there any news on TristatePort support on the Shieldbase? Doesn't seem to work yet

I tested new firmware today. Mine is ok. I deleted old gobus.dll and add new one

hmm, thats strange.

I also deleted the GoBus.dll reference, and readded. I uninstalled the old SDK before installing the new one.

What version is your GoBus.dll? Mine is 1.0.0.0, created Nov. 7 2012, 02:43 (might be my local time)

Just to confirm... the bug with deployments bigger than 128 kb is still there. Actually, I had to erase and flash every time I made a code change..

I'm having an annoying problem since deploying this update to the GO. I cannot deploy an application without having to unplug the USB from the GO board. In order to deploy I have to perform the following:

Compile and deploy in VS
Remove the USB cable
Plug the cable back in - at this point VS starts talking to the board.

Is this a known issue?

Regards,
Mark

I do also have this thing going on... mostly when an exception occoured, but also when it's running normally.

It's not due to the 128kb+ bug, because I've already tried erasing/reflasing...

edit: oh forgot to mention, if I unplug the cable when it tries to deploy (when it fails), I get BSOD - both Win7 and Win8

I also have to replug my NGo 90% of attempts to deploy code to it after upgrading.

Further more, and this seems totally random, sometimes the NGo "looses" it's entry point, and then I have to erase the chip and reflash before I can run my code. I can't deploy another project neither.

Output from Build:

------ Skipped Deploy: Project: ComLink, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
------ Skipped Deploy: Project: OS, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
------ Deploy started: Project: NetduinoGoApplication2, Configuration: Debug Any CPU ------
------ Deploy started: Project: NetduinoGoApplication2, Configuration: Debug Any CPU ------
------ Skipped Deploy: Project: LV-MaxSonar-EZ, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
------ Skipped Deploy: Project: AM2302, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
========== Deploy: 1 succeeded, 0 failed, 4 skipped ==========

Output from Micro Framework Device Deployment

Incrementally deploying assemblies to device
Deploying assemblies for a total size of 219324 bytes
Assemblies successfully deployed to device.

Output from Debug

Create TS.

 Loading start at 8056ce0, end 806dd8c

Assembly: mscorlib (4.2.0.0)

Assembly: Microsoft.SPOT.Native (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0)

Assembly: Microsoft.SPOT.IO (4.2.0.0)

Assembly: System.IO (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)

Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0)

Assembly: SecretLabs.NETMF.Diagnostics (4.2.0.0)

Assembly: SecretLabs.NETMF.IO (4.2.0.0)

Loading Deployment Assemblies.

Resolving.

The debugging target runtime is loading the application assemblies and starting execution.
Ready.

Cannot find any entrypoint!

Done.

Waiting for debug commands...

'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\mscorlib.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Native.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.Usb.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Secret Labs\Netduino SDK\Assemblies\v4.2\le\SecretLabs.NETMF.Diagnostics.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files (x86)\Secret Labs\Netduino SDK\Assemblies\v4.2\le\SecretLabs.NETMF.IO.dll', Symbols loaded.
The program '[3] Micro Framework application: Managed' has exited with code 0 (0x0).

Hi indimini,

I tried to reproduce your error using the above code but did not get an error. After a couple deploys I commented out the 3 lines for the myButton, and still had zero issues. I wonder if this is similar to the seemingly random USB issue we used to have with the Netduino. I do believe at some point in the near future we will also see a move to the WinUSB drivers for the Netduino Go as well. Perhaps that will helps solve some of these issues where you need to unplug and plug your device back in.

Steve

I also have this one.. almost all the time. I'm running a N+ at the same time... could this have something to do with it?

I would be happy to look at the Wireshark file to see if I can figure out what's going wrong.

That would be great. Althrough I really don't have time to work with this anymore the 7 days. Have to focus on the other stuff, but after Dec. 21st could be cool. I don't know what Wireshark is through? Guessing that it's some network monitoring. I've used a tool from Microsoft, but can't tell if Wireshark is better

Great question. It's Apache 2.0. I started with a driver ported from C written by hanzibal in C# which was GNU (with permission). Then I tried to get permission from the authors myself to go Apache. I got no response, but I soon found out that the C version was actually based on the Microchip sample code with little modification. So I wrote my own driver based on that and not based on any GNU code and licensed that as Apache 2.0. That is the driver used in the Beta of mip and the original GNU driver is no longer included. So everything is Apache. This allows it to be used commercially.

Yeah, that was kind a like I understood it. I've tried making my own driver based on the datasheet, and got some functions working, but discarded it, when I saw your version was the only one included in the download. Eventhrough the problem i had on local network, I still think it's a impressive library. I know most of it's is just protocols, but the amount of time spendt on this ain't small.

So, you are thinking of wrapping mIP with a new class that implements System.Net methods and classes? Definitely possible. And I think a lot of people would appreciate that. But, one of my goals is to simplify networking and save some overhead by not implementing all the typical layers. Although with the new ST chips, it's really becoming less of an issue because of all the extra memory. But, still, mIP can run out of memory under heavy traffic.

Yes, something like that. But instead of making a new class that implements System.Net, I was thinking about modifying the System.Net namespace to use mIP instead of the NativeSocket. Althrough the assembly has to be named something else, or it would require a custom firmware, it can still expose the System.Net classes.

Regarding the memory, maybe that could be handled by dropping/rejecting packets in a sophisticated way. I don't know if the receivefilters could be changed during operations, but then the ENC28 could check the port on TCP packets before passing it through. So if a HTTP server is listening on port 80, then all other packets are dropped (unless they are in the in the ephmeral range (or what ever it's called)).

Anyways, that was just a quick thought, I'm not completely into all aspects of the library, or the ENC28 capabilities.

As somebody who bought into the Netduino Go's vision based on what was posted by your company on this forum, I honestly feel like I've been mislead and bought into a technology that isn't ready for my needs. (I'm also waiting for a one-wire library and a shield base that doesn't require four sockets to use.) I don't mean to be an *ss, but honestly, lots of promises have been made to your customers that aren't being fulfilled. When can we expect real dates for these products/features?

I must agree. I've been working on my finals the last few months, based on Netduino Go because there would be a module ready.

Instead of working on the project it self, I've spent countless hours getting Ethernet running on the Go... both with and without mIP.

Ah, you've tried mIP? Have you tried the newly released Beta? Do you have any feedback?

-Valkyrie-MT

Yeah, it's quite impressive, but I've had problems accessing server on our local network. ARP works fine, TCP sends SYN, but never receives SYN/ACK - my development machine sends SYN/ACK 3 times before sending the RST.

I also can't figure out if the driver included in the download is under GNU license or Apache?

Anyways, I would love to see a more framework like version of the library. Why? To make it easier to reuse the code, on multiple devices.

I'm currently using a modified System.Net library, to have Networking on the Go using a Netduino Plus (not the version on codeplex in my signature, thats an old, bad, implementation) - it should be possible to implement mIP this way. I just don't have the time right now. Have to hand in my exam in 7 days. Are you, or the community interrested in the this, I could continue working on it during the holidays/beginning of january.

The nwazet] display module for Netduino Go can be used on the Netduino Plus... it has a library for making a UI. If you wan't a more sophisticated UI, i would do like Lunddahl says. Or maby host a webpage on the Netduino it self. You can make a very nice UI with HTML and jQuery (or just regular JS), and then use AJAX calls to read/set values.

Are you sure its just the threading? I'm running 4 - 5 threads at the same time, UDP listener, webserver, serial server, main thread and sometimes a background worker to store data, I notice no (big) performance disadvantages on a standard ND+.
You know you can set priorities on your thread? I assume you have something going on in your main thread (the starting one) that keeps the other from executing.

Sounds like me and Noom are experiencing the same, so I can tell:

- Main-thread: Idle
- Every second, an event raises, refreshing sensors + screen and saves data (writes 100 bytes of json (automatic parsing)) if enough time has passed.
- When ever theres data to be sent, an uploader worker sends the file with a lightweight http request (1 request line, 3 line header, 100 bytes payload).

That is basicly whats killing my NGo ... singlethreaded, it can refresh, save and send data in less than a second. Multithreaded, it kills it self.

I have switched to single threaded programming on my Netduino Go, because when theres 4-5 concurrent threads running, one or two of them never gets CPU cycles after a minute of operation. Then if I reboot, it might work for two minutes, next time maybe five, next time maybe not at all. Everything shared is thread safe, minimal writing/reading to SD/ethernet due to buffers. And also... with 4-5 threads, it can take up to almost 14 seconds write 100 bytes to a SD card... the exact same code, when only 1 thread runs, it takes only a few milliseconds to write 1-2 kb. When that said, thats when my uploader should be working constantly, and saving every few second. But compared to single threaded mode, those few threads has an insane impact on performance... Sometimes a it can also take a few seconds, or maybe a minute, before the Netduio changes to a specific thread. They all have the same thread priority, but some threads get skipped when cycling!

Oh you sneaky sons of b**ches! Just as I was going to settle with my Netduino Go .. dammit, decisions decisions.