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

Is there any updates about the timeframe in which this module would become available? I've found the SD Card module ready for shipping late september, and it would be amazing to have this module at the same time. Can it really be true, that it seems almost impossible to find a descent alternative to the upcoming ethernet module? I'm aware of the fact, that it would be most optimal to use the upcoming module, but I have a very limited time to get my solution complete - it's my final exams, with deadline in december. I'm currently using a N+, but I'm in a desperate need of extra ressources

Is the Netduino Plus an option for your project?

Got the N+ atm, but could really use some more memory. That's the whole point switching to NGo - hopefully it can be used as a DPWS client/server

After posting my earlier message, I found the ENC28 + mIP solution which I'm gonna tryout.

Is there any timeframe at this point, for when you expect the modules to be ready for shipping (a realistic timeframe)... seems like those 10 days of testing back in July is still going on, and I've seen many other statements, where it was just a matter of a few weeks - months ago. Of course it's better to have a working product, except from a beta, but it does seem to me, that you don't really knows it either and just mentions X weeks/days. Straight out of the box, can an European be expecting to have his own Secret Labs Netduino Go Ethernet Module before November?

I might be able to help, mainly because I broke stuff on mine. Are you doing any of this in multiple threads?

There's multiple threads running, and after it's completely initialized, worker threads can call Screen updates if needed. But at the initilization-process, only the main thread is calling the screen.

Since this is already a discussion about the nwazet products, and Fabien is active in this topic: Does the nwazet display module, have some sort of response/idle timing between executing commands? It seems to me, that it often, doesn't do the Execute(), even through its told to do so, if two update cycles runs immediately after each other. Currently it happends during the my initializing-phaze, where I want to show a progressbar showing the progress step by step. It changes from load to load, even without any codechanges. But it seems to be having something to do with updating to frequently. Note: It happends with both 4.2.0.* and 4.2.1.0 firmware. The SPI is running at 10 MHz.

Thanks for the answer Fabien. I have no excuse for my stupidity here - I've forgot to make the code threadsafe. Two quick questions: a. Can the nwazet screen be replaced? b. Is it normal that the screen flickers when it updates?

Thank you for your answers. In this case, it would mean to the Netduino is rendering a bitmap, and then sends it to the module, which updates it immediately? For research purpose only: If need, would it be possible to order a batch of screens with custom logos?

a. Yes, it can be replaced with the same touchscreen model. If you look at the display carefully, it's held in a metal cradle from which it can be extracted to swap a new one. It's also possible to replace the touchscreen with a regular display (same model but no touchscreen)

Ah that wasn't exactly what I meant.. it's the yellow screen when it initializes i was referring to

b. Yes, it's normal for two reasons: there's SPI latency between the Netduino Go and the Touch Display module, then the set of commands send to the display is interpreted and bit-banged onto the IC display driver bus (the STM32F205 does not have an FSMC peripheral, so bit-banging is the only option). This results in some flickering when refreshing the screen. I hope this makes sense

Ah I see.. and this is the case for all Go Modules, right?

You might want to make sure that you are not somehow sending multiple commands to the hardware before the other command is finished.

Yeah, thats why I was wondering, if it had some responsetime or something. Couldn't find anything about it on the nwazet site.

Beside that I would have to see your code and test it.

Sure, I'll post some code when I get home. I don´t have it here at the moment.

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)

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

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..

Hi Chris,
We're a couple days away from September 29th and we have not heard from you on the availability of the SL SD card reader.
Can you please provide us with an update?
Thanks,-Fabien.

God damn I hope those modules are ready for shipping in about 24 hours... otherwise I might have brought a NGo Startkit, Shieldbase and other stuff, that I can't use for my finals anyways :s

24 hours?, sounds like bad planning.
Do something like this if you have access to spi: http://elasticsheep....h-an-atmega168/

Nah, the release date is in less than 24 hours Or at least according to http://nwazet.com/gosd and http://shop.microfra...ctOut.aspx/4801 .... and if Fabien, who I expect is the reseller at nwazet.com doesn't know anything, it doesn't seem good...

That link does seem kind of interresting through... thanks

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 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 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...

Hi Nicky,


Are you using the NetduinoGo.ShieldBase.dll that came with beta 4 (v0.3)?

Chris

:facepalm: !!!!

I don't know what I was thinking yesterday... first the Win8 thing, and now this.. Thanks.

Oh ffs... so that means, that I always will have to multiply the returned value with the voltage? Sigh, these electronics are killing me! Thanks mate.

Am I the only one, who gets "AsyncEventReceived | profile: 128; instance: 6; function: 5" everytime an InterruptPort gets interrupted?

Has anyone experienced, that their analog readings are wrong? Measured directly on the sensor, i get a value of 0.47v but Shieldbase reads 0.14v... it seems to be dividing the actual value with the voltage...

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.

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.

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.