Netduino+ & TCP/IP comms with PC

I’ve been spending quite a few hours with the Netduino board again. I’ve become less enthusiastic about it. Well, not about the board itself. That is well engineered and I can’t believe it’s that cheap. It has plenty of I/O and processing power. And yes it can be programmed with the simple Visual Basic.NET language. So what’s the problem? Or rather: what’s my problem? Well, as you may know I couldn’t care less about the much-touted Arduino because I don’t want to learn a new language (how simple it may be – no clue about it). So when I found out about Netduino and the fact that is is programmable in VB.NET, I jumped on the bandwagon. But when I actually wanted to use the board and start programming it, I noticed that almost all online samples and ‘how to’ articles were for C#. That’s highly inconvenient, but not a biggie: I can convert a few lines of simple code myself and there are online translators that convert big C# code slices and make it VB you can CRTL+V from the clipboard. What bothers me a lot more is that the forum is not responsive to my questions and problems. There is quite some knowledge there and a few users really seem to know the Netduino inside out, and they are fast to reply. But not to my postings. Maybe it’s because of me and the way I write, quite possible although I wouldn’t know why. Maybe it’s because my problems are too specific (mostly about the I²C bus interface ), but I suspect that it’s because I always ask help for VB and give my code in VB. And believe me: before I turn to a forum for help, I have looked for solutions everywhere and have tried a lot of things – even RTFM (if there is one).

You can think what you want but to me VB is a simple yet powerful programming language that allows mortals like me, who didn’t spend years on a university campus studying C++, to write effective programs that get the job done. VB = RAD.

Anyway this time I managed to have a PC and the Netduino board exchange ASCII strings over the LAN. No more RS232, no more USB, exit UART. Over the years I have learned myself quite a few tricks and programming techniques by reading books and online articles and analyzing what I consider to be well written code. There are two fields where my knowledge is poor to non-existent: databases and network programming. I have fiddled with both in the past and managed to make a few ‘proof of concept’ applications but never something really usable. So now it was time to tackle TCP/IP. I looked for some decent VB applications. Decent meaning: a) working, b) complying to good programming techniques and c) adaptable to my needs. I liked and learned a lot from this nice example and from this forum thread.

Communicating between two PC’s is a nice bonus but not exactly what I was looking for. I rather want a PC server program to exchange information with the N+ module over the LAN, I used the server code of the latter example to make a simple server. For the client code in the Netduino, I found a simple HTTP webserver written in C#. I used DeveloperFusion’s online code translator and ported the C# code to VB. It worked: I could handle HTTP web requests coming from the PC’s browser. While I learned some nice things along the way about HTTP headers and stuff (and seemingly different behaviour depending on the browser of course), I decided this was not the way to go. I wanted to exchange and parse pure ASCII strings in order to make my own protocol. So I kept most of the webserver code but modified it to receive and parse pure ASCII strings in stead of HTTP headers. Not a big deal since an HTTP header is just an ASCII string once it’s received.

I encountered some problems but managed to solve them. In the end I now have a WinForms server program that can communicate both ways over the LAN (TCP/IP) with the Netduino+ module. I am glad I got this running and so far working. I can toggle I/O from the PC and report back from the hardware to the PC. But I’m not 100% happy with it. A few years ago I would have been ecstatic: code written, program tested, goal achieved, time well spent. But I had to use a few hacks and workarounds which I think would not have been needed if I understood the TCP/IP combined with multithreading programming in detail. Yes the Windows server program and the client on the Netduino are multithreading apps. As if it isn’t complicated enough already!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.