why does this code generate an error "INTCON1bits_TMR0IF = 0 not found"

[okmn]

hi,guys,
why does this code generate an error "INTCON1bits_TMR0IF = 0 not found"

Code Select Expand

  ' Demonstrate the use of context saving of the compiler's System variables
' Creates low and high priority interrupts incrementing on Timer0 and Timer1
' Within the interrupts a value is displayed and incremented
' In the foreground another value is incremented and transmitted serially
'
Include "Proton18_4.Inc" ' Use the Proton Board with an 18F device
'
' Point to the High Priority interrupt handler to the subroutine
'
On_Hardware_Interrupt GoTo ISR_High
'
' Point to the Low Priority interrupt handler to the subroutine
'
On_Low_Interrupt GoTo ISR_Low
'
' Create some variables
'
Dim HighCounter As Dword ' Counter for the high interrupt routine
Dim LowCounter As Dword ' Counter for the low interrupt routine
Dim ForeGroundCounter As Dword ' Counter for the Foreground routine
Dim wTimer0 As TMR0L.Word ' Create a 16-bit Word from registers TMR0L/H
Dim wTimer1 As TMR1L.Word ' Create a 16-bit Word from registers TMR1L/H
' ------------------------------------------------------------------
GoTo Main ' Jump over any subroutines
'
' ------------------------------------------------------------------
' High Priority Hardware Interrupt Handler
' Interrupt's on a Timer1 Overflow. Display on the LCD and increment a value
'
ISR_High:
'
' Save the compiler's system variables used in the interrupt routine only
' Also save any SFRs used
'
Context Save PORTD, TRISD
If PIR1bits_TMR1IF = 1 Then ' Is it a Timer1 overflow interrupt?
' Yes. So Display the value on the LCD
Print At 1,1,"High Int ", Dec HighCounter
Inc HighCounter ' Increment the value
PIR1bits_TMR1IF = 0 ' Clear the Timer1 Overflow flag
EndIf
'
' Restore compiler's system variables used within the interrupt routine only
' and exit the interrupt
'
Context Restore
' ------------------------------------------------------------------
' Low Priority Hardware Interrupt Handler
' Interrupt's on a Timer0 Overflow
' Display on the LCD and increment a value
'
ISR_Low:
' Save the compiler's system variables used in the interrupt routine only
' Also save any SFR's used.
'
Context Save PORTD, TRISD
If INTCON1bits_TMR0IF = 1 Then ' Is it a Timer0 overflow interrupt?
'
' Yes. So Disable Timer 1 High priority interrupt while we use the LCD
'
PIE1bits_TMR1IE = 0 ' Display the value on line 2 of the LCD
Print At 2,1,"Low Int ", Dec LowCounter," "
Inc LowCounter ' Increment the value
PIE1bits_TMR1IE = 1 ' Re-Enable the Timer1 High priority interrupt
INTCON1bits_TMR0IF = 0 ' Clear the Timer0 Overflow flag
EndIf
'
' Restore the compiler's system variables used in the interrupt routine only ' and
'exit the interrupt
'
Context Restore
'
' ------------------------------------------------------------------
' The Main Program Loop Starts Here
'
Main:
DelayMS 100 ' Wait for the LCD to stabilise
INTCON1 = 0 ' Disable Interrupts
Low PORTD ' Set PORTD to Output Low
HighCounter = 0
LowCounter = 0
ForeGroundCounter = 0
Cls ' Clear the LCD
'
' Setup Timer0
'
T0CONbits_T0PS2 = 0 ' \
T0CONbits_T0PS1 = 0 ' | Timer0 Prescaler to 1:4
T0CONbits_T0PS0 = 1 ' /
T0CONbits_PSA = 0 ' Assign the prescaler
T0CONbits_T0CS = 0 ' Increment on the internal Clk
T0CONbits_T08Bit = 0 ' Timer0 is configured as a 16-bit counter
wTimer0 = 0 ' Clear Timer0
T0CONbits_TMR0ON = 1 ' Enable Timer0
'
' Setup Timer1
'
T1CONbits_RD16 = 1 ' Enable Timer1 in 16-bit operation
T1CONbits_T1CKPS1 = 0 ' \ Timer1 Prescaler to 1:2
T1CONbits_T1CKPS0 = 0 ' /
T1CONbits_T1OSCEN = 0 ' Disable External Oscillator
T1CONbits_TMR1CS = 0 ' Increment on the internal Clk
wTimer1 = 0 ' Clear Timer1
T1CONbits_TMR1ON = 1 ' Enable Timer1
'
' Setup the High and Low priority interrupts
'
INTCON1bits_TMR0IE = 1 ' Enable the Timer0 overflow interrupt
INTCON2bits_TMR0IP = 0 ' Timer0 Overflow Interrupt to Low priority
INTCON1bits_TMR1IE = 1 ' Enable the Timer1 overflow interrupt
IPR1bits_TMR1IP = 1 ' Timer1 Overflow Interrupt to High priority
RCONbits_IPEN = 1 ' Enable priority levels on interrupts
INTCON1bits_GIEL = 1 ' Enable low priority peripheral interrupts
INTCON1bits_GIE = 1 ' Enable all high priority interrupts
'
' Display value in foreground while interrupts do their thing in background
'
Do ' Create an infinite loop
' Display the value on a serial terminal
HRSOut "ForeGround ", Dec ForeGroundCounter, 13
Inc ForeGroundCounter ' Increment the value
DelayMS 200
Loop ' Close the loop. i.e. do it forever


[RGV250]

Hi,
Probably because it is INTCONbits, not INTCON1bits.

 in the def file.
; INTCON Bits
$define INTCONbits_GIE INTCON.7
$define INTCONbits_GIEH INTCON.7
$define INTCONbits_PEIE INTCON.6
$define INTCONbits_GIEL INTCON.6
$define INTCONbits_TMR0IE INTCON.5
$define INTCONbits_T0IE INTCON.5
$define INTCONbits_INT0IE INTCON.4
$define INTCONbits_INT0E INTCON.4
$define INTCONbits_RBIE INTCON.3
$define INTCONbits_TMR0IF INTCON.2
$define INTCONbits_T0IF INTCON.2
$define INTCONbits_INT0IF INTCON.1
$define INTCONbits_INT0F INTCON.1
$define INTCONbits_RBIF INTCON.0

Bob

[top204]

Bob is correct.

The original code was written for a PIC18F25K20 device, which has the INTCON1 SFR, but Microchip keep changing names for SFRs, so even though it does the same operation as the INTCON SFR, its name was changed to INTCON1 in the data produced by Microchip. Unbelievably stupid, I know, but they continuously do it with each new device!

For the bit names, take a look in the the device's .def file and it has a whole list of the bits associated with the SFRs.

[RGV250]

Hi,
Just in case you do not know about the "def" files, they are in ProgramFiles(x86)\ProtonIDE\PDS\Includes\defs (or ProgramFiles for 32 bit). It is work looking if you do get an error like the one you have in the future.
I always open with Notepad++ but I think Notepad will do as well.

Bob

[okmn]

can't all changes that require such correction be included in the compiler itself?

[RGV250]

I am sure if it was possible Les would have done it as he has already made a fantastic job of taking all the hard would out for us.
The problem is that Microchip keep changing their minds what the call things.

Bob

[top204]

If I were to change the names of all the SFRs to suit "what they used to be", it would make a nonsense of reading a datasheet for a device!

The datasheet would read something like, "Bit-7 of the INTCON1 SFR controls interrupt enabling". However, when the datasheet was read and searched, there would be no reference at all to the INTCON SFR, when an error is produced or code is written, because it is now known, officially, as the INTCON1 SFR.

I have added some extras in the compiler's SFR names so that they match for the compiler's internal library creations. i.e. SSPCON1 as well as SSP1CON1, which it now is. However that is purely so the compiler can generate its libraries without hundreds of if(SFR is named this) || (SFR is named that) comparisons in its code creation, and the SFRs must operate exactly the same as they uses to do. If they do not operate the same, they are changed to the official name and bits within them. Have you any idea of the logistics involved in creating the data for every single device available in the compilers? Thousands upon thousands of lines of text and code that always has to be correct and checked!!! It has taken years of dedication, by me alone, to get them to the standard they are.

If a user does not like the, official, name given, it can always be changed with their own $defines in the program or library routines. But always read a datasheet if the compiler gives an error concerning an SFR or peripheral, because Microchip will probably have changed something in the device, as opposed to the device the program was originally written for. Sorry, but I have always done that and I thought it was part of "being a programmer". i.e. An inquisitive mind and a finder of why code works, or does not work, and not simply copying and pasting and expecting everything to be Rosey. That does not work in any situation, code or real life. :-)

[okmn]

after i added that lines  marked in red in 18F452.def files
you were talking about it to do!.
there is no any error now.
thanks.

; INTCON Bits.........................these lines are same not touched
$define INTCONbits_GIE INTCON.7
$define INTCONbits_GIEH INTCON.7
$define INTCONbits_PEIE INTCON.6
$define INTCONbits_GIEL INTCON.6
$define INTCONbits_TMR0IE INTCON.5
$define INTCONbits_T0IE INTCON.5
$define INTCONbits_INT0IE INTCON.4
$define INTCONbits_INT0E INTCON.4
$define INTCONbits_RBIE INTCON.3
$define INTCONbits_TMR0IF INTCON.2
$define INTCONbits_T0IF INTCON.2
$define INTCONbits_INT0IF INTCON.1
$define INTCONbits_INT0F INTCON.1
$define INTCONbits_RBIF INTCON.0

i added these lines all
; INTCON1 Bits
$define INTCON1bits_GIE INTCON.7
$define INTCON1bits_GIEH INTCON.7
$define INTCON1bits_PEIE INTCON.6
$define INTCON1bits_GIEL INTCON.6
$define INTCON1bits_TMR0IE INTCON.5
$define INTCON1bits_TMR1IE INTCON.5
$define INTCON1bits_T1IE INTCON.5
$define INTCON1bits_INT1IE INTCON.4
$define INTCON1bits_INT1E INTCON.4
$define INTCON1bits_RBIE INTCON.3
$define INTCON1bits_TMR0IF INTCON.2
$define INTCON1bits_TMR1IF INTCON.2
$define INTCON1bits_T1IF INTCON.2
$define INTCON1bits_INT1IF INTCON.1
$define INTCON1bits_INT1F INTCON.1
$define INTCON1bits_RBIF INTCON.0

[RGV250]

Hi,
Either will work but I would have altered the code and removed the 1, the reason for this is that a future update may overwrite the DEF file and then you are back to square one.

Regards,
Bob

[top204]

A future update will overwrite the .def file.

It is an intricate part of the compilers so it will be overwritten. All changes should be placed within the user's programs. Then the updates will not touch them in any way, shape or form.

[okmn]

hmm, now I understand this subject better;
I was seeing lines beginning with "$ define" in many sample codes and trying to understand.? what is this? ...

but still I haven't been able to put kingdom of  "Procedures" in place of my mind completely.!!!!
but it will be one day exactly.