| View previous topic :: View next topic |
| Author |
Message |
tae
Joined: 15 Jan 2010
Posts: 11
|
| Bug #int_ra routine family Enhanced Mid-range |
 Posted: Mon Dec 17, 2012 3:48 pm |
 |
|
Hi Guys!
At a one Russian forum, we found a problem with your compiler.
PIC12F1822 list source code
| Code: | #include <12LF1822.h>
#case
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES NOCPD //No EE protection
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOMCLR //Master Clear pin not enabled
#FUSES NOPUT //No Power Up Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES INTRC_IO
#USE delay(internal=4M)
//***********************************************************************************************************************
#INT_RA
void isr_ra(void) {
}
//***********************************************************************************************************************
void main()
{
int8 dummy;
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_comparator(NC_NC);
set_tris_a(0b00001000);
dummy=input_a();
clear_interrupt(INT_RA);
enable_interrupts(INT_RA3);
enable_interrupts(GLOBAL);
for(;;) {
};
} |
piece of asm LST file:
| Code: | .................... //***********************************************************************************************************************
.................... #INT_RA
.................... void isr_ra(void) {
....................
.................... }
....................
.................... //***********************************************************************************************************************
001C: BCF 0B.0
001D: MOVLP 00
001E: GOTO 013
.................... void main()
.................... {
001F: CLRF 05 |
why the compiler is trying to clear the bit IOCIF
which is described as a datasheet Read-Only, instead to reset the bit in the register IOCAF ?
for PIC12F675/683 and more old family PIC this situation is true
but for PIC with family Enhanced Mid-range this not work, they should reset an appropriate bit in IOCAF.
This situation has been tested by the three controllers 12F1822, 16f1824, 16f1936
can comment ?
p.s. I sorry for my English |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Mon Dec 17, 2012 6:22 pm |
|
|
Which version of the compiler? CCS is very good at fixing 'bugs' , once they are reported(not here by the way) and they update the compilers very often.
They also post version and updates on their website.
hth
jay |
|
|
tae
Joined: 15 Jan 2010
Posts: 11
|
|
| Posted: Mon Dec 17, 2012 6:42 pm |
|
|
no problem, we use version 4.138
| Quote: | | not here by the way |
and where ? |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1934
Location: Norman, OK
|
|
| Posted: Mon Dec 17, 2012 6:55 pm |
|
|
Read the notice in the upper right corner of this web page!
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Mon Dec 17, 2012 10:01 pm |
|
|
| dyeatman wrote: | | Read the notice in the upper right corner of this web page! |
In fairness a sanity check is nice...
But yes -- if it's a bug, it should be reported to [email protected]
Now -- Setting a R/O bit isn't so much a bug if there are other parts that might need that because the bit is R/W.
I wouldn't call that a bug since it, by itself, doesn't break anything.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
| Re: Bug #int_ra routine family Enhanced Mid-range |
| Posted: Tue Dec 18, 2012 6:58 am |
|
|
Yes, you have found a bug, but not a serious one, it is doing nothing only wasting a few bytes of memory and slows down your ISR a tiny bit.
Still worth to report to CCS at the above mentioned link.
| tae wrote: | | ... they should reset an appropriate bit in IOCAF. |
This has confused many other programmers on this forum but is correct behaviour. For most interrupts the CCS compiler clears the interrupt flag for you, which is nice. But the compiler can not clear the Interrupt-On-Change flag because it depends on your software. Sometimes, you as a programmer can have good reasons for not clearing the interrupt flag; for example when 3 pins have all changed but in your software you can only handle one change at a time. Perhaps you should write better software that can handle all changes at the same time, but that is up to you and not enforced by the CCS compiler.
For the correct procedure on clearing the IOC flags see the chapter 13.4 in the PIC12F1822 data sheet. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19537
|
|
| Posted: Tue Dec 18, 2012 10:03 am |
|
|
Yes. Compile with the interrupt set to 'NOCLEAR', then the compiler will no longer generate the faulty code, and do the clear yourself the correct way (XOR the bits you have used, then AND this with the register).
A bug, should be reported, but easily programmed round.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Dec 18, 2012 7:29 pm |
|
|
In general, CCS does not clear the condition that caused the interrupt.
You have to do it manually, in code in the isr. For example, you have
to call getc() in #int_rda, and you have to read PortB, or a pin on PortB
in #int_rb, etc.
This post shows how to clear the IOCAF flag in a 12F1822:
http://www.ccsinfo.com/forum/viewtopic.php?t=46785&start=2 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
