View previous topic :: View next topic |
Author |
Message |
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
Any CAN bus book recommendations? |
Posted: Thu Jan 07, 2016 9:44 pm |
|
|
Hi,
I'm disappointed that the new CCS book doesn't talk about the CAN protocol (yet they supply examples and make dev. board )
Any book recommendation for learning CAN?
Thanks guys! _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Fri Jan 08, 2016 8:16 am |
|
|
CAN't help you about any books but if CAN is like MODBUS or 'RS232' there's probably dozens of implementations with a zillion variations on how it is used!
The CCS examples and board are probably 'basic' starting points that allow you to 'get a feel' of how it works but we all know the Devil is in the details.
I'm sure those that use CAN will have their favorite book and hopefully post for you but my gut feeling is there's a lot of 'custom' application specific stuff not generally known or written about it.
Jay |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Fri Jan 08, 2016 9:04 am |
|
|
I haven't found a CAN book. In my opinion, the place for you to start would be the Bosch CAN specification, which is actually a good read. Once you're done with that, consult the data sheet for the PIC you're considering and really study the CAN/ECAN section of the data sheet. Pay particular attention to the registers used by the CAN hardware.
Once you have done that, if you have prototyping boards (I used the MELabs Lab-X1 when I did my first experimentation with CAN), start playing on your own.
Some things that bit me at various times:
- CAN errors. A CAN system needs at least 2 nodes. Every transmission by a node REQUIRES at least one other node to ACK the transmission. No ACK = error, which triggers automatic retransmissions ad infinitum which then appears to be hung code/hung CAN bus. Any node can ACK any packet - it doesn't have to be a message that the node is set up (via masks/filters) to receive.
- Use the microchip bit timing calculator. Google it. It's invaluable.
- If you're developing a system from the ground up, put some thought into the message IDs you choose instead of simply starting with ID 0 and working your way up from there. Filters are like real estate - they're not unlimited and sooner or later you'll run out if you don't choose your IDs wisely. I came up with a simple "addressing" system using extended IDs (29 bits) whereby the 29 address bits are broken into different fields to denote the message originator, the destination (either one specific node or a broadcast meant for all nodes), a counter (for multimessage transfers), message ID, etc. If you do this, you really only need two filters: one for messages directed to THIS node, and another for messages broadcast to ALL nodes.
- Pay particular attention to the errata for the PIC you choose.
- Don't place too much confidence in the CCS supplied CAN routines. The basic routines meant for the 8 bit PICs with ordinary CAN transceivers (not ECAN) worked fine but when I started developing projects using dsPICs and v4.141 I quickly found out that the stock CCS routines didn't work at all. At that point I "rolled my own" as I had little confidence in the v5 compiler releases available at the time. I'm actually glad I was forced to do so because I developed rock solid fast CAN routines using DMA which allowed my projects to be much more reactive with "real world" CAN traffic.
- Finally a comment that goes in all my code just before my masks/filters:
Code: | // mask bit n | filter bit n | message ID bit n | result
// 0 x x accept
// 1 0 0 accept
// 1 0 1 reject
// 1 1 0 reject
// 1 1 1 accept |
|
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
|
|