A little networking humor explained ...
The Gator board (Arudino compatible) is the Master Node 0 in the Master/Slave (half/duplex) network configuration.
The LIN bus (Automotive "Local Interconnect Network") is modified for use for the Arduino/Freeduino network.
My KIRSP Protocol 1.0b "Keep IT Real Simple Protocol" is the communications network protocol software for all the nodes.
All Slaves are controlled by the Master node 0.
From the picture(s) below:
Node 0 ---> Rugged Cicruits Gator with 2 hardware serial ports running at 20 MHZ. (324P) (Green PCB)
Node 1 ---> Evil Mad Scientist quick protoboard. (328P) (20 ma idle draw) (Black PCB)
Node 2 ---> Modern Device BBB board stripped down. (328P) (20 ma idle draw) (White PCB)
Node 3 ---> Protostack development board (dirt cheap) from Australia (328P) (20 ma idle draw) (Red PCB)
Nodes 4-15 ---> Not connected due to "lack of funds"
<Thats it, I am running out of my Arduino/Freeduino development boards for slave nodes this project!>
Picture Notes:
All nodes are crystal controlled ---> NO ceramic resonators which can drift with temperature.
Only one dirt cheap unregulated power supply is needed to drive the whole LIN bus.
The master is driven via USB power and the slaves via 50 ma. 5 VDC regulator on each LIN node supplies the power.
Low cost Ethernet "patch" cabling connects each node on the LIN bus. It carries the Power/Ground/LIN bus signals.
40 meters max.
The Gator sketch software is uploaded via USB. The second Gator hardware serial port is connected to the LIN bus board.
This makes it extremely easy to debug networking problems.
All the Slaves are uploaded by attaching a FTDI cable or Modern Device BUB board and dis-connecting each LIN bus / slave
interconnect cable.
On each LIN Bus board there are 3 low power LEDs for Tx, Rx and LIN fault.
On all nodes have the pin 13 red LED that is used to indicate configuration errors, good data and diagnostic errors.
<Helpful hints and tips networking Arduinos/Freeduinos>
Unless you have an expensive communications anaylzer ... here is a few tips and hints in networking Arduinos/Freeduinos.
#1. Have the Master Arduino network main board with 2 or more serial ports. (Mega [4] or Rugged Circuits Gator [2])
This will speed troubleshooting and by using one serial port for the network and the other for uploading. This
helps speed up development time.
#2. All network nodes should be crystal controlled as opposed to ceramic resonators. (Precision baud rate timing)
#3. Use only "hardware serial ports" instead of software serial ports.(Hardware works much better than software UARTS)
#4. Have a 5 vdc buzzer to indicate the reset startup sequence. (Helps troubleshooting)
#5. Use only low power LED indicators 2 ma or less to indicate communication error status or TX/RX status.(Save power drain)
#6. Use the FREE internet "RealTerm" serial port anaylzer program for serial troubleshooting.(Saves troubleshooting time)
#7. Error checking is a requirement. My design used CRC-16 error checking. If it is good enough for disk drive
manufacturers to use then it should be good in networking Arduinos/Freeduinos.
#8. Since the LIN Bus uses a Master/Slave configuration (half duplex) along with RS485, then having a "resource heavy Master"
micro controller which has the speed, I/O, serial ports and memory to poll the many slaves in the network is a requirement.
I chose Rugged Circuit's 2 hardware serial port "Gator" 324P board which runs at 20 MHZ which has the same memory as the
328P. The next step up would be the 4 port Mega Arduino at $26 more in cost.
<Design Problems (all fixed)>
#1. Designing an easy to use network protocol for the Arduino/Freeduino.
#2. Finding the best, easy to use, low cost bus transceiver -> LIN. If it works well in the harsh environment of an
automobile then it should work well with an Arduino/Freeduino. (RS485 / 2 node RS232 should work fine also)
#3. Designing a compact LIN node printed circuit board.
#4. Finding and modifying an EEPROMLESS non table driven CRC-16 error checking routine for the LIN Bus.
#5. Echo back from the LIN transceiver. A RS485 transceiver has a direction pin which switches the bus transceivers from tranmit to receive mode.
The LIN chip has none and when it transmits all the chars are echoed back into the receive buffer.
#6. Making the network work using Arduino sketches for the network software.
<Hardware features LIN (Local Interconnect Network)>
Maximum network nodes 16 ( 1 Master & 15 Slaves)
Single wire transmission plus ground. Uses low cost automotive LIN transceiver for power and data.
(3 wires for +12 VDC power, data & ground).
Automotive LIN transceiver (MCP2021) provides additional regulated +5 VDC power for Arduino/Freeduino @ 50 ma. max.
The regulated power originates from the +12 VDC which powers all the automotive transceivers.
One power source via RJ45 will power the Master and all the Slave nodes in the network.
This includes the optional regulated power for the micro controller if the current draw is less the 50 ma. (MCP2021)
Maximum LIN transmission length about 120 feet / 40 meters. 16 nodes max. 15 slaves & 1 master.
Built in bus diagnostics from the automotive transceiver using the MCP2021 LIN transceiver.
Bus termination of 1k for Master and built-in resistor termination for the Slaves.
RJ45 low cost Ethernet cabling and connectors for node interconnections which includes power, data and ground.
On the software protocol side, there are not that many protocols to chose from. Modbus is a open “standard protocol”
but it was not created for a micro controller like the Arduino, so I decided, to roll my own with a very simple,
very reliable, easy to use, protocol that would not overburden the limited resources of the Arduinos/Freeduinos.
I named it KIRSP. “Keep IT Real Simple Protocol”
Note: KIRSP can be easily adapted to RS485. You could even adapt KIRSP to a Master/Slave
configuration by using RS232 @ 2 nodes @ 50 feet.
KIRSP and LIN application uses: Very low cost, reliable, hardware & software for robotic, sensor, security,
automation & environmental short range networks.
What KIRSP doesn't have using LIN bus:
#1. NO peer to peer communications due to the automotive 1 wire bus LIN transceiver.
#2. Nodes greater than 16. This LIN bus limits this to 16 nodes max.
(1 master & 15 slave nodes)
#3. High data baud rates. 19,200 is the fastest baud rate allow on the LIN bus.
#4. Full duplex communications. The LIN bus transceiver requires half duplex only.
Protocol Software KIRSP 1.0 [Keep It Real Simple Protocol] Rev 1.0 b features:
Free and open network protocol. Easy to learn, use and implement.
Baud speed of 9600,8,N,1 to 19,200 max.
Low packet overhead for fast data transfer.
Packet overhead of 4 bytes + 32 data bytes + 2 Byte CRC-16
Maximum number of destination slave addresses 15 - Address 0 is reserved only for Master node]
Slave node feedback ACK/NAK.
Adjustable maximum number of data bytes in each data packet. 64 bytes maximum due to the Arduino/Freeduino
maximum receive buffer size of 128 bytes.
Master/Slave - One master and many slaves - half/duplex mode only due to the LIN transceiver.
Supports broadcast messages to all slaves.
Fast Hex byte data packet message transmission.
Error detecting method - cyclic redundancy check x16 + x15 + x2 + 1
The CRC-16 algorithm is used in Modbus, SDLC, USB, disk drives and by IBM and many others.
Also known as CRC-16. The error detection accuracy of 100%. (See notes below.)
With KIRSP protocol you can do the following:
Send data bytes to another node. Adjustable from 0-64 bytes.(no data bytes could be sent)
Send a command byte to another node. 1 Byte = 255 commands. (can be enabled/disabled)
Send a “All Slave” broadcast message to all the slave nodes. (can be enabled/disabled)
Receive an ACK/NAK conformation from each slave node on receiving an error free message packet.
(This function parameter can be enabled/disabled)
Several items to keep in mind when using KIRSP.
There is only ONE Master (node) and many Slaves(nodes).
Each node has a unique “node ID” The Master node ID address is fixed at 0 and the Slaves are user defined between 1-15.
The Master node commands all of the Slave nodes. Slave(s) never commands but only responds to the Master. Slave node(s)
only wait for a transmit packet to be sent from their Master with their unique node ID address. Only after receiving
the transmit packet from the Master and after CRC-16 error checking will the Slave responds with data to the Master,
if commanded to do so with the ACK/NAK enable bit set by the Master node.
Slave node(s) never talks to other Slave(s), due to the LIN transceiver bus.
The Master initiates all communications on the bus.
The Master never responds to a Slave node and the Slave never transmits unless the Master commands/instructs
it to do so.
The Master should have more memory and I/O resources to handle all the data from all of the Slave nodes.
The Master should have two serial ports for easy serial troubleshooting.
The Slave nodes can be very inexpensive low power clone(s) which draw their power from the bus.
More testing .... work in progress ... cheers.
