DIY develop a house network with the PIC [PicNET2]

So I started to search on the Internet to find something interesting. I found a lot of ideas but nothing concrete. So I decided to collect the hardware and the software ideas and indications to develop a house network. My purpose is to give the first steps to develop something personalized so that's why I am orientated to all those that like DIY projects. Feel free to comment this article in order to improve the project.

All the software material is available for a personal use, can be copied and used to such ends for free.

PIC is the core of this system. I used various models, based on my requirements. Many typologies of PIC can be used because they have at least one integrated USART, I tried the 16F88, 16F876,16F628 and all work perfectly, even using the internal oscillator (16F88). In the attached code I named 16F628 which manages all the protocol and interfaces with the external world through its input/output ports. For the physical transfer of the data a transceiver frequently found in CAN networks is used (MCP2551 or Maxim, MAX3050 and others of the same family).

The use of this transceiver simplifies the SW because the rx-tx commutation is automatically managed from the chip. The protocol is completely different from the Can-Bus and designed to use the PIC resources, simplifying to the maximum maintaining as priority reliability of the received data. The BUS is made by a 4 wires cable, two wires for data and two for power. Use of differential driving, commonly used in industrial applications, guarantees a high level of noise immunity.

Default transmission parameters are: asynchronous 38400bps 8N1, speed can be either increased or decreased, distance being a limiting parameter for maximum allowed speed. Can specs provide the following limits 40m @ 1Mbs, 600m @ 115200bps, and so on, for more information take a look at CAN BUS

The program is written in PicBasicPro, this choice was dictated from pragmatism as well as the ease of modification and integration of future code. I put the code in an external file to be included in the main program, to make the protocol portable also for other applications. The protocol is normally in an idle state, waiting for a request from the bus, while the PIC runs the main program.

The code manages the MultiMaster Bus protocol and it is easily portable to other PIC (featuring an USART) just modifying the definitions, at the same time additional capabilities can be included. Several communication speeds can be set with the appropriate definition, just make sure that your CPU-Oscillator can handle the requested speed baud-rate. I found that tollerance is not that tight.

With a 20Mhz quartz you can reach the speed of almost 1Mbps! For a correct use of the USART always take as reference PIC Data Sheet. The use of the high speed can be useful for automatic machines which must communicate quickly in short distances. Using standard speeds allows to use a PC to monitor bus traffic.

Monitoring the traffic using a PC is useful to check the correct behaviour of the system, but keep in mind that each node can act as either a MASTER or a SLAVE, thus a PC is not strictly required. The protocol is MULTIMASTER, and minimum number of nodes is two, where eventually one of them may even be a PC with an RS232 adapter. More nodes can be added, each of them with an unique ID.

The latest sw version makes use of interrupt from the serial port. This allows for fast response time from bus queries, on the other hand care should be taken handling sw delay routines, which could be corrupted by interrupt being serviced while executed thus altering their duration

To avoid this problem, when leaving the ISR, the code does not returns to the instruction following the interrupted instruction, nstead it jumps to the loop label located in the main program. This practically aborts the instruction being executed when the interrupt is activated, avoiding a wrong behaviour. Other ways to solve this problem are bit-banging and real-time, we will face them in a coming future blog.
One thing to be avoided is a steady querying. To avoid bus saturation, use delays or use a timer to pace the queries.

PROTOCOL

A message is made of 12 bytes packets. Bus state is not controlled, instead conflict detection (simultaneous access of more than one node) is used to check transmission. A checksum is used to control packet integrity.
The cheksum is a two bytes number (byte 11 and 12), obtained adding bytes 1 to 10.

Packet fields :

ID=50 is used for broadcast, thus allowing with only one transmission to reach all nodes, other ID can be used to activate/deactivate groups as in X10.

Packets sent by a MASTER:
Field D1 is the command to be sent, it is a value from 0 to 127.
Field D2 is the address.
Field from D3 to D6 are data

Packets sent by a SLAVE:
They are sent following a MASTER query.
Field D1 is the answer to be sent, it is a value from 128 to 255.
Field D2 is command acknowledged and executed.
Field from D3 to D6 are data

Following is an explanation of protocol commands:

REG = access to PIC register or RAM location. It gives access to I/O ports, but can potentially access any PIC register such as STATUS, INTCON etc. If this command is used in a wrong way, system crash is a possible outcome. On the other hand it allows to read/write PIC peripherals such as ADC, I/O ports, timers etc.

FILE access to PIC EEPROM used as a permanent storage area. Available area and addresses are PIC dependent. WARNING : first 8 bytes should not modified, since they represent system parameters. Byte 0 is the node ID, thus modifying this byte you can remotely change node ID.

I° BYTE = ID number from 1 at 255 (except 50) identifies the destination node
II° BYTE = ID " " " identifies the sending node
III° BYTE = function change bit 7=1 (> 128 decimal identify an answer of the node)
0 = test verify node status. Turns back string "Test"
1= read 6 byte consecutive REG. (initial address byte 4) return 6 bytes (5..10)
2= write REG. just a byte (address byte4) (data byte5)
3= write REG. just a byte and return confirmation (address byte4) (data byte5)
4= read 6 byte consecutive FILE (initial address byte 4) return 6 byte (5..10)
5= write 6 byte consecutive FILE (initial address byte 4) (data byte 5...10)
6= write 6 byte consecutive FILE and return confirmation ((initial address byte4) (data byte 5...10)
7= read bit REG. (address byte4) (n.bit 00000100 byte5) return byte5 = zero o uno
8= setta bit REG. (address byte4) (n.bit 00000100 byte5)
9= resetta bit REG. (address byte4) (n.bit 00000100 byte5)
10= inverti bit REG. (address byte4) (n.bit 00000100 byte5)

IV° BYTE = Address of the operation to carry out
V° BYTE = Value to memorize and or beginning data read.
....until ..........
X° BYTE = last data.
XI° BYTE = Checksum 16 bit. Data 1....10 ( byte low)
XII° BYTE = Checksum 16 bit. Data 1....10 ( byte high)

The data is always sent in 12 byte packets also when not all the bytes have a meaning.

Examples of the communication:

For the first tests better build a node and the serial interface RS232 to connect to the PC to make the tests to verify the operation. Also test the PIC read and write, access to registers, I/O ports, EEPROM etc.

WHAT DO YOU NEED TO START

Get the program PicBasicPro from Melabsfor to compile the code basic of the pic, it is a commercial program which costs.
(but a demo version for evaluation is available).
A help on the writing of the code is MicroCodeStudiowhich can be integrated with the PicBasic, it is free, help on line, control of the code ecc.
I think that there is also an on line compiler but I don't know the link .
The PIC16F628 can be found without no problem at a good price even lower than the famous 16F84.

The programmer is X_pippo possibly fed externally to use with the very famous one IC-Prog 1.05A.

The Documentation

FIRMWARE
'-- Control BUS Home Automation PicNet
'- Luigi 11/2005 Rel. 0.3
'- Resources COM1 bus PicNet

DOWNLOAD THE COMPLETE DOCUMENTATION OF ELECTRICAL SCHEMATICS AND FIRMWARE SOURCES --->> DOWNLOAD

Maybe I wasn't so clear in the description, but I'm not so good at writing, so all the critics are welcome
For informations and or questions write to the addresses' site.

Luigi