CAN bus newbie questions... Also, thoughts & experiences

[jseidmann]

Hi All,

I am currently moving my application from an RS-485 based communications system to a CAN bus system due to the benefits of CAN (such as arbitration, broadcasting, message resending, etc...)

My questions are:

1) Does anyone have any issues in general with CAN (as compared to RS-485 or not)?

2) Are Pull-up/Pull-down resistors needed on CAN bus like in RS-485?

3) I've seen various distances said for max distances at various baud rates (and they're all different!) Is there some definitive list I should look at?

4) Should CAN be used only in a multidrop fashion or is it acceptable to use in a "star" configuration?

5) In the extended CAN bus mode, I believe that people use the first identifier as the node address, and the second identifier as what data is being transferred, is this true? If not, could it be used this way?

6) Most of the data that I will be transferring from my nodes is floating point data which is stored in the PIC as a 4 byte value. What is the best/easiest way to format the data? Should I send it as ASCII or as a 4 byte value and convert it on the receiving end? What have people typically done?

Thanks for all your help!

[PCM programmer]

Many of these questions can be researched on the net with these keywords:

[jseidmann]

Here are some of the answers that I have found while looking (with help of PCM Programmer's assitance...)

-Pull Up/Pull Down resistors not needed

-Max distance is 40 Meters for 1 MBit, and 500 meters for 128 Kbit baud rate (a reasonable substitute for RS-485)

-CAN should not be done in a "star" configuration, but in a trunklike configuration, but should be avoided at higher baud rates (1MBit) for true multidrop bus configurations.

What I still can't find out information for is peoples experiences with CANbus in general. Do people like it vs RS485? Also, I cannot seem to to find out how people generally format the data bytes when communicating. Have people used integer to ASCII conversion and stored the bytes as ASCII bytes? Thoughts?

[newguy]

I've never used RS485, so I can't comment on the comparison to CAN. However, I've used CAN for a quite a few things, and I really like it. It's pretty much foolproof.

Regarding formatting, I just transfer the bytes unadulterated in the up to 8 byte payload of the CAN frame. Treat multibyte items as you would if you were storing those items in EEPROM (ie storing a 4 byte float in EEPROM).

I use the extended addressing (31 bit) mode, as those 31 bits can be very useful in distinguishing messages. For instance, I break up those 31 bits into fields - one for destination (specific processor or broadcast), one for originator, one for message purpose, etc. Doing things in this manner also helps reduce overhead in the processors on the bus as you can set the filters to only respond to messages sent to that processor and the broadcasts.

[jseidmann]

So I take it you mean that you just stuff them in one byte at a time, and send floating point values using the PIC 4 byte floating point format?

Is it true that when you send the CAN message via the CCS processor and point to a variable, that the variable is sent (provided it is a float) in a 4 byte format? If it is sent this way, isnt it kind of a pain for CAN nodes receiving the message to decode this especially if they are not PIC's? For instance, it takes a good chunk of processing to convert the 4 bytes into a floating point when you dont use a PIC.

I guess what I'm getting at is this: If you're communicating on a CAN bus, and there is a computer viewing the CAN bus, what is the best way (in your experience) to send floating point data to the PC? Send the float in ASCII format? PIC's 4 byte floating format? Is there a more standard approach?

[jma_1]

Greetings jseidmann,

I would follow an implementation of a CAN protocol like J1939. The protocol defines how data bytes are to be interpreted. For example engine speed in the EEC1 message is a 2-byte WORD and the data is 0.125 rpm/bit. A scheme like this would work depending on the resolution you require on the PC side.

Cheers,
JMA

[newguy]

First, I haven't written/done anything that communicates with a PC or any OEM CAN modules. My stuff communicates with my stuff.

I now understand your reservations. You'll have to dig a bit further to see how other processors on the bus interpret/expect floats, and 'massage' the data within the PIC prior to transmission. When it comes to actually transmitting data, you have to manually load the 8 byte data buffer; you can't simply "point" to a multibyte variable. If you use the CCS can_putd, you have to load the out_data[] array.

[iso9001]

I've written CAN to PC, CAN to in place network, CAN to CAN Pic, etc. I've found it all as newguy said to be very reliable.

I wrote my own can drive which handles pointers very well, it doesn't handle extended id's but thats really my own fault. If you are really interested in CAN I would recommend ditching ccs's driver and writing your own. It does worlds to help understand what's actually going on with the protocol and registers.

I have used just about every protocol I can think of at some point in some project's development, and CAN is my favorite. If it ever gets too slow I'll look into something else (flex?) but for now its great.

Your data layer/protocol can be anything. ASCII, J1939, plain old hex etc. It will depend on your pc software or programming and how much you want to transmit.