| View previous topic :: View next topic |
| Author |
Message |
rusty_shackleford
Joined: 16 Sep 2014
Posts: 5
|
| CAN code between different 18F pics [Solved] |
 Posted: Wed Apr 01, 2015 10:58 am |
 |
|
I have initialization and communication code that I have used for years with a PIC18F4685. Trying to use a PIC18F26K80 for a different project using the CAN bus. I didnt expect to have trouble porting the CAN stuff the 18F26, but I am. Anybody got any tricks or pitfalls Im not aware of?
I use the can-18f4580.c and the .h file it references on the 18F4685. I did modify the BRGCON registers once probably 8 years ago and have used those values since. My hope was that they would be the same for an 18F series device. Wishful Thinking?
Thanks |
|
 |
rusty_shackleford
Joined: 16 Sep 2014
Posts: 5
|
| solved |
| Posted: Wed Apr 01, 2015 11:59 am |
|
|
ended up with
BRGCON1 = 0x01
BRGCON2 = 0x92
BRGCON3 = 0x02
using the can-18f4580.c and .h files.
20MHz crystal
tx and rx all working |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
| Re: solved |
| Posted: Thu Apr 02, 2015 1:49 am |
|
|
| rusty_shackleford wrote: | ended up with
BRGCON1 = 0x01
BRGCON2 = 0x92
BRGCON3 = 0x02
using the can-18f4580.c and .h files.
20MHz crystal
tx and rx all working |
Such "magic numbers" and direct manipulation of the CAN registers is NOT the best way to solve this when using the CCS C CAN support. It just patches over the issue and carries your portablilty problem over to the next time.
The CCS C CAN support comes in three flavours: can-18xxx8.c, can-18f4580.c and there's a dspic/24/30 series version too I beleive. With the 18s can-18xxx8.c is the version to use for most jobs UNLESS you are using the extended facilities offered by the ECAN peripheral first introduced with the 4580. All the PIC I use have the ECAN, but my CAN code never uses any of the ECAN extended functions (not to be confused with extended IDs, which all PIC CANs do), so as it's faster for general use, I use the basic can-18xxx8.c.
CAN speed set up, which I presume is what you are having trouble with, is necessarily complex. The way the bit period is divided up, with each part individually timed is tricky, and of course is PIC clock speed dependant. I have no idea what bit rate and bit period make-up your magic numbers give you. I have no idea how to change them to accomodate any change, say to a different PIC clock rate. That's why suhc magic numners are a bad thing - they make changes, and reading and understanding the code difficult.
If you take a look at the includes, you'll see that CCS can support has a set of user overridable defines that set CAN bit rate and which IO CAN pins are used for CAN. The defaults are good for 125kbps from a 20MHz clock. You should define those before the inclusion of can-18xxx8.c (or can-18f4580.c if you really insist on using it...)
There are a few CAN bit timing calculating utilities on the internet to help you to get the timing right - there are a number of ways to skin any particular cat. Here's how you might set up 100kbps on 20MHz using 10 time quanta per bit on the alterenate IO pins:
| Code: |
// This is untested and is NOT guaranteed to be correct - its for illustration ONLY.
#define CAN_BRG_PRESCALAR 9 //baud rate generator prescalar
#define CAN_BRG_PHASE_SEGMENT_1 4//phase segment 1 (def: 5 x Tq)
#define CAN_BRG_PROPAGATION_TIME 0 //propagation time select (def: 1 x Tq)
#define CAN_BRG_PHASE_SEGMENT_2 2 //phase segment 2 time select (def: 3 x Tq)
#define CAN_ENABLE_CANTX2
// Notice that there's no fiddling around with SFRs....
#include <can-18xxx8.c>
|
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
