compiler problems
 

this code in user routines fast.c is saying that there is a problem that we can't figure out.

#pragma code InterruptVectorLow = LOW_INT_VECTOR // problem is here<---
void InterruptVectorLow (void)
{
_asm
goto InterruptHandlerLow /*jump to interrupt routine*/
_endasm
}

The compiler says the error is: non-overlay and absolute but occurs in more than one input file.

There is also an _entry_scn with the same problem, located in ifi_startup.

#pragma code _startup_scn
void _startup (void)
{
_asm
/* Initialize the stack pointer */
lfsr 1, _stack lfsr 2, _stack clrf TBLPTRU, 0 /* 1st silicon doesn't do this on POR */
bcf FPFLAGS,RND,0 /* Initialize rounding flag for floating point libs */

/* initialize the flash memory access configuration. this is harmless */
/* for non-flash devices, so we do it on all parts. */
bsf 0xa6, 7, 0
bcf 0xa6, 6, 0
_endasm

Please help. it is the only problem we have left in our robot's code.

Re: compiler problems
 

UPDATE:
Ok, a new problem has arisen for us. We found the problem with our compiler problems, but now our encoders will not work. Somehow, while we were fixing our compiler data, we accidentally broke our PID code, which we've made from scratch. anyone knowing how to fix the encoders please give us some info.

Re: compiler problems
 

if u go to kevin's code repository they have encoder code and more. try getting your code from there

Re: compiler problems
 

Your encoders undoubtedly depend on interrupts, and that is the area of code where you had the problem (the #pragma).

Look at the default code again and see where the #pragma belongs and what it should like like. And make sure your encoder interrupt-service-routines are being called when the appropriate interrupt occurs.

The #pragma, by the way, tells the compiler to save and restore CPU registers when invoking the routine (when an interrupt happens).

Re: compiler problems
 

Try the search function,

"The compiler says the error is: non-overlay and absolute but occurs in more than one input file.
There is also an _entry_scn with the same problem, located in ifi_startup."

issue has been discussed is several other threads including:

http://www.chiefdelphi.com/forums/sh...ght=_entry_scn