Intro to CAN bus

Hi Aayushi Sahu,
First, try posting only to [email protected].  Saves everyone getting multiple copies of the messages.

The goal when building a system is to look at what it does, what it will do and how you will solve the problems.  Not to select blue and white 24g wire and then try and design the entire system around them.

So you are building an autonomous vehicle?  Draw a block diagram and decide what you need and where it will be.  Don't select the processor and then try to fit the program into it.  The same goes with choosing how the modules communicate.  

For example.  Although it's cool to have a network run to every corner of the vehicle to save individual wires for signal, running and brake lights it's far simpler to run individual wires.  Only if your volume production is high do you start to see the savings on a network solution.

Now having said all that how would the Controller Area Network fit into this?  Think of the CAN system as representing system where the giant processor memory is spread out over a number of different modules.  

For example CANOpen uses an Object Dictionary model where the memory map is huge.  Each memory location across the system consists of the ID[7]:Index[16]:SubIndex[8] potentially creating an address space as large as 0x7FFFFFFF or 2.1 Gigabytes.  In reality it's much smaller but it's still quite large.

You could now assign the left tail light lamps to 20:4000:0..F and the right tail light to 21:4000:0..F while the front ones have node ID 0x40 and 0x41 for left front and left right respectively.  Each lamp assembly occupies 16 bytes of the memory map.   

You could have an instrument cluster module with an ID of 0x10.  The cluster periodically reads the values of the lamp switches and reflects their status into a memory location.  .  I think it's important to observe that this model works perfectly well on a processor with a large address space and a multi-tasking or multi-threaded operating system.  Each task or thread monitors its own global memory locations and acts on them.

For example:
1.  Reading the park light switch and seeing that it's on means a 1 is written into the location 0x10:4000:5 by the task or thread called Dashboard.
2. Each lamp cluster periodically looks at the Dashboards memory locations and depending on what they see act up on it.  In this example seeing a 1 in the 0x10:4000:5 location means that the park or running light should be turned on.  
3. Or you can write the code so it's event driven.  Once every 100mS the Dashboard writes into the memory allocated for each lamp assembly with switch status or perhaps a lamp control status and the run status is set for each lamp.  Now the lamp threads or tasks are woken because their run status was set on.  They the check their mailbox and act on the command which is to turn on the running lights.

My point is that the design of the system shouldn't care what type of communications medium you choose.  In fact, you can simulate with a few switches and LEDs an entire system without using a network.

Then, once your system is designed you can look to see if it fits into one of the major high level network protocols.  Say you find that 90% of what you want to do can be done with CAN J1939 messages.  What that means is a trip back to the drawing board to figure out how to make the other 10% also fit.

I've done the same thing with CANOpen.  A thread (state machine) controls the run/stop signals for a generator and monitors the running and error status.  The main application doesn't know about those hard wired signals.  All it knows is that if it puts a GEN_START_RQ into a mailbox memory location that the generator thread will start the engine.  It knows the engine is either starting or running or had an error because the same mailbox will have a new value in it based on what the generator thread does.   

The thread was running on the main controller.  The I/O bits were on a different module which broadcast the inputs and received the outputs on a periodic basis.  As far as the generator thread was concerned the inputs and outputs were just memory locations as was the mailbox which was also broadcast for diagnostic purposes.

I then moved the generator thread to the processor that monitored the I/O.  The main processor didn't care.  It still requested a start generator by putting the command into the mailbox.  The mailbox was broadcast on the CAN bus.  The generator module received that mail box, acted on the Start Request and put a Generator Busy message into the mailbox while starting the engine.  Once running it put an ACK MSG into the mailbox.  

It's a perfect example of information hiding and abstraction because the main system had no idea what type of generator was connected nor who was controlling the generator.  The entire system could run on one processor with many wires to all the I/O or a smaller processor with distributed I/O.

That's the type of thinking you have to do for your project.  Not what processor to use or which CAN bus driver or what protocol.    If the goal is to use CAN you do have to keep it in mind.  It's a "one to many" protocol with no confirmation of reception at the low level.  

John Dammeyer

"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950




--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>