Saturday, October 09, 2010


Quick Arduino or Netduino Shields

Ok what’s a Sanguino guy doing messing around with little Arduino’s?

Actually I happened across the Netduino product offering which like the RepRap project supports open source as an operating principle.

The strength of Netduino is that you can program it in C# easily with break points, variable modifications, basically everything you could ask develop/debug environment, except modify
the code on the fly.

How is C# open source?

Microsoft has released the entire .NET micro framework and porting kit under the Apache license, while continuing to support with a small team on the Codeplex website. In support of open source the netduino people are busily extending the support where it can interact easily Mac's and Linux as development platforms.

From a RepRap standpoint I am experimenting with this and specifically looking at creating a virtual com port driver so that we can leverage the micro framework for USB, network and SD card connectivity in front of the Arduino type processors.

The netduino family currently has two members. The base Netduino and the Netduino Plus that has a micro SD card and Ethernet interface on board.

From netduino

Since the netduino is open source we could use the same processor chip with a few components to provide USB interface on steroids for the RepRap project.

Ok back to shields, I ordered a shield kit along with the netduino to experiment with.

From netduino

In working on USB drivers I needed to switch the Netduino from USB debugging to serial debugging and I was able to reuse the USB serial cable from my Sanguino project as the serial interface.

This involved hooking up four wires, which tended to come out so I needed an adapter shield for something a bit more robust.

Not wanting to use up the one shield I had on hand for this simple task I went for the quick, dirty (more on dirty later) and cheap (especially cheap!) solution.

Running down to the local consumer electronics store I was able to procure a perforation prototyping circuit board with equally spaced holes 0.1 inches apart.

Perfect quick cheap solution? Ah not so fast; there is a fly in the ointment when come the Arduino form factor! It turns out that the Arduino is only partially laid out on the 0.1 standard grid!

From netduino

The ones that are, are the power pins and analog pins on the bottom of the board and digital pins 0-7 on the top side of the board. Everything else seems to be offset 0.05 inch off of the standard grid, as you can see from the close up picture with the two jumper wires.

From netduino

Since my project serial cable interface project did not involve the upper range digital I was still free to proceed. So using the one proto board as an outline, I took a marker pen and drew around the basic outline and used a band saw to cut the board. If you do not have such a tool a hack saw could still make short work of it.

So in short order I had created my serial cable interface shield with a couple of big mistakes as my first effort.

From netduino

From netduino

Ok what were the mistakes? First off I made a cut out for the power plug as I had noticed that the circuit board wasn’t flat when I did trial fittings on top of the Netduino with pieces of wire to test alignment, not realizing that connector pin strips would offset the board just enough to clear the power connector.

The second is that I put the serial interface on the centerline of the board which seemed logical at the time.

From netduino

However in doing so, I covered up access to the USB port!

Ok back to the drawing board, here’s how I would make a second attempt.

From netduino

I then got extremely busy at the day job and wasn’t able to return to this for a bit. In the meantime I decided that I didn’t care about it being nice and neat and here’s the next iteration.

From netduino

So another quick trip to the band saw to flip the connector up on top and some quick hot gluing and problem solved!

As to the upper digital pins not being in the 0.1 registration layout you can do like I did and simply make a cutout for them; then use a pin strip with wires to come back to the main area of the perf board.

As a side note the Netduino has a 3.3 volt processor that is 5V tolerant on the digital pins, most people suggest using a 3.3v USB cable, my suggestion is to stick with the 5V cable as you can take power from it and inject it on the 5V pin and have full functionality and power via the serial cable.

Plus you can reuse the cable with the Sanguino and other Arduino’s clones out there!

One problem with C# is that is slow. However the netdunio has a fairly speedy processor to help make up for that fact.

Also the .Net Micro framework does not support generics, lambda expressions or Linq that the full .net platform supports.
Your right about it being a subset of the .net enviroment, but compared to the Arduino programming enviroment it is a very rich subset!

It requires native drivers to to do rapid i/o and while that is doable it is not as simple as C# development.

How ever it does have full SD card support and support for two serial ports downstream of the USB interface.

It would be much simpler to implement a user interface using C# as a front end; either via USB or network interface or attached display module.

And heck it's only $15.00 more then the standard USB serial cable that we use.

While there are some delays while it does garbage collection under .NET, it would be trival to buffer up 20 seconds of extruder commands to send out the serial port.

A second stage effort would be to implement native interrupt driven robot stepper control code for the realtime movement and do heater managment and gcode decoding in C# since it is not time critical.

I just stumbled across a wrapper that adds a degree of compatibility between the AVR Processing language and C#.
I am sorry to say .net engine inside a microcontrolers makes as much sense as java jvm inside a microcontroller net. Basically it does not make any logical sense.

There are two correct ways around this problem. llvm C# compiler or something like vala both basically translate the .net out of existence and produce a native binary.

Embeded normally don't do garbage collection. Reason that would cost time. Instead allocate blocks of memory correctly in advance. Remember C++ is frowned on in Embedded for its little bit of garbage collection causing hell at times.

Sun tried this stupidity first with Java. Why don't we learn from history. Sun got to the point of having a processor that directly processed java byte code. That at least somewhat worked. There is no processor that exists that can directly process .net byte code.

Waste of resources. If there was a translate two boards would not have to be produced so production of arduino boards could be kept cheeper.

There is no logic to netduino idea that has not been tested in the time and java and proven to be stupidity.
"While there are some delays while it does garbage collection under .NET, it would be trival to buffer up 20 seconds of extruder commands to send out the serial port."

Urk, no. Garbage collection is effectively nondeterministic, and will take an unknown time to run and happen at times which are more or less out of your hands.

This means it is only really useful for systems which have no realtime requirements! You might be able to pause your cartesian platform's motion (with the associated blobbing that might bring), park the extruder away from the part (which may leave lots of extra strings) etc, but you may find you have serious problems with things like extruder temperature control.

C# is a perfectly good language for general development (and calling it 'slow' is a bit unreasonable) but for embedded stuff with limited memory and hard realtime response contraints you really, really want something that has explicit memory management.
You can keep garbage collection to a minimum by reducing the usage of "new" and possibly manually calling GC.Collect when you have plenty of time for it to do its thing (moving with extruder off).

If that doesnt work, we can always write the bit that actually handles the extruder in C (using RLP). I've seen these devices play video this way, and if its good enought to render video without jumping, it should be good enough to run a extruder/xyz stage.
That is not true. You can afford to drop the odd frame with video. When extruding at say 50mm/s a frame is 0.8mm, way below the target accuracy.
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]