If you were to get two netduinos to talk to each other, what would you use?
#1
Posted 13 January 2011 - 08:31 PM
#2
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
Posted 13 January 2011 - 08:48 PM
#4
Posted 13 January 2011 - 08:55 PM
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
Posted 13 January 2011 - 09:04 PM
#6
Posted 13 January 2011 - 09:57 PM
#7
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
Posted 13 January 2011 - 10:10 PM
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.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....
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
Posted 14 January 2011 - 07:58 AM
#10
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
- JonnyBoats likes this
#11
Posted 14 January 2011 - 12:06 PM
From what I know of SPI, it's not that different from master, so it ought to be an easy fix.
I hope.
Mmmmmmm ... finished up 4.1.1. Do you have a 'roadmap' or something somewhere?We need to finish up v4.1.1
#12
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
Posted 14 January 2011 - 03:43 PM
If you think Slave SPI would be super-useful, please say "aye"
Aye aye mon capitan!
#15
Posted 14 January 2011 - 05:59 PM
#16
Posted 14 January 2011 - 07:26 PM
#17
Posted 14 January 2011 - 08:48 PM
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
Posted 15 January 2011 - 12:37 PM
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.)What kind of applications would you folks use it for?
#19
Posted 15 January 2011 - 01:16 PM
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'.we do have a roadmap but we don't publish it since we want Netduino to be community-driven
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
Posted 15 January 2011 - 07:44 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users