1
\$\begingroup\$

Previously I have asked about running I2C over CAN PHY over Cat5e cables for my home automation project. Now after a round of money saving and experimenting, it seem to me that abusing RS485 chip MAX1487 may be a cheaper idea than I2C-over-CAN. Now I need a protocol to allow the host device (with Ethernet) and satellite nodes talk with each other.

Environment

The environment is the same: Cat5e in very hostile alien crosstalk environment, cable already have RJ45 crimped on in TIA/EIA-568-B pinout, and budget is very tight. So is this a suitable pinout that carries both power and signal to the target device:

  1. N/C
  2. N/C
  3. D+
  4. +5V
  5. +5V
  6. D-
  7. GND
  8. GND

Also an extra constraint: all chips used here MUST be available in DIP package. Preferred MCU for me is ATtiny85 for the satellite nodes and ATmega328P for the node with Ethernet access.

Physical layer

And since all devices in the system have some kind of MCU in it, I can make the bus talk peer to peer. However I do need to avoid collision. Will this physical protocol and collision avoidance scheme work:

  1. Talk using RS485 physical layer chip MAX1487 at UART baud rate 9600bps and 8/N/1.
  2. Resistive bias/termination network makes the line float at 1. Drive the bus only when sending 0 (since MAX1487 can tri-state its drivers.)
  3. Talk when the bus is idle, a.k.a read as 1, for at least 5 bit of time.
  4. Read every sent bit back immediately after transmitting, as well as before transmitting the next bit. Whenever a mismatch is found, abort transmission and back off for a pseudo-random amount of time before retransmitting.
  5. First transmission of every node that just come online have to be delayed use the same pseudorandom backoff time as collision backoff.

Talk here means drive the bus. I chose the MAX1487 chip that can have its transmitter turned off when not used. Normal bias network:

schematic

simulate this circuit – Schematic created using CircuitLab

Link layer

And since it is multidrop, some kind of addressing have to be used, which leads to this framed protocol:

Frame format (using C structure syntax):

struct frame {
    uint16_t magic;          // = 0x55aa
    uint16_t source_address;
    uint16_t target_address;
    uint16_t payload_type;   // Like EtherType
    uint16_t payload_length; // Exclude padding, if any
    uint8_t  payload[];      // Padded to 2-byte boundary
    uint16_t checksum;       // CRC16 of entire frame before this frame
}

Source and target addresses are hard coded into the chip, either during programming, or use some chip-specific value during manufacturing like the AVR's RC calibration value. Target address 0xffff means broadcasted frame.

Questions

  1. Will this protocol be good enough as a home automation controlling protocol?
  2. Will this protocol be able to be extended into carrying IPv4 or IPv6?
\$\endgroup\$
  • \$\begingroup\$ Your edit still doesn't make clear that what you're planning on doing - I think - is to use "driven" as 1 and "idle" as 0, which isn't really RS485. What was wrong with CAN PHY, which is specifically designed for collision detection? \$\endgroup\$ – Nick Johnson Apr 26 '15 at 19:00
  • \$\begingroup\$ @NickJohnson I think the bias network is very clear - when the line is idle it reads 1, and since MAX1487 can have its driver turned off only 0 is sent by driving the line (and a floating line means 1) CAN PHY chips can be a bit expensive here (US$1/each, but MAX1487 costs US$0.05/each) \$\endgroup\$ – Maxthon Chan Apr 26 '15 at 19:03
  • \$\begingroup\$ The bias network is clear, yes, but RS485 drives both high and low, not just low; see en.wikipedia.org/wiki/RS-485#Waveform_example for an example. What you're proposing is not RS485, it's a variant. \$\endgroup\$ – Nick Johnson Apr 26 '15 at 19:18
  • 1
    \$\begingroup\$ I2C allows multipoint in part because there is one master which addresses each slave. You could do a similar thing with the MAX1487. Have your master send out a packet on the bus addressing a particular slave, giving it permission to start broadcasting. Then as soon as it is finished it must stop sending anything and switch back into receive mode. That way you can never have any contention as long as every slave has a unique address. The master can poll each device in a loop. If the slave has nothing to say it can send a NOP packet or something. \$\endgroup\$ – Tom Carpenter Apr 26 '15 at 19:19
  • \$\begingroup\$ @NickJohnson I just edited the post to make it clear that I am not exactly using RS485, but abusing a RS485 chip into talking like CAN. What I am doing is to make MCU's talk peer to peer over one twist pair of Cat5e under harsh alien crosstalk. \$\endgroup\$ – Maxthon Chan Apr 26 '15 at 19:20
1
\$\begingroup\$

RS-485 is a poor choice of protocol with multiple masters. Unlike CAN, it does not have 'dominant' and 'recessive' states - 1s and 0s both involve driving the bus. Thus, a collision results in both devices driving the bus to opposite states, sourcing and sinking as much current as they can handle. The resulting voltage will depend on the drivers' relative strengths, and won't have a well defined value; indeed, each device may read a different value.

Have you considered using ethernet? You can define your own protocol on top of it, as well as carrying IPv4 or IPv6 if you wish.

\$\endgroup\$
  • \$\begingroup\$ I have considered ethernet but W5100 is too expensive while ENC28J60 does not work well with ATtiny85 which is a real small MCU. In my protocol "talk" means drive the bus - the drive chip I chose, MAX1487, can have its driver turned off. By default, D+ is pulled high and D- pulled low, with 100Ω impedance across lines. \$\endgroup\$ – Maxthon Chan Apr 26 '15 at 18:51
  • \$\begingroup\$ You need to explain that in your question then. In that case you're not really using RS-485. \$\endgroup\$ – Nick Johnson Apr 26 '15 at 18:52
  • \$\begingroup\$ It's also difficult to answer questions with hidden constraints. What's problematic about interfacing an ATTiny with ENC28J60? \$\endgroup\$ – Nick Johnson Apr 26 '15 at 18:53
  • \$\begingroup\$ Not ATTiny in general, ATtiny85 in particular. It is just too small to drive ENC28J60 which needs 4 I/O lines (and all ATtiny85 have is 5) I have also edited my question to make it clear that all chips used must be in DIP packages and obviously ENC28J60 is not. \$\endgroup\$ – Maxthon Chan Apr 26 '15 at 18:56
  • \$\begingroup\$ That's a significant hidden constraint that you need to explain in your question, then. \$\endgroup\$ – Nick Johnson Apr 26 '15 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.