Introduction
CAN bus is a great way to connect several microcontrollers together as it can cope with large distances or noisy environments and it works very well. This is why the automotive industry made CAN bus a required standard for communication for all modern cars. As well as automotive applications the CAN bus can also be used for many other applications and is very simple to implement.
The basics of a CAN bus communication is that any node on the bus can both send and receive a packet. A single packet consists of an ID which is basically a number and an optional 0-8 data bytes. Extended CAN simply has more ID numbers available due to a larger message format.
The automotive trade has implemented lots of meanings for the ID numbers and used this to build up more advanced high level systems such as DeviceNet. If you are interacting with an existing system like a car then you will likely have to get hold of a breakdown of the manufacturer's ID meanings which may be costly if the information is not readily available on the internet. This is generally why manufacturer specific automotive analyser tools are so expensive to buy.
The good news is that if you are developing you own system then you get to make your own ID based protocol which greatly simplifies things. For this blog I will demonstrate designing a system using CAN bus that should be a good base for developing your own systems.
Stage 1 System Design
For this blog I am going to design a relay control system that can be manually controlled from a fixed keypad on a wall and controlled via a device on the local network. The relays could be used for pretty much anything but I will use them to multiplex incoming video feeds from various wired CCTV cameras. Note that the video signal itself is not processed via the microcontrollers, merely switched by the relays.
My system will consist of three nodes:
A - Keypad Node - Monitors the keypad and transmits when a key is pressed
B - Relay Node - Listens for incoming messages and switches the relays on and off
C - Monitor Node - Bridges the CAN bus signals to a PC via USB connection
For nodes A and B I will use an EB006 with a PIC16F1937 device and EB018 boards to do the CAN bus communications.
For node C as we also need USB communications I will use the MIAC as this has both USB and CAN built in.
Flowcode will be used to decode the signals and provide a web page based interface to the local network.
Here is a conceptual block diagram of the setup.
The input video signals from the 4 cameras are wired into the N/O terminals of the relays board and the output video signal is wired to all four relays COMM terminal. This way when a relay is active it will pass it's input signal onto the output connection. Note we must be careful to only have one relay activated at a time or we will be essentially shorting two or more signals together.
Stage 2 Simulation
The first thing we need to do is create a simple system we can simulate to gain familiarity with the system. I only create programs for nodes A and B at the moment.
Node A
The node A program is a tight loop that checks the keypad and sends out signals as we need them.
Key 1 has been pressed - ID = 1, No data
Key 2 has been pressed - ID = 2, No data
Key 3 has been pressed - ID = 3, No data
Key 4 has been pressed - ID = 4, No data
Key 5 has been pressed - ID = 5, Data 0 = 5 seconds
Key 6 has been pressed - ID = 5, Data 0 = 10 seconds
Key 7 has been pressed - ID = 5, Data 0 = 15 seconds
Node B
The node B program is also a tight loop which checks for incoming CAN data and switches the various relays on and off using various IDs.
ID 1 = Camera 1 Active
ID 2 = Camera 2 Active
ID 3 = Camera 3 Active
ID 4 = Camera 4 Active
ID 5 = Camera Auto Cycle, Data 0 = Cycle delay speed in seconds
Whenever the relay output is altered we send out a signal to confirm the change has occurred.
ID 6 = Camera Change, Data 0 = Current Camera, Data 1 = Current Mode Manual/Auto
By attaching the Injector (CAN) component to the Flowcode program and creating a simple CSV file we can decode the simulated transmitted CAN messages. Running the simulation and pressing keys on the keypad should generate console messages with decoded packet information.
Node A:
Stage 3 Hardware
Now we have our programs for nodes A and B it's time to transfer them to hardware and see if the system works.
With Nodes A and B connected together I can manually set the camera channel and automatic mode on Node B using the keypad on Node A.
So now it's time to bring the Flowcode simulation into the picture again and see if we can monitor the data on the bus.
We program the MIAC with the MIAC USB Slave Firmware and then the Node C program simply runs in the Flowcode simulation controlling the MIAC hardware via the USB connection.
Instructions for the MIAC USB slave component are available from here: http://www.matrixtsl.com/wiki/index.php?title=Component:_MIAC_USB_Slave_%28MIAC_Module%29
With The Node C program simulating I can press the keys 1-4 on the keypad and receive the following packet breakdown on the console window taken from the live data.
Pressing the keys 5-7 on the keypad enable the auto switching functionality with delays of 5, 10 and 15 seconds respectively. Every time the channel changes I get the corresponding message on my console.
Stage 4 Further analysis and application ideas
So now we have a working system which is fully operational and we can monitor the activity on the system. Lets see what else we can do.
The Program NodeC-Webserver combines the current functionality with the option to control the Flowcode simulation via a webpage. The webpage allows us to replicate the NodeA functionality which allows us to control the system from various points. i.e. The Keypad on Node A and local network web page requests to the Flowcode web server running on the PC.
Here is the output of the simulated web server running in a web browser.
Here is a log of the TCPIP console data, shown is a request for manual camera 3.
All the programs from this example are available from here: http://matrixtsl.com/blog/wp-content/uploads/2014/09/CAN-bus-with-decoding.zip
By using video input hardware on the PC and sharing the feed using webcam software I can create an iframe in the HTML for the web server NodeC code which refers to the feed from the camera and allow me to monitor the video via the web page. I can also record the feed using the PC software if I need to. By changing the server port and configuring my router to port forward the specific port to my PC's IP address I can then access the camera feed and control webpage from anywhere in the world with an internet connection.
Conclusions
CAN bus is a great tool for connecting several microcontroller systems together. It is very good with noisy environments or across long distances. It comes in external and internal flavors depending on your microcontroller device. Internal CAN simply requires a driver IC such as the MCP2551. External CAN requires a CAN transceiver IC such as a MCP2515 as well as the driver. The EB018 CAN E-blocks board datasheet shows the schematic for connecting up the IC's to a microcontroller.
When rolling out CAN to a system Flowcode 6 can be a very powerful tool in helping to get the hardware up and running as well as a link in the chain should you wish to do anything else e.g. a data bridge.
The MIAC Slave component will work with the Flowcode 6 simulation but will also work with products like Labview, MathLab and VB. Examples of this are available on the learning center.
