1
\$\begingroup\$

I know it will sound a little bit newbie, but I'm indeed a beginner... I need to design/define a CAN communication between two devices (one uses a AT90CAN32 from Atmel and the other is not yet defined), without using any specific protocol (CANopen, J1939), but just a kind of a simple "self-made" protocol. First I just need to do this from a conceptual point of view.

My question is what kind of things should I take into account?

I've already defined a couple of CAN IDs (ex. 0x1FFC) and what kind of data will be sent within these messages. But what should I do next? Do I need to define the whole ACK, CRC checking, etc. "stuff" or is it made by the CAN controllers on the devices?

Sorry if I didn't make myself enough clear, but I don't know how to explain this in a better way...

Thanks in advance for your help!

\$\endgroup\$
  • \$\begingroup\$ Communication can be done very simply even using the input ports, but that depends on both of your devices and what you intend to do, you can use the SPI also incase you want to receive some data.If you are using CAN then you will have to follow all the rules, that is essential if your product is commercial. \$\endgroup\$ – MaMba Oct 6 '15 at 7:58
  • \$\begingroup\$ In general the CRC and resend functionality is handled by the CAN peripheral in a microcontroller. \$\endgroup\$ – Daniel Oct 6 '15 at 8:02
2
\$\begingroup\$

The CAN protocol itself handles the CRC checking and ACK checking so you don't have to bother about that.

First you need to define the IDs regarding the priority. On CAN bus the more dominant bit you have at the begining of your ID, the more important is your message. Indeed if two nodes try to send two differents messages for example 0x1FFC and 0X0FFC, the second one will be sent firstly because there are more dominant bits at the begining of the ID.

Next you need to know that you can send 0 to 8 octet of data in each message.

Regarding the applicative protocol it's pretty much everything you need to look at.

The last but very important thing is at driver level, it is the repartition of the different segment.

The CAN bit is cut in Time Quantum (TQ) that you need to define. After that the 4 segments are : the SYNC (1TQ) the propagation segment (0 to 8 TQ) the segment 1(0 to 8 TQ) and the segment 2(0 to 8TQ). You will find on ethernet how to define those segments if you don't know how to do it.

The sample point is between segment 1 and 2 and you need to place it around 75% of the bit.

\$\endgroup\$
  • \$\begingroup\$ Thanks @damien for your answer. The first part is clear to me, but the last paragraph (about Time Quantum) I didn't understand very well. Can you clear it up? \$\endgroup\$ – jnota Oct 7 '15 at 6:32
  • \$\begingroup\$ @jnota Each bit sent over CAN is synchronized in a detailed manner, to make it more robust. This is done by chopping up the bit up in a number of time quanta, in order to be able to specify at what point in time, during reception of the bit, that the hardware should read it. The edge is supposed to be inside the sync segment. After that follows propagation segment, which can be set to different times to compensate for hardware delays, followed by two phase segments, which surround the actual sample point where the bit is read. \$\endgroup\$ – Lundin Oct 8 '15 at 11:24
  • \$\begingroup\$ @jnota There's also something called synchronization jump width (SJW), which determines how much the sample point is allowed to deviate inside the phase segements. All of this is somewhat advanced and delicate stuff, which is always the main obstacle to overcome when writing a CAN driver. Therefore, no matter protocol, I would strongly recommend to follow the CANopen recommendations for how to setup the different segments, depending on baudrate. Chapter 7 in CANopen DS301. \$\endgroup\$ – Lundin Oct 8 '15 at 11:26
2
\$\begingroup\$

A. Choosing an appropriate data rate can make the difference between a reliable and flaky system:

  1. There is usually a trade off between the max reliable communication speed and the cable length/number of nodes.
  2. Termination at each end of the bus is important.
  3. Cable impedance also important for good signal integrity.
  4. EMC filtering will help immunity to external noise but too much or inappropriate filtering will affect the signal integrity and max data rate.
  5. Proper screening of cables always helps.

Once the electrical design is fixed, you can tune the data rate and the Tq parameters: PropSeg, SyncSeg, etc to give best reliability. Generally: If the design has independent clocks for the nodes then you will need to have a longer SyncSeg. Longer cables (more delay) call for a longer PropSeg. Some chipsets allow for sampling once or three times in the DataSeg to give better noise immunity.

B. You may also find that Messages from multiple nodes may appear out of time order sequence due to the prioritization. This may or may not be relevant/important for your application.

C. Be wary of CAN driver code given away for free by microcontroller vendors. I found so many bugs in the vendor's code that I ended up writing my own low level routines - which was a good thing because by doing so I understood a lot of the subtleties of how it worked.

\$\endgroup\$
  • \$\begingroup\$ Strongly agree with the warning for microcontroller vendor drivers. It is fascinating how much money these companies spend on R&D, and yet they aren't willing to spend 5 cents on having a competent firmware programmer writing the example code which will be read by all of their customers. Instead they find some bored FAE hobbit who briefly studied C in an earlier life, and make him spew a flood of magic numbers into an app note, of course without even compiling or testing. Then call it a fine example of a hardware driver and publish it on their web site. \$\endgroup\$ – Lundin Oct 8 '15 at 11:36
  • 1
    \$\begingroup\$ It may be true that there might be some bug in the driver of microcontroller vendors, but for the one given by microchip, at least on PIC32, it is quite good and quite useful to begin with. It is always easier to begin with something already done not so bad and correct than doing everything from scrath. At least it is my experience. But of course you have to modify the driver at least a little bit to match your expectations \$\endgroup\$ – damien Oct 9 '15 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.