I have decided that I want to create a PIC based relay controller that can be accessed via a RS485 connection. The idea is simple. Each PIC controls one single relay, and by addressing a single bit to that PIC, it will either turn the relay on or off (the controller would probably be a PC).
The PIC to be used will probably be of the PIC10 variety. For now this page is sparse as it's just being used as a store for me to gather information about the feasability of this project. If anyone has any ideas feel free to contact me with them.
I picked the RS485 standard because it is similar to the RS232 standard (actually, they are closely related) except RS485 only needs two wires, and can reach up to 4,000m, more than enough for someone to wire up their entire house.
As it only needs two wires, I have decided to use the RJ11 plug/socket (for those of you that don't know, these are sockets as used on modems and phones) . The reasoning behind this choice is to do with making my life easier. wiring for these sockets can be found in most hardware stores quite cheaply, from lengths that are less than a meter to 100m extension cables. By picking this standard I don't have to go through the trouble of making my own cables/splitters/etc....
After some researching, it would seem that RS485 is just the electrical specification, not the protocol. As such it only deals with the physical layer of communication. This means that I send the data any way I please. I have decided on the RS232 standard because:
What you do need though is an interface. the RS485 specifies the electrical interface to use, and now my choice is either to implement it using discrete components or just buy off the shelf RS486 Transceiver ICs. A good chip would seem to be the ADM1485, by analog devices(*1), or the MAX487, or the LTC485.
RS485 is a master/slave bus. So you have one terminal being the master, which sends commands to the slaves and generally manages the bus. The slaves do not communicate with each other. They only speak when the master first talks to them. This pretty much fits in with the structure of this project, as we will have one master (the PC) telling the slaves what to do. Slave-to-slave communication is not desired, and I'm not sure if I will even implement half-duplex communication (I may just make it simplex).
According to the RS485 standard, you can connect up to 32 slaves to the bus, but as of yet I'm not sure why (being an electrical description, I'm not sure where the limit applies).
Well, I decided on the PIC16 family, (a mixture of 627 and 628) primarily because I already have these chips in decent quantity (I figure it will be cheaper for me to just standardise on one family and buy in bulk) and because they are compatible with my programmer under Linux.
Next thing I wanted to do was get a rs232 link working. To do this I needed a prototyping board which had rs232 (my programmer doesn't have one). So I bought a kit and assembled it:
All good, the kit even had a convenient ICSP (In Circuit Serial Programming) socket, which means I don't have to keep taking out the PIC in order to reprogram it before putting it back in to test. Alas, that would have been too easy. After trying for ages to get the Linux k8048 program to recognise the PIC and program it, I gave up and resorted to constantly removing and reinserting the chip (if anyone got ICSP to work under linux with the k8048, please let me know).
I decided on progamming the PIC using the C language (with the open source SDCC compiler) and I have so far got it to print out random ASCII characters and echo what I send to it from my laptop running minicom (set at 9600@8N1) .
The next stage for me would be to implement the communication part of this system. I decided on the following structure:
TID STATUS SB
TID = Target ID:
STATUS= Bit Status:
SB= Stop Byte:
Communication and outputs work!
Mini milestone in my opinion. We have got rs232 communication to work, I can send a TID and command to turn on any one of 8 ports from port A.
I decided to scratch the stop byte. Instead we have half duplex communication, which looks like this:
Instead of a stop byte, we have the PIC echo the sent command as an acknowledgement byte. I also wrote a little python program to communicate with the PIC:
In this example the program sends commands to target number 2 (this PIC, number 1 is the PC) and a command to turn on every pin on the port in sequence. The PIC responded correctly and I checked out if it actually does turn on the pins with a multimeter (which it does). All is good so far. Next thing to do is design the circuit and build a prototype.