Yes. It is a brokered message passing system. Strikes me as identical to ROS internal stuff.  Clients subscribes to topics, and clients can publish topics. Either side can be a client.  I ran both directions in simple tests, at the same time.  Master asked for an update by publishing a request.  Slave (Netduino) published accelerometer data via a JSON string.  I'm not sure if there was a 'reply' to publish supported, as in a blocking publish, but I don't think you would want that anyhow, on loosely coupled systems.

BTW, I was unable to get the micro frameworks supplied DPWS samples (mf version of wcf) to run. It looks like they encountered an error in the MF implementation - multicast udp not supported?.  It seems to me that you should able to get around that not using 'discovery', but I did not want to spend much time on it just to run into the next problem, and no one spoke up and said it would work.  M2Mqtt worked first try, seems to be currently actively maintained, I was impressed.

Other projects I ran across had not seen activity in years, and maybe that is because they work and don't need fixing, but that is seldom the case in my experience.  I got the popular web server to run after a few code tweaks, but I would end up just making it look like M2Mqtt anyhow.

I will go look at some of those links posted in a minute, but a quick note first;

There are jobs at Microsoft, whose entire description is Evangelize. People in these positions make incredible enthusiastic presentations of products, as is their job. But unfortunately it in no way reflects management directions.

Measure not what is promised, but what is delivered. The lateness of the Windows on devices would (does) have me a bit worried. How it is handled may well define the concepts viability.

Wild guess since I do not have any of the pieces, but I suspect changing the motor mode and speed over and over again as fast as possible might have unintended consequences.

Try setting them both, sleep 1 second then set speed to 0; get rid of the while loop.  If that works you need to rethink your logic.

That will get you going, but down the road keep in mind there is a reason logic voltage and motor voltage are usually kept apart. There are several ways to accomplish isolation, one the easiest/best being 2 different batteries.

The problem is, in some configurations the motor pull can drop the voltage below what the logic can tolerate, even if just for a microsecond the results can be bad. Also motors, being mechanically/electrically connected (brushes sparking) tend to introduce 'noise' on the circuit and cause all  kinds of hard to find problems.

Again, hook it up as you described, see if it works, then think a more permanent solution.

Motor speed 8 may be too low. My motors generally do not start until around 30 or so. Stick with 50 for now.

Other than that, perhaps take a pic to show your wiring. Maybe someone who has the device can spot an issue.

mqtt is used separately for m2m.

The important thing to realize is you can allocate 1 i2c, then switch configs;

....a handfull of examples I came across which all appearantly did things the wrong way.....

Wait until you look into ultrasounds. I have yet to see a single example on the entire internet, arduino or anything else, done correctly :|

What sensor(s) are you using? Curious if you could 'charge' all 3 at the same time to save some time.

There is no doubt and Arduino without any sort of firmware will be faster than a .Net managed device, but my experience is my Netduino can always be fast enough for me. 

I had pretty good luck with a 9 DoF IMU, which was 3 i2c devices with 6 bytes of data each - similar data size to your application. I ended up switching to an mpu6050 that does all the math on chip, and lowered the complexity immensely. In the end it took like 2 real lines of code to do 3D rendered AHRS.

.Net  is an interpreted Managed language.

As such there are a few things you should not do if you want efficient code.

Note that efficiency was not a goal of .Net, robustness was. That doesn't mean you can not be efficient, you just can not go throwing around features that were intended to protect you from yourself, and expect efficiency.

In your main loop, you re-allocate (using) a i2c device 3 times every loop. That has to be cleaned up by the garbage collector. Allocate it once outside the loop, then re-use it.

Same can be said for your transactions.  There is NO reason to re-create 9 (or worse as I looked more, you are doing bytes?) of them every single loop.  Creating new objects is not free, nor is disposing of them when no longer being used (every loop in this case).

I posted an article a while back when I first started playing with the Netduino, showing an efficient way to talk to an i2c IMU; http://www.spiked3.com/?p=421

The code in the next post show multiple devices, so look at it also; http://www.spiked3.com/?p=438

Bottom line;  Think every time you use 'new', and if it is appropriate. Do not just copy someone else's code without understanding it.

As far as I know .Net in general checks every array access to make sure your index is in bounds.

Making some of your data a plain byte, versus new byte[1]   may help quite a bit.

You are pretty close to that now. The wait function you posted, is close. But instead of (reading and) setting wait_Flag in this routine, set it in an interrupt routine as described in my last post.

Yes, you can make a nice little class out of it, but you'll have to make arrangements for multiple wait flags, one for each pin/switch maybe. You will have to do a little exploring on your own, you learn so much more that way.

If you do get stuck, follow up with questions. BTW, looking at your code, you are doing fine for a newb

I didn't know that CW2. Somewhere I read the timing could be off by 4us, so I kind of guessed at the rest.  I guess it also depends on what you consider low level code, as pin logic certainly could be considered really low level code, but you're right it was not what I was thinking.

Is there any reason to re-use an event handler other than to save memory, and we are talking about a very tiny routine as discussed.

Hopefully, you have some UI experiences with message pump applications, like windows.  Think mouse buttons. You get an event mouse down, a different event for mouse move, and yet another for mouse up.  

You can tie any digital pin as an interrupt with the netduino (to my knowledge) as its not really an interrupt but a flag to the low level code to poll the pin and post an event at level change, and this appears to your code as an interrupt event and the actual event is time stamped with the actual poll time, so while your code may not get it exactly when it happens, you do get a good timestamp of when it happened. At least this is my understanding, and so far has worked out.

With that in mind you do the same, post as a mouse/button down event up a level, and in your code check to see if that event occurred. Dont forget to indicate that the event has been 'handled' if appropriate, and dont forget to take the proper action, for mouse/button down and mouse/button up.

Quick look at your above code; make Wake_SW global. in a level high interrupt, set it to true. When you handle it in code do not forget to reset it to false. Also if you are not doing both level down and up, you need to re-enable the interrupt each time it occurs.

If I have any of this wrong, please someone jump in, but I think this is the way it works.  I'm using 2 motors, 2 interrupt pins per motor (ie 4 interrupts) and I think it is doing ok reading encoders (now, after a lot of experiments). I get some jitter determining speed, but I think that is just frequencies not being perfectly aligned (motor encoders vs firmare polling), so I smooth them out. At least until somebody explains otherwise to me. To my knowledge, I am not losing any interrupts, just getting the velocity jitter, when the motion is smooth.

Perfect, thanks for that. I have a feel for the grey line between hardware and software having worked some with the microcode interpreter that makes an IBM system 370 run (the good old days). I'm sure that idea has carried forward, but I am not intimately familiar with it anymore, like I was.

Great explanation on why on the single interrupt handler. My code currently wraps threads in objects, so I sort of accomplish the same goal (re-entrant single code instance), albeit a slightly different path to get there (the encoder stuff).

I always thought it was kind of a cool idea, but never had a reason to use it;

https://www.sparkfun.com/news/1527

Assuming you have internet connectivity, since you mentioned Azure, I suspect you do.

I use MQTT, which probably makes more sense, but not as much fun since I already know it

https://m2mqtt.codeplex.com/

Dang, I looked at your code and totally missed your commenting system, my bad.

In that case you are missing some needed, I call it coffee code;

 // required i2c kick
            OutputPort p = new OutputPort(Pins.GPIO_PIN_SDA, true); p.Write(false); p.Dispose();

throw that near the beginning of main.

I am also using the ADXL345, on a 9DoF board.  I seemed to remember not getting anything out of it without sending some config to the device - and you do not appear to have any (not totally sure, it was one of the devices, but memory on which one isnt quite 100%)

I'm not sure why your one device works without 'coffee', at least its worth a try.

My experience was you could not access different devices on the bus like that. Granted I'm a newb, but after digging I finaly came up with just setting a different device config, and not creating separate instances.  Some of the 'generic' code I've seen published tried to abstract this, although I prefer to do it myself.

Here is a code extract illustrating what I am saying;  I may be totally wrong, if I am, some please tell me.

 I2CDevice.Configuration accellConfig = new I2CDevice.Configuration(0x53, 400),
               gyroConfig = new I2CDevice.Configuration(0x68, 400),
               MagnConfig = new I2CDevice.Configuration(0x1e, 400);

            I2CDevice i2cBus = new I2CDevice(null);
            System.Threading.Thread.Sleep(20);

            // devices initialize
            i2cBus.Config = gyroConfig;
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x16, 0x03 << 4 | 0x04 }) }, 100);
            System.Threading.Thread.Sleep(5);
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x15, 0x07 }) }, 100);
            System.Threading.Thread.Sleep(5);

            I2CDevice.I2CTransaction[] gyroTrans = new I2CDevice.I2CTransaction[] {
                I2CDevice.CreateWriteTransaction(new byte[] { 0x1D }),
                I2CDevice.CreateReadTransaction(tmpBuf)
            };

            i2cBus.Config = accellConfig;
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x2D, 0x08 }) }, 100);
            System.Threading.Thread.Sleep(5);
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x31, 0x08 }) }, 100);
            System.Threading.Thread.Sleep(5);

            I2CDevice.I2CTransaction[] accelTrans = new I2CDevice.I2CTransaction[] {
                I2CDevice.CreateWriteTransaction(new byte[] { 0x32 }),
                I2CDevice.CreateReadTransaction(tmpBuf)
            };

            i2cBus.Config = MagnConfig;
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x00, 0x70 }) }, 100); // 8-average 15hz
            System.Threading.Thread.Sleep(5);
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x01, 0x0B }) }, 100); // gain 8.1
            System.Threading.Thread.Sleep(5);
            i2cBus.Execute(new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(new byte[] { 0x02, 0x00 }) }, 100); // continuous
            System.Threading.Thread.Sleep(5);

            I2CDevice.I2CTransaction[] magnTrans = new I2CDevice.I2CTransaction[] {
                I2CDevice.CreateWriteTransaction(new byte[] { 0x03 }),
                I2CDevice.CreateReadTransaction(tmpBuf)
            };

            // main loop
            // gyro and magno are reverse endian order and need to be corrected
            for (; ; )
            {
                byte t;
                long thisTick = DateTime.Now.Ticks;
                Rb.dt = (uint)(thisTick - lastTick);        // better be a uint or we got problems!

                i2cBus.Config = accellConfig;
                i2cBus.Execute(accelTrans, 100);
                System.Threading.Thread.Sleep(5);

                Rb.ax = BitConverter.ToInt16(tmpBuf, 0);
                Rb.ay = BitConverter.ToInt16(tmpBuf, 2);
                Rb.az = BitConverter.ToInt16(tmpBuf, 4);

                i2cBus.Config = gyroConfig;
                i2cBus.Execute(gyroTrans, 100);
                System.Threading.Thread.Sleep(5);

                for (int i = 0; i < 6; i += 2)
                {
                    t = tmpBuf[i]; tmpBuf[i] = tmpBuf[i + 1]; tmpBuf[i + 1] = t;
                }
                Rb.gx = -BitConverter.ToInt16(tmpBuf, 0);
                Rb.gy = -BitConverter.ToInt16(tmpBuf, 2);
                Rb.gz = -BitConverter.ToInt16(tmpBuf, 4);

                i2cBus.Config = MagnConfig;
                i2cBus.Execute(magnTrans, 100);
                System.Threading.Thread.Sleep(5);

                for (int i = 0; i < 6; i += 2)
                {
                    t = tmpBuf[i]; tmpBuf[i] = tmpBuf[i + 1]; tmpBuf[i + 1] = t;
                }
                Rb.mx = BitConverter.ToInt16(tmpBuf, 0);
                Rb.my = -BitConverter.ToInt16(tmpBuf, 4);
                Rb.mz = -BitConverter.ToInt16(tmpBuf, 2);
                
                string json = JsonSerializer.SerializeObject(Rb, DateTimeFormat.Default);
                client.Publish("/RoboNUC/Netduino/ImuData", System.Text.Encoding.UTF8.GetBytes(json));

                lastTick = thisTick;
                System.Threading.Thread.Sleep(35);  // + 3 X 5 ms = 50ms sleep total = approx 20hz
            }
        }

BTW - the code running; 

It is hitting 3 devices on the same bus

Glad you're running!

Cool. What is the setup? Looks like a bluetooth xbee or something on a ??? I have no idea.

Did you write the i2m app? Windows phone sdk I assume?  BLE?  I'm such a newb.

Anyhow thanks, very cool.

I'd agree on using the hardware mac address first.

But if that is something you can not do, try setting it before you ask for a dhcp address.  Otherwisee mac '1234' ask for an IP address, then changed itself to '5678'  - it will never receive a reply.

Looks like it was developed against 4.1 and trying to deploy to a 4.2 loaded device.

Make sure you are referencing 4.2 in your visual studio project.

Which is really bad if you thought you were using 4.3.  Might want to take another go at it, un-install all of the PC stuff and start again.

If it also fails on com2, it almost certainly would be an electrical problem to me, as CW2 suggests. I suspect many of us do not even have PC's with RS-232 serial ports any longer, I know I do not.

Since you and your friend both have Netduinos, a netduino to netduino test might shed some light.

N/m putty.  Baud mismatch maybe?

Isn't there some concern using com1 while the debugger is running? I thought you had to jump through hoops to get it to work at all, so I've always just used ethernet.

A walkthrough of the User Interface

http://www.spiked3.com/?p=1221

re intermatic: lol, yes I'm a bit handicapped, and just plain lazy. I've had this or X10, for like 15 years, I don't know how people live without them. And, I'm shocked the idea has never caught on enough to bring prices down.

I'm trying not to spend my all of this months retirement check, so I can get the Seeed LIDAR, the holes are there  My overall goal for this project is to learn SLAM, and be able to task level autonomously navigate.  I got the last robot to that point but, the Roboard-110 made too much RF noise for the GPS to ever get a fix, so I gave up on it being intelligent. I could task level tell it to move, but without encoders or GPS, I couldn't tell it where. Since I'm a little more handicapped now, I also knew that I should start thinking more indoor than outdoor, thus this bot.