Driverless PC<->Netduino communication using USB
Posted 23 December 2013 - 11:50 PM
- untitled likes this
Posted 10 January 2014 - 06:18 PM
Just hoping on an update on the USB code tweaking?
Posted 19 March 2014 - 05:55 PM
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.
Posted 11 May 2014 - 08:17 PM
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.
Van SchOten Ict Diensten en Services
Posted 14 May 2014 - 03:51 PM
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?
Posted 18 May 2014 - 01:05 PM
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.
Posted 18 May 2014 - 04:25 PM
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'.
Posted 18 May 2014 - 04:41 PM
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:
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.
Posted 18 May 2014 - 05:37 PM
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?
Posted 18 May 2014 - 05:45 PM
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...
Posted 18 May 2014 - 06:28 PM
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
Posted 18 May 2014 - 06:31 PM
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
Posted 18 May 2014 - 07:01 PM
actually looks like you need to comment all 4
Posted 18 May 2014 - 09:21 PM
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.
Posted 18 May 2014 - 09:45 PM
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.
Posted 18 May 2014 - 10:52 PM
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.
Posted 16 June 2014 - 04:23 PM
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!
Posted 01 August 2014 - 02:47 AM
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.
"This signature does not exist!"
Posted 07 May 2015 - 06:02 PM
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 :-/
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users