Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

CAN Bus Blog Series (shameless self promotion)

Hey all, so I've been working on a blog series that I think I'm done with for now.  It is a 9 part series on various CAN stuff.  I hope that in the future when questions come up on the forums about CAN hardware, I can point people to read Part 1, or when there are discussions on how to read and write CAN data to files I'll link to Part 7.

 

I'd recommend anyone interested in learning about CAN to skim through it or read up on areas you're interested in.  There are several examples, and code in the form of VIPM packages.  The overview and downloads can be found at the main landing page here.  Comments and questions are of course welcome.

Message 1 of 9
(2,501 Views)

Great job!

Many thanks for sharing.

0 Kudos
Message 2 of 9
(2,465 Views)

Like anything else, it is always easier to critique someone else's work than create our own.

 

With that being said, let me dive into it some.  It is a very comprehensive view from the 10,000 foot hierarchical level.  It misses much of the underlying information that people would view with a scope or need in order to hardware configure their own CAN network.  (Yes, I understand that many of the scopes today can actually decode the bits and produce the CAN Frame information)

  • Hardware Addressing (DTO, CRO, Slave Address)
  • Byte Order (Big or little endian)
  • Baudrate/Sampling of bits (85% = BTR0/BTR1)
  • DBC, A2L, and other basis files
  • Bits (Dominant and Recessive)
  • Typical CAN frame (bit-by-bit breakdown)
  • built up from CAN primitives (Upload, Set MTA,...)
  • Software Updating (Bootloader, Flash Kernels, Application)
  • Others (Catch all for anything that I might have passed over) Smiley Wink

Perhaps you could add some Appendices that show all of this from the ground-up or extend Part 1. 

Thanks for putting this together.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 3 of 9
(2,440 Views)

Hey no worries I'm open to criticism.  Let me address some of your comments.

 


@Minions wrote:

 

It misses much of the underlying information that people would view with a scope or need in order to hardware configure their own CAN network.  (Yes, I understand that many of the scopes today can actually decode the bits and produce the CAN Frame information)


I intentionally don't go into the bit's of what is being sent and in Part 2 mention this by basically stating we aren't going into it and a frame is the smallest amount of data being discussed.  Maybe it would be best to link to the wiki article on a CAN frame.

 

This frame contains multiple components of various data types.  At the low level a frame does get transmitted as a series of bits on the bus, which can be viewed with a scope.  But when we are discussing what is sent and received in CAN, the lowest level we will discuss is a frame which is between 41 and 113 bits of data.

DTO, CRO, Slave Address - In Part 8 I do mention DTO and CRO as the request and reply IDs used in ISO 15765.  From that point I on just refer to it as the request and reply frames.  I think this is easier to identify in a natural discussion where at least for me I have to keep looking up which direction DTO and CRO is, but stating "The request frame" is easier to identify the direction.

 

Byte Order - Yeah never went into this, but I do mention in Part 5 how signals are made up of things defined in a data base which include offset, scale, etc.  I do mentioned Byte Order here but don't talk about what it means.

 

Baudrate/Sampling of bits - Might be good to add, but again I defer that the frame is the smallest amount of data discussed, which happens after this sampling process.  It could be added maybe in a new post that covers sampling, scope, and bit packing.

 

DBC, A2L - I do mention DBCs in both Part 5 where I have a section on it, and in Part 6 where we talk about XNet Databases.  A2L's aren't mentioned because I don't have a post on XCP/CCP, but I would like to have that one day.  I don't mention CDDs, which I probably should since I talk about diagnostic CAN stuff in Part 8.

 

Bits (Dominant and Recessive) - I do talk about message priority in Part 2, but again not at the bit level.  The more I type this up the more I think a new part for that should be added.

 

Typical CAN frame (bit-by-bit breakdown) - Yup again it was intentional, but could be a new part.

 

Built up from CAN primitives (Upload, Set MTA,...) - Again I don't have a part discussing XCP/CCP but if I do this will be mentioned.

 

Software Updating (Bootloader, Flash Kernels, Application) - I do have a draft of a post discussion CAN flashing.  But at the moment it only covers ISO 15765 diagnostic flashing, since this builds on Part 8.  My intent was to one day post on XCP/CCP, and then make a single post on flashing which covers the two common types of CAN flash.

 

So future parts which I don't see doing for several months could be:

 

Part 10 - Low Level CAN, talking about the bits that go into a frame, sampling techniques, baud rates, what the signals look like on a scope.

 

Part 11 - XCP/CCP, talking about how this works, along with the various common request functions.  This will likely be another VIPM package just like how there is an ISO 15765 package.

 

Part 12 - CAN Flashing, talking about the two common methods of flashing with XCP/CCP, and diagnostic CAN.  This again would come with one example of each, both using the S rec and Hex file function mentioned in Part 7.

 

Part 13 - Running Code on XNet hardware, which is an undocumented feature of the hardware, which NI said I can talk about with locked block diagrams demonstrating CRC and counter functionality.

0 Kudos
Message 4 of 9
(2,433 Views)

Looking forward to Part 12....

0 Kudos
Message 5 of 9
(1,737 Views)

Ugh, I wish.  I moved up the XNet custom code to Part 10, but I wanted to cover ECU flashing after XCP so that I could have one post talking about flashing in general with examples for ISO15765 and XCP but the way things are going I'm not sure I'll ever get to a re-write of XCP.  Thanks for the reminder and I may look into making two separate flashing posts just so I don't have to wait for XCP to at least show the other flashing technique.

0 Kudos
Message 6 of 9
(1,717 Views)

Thanks so much for the blog and packages. They have been invaluable in learning about CAN, XNET, and for using non NI hardware.

 

I do have one question, is there a reason the "CAN Drivers" package is 32bit only?

0 Kudos
Message 7 of 9
(142 Views)

@MB_CAR wrote:

 

I do have one question, is there a reason the "CAN Drivers" package is 32bit only?


The same reason there isn't CAN-FD support in those packages.  Time.  The practical reason the driver package is 32 bit only is because it uses a 32-bit DLL for communicating with Intrepid, Vector, and KVaser hardware.  Each manufacturer has released 64 bit DLL drivers, and I have started porting the drivers to work with either LabVIEW 32, or 64 bit. 

 

The Vector specific drivers do actually have 64 bit and CAN-FD support as part of the Vector XL Driver wrapper which I posted to a month ago here.  But as for the blog posts, I just haven't got the time to update them and polish them the way I want.  Specifically I have improved the CAN driver package immensely since that post for internal use.  But getting that code available for public consumption is a bit harder.  I do hope I get the time to post it because I'm quite proud of it.

0 Kudos
Message 8 of 9
(136 Views)

Okay, I figured it was an issue with the DLL's.

 

I'd love to see what updates you've made but thank you for sharing what you have!

 

It inspired me to make my own internal packages and improve my code modularity.

0 Kudos
Message 9 of 9
(133 Views)