Jump to content
43oh

Book Review: Controller Area Network Projects


Recommended Posts

Controller Area Network Projects by Dogan Ibrahim, Elektor International Media

 

Link to book: http://www.amazon.com/gp/product/1907920048/ref=oh_details_o02_s00_i00?ie=UTF8&psc=1

 

So I bought this book as an intro to CAN as I am working on an MCP2515 boosterpack for the MSP430 et al.  I was excited mainly b/c they make mention of the MCP2515 inside the book.

 

The first 8 chapters do pretty good justice as an introduction to CAN from the physical to data link layers, making mention of some network-layer stuff above (like CANOpen and the automotive standard J1939) but no detail into any of them.

 

Chapter 1 is particularly interesting b/c it's not about CAN but rather an introduction to automotive busses in general; I didn't know there were fancy 10-15Mbps busses out there, e.g. FlexRay, MOST et al for either high-speed safety (airbag) or media streaming applications.  CAN is typically used in the engine control layer and since 2008 it's mandated for the OBD-II diagnostics interface on all vehicles sold in the USA, so CAN may exist simply as a gateway bus to the various other busses in the vehicle, but it's typically used for engine control.

 

I feel pretty solid about the physical characteristics of CAN, or more specifically ISO 11898's implementations involving a differential interface.  Basically a high-speed CAN bus (up to 1Mbps) involves a CAN_H and CAN_L signal line whose voltage levels referenced to GND (typically brought along with the signals) can swing from a max of -2V to +7V, but the voltage level doesn't matter too much.  What matters is the difference -- a "recessive" (logical 1) state means the voltage difference should be <0.5V for recessive and ~1.5-3.0V for dominant (logical 0).  The typical reference is centered around 2.5V but it shouldn't really matter.

 

There's a solid standard for minimum/maximum differential voltages at the transmitter and at the receiver but I can't seem to find where it was mentioned in the book.  I might have read it online, can't remember.  Anyway it is expected there may be voltage drops over long distances so the transmitter is naturally required to drive the "dominant" state pretty strong.

 

The bus is expected to run over 120-ohm characteristic impedance transmission lines, typically twisted pair wire, CAT3 or CAT5 cable should be perfect.  It's expected to be a bus topology, not a star, so there should be 2 logical endpoints with controllers branching off the bus using short stubs (there's a standard for how far away those stubs can be relative to bus speed, and also a standard for total bus length vs. speed).

 

Termination is used at either end; the most basic termination (Standard Bus Termination) is a 120-ohm resistor between the CAN_H and CAN_L lines at either end, but other EMI-reducing options have been proposed including termination with two 60 ohm resistors and a capacitor to GND in the middle (Split Bus Termination), along with a biased configuration with two 60 ohm resistors, capacitor to GND in the middle, but that midpoint also has a resistor to +Vcc and equivalent resistor to GND (Biased Split Bus Termination).  Pic of this for clarity: post-15991-0-70783400-1373811020_thumb.jpg

 

The book does a decent job introducing you to the nitty gritty details of CAN bus error and timing.  I must say, it is neat; the error frame mechanism ensures a short maximum duration of bus inactivity following which normal communication may occur, and each controller is expected to maintain self-awareness of its own perception of errors vs. error frame storms on the bus and if it reaches a certain counter, the device will voluntarily remove itself from the bus (stage 1 allowing I/O to occur but never issuing error frames, stage 2 disconnecting itself entirely).  This is to ensure reliability and maximum latency-control in the event of device faults and it makes sense in the context of a critical real-time system like automotive engine control.

 

Overall the CAN bus seems like it's typically zero-power except during transmission, where the transceivers have to drive against those termination resistors.  From the datasheets I've read with the MCP2515 and the NXP TJA1051T/3 (which I bought a few months ago for kicks b/c of its built-in 3.3V-compatible level shifter plus its ~$0.50/pc cost), typical standby power is ~5mA for both of them.  Better suited for plugged-in applications or extended battery-capacity (e.g. lead-acid + solar/wind) applications IMO.

 

The book does a rather lackluster job at introducing the MCP2515, although most of its details are locked into a part of the book I don't care for -- Chapter 11, MICROCONTROLLER BASED CAN BUS PROJECTS.  This chapter takes up ~42% of the length of the book, and it is quite literally a Microchip PIC introduction.  They finally round it up with some MCP2515-example projects but they spend an awfully long time talking about basic C programming, pointers, microcontrollers, etc.  I didn't read much of this because I don't care to learn PIC; my hobbyist-scope electronics knowledgebase is already replete with more platforms than it cares to learn.

 

For this reason alone, I wouldn't really recommend the book.  I'd rather have seen more detail on CANOpen and other higher-layer CAN protocols than a thinly veiled marketing piece on PIC.  I think this publisher is related to the mikroElectronica folks though, so they have a vested interest in pushing their PIC products.

 

Otherwise, with this under my belt, I may try to sell off the book and meanwhile find something on CANOpen since I am curious what it offers and whether it's suitable to implement with the MSP430 on top of MCP2515.

Link to post
Share on other sites

Lastly, mentioned both in the book and from what I've found online, there are a few standard connectors -- DE9 (DB9) can be arranged in OBD-II format, where the CAN_H/CAN_L lines coexist with other J1850 (oldskool OBD-II) lines or there's a CAN-specific industrial layout.  Then there's an RJ45 standard layout for the lines.  All standards support sending a +Vcc and GND line for powering devices over the cable.

Link to post
Share on other sites

Spirilis,

 

Since you are interested in CANOpen you may want to check out the NXP LPC11Cxx series of CAN enabled MCUs. They have the CAN transceiver built in and CANOpen drivers in firmware. Although they don't implement the entire protocol (e.g. Heartbeat), it is a pretty cool all in one package for doing CAN oriented projects. Please see my previous post on a petty cool home automation project using CAN:

 

http://forum.43oh.com/topic/3536-i2c-vs-spi/

Link to post
Share on other sites

Spirilis,

 

Since you are interested in CANOpen you may want to check out the NXP LPC11Cxx series of CAN enabled MCUs. They have the CAN transceiver built in and CANOpen drivers in firmware. Although they don't implement the entire protocol (e.g. Heartbeat), it is a pretty cool all in one package for doing CAN oriented projects. Please see my previous post on a petty cool home automation project using CAN:

 

http://forum.43oh.com/topic/3536-i2c-vs-spi/

Ah yeah I recall that one.  I have no plans to play with LPC's yet but in the future it might be a good option.  That Renesas RX62N board also has CAN with transceiver onboard (only controller in the silicon, but the RDKRX62N has a transceiver onboard) too :smile:

Link to post
Share on other sites

Let us know what you find, and what you think of it in relation to CANOpen.

 

And yeah, thats the problem with so many book authors now days. They literally know nothing about the content they write, until they write the book. I knew a couple of kids on gamedev dot net who did exactly that. They wrote books, as they learned the subject matter themselves . . .

Link to post
Share on other sites

I didn't read much of this because I don't care to learn PIC; my hobbyist-scope electronics knowledgebase is already replete with more platforms than it cares to learn.

 

 

@@spirilis If i had more thoroughly read your first post and seen this I would haven't posted the NXP reference....speed reading has it's downsides. :smile:

Link to post
Share on other sites

@@spirilis If i had more thoroughly read your first post and seen this I would haven't posted the NXP reference....speed reading has it's downsides. :smile:

haha np, the link was a good reminder though because I want to go back and see what that guy did after I have crunched a CANOpen book.

 

Sent from my Galaxy Note II with Tapatalk

 

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...