A battery with a resistor is not a good idea ... and yes, the pin has to be on - as I said, just use it as an outputport and set it to high.

Using a netduino pin as the 3.3V supply is hacky, but could work (output port, logic level high) - however make sure that you don't draw too much current from it (you don't if you just use it for this level converter). A "clean" solution would involve another regulator like http://www.sparkfun.com/products/526 (make sure you read the datasheet and add the caps if you do that).

Has anyone else dug into the bowels of the CLR to look at atomicity of INT32s vs INT64s? I'd never even thought of this question before...

From partition I of the CLI specification:

A conforming CLI shall guarantee that read and write access to properly aligned memory locations no larger than the native word size (the size of type native int) is atomic (...)

Note: There is no guarantee about atomic update (read-modify-write) of memory, except for methods provided for that purpose as part of the class library (see Partition IV). (...)

Note: There is no guaranteed atomic access to 8-byte data when the size of a native int is 32 bits even though some implementations may perform atomic operations when the data is aligned on an 8-byte boundary.

In the case of the code sample from Mario, Interlocked.Increment would be the tool of choice.

The 500 microsecond delay is supposed to happen after you sent the data, it's unrelated to the frequency (except that it means that you can't use a frequency <= 1khz because then it has 500 µs lows during data transfer). 0xFF means "all bits high", so my random guess is that means that you have some noise/other data on the clock line and your data line is high ... is there anything else connected to the clock pin?

Is the error "random"? Have you tried reducing the clock rate (on a phone right now so I can't look at the datasheet for timing info)?

I might be mistaken, but I think on rev a boards there is no internal connection between aref and 3.3v? And his wiring is without a connection to aref, so it should be rev b.

But it will light, so "it won't work" is a wrong statement. "You should not do it" is a true one. (Also, it's engineers that adhere to specs, scientists test the limits ) To make it clear: I agree with what you said in http://forums.netdui...dpost__p__19163 but I don't agree with you "It is not possible" and "you can not" statements, because it is very well possible - if there is even one case where it does work, "It is not possible" is a wrong statement.

If you want to say "it should be not the normality", then say that and not "it is not possible", because then the scientist in me forces me to find counterexamples

So, you would feed a voltage above the recommended limit? Along this way, we may also feed the ADC inputs of the Netduino with +5V...

The datasheet of the multiplexer explicitely says that it is okay to feed it a voltage above the recommended limit as long as you keep the current down, which is what the pullup resistor does.

Are you saying the datasheet is wrong?


Disregard that, it's talking about negative voltages, not voltages above the limit

Moreover, do you think that would be reliable a I2C-Bus having one or more 5V powered devices, seeing voltage levels of 3.8V?

As I said before, as long as the "logic high" thresholds are below that (and they usually are), why should it not?

Why? I see no reason why it shouldn't work. There's power wasted, yes, but unless you're running on batteries one mA won't hurt you (or your equipment).

Why should it not be possible? The datasheet of the chip says that the switch voltage may be exceeded if the maximum diode current is not exceeded. so the data lines will be @3.8V or something, so as long as the logic high thresholds of each chip is below that, it shouldn't generate problems.

You can use basically all of those for a first adventure into the world of electroncis. The last kit lacks resistors as "basic components", as it also says in the description, so you'll need some of those. However, don't focus too much on those kits - they give you something to play around, but usually if you have a specific project in mind you'll need to go shopping again for the parts. For the first steps, I'd also buy a breadboard (like http://www.cooking-h...breadboard.html) so you have something to put your components on.

Yeah, pretty much, the only thing I think may need a bit of clarification is on the "reset" process... you don´t need any special hardware, when u put 3.3v on the reset pad, and restart the netduino, it will boot from it´s room and u will be able to use the SAM-BA software to upload the native code then. You will not be able to do that before u use the reset pad.

That's what the piece of wire is for

To clarify my previous post - you don't need a special compiler to put any native code on the netduino plus - if you program it "from scratch", you'll have plenty of room. But if you want to modify the netduino plus firmware, you run into space issues unless you use a compiler that is very good at optimizing for space.

You need the expensive tool if you want to fit netduino plus firmware onto the netduino plus, which you asked about. You don't need it for the "regular" netduino, which he uses. Illishar already detailed the software you need, hardware, is, well ...

• A computer
• A netduino
• A USB cable
• A piece of wire

"I have read something on the internet" is a bad base for security considerations. It's true that usually you don't want username in password in the URL, but the reasons for that don't apply in your case. If you want to make this "secure", what you'd need to do is encrypt the stream somehow, I don't know if netduino/arduino do that (.net micro framework in general does have support for ssl streams, i don't know if it's in the netduino plus). Both the query string and the HTTP authentification data are sent in plain text (for plain authentification, which is what you mostly see) in the HTTP request, so that does not make a difference.

The methods you are outlining don't differ in safety. Why do you think the second is safer than the first?

Does the emulator have the memory constraints of a specific device?

Regexes can be really memory-heavy and slow, you just don't notice on desktop computers as much. If you anchor your regex and make the group atomic, it should work.

var regex = new Regex("^\\+CUSD: 2,\"(?>[^\"]*)\",0$"); // Our regular expression

Hi,

Somebody has probably already asked this, but the keywords are so general ("analog", "pin", "power", "ground") that I haven't been able to find it.

The BlinkM documentation suggests that it can be plugged directly into a 'duino. If so, I guess it would be using A2 and A3 as GND and 3.3V. I think I read elsewhere that the Netduino analog pins come up at 3.3V when it is powered on... Is it safe to have 3.3V to the device's VCC and GND? Would it just mean that the device has no voltage potential to operate, but that it wouldn't smoke and that it would begin operating once the A pin connected to GND is set to 0V?

I'd like to make a little standoff that holds sensors off to the side, away from the minor heat island caused by the Netduino. I want to use a strip/vero board with 8 lines, 6 of which will be connected to A0 through A5. Then, with two jumper wires and three cuts, I can connect the two i2c sensors and one analog sensor, but I'd need to use A2 as a 3.3V supply and A1 as ground. If you've ever seen pirates make somebody "walk the plank", that's what I'm doing with the sensors. Ship = Netduino, plank = strip board, pirates = me.

I've thought about alternatives (e.g. sensors dangling from ribbon connectors) but I really have my heart set on having them walk the plank, if I can, and it all hinges on using A2 as 3.3V device supply and A1 as GND for devices. Any reason not to try this?

The device won't smoke, but the netduino will. See http://www.netduino....duino/specs.htm - you're only allowed to draw 2mA per analog pin, your LED will draw more. You'll need to use the "real" 3.3V and ground pins of the netduino.

I just read the DS1307 datasheet for something else and noticed that you don't need a level converter for it. As you already have the breakout, you could just remove the pullups on the breakout and add external pullups to 3.3V - the DS1307 has a logic 1 threshold of 2.2V which is well below 3.3V. So while you power the device at 5V, the data lines can operate at 3.3V "high".

Hi Stefan, see http://forums.netdui...dpost__p__18103 (yes, they are 5V tolerant unless you do analog input with them, however they are not switched to different pins on the MCU like in the case of I2C). Cheers, Stefan

Stefan: I may use some breakout boards because of my morbid fear of surface mount. I've always assumed that surface mount was invented for industrial robots and that I shouldn't attempt it. I suppose I should try it before I write it off, but the BMP085 looks like a lost cause to me:

I also use breakouts for smd-mounted things, however for the logic level converter you aren't restricted to SMD - you can still get transistors in a to-92 package

The mobile version of the forum won't let me edit my post, so I'll use a new one: the reason for this are the high ESR values of electrolytic caps at high frequencies (they are "sluggish"), while ceramic caps have low ones.

Larger is not necessarily better. Try wiring a ceramic capacitor (100nF or so) in parallel to your electrolytic cap.

The protocol it's talking is I2C, you can see some example code using I2C linked in http://forums.netdui...-i2cbus-class/.