79 replies to this topic

[Chris Walker]

Hi Mike,   We just finished Netduino Update, the first pre-requisite for custom USB configurations.  Next up is tweaking the USB code to enable the custom configurations...we're working on that now, but USB is pretty complicated so this may take a little while.   The easiest way to communicate with the PC via USB today is by using an FTDI 3.3V USB-TTL serial cable and 3 jumper wires (TX->RX, RX->TX, GND->GND). https://www.sparkfun.com/products/9717 Bienvenido a la comunidad Netduino! [Welcome to the Netduino community!] Chris

[MrGibblets]

Hello Mike,

 

Just hoping on an update on the USB code tweaking?

 

Regards,

 

Eric

[untitled]

I posted a project to communicate with netMF boards via USB from a PC a while ago (http://tinyurl.com/l2dy6po).  My solution uses a driver, but ignore that difference.  I had the same USB debugging problem to work around.

 

Basically I Stop the USBController from debugging and use it when I want it.  By default I have my device always boot into USB debug mode. See my USB.Init() method in the code I posted for the details.  This may not be a great solution for everyone, but this works for me.

[beastyboy]

Hi untitled,

 

Could you supply the your complete installation package?

I am trying this for the GO for the last couple of days but the drivers keeps on displaying an error that it cannot start.

 

Deploying your code to the GO was easy and I changed the VID and PID to my hardware but UsbView does not shown any new hardware.

The Netduino is correctly removed but then nothing happens.

 

Best regards

Olaf

[Spiked]

Hello all, Netduino Noob here, so apologies. I'm quite experienced as a .Net developer, but slightly new at robotics and MF, having done a little of both.

 

I have a robotics project where the Netduino is intended to serve as the hardware interface, and communicate back up to the WIndows app.

 

This involves some sort of remoting. So in googling, I've run across a stale remote project (http://kaushikspotse...s.codeplex.com/), Microsoft dpws, and now this.  

 

I tend to gravitate towards this since it has some fairly recent activity and is the most specific for the Netduino.  Is that the correct assumption?

 

I also notice that at present because of interaction with the debugger a separate FTDI is needed. I happened to have the Sparkfun 3.3v FTDI breakout board already (not the cable, but the equivalent board).  Will this get me going? Am I on the right path?

 

Mike

[Jack Chidley]

This project uses USB whilst the other is network based, which could be wireless with a Wired/Wireless bridge. Old just means will require converting to use the latest version of netmf.

The Sparkfun FTDI should work provided the drivers are OK on your version of windows. You'll have to connect the debugger over com1 D0 & D1 on the Netduino / whatever the com port is on the PC is for the Sparkfun. There is a post (somewhere) about running Visual Studio over a com port and not the USB.

Jack

[Spiked]

Any speed comparison between dpws(ethernet) and USB? I can find out the hardware differences (12mbit v 10mbit), but some feel for the actual stack throughput / latency on this particular device (plus 2) would be helpful. right off the bat I would think dpws would have the advantage of ease of use (WSDL) in visual studio, if it performs as well, does not require extra hardware, then it is the obvious choice. This assumes dpws works as intended (and any insight on that would be helpful).

 

So far I have been unable to get any ethernet communications going. MF deploy indicates good DHCP obtained config, but ReceiveFrom throws 'Network is down'.

[Jack Chidley]

Right off the bat: these devices (Netduino, et al) are really slow and resource constrained - the limiting factor is the Netduino, not the USB/Ethernet. The simplest way to communicate with the device, incidentally, is wiring up your serial device directly to the COM port.

As for why your device isn't working. I don't know. You need to set the MAC address using MF Deploy, then use this to discover the correct IP address assigned.

You'll need something in the Netduino capable of responding (I can't remember if it responds to ping, for example). You can run code on the Netduino to find out the Network Information and use either the debug interface to inspect the values or Debug.Print("message");

But the problem with Debug.Print is that it is using the same line that is used for all communication so 1) you are shoving things into the USB stream that you may not want there and 2) it may be difficult to interrupt the Netduino to communicate with it to debug or push your code onto it. So use Debug.Print sparingly.

As for options to talk to your Netduino or get it to respond, I can offer 2 more Internet based ones which are being actively developed and supported:
http://forums.netdui...nmikawebserver/
http://forums.netdui...-of-things-431/

The latter is the source code for an excellent book (available on the Kindle) written by Cuno which might give you a quick start on .net Micro Framework and networking.

Jack

[Spiked]

Thanks Jack.  The mac has been configured, that is why I indicated it had gotten a valid dhcp IP - it pings fine, but it is nmikaweb server that is getting the network down exception.  I'm trying other IP stuff to see if I can figure it out. One thing I notice consistently is the use of non-dhcp, which might be a hint, I can explore that angle on my own more.*

 

Yes, debugging is crucial, otherwise I'd just as soon use an arduino. So I need to do both, communicate and debug. I would have to disagree though on simplest way to communicate, if I can code a object, import its wsdl file into visual studio, and treat a object on a remote device (netduino) as local (intel NUC), that is simple.  I understand your description is more from a bytes across the wire point of view, not a developers point of view.

 

I'll take a look at the internet of things.

 

*so yeah - after double checking before posting this, I am finding totally unreliable unrepeatable dhcp usage. time to go fixed.

 

Update: yep, going to fixed, it is now communicating.  So a question remains, has anyone used dpws and what was the experience, good or bad?

[Jack Chidley]

I would have to disagree though on simplest way to communicate, if I can code a object, import its wsdl file into visual studio, and treat a object on a remote device (netduino) as local (intel NUC), that is simple.  I understand your description is more from a bytes across the wire point of view, not a developers point of view.

Which shows that you are way more experienced than I am at development! My background is in infrastructure and so that stuff is trivial to me but I try not to assume too much.

"Simple" in this context is simple to diagnose the issues.

Like you said good debugging is a killer feature. I know almost nothing about development but I'd much rather use C# and Visual Studio than the alternatives. You can use C# on a Raspberry Pi but its debugging is not as comprehensive.

I guess you're probably already using Visual Studio 2013 R2 Update with the Experimental build for the Netdunio. If not, it might be worth a look.

Incidentally, for work on these devices I think you'll find, in time, a logic analyser very, very helpful for debugging. And then an oscilloscope. And then...

[Jack Chidley]

You might find this blog: http://blog.mark-ste...egory/netduino/ interesting. Mark is a developer and has gone a long way down the electronics rabbit hole...

[Spiked]

Again, thanks for the noob pointers. Yes I am quite experienced as a developer, Remoting, WCF, WPF all all pretty much second nature to me and I cringe on the thought of not having them.  But Solder? I cringe at thought as well  But as I mentioned, I have done some. I have the saleae analyser that does I2C and others, as well as the newer one which adds analog (oscope), on order  

 

Yes getting vs2013 up was the first step.

 

So I had a look at the internet of things. I ran step 1 ok, step 2 was not blinking the light, so I added a Parameters.Setup(), because I didn't see where the proper pin was being set.  And that invoked the 'sign up for you private key, we only want your personal information' routine and I bailed.  I'll see what I can get from the code, but I really dislike that kind of dishonest thing. If it truly can be run without it (as advertised), one preprocessor variable should do the trick, not 30 minutes of chasing down unrelated code.

 

I'll take a look at Mark's blog now.  Mine is at http://www.spiked3.com  <- warning; not open source friendly at all

[Jack Chidley]

Configuration.Parameters

Comment out these 2 lines:
public static string ApiKey = "FSROGLGYAzdjj8rzGT9PfR3GqVBItuj9HgiZ1bQIQyetc.";
public static string FeedId = "1978138etc";

And you're done.

You need to know the IP address of the Netduino and you can hit it directly. Cuno develops for embedded systems - he ported netmf to the F4 cores.

ooohhhh. Like the blog. Will be checking this out later

[Spiked]

actually looks like you need to comment all 4

  //ApiKey = "<insert your API key here>";

  //FeedId = "<insert your feed ID here>";

 

  //RelayDomain = "<insert your relay domain here>";

  //RelaySecretKey = "<insert your secret key here>";

 

but that seemed to work for the blinky anyhow.  Which example are you referring to, as far as needing the IP address?

[Jack Chidley]

Ah yes. It's the relay ones that are the key. I replied too quickly but you worked it out anyway.

You may need the IP address for any example where it's a server. But if your name resolution is working OK then that shouldn't be necessary.

Parallel Blinker is the final, template, application.

Obviously if you want to access your device from the internet you'll need to provide some kind of routing for it. Or set up your own relay.

[Jack Chidley]

And this blog http://blog.roguecod.../tag/bluetooth/ might be useful too. Cheap bluetooth for point to point links. The bluetooth module that Mark mentions in his blog looks interesting.

For a hobbyist ease of use is probably the most important thing. But for professionals resources, money, size, power consumption and ease of manufacturing seem, to me, to be way more important.

From what i can see, in embedded development, hardware skills are the most important thing. But that will probably change with increased computing power. Making software development more important.

FYI. Check out Build 2014 IoT (Internet of Things) presentations. Microsoft is investing in this space.

[Spiked]

I do not really want internet access. I am just trying to develop a robot platform above a line following LED blinker.  You know, collision avoidance, drive motor encoders, IMU, LIDAR, ICP-SLAM, basic robotics stuff  :|  Then move on to arms and IK, motion planning, high school stuff.

 

So an Intel NUC main processor w/windows 8 (and vs 2013), a netduino for I/O.  I guess I must be bleeding edge or something. I am not finding anything similar. Sigh, I'll work through it eventually.

 

http://www.spiked3.com/?p=338

[_Elias_]

Hi there, I was wondering what speeds you guys were achieving using the USB connection to a pc? I am designing a data logger and I want to be able to pull about 50Mb of data logs off of the Netduino in a timely fashion. Thanks!

[Dr Who]

Chris, anyone, someone, what finally happened here? I never got a chance to setup anything. What with working on other things surmounting this one and the other in this area, I never got around to trying any of this out.

[luto]

Anything new on the updated USB-Code to achive this out-of-the-box?

 

I still think that this is a great and needed feature :-/