Setup of CAN2 when using both Controllers on CANBUS

[Len_Manning]

Hi,

New to the CANBUS, but need to add another CAN network to the existing one using the CAN2 Controller.

Does anyone have a simple example code of the setup and list of steps ?

My initial idea is to copy the code of the first controller inserting CAN2 where appropriate, but I am not sure how the constants for the setup may change for the 2nd controller.

Any help would be appreciated.

Len

[PCM programmer]

Look in the files can-dspic30.h or can-pic24.h (you didn't post your PIC).
There are a complete parallel set of constants for CAN2. If you call
can2_init(), it will do the setup for CAN2 and it will use those constants.

Also call can2_kbhit(), can2_putd(), can2_getd(), etc.

[Len_Manning]

Hi PCM

Thanks for that. I have done that, but some of the variables or defines are common I guess for CAN1 and CAN2 such as those found in can_set_mode

If there were any examples showing use of both simultaneously it would be helpful.

The processor is a PIC24 by the way.

Thanks for the response.

Len

[RF_Developer]

[Len_Manning]

Hi RF,

Thanks for that. Luckily messages are not moving through the system too fast so it is hopefully going to be easier.

Also the rate of sending from the nodes connected to Can2 I can also control so hopefully should be able to tweak it.

[newguy]

I have a lot of experience with 2 CAN streams on dsPIC devices, but I've never touched a 24 series PIC yet.

When I did my development, the v5 compiler wasn't really all that stable yet so I used v4.141. Actually I started with v4.099 but it didn't support my chosen dsPIC at all, so that forced the move to v4.141. First thing I learned is that the CCS built in CAN functions didn't work all that well (or at all) for my processor. That forced me to do all the setup myself by directly writing the necessary registers. At the time I wasn't happy about it, but in hindsight I'm glad that I was forced to do it that way.

The family of devices I developed were all very CAN intensive along with other functions, so I thought that using DMA, which was new to me at the time, would help overall throughput. Again, that forced me to learn the low level nitty-gritty associated with DMA, and again, in hindsight I'm grateful for it.

Your PIC24 will be able to handle two CAN streams and just about anything else you can imagine with great ease. On the receive side, you set up your hardware filters to only react to messages you want to examine. When your CAN receive interrupt fires, it's because there's a message you want waiting for you. On the transmit side, yes, you'll need to set up a software transmit buffer. Your code writes to your buffer and behind the scenes you'll need to write a routine that monitors whether your buffer has one or more messages, and whether the CAN transmit buffer is empty. The reason for this is that the higher end PICs have ECAN buffers which have 16 individual channels or buffers, and it's pretty standard to only dedicate one of them to transmit.

Again, you'll have no trouble getting your PIC24 to handle normal CAN traffic. There's no need to intentionally slow a network down. One of the devices I built was a 4 port bridge used to connect two different CAN networks in two different locations. Each bridge had 2 CAN ports and 2 serial ports (one set up with RS485 line drivers for a long distance link to another (remote) bridge unit and the other being an "ordinary" RS232 level port). Each CAN port was running at 250kbps. One of the serial ports ran at 417 kBAUD (the long distance RS485 link) and the other ran at 500kBAUD (a local connection to a Linux SBC).

The serial data rates were chosen to handle 100% CAN utilization on both CAN ports plus about 40% overhead for future expansion (basically for the two SBCs to directly communicate over the RS485 "tunnel"). The bridge easily handled flood testing in the lab and real world data in the field. I remember when we compared the log file captured using the SBC "piggybacked" on the bridge to an older legacy SBC directly attached to the CAN network, the first thing we noticed is that the new log file was much larger than the old one. Ruh-roh. It was only then that we discovered our old legacy SBC was missing CAN packets. Correction: a lot of CAN packets. ~15 years of operation before it was discovered that it was faulty. Looking back, it explained a lot of weird issues we could never duplicate.

[Len_Manning]

Thanks newguy. That helps.

Guess I need to play around and see what works and what doesn't.

I will keep an eye on the version 5 compiler as well.

Any good links for info on the CANbus or just the Microchip data sheets?


Thanks Len

[newguy]

As I said, I've never used a PIC24, but the dsPICs have both a processor (or processor family) data sheet, which doesn't have much detail, and a FRM (family reference manual), which has an incredible amount of detail.

Regarding CAN, there are some things to keep in mind. Every CAN packet involves some 2-way communication in the form of an ACK. With serial, as you know, you can send a message and that's it. There doesn't have to be anyone listening for the message, but with CAN there absolutely MUST be at least one other node on the bus. All CAN nodes will ACK any valid packet they see, regardless of whether that packet is addressed to that node (whether that node wants to listen for that message) or not. If a node can't make sense of a message, it will generate a CAN error packet. The number of CAN errors doesn't climb monotonically and can jump by several 10s with just one additional error (this is due to the way the error counter is allocated in the packet and the fact that a node just looks for an empty bitfield to assert if it has detected an error). The count goes down 1 for every good packet exchanged.

Look for the Microchip CAN Bit Timing Calculator. It will calculate what the CAN baud/etc registers should be for your required CAN bit rate and clock. You can use this program to verify that the CCS functions are setting things correctly if nothing else. I just directly set the necessary registers myself.

Per CAN channel/transceiver there will be 16 message buffers, 16 filters, and a few control registers. You'll want the standard setup, and that's for buffer 0 to be set to TX and the rest set to RX.

For reception, there are MASKs and FILTERs. If a mask's bit is set to 0, that's a don't scrutinize in filter/don't care/blanket accept. If a mask's bit is set to 1, then the filter's bit has to match the incoming message ID's bit in order for the message to be accepted. There should be (I think) 3 different masks per CAN. The masks are used to set aside "families" of message IDs you want to examine while the filters are used for specific ID(s - depending on the mask).

If you don't use the CCS functions, just pay attention to how a message is "packed" in the buffer. Each message buffer will be 8 int16's. There will be diagrams in either the FRM or the datasheet. To send a message, you just pack message buffer 0 with the outgoing message, paying attention to what bits are for various flags, parts of the ID (which is split up for historical reasons), and the data bytes. Finally there's a "attempt to send now" flag that you assert and then it's "hands off" on your part.

Once CAN is told to send a packet, come hell or high water, it will. This involves automatically waiting for the bus to go inactive and "silent" for a period, then starting to transmit. All the while a node is transmitting, it is also automatically monitoring the bus to detect bus contention (some other node is also transmitting). If the node loses contention, it starts the process over again. It will only give up if the transmission is successful or if you abort the transfer. If you attempt to test something you've written and you don't have a node attached to your CAN bus, the transmits will block for this reason. If you do have an external CAN bus to test with, ensure your bit timing is correct and that you ensure that your processor powers up with the CAN TX pin in the recessive state (listening). If you attempt to attach a node with different CAN bit timing, you'll essentially brick the entire bus until you remove the node.

[Len_Manning]

Thanks NewGuy,

Bit of a Homer Simpson moment here. The PIC on the board is actually a dsPIC30F6012 - Doh !

I will use the CCS Library Functions

Thanks for all the advice.

Len