Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

If you were to get two netduinos to talk to each other, what would you use?


  • Please log in to reply
23 replies to this topic

#1 bill.french

bill.french

    Advanced Member

  • Members
  • PipPipPip
  • 260 posts
  • LocationPrinceton, NJ

Posted 13 January 2011 - 08:31 PM

If you had two netduinos in very close proximity, what protocol would you use to connect them? SPI, uart, I2C? Something else? Why? I guess I'm looking for what would be the easiest way to do it, and would tie up the least valuable resources.

#2 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 13 January 2011 - 08:48 PM

If you had two netduinos in very close proximity, what protocol would you use to connect them? SPI, uart, I2C? Something else?

Why? I guess I'm looking for what would be the easiest way to do it, and would tie up the least valuable resources.


Over long distances or right next to each other?

#3 Flores

Flores

    Advanced Member

  • Members
  • PipPipPip
  • 64 posts

Posted 13 January 2011 - 08:48 PM

Serial.. by far the easiest.

#4 Flores

Flores

    Advanced Member

  • Members
  • PipPipPip
  • 64 posts

Posted 13 January 2011 - 08:55 PM

Connect pin 1 on netduino 1 to pin 2 on netduino 2, pin 2 on netduino 1 to pin 1 on netduino 2, and connect the grounds.

On the sender:

  1:          public static void Main()
   2:          {
   3:              SerialPort port = new SerialPort(SerialPorts.COM1,115200);
   4:              OutputPort led = new OutputPort(Pins.ONBOARD_LED, false);
   5:   
   6:              port.Open();
   7:   
   8:              while (true)
   9:              {
  10:                  led.Write(true);
  11:                  port.Write(buff, 0, buff.Length);
  12:                  Thread.Sleep(100);
  13:                  led.Write(false);
  14:                  Thread.Sleep(900);
  15:                  buff = Encoding.UTF8.GetBytes(DateTime.Now.TimeOfDay.ToString());
  16:              }
  17:          }

On the receiver:

  1:          public static void Main()
   2:          {
   3:   
   4:              SerialPort serial = new SerialPort(SerialPorts.COM1, 115200);
   5:              serial.ReadTimeout = 8;
   6:              serial.DataReceived += new SerialDataReceivedEventHandler(serial_DataReceived);
   7:              serial.Open();
   8:              while (true)
   9:              {
  10:   
  11:                  Thread.Sleep(Timeout.Infinite);
  12:              }
  13:   
  14:          }
  15:   
  16:          static void serial_DataReceived(object sender, SerialDataReceivedEventArgs e)
  17:          {
  18:              int bytesReceived = ((SerialPort)sender).BytesToRead;
  19:              byte[] bytes = new byte[bytesReceived];
  20:              ((SerialPort)sender).Read(bytes, 0, bytes.Length);
  21:              string received = new string(System.Text.Encoding.UTF8.GetChars(bytes));
  22:              Debug.Print(received); 
  23:   
  24:          }


#5 bill.french

bill.french

    Advanced Member

  • Members
  • PipPipPip
  • 260 posts
  • LocationPrinceton, NJ

Posted 13 January 2011 - 09:04 PM

Very close distance. Serial is definately easy. I guess my one concern with serial is that there's only two uarts, and point-to-point, so they are kind of "precious". Hmmm....

#6 darkSol

darkSol

    Member

  • Members
  • PipPip
  • 13 posts

Posted 13 January 2011 - 09:57 PM

I'd personally prefer to leave the serial UARTs open and free for talking to other things. My personal vote would be I²C... I could see a NetduinoPlus (with Ethernet) acting as Master, the other Netduino(Minis?) acting as data-retrieving/analyzing slaves... That would be kickbutt! ;) -David

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 13 January 2011 - 10:03 PM

I'd personally prefer to leave the serial UARTs open and free for talking to other things.

My personal vote would be I²C... I could see a NetduinoPlus (with Ethernet) acting as Master, the other Netduino(Minis?) acting as data-retrieving/analyzing slaves... That would be kickbutt! ;)


I2C is master-only in both .NET MF and on the Atmel ARM microcontroller. SPI is master-only in .NET MF, but we could add SPI slave support if there is demand (since the microcontroller supports it).

Chris

#8 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 13 January 2011 - 10:10 PM

Very close distance. Serial is definately easy.
I guess my one concern with serial is that there's only two uarts, and point-to-point, so they are kind of "precious". Hmmm....

Well, there are not really many options left besides UART: SPI is easy and fast (full-duplex), but the current implementation of .NET Micro Framework supports only Master mode, and two Masters cannot talk to each other, SPI communicates in master/slave. Similarly for I2C, the microcontroller can be programmed as either master transmitter or master receiver, not a slave.

Note regarding UART speed: You should be able to setup communication at rather high baudrates (much higher than usual 115200 bps), the microcontroller max baudrate is MasterClock/16, where MasterClock = 48*10^6 (48 MHz), 16× oversampling.

#9 Illishar

Illishar

    Advanced Member

  • Members
  • PipPipPip
  • 146 posts

Posted 14 January 2011 - 07:58 AM

SPI or I2C is usually the prefered "interboard" communication. But if Netduino doesn't support Slave SPI ... it's a pity really.

#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 January 2011 - 08:31 AM

SPI or I2C is usually the prefered "interboard" communication. But if Netduino doesn't support Slave SPI ... it's a pity really.


I think Slave SPI would be an awesome addition to the Netduino firmware. We purposefully exposed the slave chip select line on both Netduino/Netduino Plus and Netduino Mini. There's a shield we're thinking about building later this year that would need it...but otherwise we haven't heard many requests for the community for support.

If you think Slave SPI would be super-useful, please say "aye" :) We need to finish up v4.1.1 first but this could make an interesting v4.1.2/v4.1.3 feature.

Chris

#11 Illishar

Illishar

    Advanced Member

  • Members
  • PipPipPip
  • 146 posts

Posted 14 January 2011 - 12:06 PM

Aye :P

From what I know of SPI, it's not that different from master, so it ought to be an easy fix.

I hope.

We need to finish up v4.1.1

Mmmmmmm ... finished up 4.1.1. Do you have a 'roadmap' or something somewhere?

#12 JonnyBoats

JonnyBoats

    Advanced Member

  • Members
  • PipPipPip
  • 155 posts
  • LocationPhillips, ME

Posted 14 January 2011 - 01:08 PM

I think Slave SPI would be an awesome addition to the Netduino firmware. We purposefully exposed the slave chip select line on both Netduino/Netduino Plus and Netduino Mini. There's a shield we're thinking about building later this year that would need it...but otherwise we haven't heard many requests for the community for support.

If you think Slave SPI would be super-useful, please say "aye" :) We need to finish up v4.1.1 first but this could make an interesting v4.1.2/v4.1.3 feature.

Chris


AYE!

#13 darkSol

darkSol

    Member

  • Members
  • PipPip
  • 13 posts

Posted 14 January 2011 - 03:43 PM

If you think Slave SPI would be super-useful, please say "aye" :)


Aye aye mon capitan! ;)

#14 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 14 January 2011 - 04:38 PM

Aye!

#15 AlfredBr

AlfredBr

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationConnecticut, USA

Posted 14 January 2011 - 05:59 PM

Aye

#16 Matthew Kennedy

Matthew Kennedy

    New Member

  • Members
  • Pip
  • 1 posts

Posted 14 January 2011 - 07:26 PM

Aye!

#17 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 January 2011 - 08:48 PM

Well it looks like there's some interest :) What kind of applications would you folks use it for?

I'll take a look at the internal roadmap and see where we can squeeze this in.

[Illishar: yes we do have a roadmap but we don't publish it since we want Netduino to be community-driven. Generally our development priorities are, in order: [a] Netduino and .NET MF bugfixes; [b] incorporation of community (requested/contributed) features; [c] incorporation of Secret Labs features. A lot of the new Secret Labs features come from the other side of the business (building and/or managing products for other companies) and when possible we build them on our own time and then contribute them both to customer projects and to the open source codebase.]

Chris

#18 Illishar

Illishar

    Advanced Member

  • Members
  • PipPipPip
  • 146 posts

Posted 15 January 2011 - 12:37 PM

What kind of applications would you folks use it for?

Slave SPI is just the other end of the wire. And it's very well suited for communication between processors. Which is a rather common scenario. (Pick up some random piece of electronics and take a closer look. Most likely you'll be able to find more than 1 processor.)

#19 Illishar

Illishar

    Advanced Member

  • Members
  • PipPipPip
  • 146 posts

Posted 15 January 2011 - 01:16 PM

we do have a roadmap but we don't publish it since we want Netduino to be community-driven

Nothing good has ever come from uncontroled development. A prioritized todo list would let us know when to expect a given feature. And it would enable the community to volunteer for assignments that are 'far away'.

If we make up our own assignments it'll most likely just result in a waste of our time. Eg. say that some 'inexperienced member' decided to contribute a OneWire driver of his own devise. The result most likely wouldn't comply with things like proper coding rules, existing netmf guidelines and it'll likely be completely useless. And yet this is the most common kind of contribution to any given open source project. A polite response to this is often just to ignore it and take a look on a new OneWire driver 'whenever we get the time'. And after a time, this just become the default response to all contributions.

If you want help from the community have the decency to supply and organize the assignments, so that we'll know that our work will be used, reviewed, tested and distributed.

#20 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 15 January 2011 - 07:44 PM

Good points, Illishar. I really appreciate your enthusiasm. Once we get everything organized on CodePlex, we'll be able to start taking community member contributions in a more organized fashion. As you mentioned, the last thing we want is for community members to contribute and then have their work unused/ignored. Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.