First off, thanks Mark for pointing the article: I missed it although I check Hackaday daily.

Secondly, I'm happy twice, because it is rare to see something about on Netduino (NETMF in general) on Hackaday.

Will be that kinda "divine-sign" that something is gonna changing?

Have a nice weekend everybody!

1)  What's a good way (following GEP of course) to deal with the 5V / 3V3 difference? 

 

What is "GEP"?

As for what is supplied by the HC11, the Netduino (by means the MCU) is 5V tolerant so there's no problem.

As for what is supplied by the Netduino (3.3V), the "HC" voltage levels (68HC11) are able to recognize the logic high at 3V: again, no problem.

2)  Is it true that the nd+2 can't operate as an SPI slave? 

 

Yes, that's true. You can only try using the Netduino as master and the HC11 as slave.

3)  Anyone know of a similar project that I can reference?

 

I'm not aware about similar projects, but (under the 2' answer context) should be pretty similar as you connect an Arduino.

Question: why don't you use the UART? It's much more convenient if you want exchange data between MCUs...

Fine.

Just forgot:

• connect the ground between the two boards (EVB and Netduino) before any other wire.
• keep the wires as shortest as possible.

Have fun.

Here is my (modest) contribution...

I believe that iced98lx answered mostly fine, although I never liked Go! nor Gadgeteer.

Netduino Plus 2 is a very nice board, which *never* leave you disappointed, except when...you'll enjoy so much, that you wanna have more, and...there's NO more than a Netduino.

This is the biggest fault, IMHO.

Please, don't mind my signature comment, because derived from the huge blackout in NYC some year ago...keep it likely as a "too deep dependency of the humans from the energy"

BTW, I really endorse Spiked. Maybe he's very "direct", but...it's just what I've written above: the real problem is "behind" the Net MF project, and MS in general. Many, many, many announces, but nothing concrete. We use to say "lot of smoke and no roast".

I wouldn't bet a single cent on what will be the future, but it's also evident the dramatic change that MS shown after the Nadella leading.

Technically speaking, the Arduino board is not "much" different from the Netduino: they both have a microcontroller (MCU), they both have I/O ports, they both have their own features, limitations, etc.

What's *really* different is the firmware inside, or "what the programmer sees". Arduino offers a minimal 8-bits MCU, with few resources (RAM, flash, speed), thus there's *NO* alternative other than "the programmer must help the machine" (C language or so). Netduino leverages its super-powerful 32-bit ARM core to simplify *A LOT* the development, the debugging and many other things.

A frequent surprise is about the "port toggling frequency": whereas an Arduino can toggle an output in the MHz-order, the Netduino barely performs 100 times lower...and it's a 180MHz CPU!

The most straightful answer should be: write a complete HTTP app (for instance), then let's remake the "comparison".

They DO NOT compare: they're two different approaches, which also may interact.

The Go! idea was nice: use the C#+.NetMF power for the higher level "app", then leave the lowest "physical" level task to a small, inexpensive chip. That's the right way. What I don't like is the "plug-and-play" way of doing that: the hardware is maybe the hardest thing to standardize, and most of the times, as soon you do it, it's already legacy.

However, many users like this way of "glueing" hardware: don't follow my words much, I love hacking hardware.

I don't know much about R-Pi or Galileo, but I think they're different beasts.

Have a look at my blog, there are many examples of Netduino exchanging data with serial, TCP, and to the Azure cloud.

http://highfieldtales.wordpress.com/

Good luck.

Let's say that 6V is borderline: it's barely above the ability of the Netduino regulator. By the way, +12V isn't too much, unless you pull too much current from the Netduino regulator.

I personally suggest any good (linear) regulator which outputs from 7.5 to 12V. However, 9V is perfect.

 

Please be careful - mains voltages can and do kill people!

...

 

Have (safe) fun - Paul

Hence the famous words: "make love, don't make war, and play with mains responsibly"...

That's very nice, but...some questions:

• where are the I/O pins (or else) for sensors and related?
• the Wi-Fi is an option/alternative to Ethernet, or is unavailable?
• could you post an image of the bottom view?

Congrats so far, and good luck!

Very nice, congrats!

To who's reading, this circuit may be useful for current-loop circuit, that is "sending" an analog signal over a very long cable. The more straightforward and intuitive voltage-way leads to pretty high errors.

You should have to post it in the "showcase" category: it seems more appropriate.

A diode is a semiconductor component which allows the current flowing only to one direction:

• when drawn as a symbol, the arrow indicates the direction
• when a real component, there's a striped which indicates the outgoing lead.

However, when the current is flowing there's a small voltage drop across the leads, roughly 0.6V (it's an exponential formula, though).

About what you want to do, consider the internal point where the power is needed: this point is Vin.

Suppose to feed the power through the barrel. Let's say exactly 10V, but there's a diode on the board (D_board), so the Vreg is expected to 10-0.6 = 9.4V. Everything's working fine.

There's a 9V battery connected with a diode (D_bat) to the same Vin point. Now, the voltage on the positive lead is 9V MINUS the voltage on the Vin is 9.4V, yields -0.4V which is lesser than the minimum required for the D_bat to allow the current flowing. That is, under these conditions the battery can't feed any energy, and all the power is given by the barrel.

Now detach the power barrel.

The voltage on the Vin pin WOULD drop to zero, but AS SOON the point falls below 9-0.6=8.4V, the D_bat begins to allow the current flowing. The battery now is the only one feeding energy.

Why 9-0.6=8.4? Because 9V is the battery voltage (on the positive lead) and 0.6V is the drop of the D_bat diode.

NOTE: I used 10V as the barrel voltage to emphasize the circuit's behavior. However, 10V is not a standard voltage for an adapter. If you have a common 9V adapter, you'll experience kinda "challenge" between the adapter and the battery: the one having the highest voltage will actually feed the board. Bear in mind that a new battery has typically a voltage slightly higher than the nominal, but decreases also easily.

I suggest to make some experiment, but if you want to be super-guaranteed there's no "challenges" anytime, just use TWO diodes in series for the battery. At this point the drop is 0.6+0.6=1.2 and the barrel should "win" all the times!

The short answer to the first question is: yes, but...

The long answer is: there is the "Vin" pin on the header which is basically the same as the power barrel pin. However, you can't wire a battery directly to the Vin pin, but you must add a diode in series to the positive lead. The ground of the Netduino should be connected to the negative lead.

The second question leads to a simpler answer.

The current required by a Netduino may span from 50mA to 200mA: it depends on the model, on the state, on the hardware connected.

Then, check the nominal capacity for a 9V battery here: http://en.wikipedia....ne-volt_battery

Finally, divide the capacity by the current flowing.

Let's say you have a Zinc-Carbon battery (400mAh) and the average current for the Netduino is 100mA. You'll have 400mAh / 100mA = 4 hours.

Bear in mind that a more practical result would lead to the time halved or a bit more.

Good luck.

It's on the 11th and 12th of april this year.

See http://www.robotchallenge.org

I won't be able to go this year, but hopefully next year.

Oh!...My chance would be near the end of April, not before.

Definitely better the next year, so I'll take the chance to visit the city once again (really worthwhile).

Cheers

They are a polish team, and I think their bot is C++ based on a homegrown PCB. They have two microcontrollers onboard. One exclusively for sensors, and one for motors.

 

It's just a matter of time: C# will definitely beat C++, and the world will be a nice place to live...(and programming machines will be feasible without brain transplant)
 

In april there'll be a couple hundred robots in Wien for an annual competition. Robotchallenge.org. I haven't been there yet, but can hopefully go next year. 

 

April in Wien? Really? Do you mean this year (2015)? At the end of April I should travel very close to Wien: let me know the details...

Amazing! Very nice indeed...

I know it's a dumb question, but...why they run so fast?

Just another question...who's "Enova"? I mean, which kind of "brain" powers it?

Hello Chris, and have a happy new year, as well as your family.

The led shouldn't be an issue, because the current flowing is low. I'd recommend to keep the SPI speed relatively low, let's say 1-2 MHz max. Also try to keep the SPI wiring short (6 inches max) and, possibly, of the same length (SCLK, MISO, MOSI, SS).

The general rule is: the slower the signals are, the easier will be everything work fine.

Have a nice holidays.

Mario

Very appreciated, thanks.

Just a small note more, although maybe you won't face this case.

You know, the SPI must be "opened" (enabled), and of course can be "closed". When it's closed, the D13 pin (as well as the others involved) can be used as a normal I/O. That is, whenever you set that pin as "input-with-pullup", the led+res act instead as a pull-down. Thus, you should "avoid" this (let's call) collision, because the resulting (floating) voltage may be at an intermediate level, which results in an unstable read.

Again, just an alert than a concrete issue. However, if the led+res were connected to the I2C pin that would have been a very annoying trouble, because I2C leverage the pull-up resistors.

Hope it's clear.

Cheers

The Netduino 2 Plus had some issues related to the SPI, and should have been fixed with the latest firmware.

That was sure for the Netduino Plus 2: not sure about the simpler Netduino 2.

Those issues were mostly related to the worse SPI hardware logic in the ST chip, than the older Atmel.

Second part is on...(scroll to top)

Many thanks everybody, but that's only the beginning!

I'd like to create something funnier, so I'd invite anyone is interested to join.

I know that many of you like robots, buggies, Legoes and other evil machines. The idea is to "connect" those toys to the cloud (for a limited time), and leave them to interact by themselves.

Feel free to suggest what you think and share your opinions.

Have a nice weekend!

Mario

Third part completed...(scroll to top)

Seeedstudio LinkIt ONE board porting completed...(scroll to top)

Tim, I'm 100% with you, but abstraction comes at a cost and Micro Framework tries to solve high-level problems on (relatively) very poor hardware.

Swapping the config is surely cheap in term of computation, but of course leaks in term of abstraction. However, you might think the I2Device as the "I2C logic driver", and the various configs as "instances" of this driver. Such a viewpoint comes maybe a little closer to the abstract-hardware model.

Good luck!

I never tried I2C on Netduino, but it sounds like other ports, which have to be disposed to be reused. This is surely a elegant yet reliable solution, but -agree- not so efficient.

Did you try to swap the configuration instead of creating many instances of I2CDevice?

Uhmmm...

The conversion is rather trivial:

ushort zz = (ushort)System.Math.Tan(c1AngleX);

However, I don't think the "ushort" is a convenient way to store the tangent values, unless they fall with a restrict angle interval.

Moreover, the "ushort" isn't a nice (nor common) type: the "unsigned" types lead to mistakes, unless you check for under/overflow.

Why don't you use "float" instead of "ushort"?

On the regular .Net (desktop) framework I'd use "double" instead of "float", but here you have a tiny board and the resources (CPU and RAM) are precious. Double takes 8 bytes and Single (float) takes 4. Furthermore, the float math should be natively supported, but the "double" not.

Cheers

Very nice, but you'd to file this post under the "Projects showcase" category for better visibility.

Thanks for sharing.

Create a Microsoft Azure application that unlocks the true power behind embedded and connected devices: the web services and applications that actually connect those devices.

Sponsored By

You could use Azure and the CodeProject API to create a mobile web app to keep track of your CodeProject rep points from your phone, or build a webservice that allows a LED on your Netduino board to blink when you get a new message. What about constructing an IoT-powered robot, automating your home or creating a dashboard that connects to your Fitbit to track your fitness? The sky's the limit - suprise and impress us!

Submit an article outlining how you built your Azure IoT app (with code snippets and screenshots) and complete tasks and missions for your chance at loads of cash prizes.

Read here:

http://www.codeproje...oT-Contest.aspx

Good luck to everyone!

Please Chris, make this post as sticky.