I’m setting up serial communication between 2 FEZ boards (using Com1 on the Panda, and Com3 on the Cobra). I’m having a bit of trouble in finding a way to make communications reliable, meaning, if FEZ A is down, FEZ B should know this and wait with sending data till FEZ A is back alive. (and the other way around too)
Any idea how I can accomplish this?
The data that is being send over is plain text.
I also suppose both boards need to share common ground?
You could have two lines running between the boards. As long as the boards are one, the lines are high. That way, if one board goes down, the line will go low and the other board will know that.
Otherwise, I don’t think there is a better solution for dealing with unexpected shutdowns.
I don’t know if your communication is high speed but if its not then you could add a checksum response.
So FEZ A starts sending a string of text. XOR every character to calculate a checksum like the NMEA is doing. When FEZ A is finished transmitting it sends a stop character like linefeed and waits for FEZ B to return the checksum for validation. Then you know that FEZ B got all that FEZ A sent and all is well. Else resend the last transmission.
Use hardware handshaking. Each FEZ has at least one COM port with this feature.
Of course additional signals should be connected RTS/CTS?
Could also pass a heartbeat message over the serial port. Also would need some type of ack message to avoid race conditions.
You need to use some kind of serial communication protocol. Xmodem (like FEZ uses for uploading new firmware) or Zmodem will work over a serial connection with a transmitter on one board and a receiver on the other. If you want to go both directions, you’ll need to use two serial ports- one for transmit and one for receive on each side.
If you really need to send serial data in both directions simultaneously over a single serial port, you need to look at a TCP/IP-over-serial protocol like PPP or SLIP. Both are quite complex. If you can use two serial ports as I mentioned above, the software becomes much simpler.
Hardware handshaking using CTS/RTS etc can pause a transmitter when the receiver cannot respond (for whatever reason), but the transmitter still doesn’t know if data was received error-free on the receiver.
On a related subject, does anyone know if there’s a way to send (or handle reception of) a ‘break’ condition on a serial line? A ‘break’ is a sustained high line state, impossible to transmit by any sequence of characters. Hence it can be differentiated from garbage data received when the receive data rate is not at the same as the transmit data rate. Breaks are often sent between two serial communication endpoints to help negotiate common baud rates.
Any hardware UART worthy of the name should be able to send a break, and somehow signal the host when one is received. I’m sure the CPU’s UARTs can do this, but I don’t see how via the NETMF or GHI serial APIs. I guess the only way to send a break would be via native code.
I do not think the processor’s uart supports break
UARTs 0, 2, 3 do- setting bit 6 of their Line Control Registers sends a break. (See table 356 page 420 of [url]http://www.keil.com/dd/docs/datashts/philips/lpc23xx_um.pdf[/url]).
The reason I’m interested in sending a break is to implement a UART-assisted One-Wire interface as described in [url]Mixed-signal and digital signal processing ICs | Analog Devices. The Maxim DS2480B simplifies this task, but Maxim’s reference software driver requires the ability of the UART to send a break to reset the bus. (See page 3 table 3 in [url]http://pdfserv.maxim-ic.com/en/an/AN192.pdf[/url].)
@ Eric
I use a similar connection in one of my projects. I send 12 bytes from Point A and acknowledge with a single character with Point B… After about 4 seconds if the ack never comes, you then send a reboot sequence. from Point A
Its a simple software time out but it works extremely well . You wont send a reboot (obviously! too long to reboot on tinyclr )… but you will re-sync the transmission!!
Three wires Rxd Txd and Gnd, Gnd IS common.
Cheers Ian
Thanks to all who provided ideas.
IanR, I thought it all over again and came to the conclusion that it is better (for the time being) to have the Cobra ask the Panda for the data. That way, the Panda doesn’t care if the Cobra is down, and can continue with what it is meant to do. Anyway, I’m still interested in you solution (for future reference), do you mind sending me your code (relevant parts of course) to eric.vdb at gmail ?
Thanks again.
Greetings
Eric
Certainly
But you must remember I do most of my projects on a pic in C But its not difficult to swap to C#
Cheers Ian
P.S I noticed this thread getting side tracked from what you originally asked. thats why I posted
Can CAN (Controller area network) be used for this? Isn’t that what the protocol was designed for?
[url]http://en.wikipedia.org/wiki/Controller_area_network[/url]
According to the comparison document all of the FEZes can do CAN.
-Eric
I looked into CAN but it seems way too complicated for what i need it.
On the AVR, perhaps, but on the FEZ it is amazingly easy to implement. All you need is a MCP2551 IC (8-pin DIP), 2 like-value resistors for creating a voltage divider for VREF, and 120 ohm resistors for bus termination.
I implemented a CAN device in about 5 minutes with FEZ, reading data from an existing CAN bus so I know it works 
Plus, you can safely physically separate and “hot plug” devices into the bus
A better I2C stack with slave support may be helpful to the cause, too.