 |
 |
| View previous topic :: View next topic |
| Author |
Message |
kontakt
Joined: 27 Jan 2011
Posts: 7
Location: HU
|
| CAN-bus receive problem with PIC18F66K80 |
 Posted: Thu Jun 14, 2012 2:25 am |
 |
|
I would like to use CAN-bus with PIC18F66K80. I turned on the loopback mode but it does not receive anything. I use external 20MHz resonator. The only modify is the can_set_baud to 500kbps on the can-18xxx8.c. The can_kbhit() won't be never TRUE. Compiler: CCS 4.130
Could me help somebody?
My code:
| Code: |
#include <18F66K80.h>
#device adc=12
#fuses HSH,NOPLLEN,NOFCMEN,BROWNOUT,BORV27,NOWDT,PUT,NOCPD,STVREN,NODEBUG,NOWRT,NOWRTD,NOIESO,NOEBTR,NOEBTRB,MCLR,PROTECT,NOCPB,NOWRTB,NOWRTC,NOXINST,SOSC_DIG // próba
#use delay(clock=20000000)
#use rs232(baud=19200,parity=N,xmit=PIN_G3,rcv=PIN_G0,bits=8)
int buffer[8],rx_len,rxstat;
int32 rx_id,rx_ad;
//send a request (tx_rtr=1) for 8 bytes of data (tx_len=8) from id 24 (tx_id=24)
int out_data[8];
int32 tx_id=36;
int1 tx_rtr=0;
int1 tx_ext=0;
int tx_len=8;
int tx_pri=3;
#include <can-18xxx8.c>
#include <math.h> // Math library for floor()
#include <stdlib.h>
#include <stdio.h>
#include <input.c>
void init_pic() {
setup_counters(RTCC_INTERNAL,RTCC_DIV_256 | L_TO_H);
setup_wdt(WDT_OFF);
setup_comparator(NC_NC_NC_NC);
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_vref(FALSE);
setup_psp(PSP_DISABLED);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1); // setup interrupts
setup_timer_3(T3_INTERNAL|T1_DIV_BY_1); //
USB_MOD =0; // RC4,RC5 digitális bemenet legyen
USB_TRANS=1; // RC4,RC5 digitális bemenet legyen
setup_ccp1(CCP_OFF); // Configure CCP1 as a PWM
setup_ccp2(CCP_OFF); // Configure CCP2 as a PWM
setup_ccp3(CCP_OFF); // Configure CCP2 as a PWM
setup_ccp4(CCP_OFF); // Configure CCP2 as a PWM
setup_ccp5(CCP_OFF); // Configure CCP2 as a PWM
}
#zero_ram
main() {
init_pic();
can_init(); //init can module
can_set_mode(CAN_OP_LOOPBACK);
while (1) {
can_putd(tx_id, out_data, tx_len,tx_pri,tx_ext,tx_rtr); //put data on transmit buffer
delay_ms(100);
if (can_kbhit())
{
can_getd(rx_id, &buffer[0],rx_len,rxstat);
rx_ad=rx_id&0x000000Ff; //get source address
rx_id=rx_id&0x00ffff00; //mask out irrevllant data
rx_id=rx_id>>8; //shift data to right 8 times
output_high(RS485_DIR);
// printf("rx_id = %4lu, rx_ad=%Lu", rx_id, rx_ad);
printf("TEXT(Txt_hiba, \"rx_id = %4lu, ry_ad=%u\" );;\r", rx_id, rx_ad );
while(!TRMT); // megvárja amig az utolso adat is kiküldésre kerül 1-be megy ekkor
output_low(RS485_DIR);
}
} // while
} // MAIN
|
The can-18xxx8.c modify to 500 kbps:
| Code: |
void can_set_baud(void) {
//500kbs @ 20MHz
BRGCON1 = 0x01;
BRGCON2 = 0xA0;
BRGCON3 = 0x02;
/* BRGCON1.brp=CAN_BRG_PRESCALAR;
BRGCON1.sjw=CAN_BRG_SYNCH_JUMP_WIDTH;
BRGCON2.prseg=CAN_BRG_PROPAGATION_TIME;
BRGCON2.seg1ph=CAN_BRG_PHASE_SEGMENT_1;
BRGCON2.sam=CAN_BRG_SAM;
BRGCON2.seg2phts=CAN_BRG_SEG_2_PHASE_TS;
BRGCON3.seg2ph=CAN_BRG_PHASE_SEGMENT_2;
BRGCON3.wakfil=CAN_BRG_WAKE_FILTER;
*/
}
|
|
|
 |
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Thu Jun 14, 2012 7:59 am |
|
|
Well, you didn't say if the loopback test worked at 125kbs. The CCS h files default the can bus to 125k. The best thing to check is to use the microchip can_bus configuration utility and obtain the acceptable values at 500k for the phase items propagation time seg 1 seg 2 sync etc. It may not matter with loop back ( it probably should ) since they are absolutely critical to a working system.
Now in case your aren't aware both the can_bus and the rs232 (485) are asynchronous. This means the while loop on the can_kbhit has to be fast in main. Sooner or later sooner is better you probably need to go to circular buffers driven by an interrupt isr on the can bus and a possible a circular transmit buffer on your printf to rs232 to reduce latency. I'd start by doing absolutely nothing more than a loop back test at 500k no extra code to check stuff etc. If that works I'd hook two can_bus target boards to each other and have them squawk at each other..send a one byte packet to each other. If that works add an interrupt isr to the can bus receive buffer full rx1 rx1 flags. The printf then needs protection via the interrupt disable parameter in use rs232. If it doesn't mess up the can receives then you may get away without a circular transmit buffer. Typically it pays to write one anyway unless the printfs are to be ripped out after testing. Attention has to be paid to delay_xx if they are time critical since the interrupts will slow them a tad. Often there are timers to spare so the delay_XX can be handled by setting up a 1ms tick.
Anyway go slow and test the addition of small amounts of code. Use __LINE__ at strategic points and watchdog timer ..restart clause to tell the last __LINE__ the code encountered before freezing. The can_bus is extremely reliable but it needs the correct software treatment. Yes it can freeze once in a rare while often due to small errors in code that we write. |
|
|
kontakt
Joined: 27 Jan 2011
Posts: 7
Location: HU
|
|
| Posted: Fri Jun 15, 2012 1:04 am |
|
|
I found something:
The can_putd() had a wrong setting, because the
int1 tx_ext=0;
That is why it sends message with standard ID. If it is TRUE I can receive the message.
The new question is how can I set the receive mask to get the standard ID also? |
|
|
kontakt
Joined: 27 Jan 2011
Posts: 7
Location: HU
|
|
| Posted: Mon Jun 18, 2012 4:10 am |
|
|
| I setted up the loopback mode and it works fine, that is why I set back to normal mode and tried to send a data. I can measure on the Tx line this message but it can I measure on the Rx pin also. Is it good? |
|
|
turhan
Joined: 24 Aug 2012
Posts: 9
|
|
| Posted: Mon Aug 27, 2012 10:17 am |
|
|
66k80 k family has different registers , you cant get it work . You have to change this registers . Also I have same problem.
| Code: |
/////////////////////////////////////////////////////////////////////////
//// can-18xxKxx.h new family ////
//// ////
//// Prototypes, definitions, defines and macros used for and with ////
//// the CCS CAN library for PIC18Fxx8 and PIC18Cxx8. ////
//// ////
//// (see can-18xxx8.c) ////
//// ////
/////////////////////////////////////////////////////////////////////////
//// (C) Copyright 1996,2003 Custom Computer Services ////
//// This source code may only be used by licensed users of the CCS ////
//// C compiler. This source code may only be distributed to other ////
//// licensed users of the CCS C compiler. No other use, ////
//// reproduction or distribution is permitted without written ////
//// permission. Derivative programs created using this software ////
//// in object code form are not restricted in any way. ////
/////////////////////////////////////////////////////////////////////////
|
++++++++++++++++++++++++++++
CCS driver code deleted.
Reason: Changed all getenv() to #byte. Still CCS driver.
Forum rule #10:
10. Don't post the CCS example code or drivers, or ask for such code and drivers.
Forum rules:
http://www.ccsinfo.com/forum/viewtopic.php?t=26245
- Forum Moderator
++++++++++++++++++++++++++++ |
|
|
Kroko87
Joined: 20 Jan 2011
Posts: 4
|
|
| Posted: Tue Aug 28, 2012 2:20 am |
|
|
Why do all use the old CAN-driver "can-18xxx8" for PICs like 18Fxx8x and 18FxxK80?
This driver is for the 18Fxx8 with CAN module and not for the ECAN in the newer PICs.
Use the "can-18F4580" driver files. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Wed Aug 29, 2012 4:25 am |
|
|
"can-18xxx8" is suitable for CAN hardware and ECAN hardware in non-extended modes. In other words its compatible with both. The newer "can-18F4580" is only needed to access the extended features of the ECAN modules. "can-18xxx8" has all the functions of "can-18xxx8", and is backwards compatible. You only need to change which file you include. I have tried and verified this.
For non-extended mode, in other words for most normal CAN use, "can-18xxx8"has more overhead than "can-18xxx8", in other words it generates larger, and a little slower code. I have tried and verified this.
Both drivers provide full extended ID capability. "Extended" in ECAN refers to the buffering modes, not to extended IDs.
It appears that the 18F4580 was the first PIC to have the ECAN hardware, but the driver is suitable for most ECAN hardware, except for some newer PICs.
It seems that some new PICs have changed some register assignments, introducing a compatibility issue so both "can-18xxx8" and "can-18F4580" won't work with those without modification. I haven't confirmed this.
Summary: "can-18xxx8" CAN and ECAN without access to extended features. "can-18F4580" for extended features of ECAN and all CAN features but a little slower and larger code than "can-18xxx8". Some new PICs need modification of both due to changed register locations.
Use "can-18xxx8" for most applications, and "can-18F4580" only if you need the extended features as it performs less efficiently for "normal" CAN use.
RF Developer. |
|
|
Bill24
Joined: 30 Jun 2012
Posts: 45
|
|
| Posted: Thu Aug 30, 2012 9:42 am |
|
|
| RF_Developer wrote: | "..
It seems that some new PICs have changed some register assignments, introducing a compatibility issue so both "can-18xxx8" and "can-18F4580" won't work with those without modification. I haven't confirmed this.
...
RF Developer. |
I am using can-18F4580 files with a PIC18F46K80 and have not needed to change any register assignments with compiler version 4.135. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
