Searching \ for '[PIC] Problem with IRQ on PIC16F877' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=16F
Search entire site for: 'Problem with IRQ on PIC16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Problem with IRQ on PIC16F877'
2007\06\14@102434 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
I have a problem.

I am using a PIC16F877 and a timer triggered IRQ service routine.
Now, I have the problem, that sometimes, the main loop is hanging.
My suggestion is, that in certain condition, if the main loop is doing
some calculation, the IRQ is occuring, and something is not restored
after the IRQ was worked out. I know, that Push/Pull of registers must
be done by hand, but I am not sure, if I catched all I need.

My IRQ routine is as following:

       ORG            0x004             ; interrupt vector location
       movwf          w_temp            ; save off current W register
contents
       swapf                STATUS,W          ; move status register into W
register
       clrf            STATUS              ; ensure file register bank set
to 0
       movwf                status_temp       ; save off contents of STATUS
register
       movf                PCLATH,W
       movwf                pclath_temp
       clrf                PCLATH
               
       call                ISR_H                        ; call the interrupt
service codes
               
       movf                pclath_temp,W
       movwf                PCLATH
       swapf                status_temp,w                
       movwf                STATUS                  ; restore pre-isr STATUS
register contents
       swapf          w_temp,f
       swapf          w_temp,w                ; restore pre-isr W
register contents
       retfie                          ; return from interrupt


ISR_H
       ...
       ...
       ...
       return


MAIN        
       ...
       ...
       ...
       goto Main


Best Jens

2007\06\14@104005 by Dario Greggio

face picon face
Jens M. Guessregen / Mailinglists wrote:

> I have a problem.
> I am using a PIC16F877 and a timer triggered IRQ service routine.


could you try placing the ISR code directly into place, rather than
"calling" it?
Could it be a stack overflow?...

--
Ciao, Dario

2007\06\14@115438 by Rikard Bosnjakovic

picon face
On 6/14/07, Jens M. Guessregen / Mailinglists
<spam_OUTjmg_mailinglistsTakeThisOuTspammcm-it.de> wrote:

> ISR_H
>         ...
>         return

If ISR_H is not too big, feel free to post it as well. It might
contain something useful for us to know, and perhaps it's traceable
without the rest of the code.


--
- Rikard - http://bos.hack.org/cv/

2007\06\14@121830 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> > I have a problem.
> > I am using a PIC16F877 and a timer triggered IRQ service routine.
>
>
> could you try placing the ISR code directly into place,
> rather than "calling" it?
> Could it be a stack overflow?...

Stack? Is there a stack in a 16F877A?

Anyway, the code for the ISR is big, and it is not the ISR, which is
hanging.
There is a small routine to have a LED blinking with the ISR, and this
LED is always blinking.

Another LED was put inside the main, and that one is stopping blinking.

Best Jens

2007\06\14@122849 by Dario Greggio
face picon face
Jens M. Guessregen / Mailinglists wrote:
> Stack? Is there a stack in a 16F877A?

ahem, *any* CPU has a stack... if it allows for subroutine calls and/or
interrupts :)

> Anyway, the code for the ISR is big, and it is not the ISR, which is
> hanging.

What could happen, is that, if Main code has already used 8 slots of
Stack (the maximum), an interrupt coming in that moment, could cause a
Stack overflow, and maybe make the main code jump to nowhere

--
Ciao, Dario

2007\06\14@122902 by Rikard Bosnjakovic

picon face
On 6/14/07, Jens M. Guessregen / Mailinglists
<.....jmg_mailinglistsKILLspamspam@spam@mcm-it.de> wrote:

> Stack? Is there a stack in a 16F877A?

Yes, an internal call-stack (for subroutines), IIRC 8 words deep. The
user cannot read/alter it.


--
- Rikard - http://bos.hack.org/cv/

2007\06\14@123640 by Nicola Perotto

picon face


Jens M. Guessregen / Mailinglists wrote:
>>> I have a problem.
>>> I am using a PIC16F877 and a timer triggered IRQ service routine.
>>>      
>> could you try placing the ISR code directly into place,
>> rather than "calling" it?
>> Could it be a stack overflow?...
>>    
>
> Stack? Is there a stack in a 16F877A?
>  
"all" PIC16 have a 8 level deep stack for call/return, see DS39582B
section 2.0 Memory organization!!!
> Anyway, the code for the ISR is big, and it is not the ISR, which is
> hanging.
>  
My english is bad but... there is not a contradiction?
In any case because the ISR interrupt (!) the main code it (ISR) can not
hang but can (often occurs) let hang the main code.

> There is a small routine to have a LED blinking with the ISR, and this
> LED is always blinking.
>
> Another LED was put inside the main, and that one is stopping blinking.
>
> Best Jens
>
>  

2007\06\14@124058 by Alan B. Pearce

face picon face
>Stack? Is there a stack in a 16F877A?

Err, yes, all 8 words of one. Where do you think the machine stores the
return address on interrupt or subroutine call?

>Anyway, the code for the ISR is big,

That is always a bad sign ...

>and it is not the ISR, which is hanging.

Sure about that? (see (1) below)

>There is a small routine to have a LED blinking with
>the ISR, and this LED is always blinking.
>
>Another LED was put inside the main, and that
>one is stopping blinking.

It sounds to me that one (or both) of two things is happening.

1. The ISR takes so long to execute that there is never enough time for the
main to do an instruction before the next interrupt arrives.

2. The ISR has subroutine calls that have overflowed the stack and wiped out
the return to main program address.

2007\06\14@124237 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> > Stack? Is there a stack in a 16F877A?
>
> Yes, an internal call-stack (for subroutines), IIRC 8 words
> deep. The user cannot read/alter it.

Ok, you are talking about the stack used for CALL's, that the CPU can
return, where it came from?

That is a good idea, since I am working with a lot of call's inside
calls ...

Best Jens

2007\06\14@130517 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> >Stack? Is there a stack in a 16F877A?
>
> Err, yes, all 8 words of one. Where do you think the machine
> stores the return address on interrupt or subroutine call?

Sorry, I was not aware of this stack. I learned on a x86 architecture,
so I did not cared about the call&return stack, which is only 8 byte in
PIC ;-)

> >Anyway, the code for the ISR is big,
>
> That is always a bad sign ...

No, it is not sooo big ...

> >and it is not the ISR, which is hanging.
>
> Sure about that? (see (1) below)

Yes. The LED which is switched on and off in the IRS, is still blinking,
even if main loop is hanging.
So, the ISR must return correctly, otherwise a new INT could not be
worked out ...

{Quote hidden}

The timer is set to 25 ms. The code is about 100 lines of code at a 10
MHz prozessor.
So it could not be to big. And the ISR code worked in another project
before.
What I changed is the main loop.

> 2. The ISR has subroutine calls that have overflowed the
> stack and wiped out the return to main program address.

That is, very I have to look. I am working a lot with call's to keep
code small, but thsi seems to be turning out the problem.

I tried to disable the INT before making calls in the main loop amd
enable after return from call, and it improved the situation dramaticly.

Best Jens

2007\06\14@133609 by Rolf

face picon face
Sounds to me like there is an interrupt flag that you are not clearing
before exiting the interrupt routine. Have you double checked that *all*
IE flags are set to 0, and that only the ones you are servicing in the
ISR are set to 1? Have you ensured that you are setting the IF flag to 0
in your ISR for all the enabled interrupts?

Rolf

Jens M. Guessregen / Mailinglists wrote:
{Quote hidden}

2007\06\14@135647 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> Sounds to me like there is an interrupt flag that you are not
> clearing before exiting the interrupt routine. Have you
> double checked that *all* IE flags are set to 0, and that
> only the ones you are servicing in the ISR are set to 1? Have
> you ensured that you are setting the IF flag to 0 in your ISR
> for all the enabled interrupts?

Yes.

It is the stack.
I removed some calles in the main code, now it is running.
But now, my space in page 0 is very small, I need to go to page 1.

And there if have the next problem.

Using

       pagesel        pgmcode
       goto                pgmcode

       org        0x0800
pgmcode
       .
       .
       .
       goto pgmcode


Is just hangin the system, nothing is working anymore.

My idea is to move most of the main loop to page 1, using page 0 more or
less only for the ISR ...

Best Jens

2007\06\14@140432 by wouter van ooijen

face picon face
> ahem, *any* CPU has a stack... if it allows for subroutine
> calls and/or interrupts :)

Not necesarrily. An ARM for for instance saves the return address of a
call in a dedicated register (LR), and in another dedicated register
when an interrupt occurs. An ARM also has instructions that make it easy
to implement a stack unsing any of the 14 remaining registers (LR and PC
are possible in theory but not practical), but that is all up to tyhe
user - the CPU does not enforce it at all. (I guess you could treply by
saying that an ARM has two dedicated, 1 level stacks...)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu




2007\06\14@160618 by Robert Ammerman

picon face
>>Anyway, the code for the ISR is big,
>
> That is always a bad sign ...
>

This is not a true statement. I have several times developed systems that
required accurate timing for complex functions ( multiple simultaneous
software UARTs, software video generation) in which nearly all CPU time, and
a large proportion of code were in a (timer) interrupt handler. One useful
trick here is that you may be able compute the correct outputs for interrupt
N+1 during interrupt N, save them, and them output them at the very start of
interrupt N+1. This can result in (on a PIC at least!) ZERO jitter.

Bob Ammerman
RAm Systems


2007\06\14@164827 by Dario Greggio

face picon face
wouter van ooijen wrote:

>>ahem, *any* CPU has a stack... if it allows for subroutine
>>calls and/or interrupts :)
>
> Not necesarrily. An ARM for for instance saves the return address of a
> call in a dedicated register (LR), and in another dedicated register
> when an interrupt occurs. An ARM also has instructions that make it easy
> to implement a stack unsing any of the 14 remaining registers (LR and PC
> are possible in theory but not practical), but that is all up to tyhe
> user - the CPU does not enforce it at all. (I guess you could reply by
> saying that an ARM has two dedicated, 1 level stacks...)

Hi Wouten, if I am understanding well from the little I see about ARMs,
it looks like the old core of Acorn Archimedes (1989) is alive and kicking!
I remember that great architecture, with 4MHz, 4MIPS. There were some 16
registers, 32 bits, and you could almost anything with anyone.
I remember that one was used as a Stack Pointer, and another as a Frame
pointer.
I did not know (or remember) this thing about interrupt, and may also be
that things changed a little. But, in the and, some Stack will always be
needed in a CPU :)

Thank you for pointing this out.


--
Ciao, Dario

2007\06\15@015700 by wouter van ooijen

face picon face
> Hi Wouten, if I am understanding well from the little I see
> about ARMs,
> it looks like the old core of Acorn Archimedes (1989) is
> alive and kicking!

It is. Some small changes since those days, but it is essentially the
same chip.

> I remember that great architecture, with
> 4MHz, 4MIPS.

nowadays it is ~ 60 MHz/60 MIPS for what I see as 'the upward
alternative to
PIC/AVR/etc': single-chip microcontrollers. or >= 150 MHz for
microprocessor
(external memory) style chips, which often run a Linux variation.

> I remember that one was used as a Stack Pointer, and
> another as a Frame pointer.

With the empasis on "used as". There is no dedocated stack pointer, just
a bunch of
instruction formats that can use any register as stack pointer or frame
pointer.

> I did not know (or remember) this thing about interrupt, and
> may also be that things changed a little.

I don't know that much about th early ARMs.

> But, in the and, some Stack will always be needed in a CPU :)

Now it is down to semantics, but I disagree with "in", and to some
extent with the whole sentence.
IIRC the DG Nova stored the return address of a subroutine 'call' in the
first address of the
called subroutine... IIRC the SC/MP did something like the ARM: copy the
return address to a register.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\06\15@023537 by Mark Rages

face picon face
On 6/14/07, Jens M. Guessregen / Mailinglists
<jmg_mailinglistsspamKILLspammcm-it.de> wrote:
> > > Stack? Is there a stack in a 16F877A?
> >
> > Yes, an internal call-stack (for subroutines), IIRC 8 words
> > deep. The user cannot read/alter it.
>
> Ok, you are talking about the stack used for CALL's, that the CPU can
> return, where it came from?
>
> That is a good idea, since I am working with a lot of call's inside
> calls ...
>

Draw a tree of your calls outside the ISR, and your calls inside the ISR.

Count the levels of the trees and add them together.

If it is more than 8, you can exceed the stack depth and the processor
will forget where it is coming from.  I usually notice this when I
have a working system, then add one more function and everything stops
working.  The solution is to flatten the program.  One optimization
that I have found useful is, if you have a call followed by a return,
you can replace those with a goto.  That saves one stack level.  Also,
small functions or functions called only once can be replaced with
macros.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
.....markragesKILLspamspam.....midwesttelecine.com

2007\06\15@025811 by William Chops Westfield

face picon face

On Jun 14, 2007, at 11:04 AM, wouter van ooijen wrote:

>> ahem, *any* CPU has a stack... if it allows for subroutine
>> calls and/or interrupts :)
>
> Not necesarrily. An ARM for for instance saves the return address
> of a call in a dedicated register (LR)

And DEC's PDP-10 architecture had a bunch of function call instructions
that put the return address in various odd places (registers, memory)
as well as instructions that could turn any register into a stack
pointer,
which gained popularity with the onslaught of languages that allowed
recursion.  (IIRC, the standard fortran compiler did NOT use stack based
function calls...)

> IIRC the DG Nova stored the return address of a subroutine 'call' in
> the
> first address of the called subroutine...

That was one of the mechanisms in the pdp10 as well.  There were also
instructions that saved the return address in a register, with or
without
first saving the register in a specific memory location.

And the 1802 microprocessor did a subroutine call by loading the address
into a register and changing the PC to be that register.


BillW

2007\06\15@042305 by Dario Greggio

face picon face
wouter van ooijen wrote:

>>I remember that one was used as a Stack Pointer, and
>>another as a Frame pointer.
>
> With the empasis on "used as". There is no dedocated stack pointer, just
> a bunch of
> instruction formats that can use any register as stack pointer or frame
> pointer.


Yeah, R14-R15... The absolute, complete "simmetry" among source Reg,
dest Reg, and shifts or else to be performed, all in a single MOV, was
something astonishing and so different for those who used to work with
6502 and 8088

>>But, in the and, some Stack will always be needed in a CPU :)
>
> Now it is down to semantics, but I disagree with "in", and to some
> extent with the whole sentence.
> IIRC the DG Nova stored the return address of a subroutine 'call' in the
> first address of the

Of course there are other methods, I agree.
One downside that I can see with the above "ARM" method, is that you
could not go recursive... I guess.
A good compiler should check for the correct saving method, depending on
single cases. Oh, not to mention parameter passing, which anyway, again,
can be handled in different ways.


--
Ciao, Dario

2007\06\15@042910 by Alan B. Pearce

face picon face
>IIRC the DG Nova stored the return address of a subroutine
>'call' in the first address of the called subroutine...

I worked on a small business machine called Qantel that did this as well.

2007\06\15@043704 by Alan B. Pearce

face picon face
>>>Anyway, the code for the ISR is big,
>>
>> That is always a bad sign ...
>>
>
>This is not a true statement. I have several times developed
>systems that required accurate timing for complex functions
>( multiple simultaneous software UARTs, software video
>generation) in which nearly all CPU time, and a large proportion
>of code were in a (timer) interrupt handler. One useful trick
>here is that you may be able compute the correct outputs for
>interrupt N+1 during interrupt N, save them, and them output
>them at the very start of interrupt N+1. This can result in
>(on a PIC at least!) ZERO jitter.

Granted there are specialised cases where one puts a lot of code in the
interrupt, but these cases are really 'the exception that proves the rule'.
You NEED to know just what you are doing to make it work right, and take
some care about how it is coded.

2007\06\15@062918 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> > That is a good idea, since I am working with a lot of call's inside
> > calls ...
> >
>
> Draw a tree of your calls outside the ISR, and your calls
> inside the ISR.

Exactly what I did last night ;-)
I removed some of the call's to small routines and added code directly
in place of the call.
Now it is running since hours and no hnging anymore ..
 
{Quote hidden}

Yes, but working with makros does not solve the space issue ;-)
I like to work with call's to spare memory space and to get a more
readable code.

I already have a lookup table on the last page, and that works pretty
well, but I still have not get some "real" code working on the second
page :-( Always, when I put code on the second page and go there with
pagesel xxx and call xxx, PIC does not even start.

It seems, that I will be able to put everything (except the tables) to
page 1 in this project, but I am very courious about, what I am doing
wrong ...


Best Jens

2007\06\15@063723 by Dario Greggio

face picon face
Jens M. Guessregen / Mailinglists wrote:

> Using
>
>        pagesel        pgmcode
>        goto                pgmcode
>
>        org        0x0800
> pgmcode
>        .
>        .
>        .
>        goto pgmcode

Hi, glad you solved at least in part.

This pagesel method usually works.
Of course, are you saving PCLATH in the Interupt? Guess so.

The above code is good enough. But, in case you were CALLing, you have
to remember to go like this:

pagesel        pgmcode
call        pgmcode
pagesel $


In case you're interested, Olin Lathrop has developed some macros which
try to "follow" program's flow, in order to save pagesels when they're
redundant.
I did do something similar, it helps saving some bytes :)

--
Ciao, Dario

2007\06\15@064536 by wouter van ooijen

face picon face
> Of course there are other methods, I agree.
> One downside that I can see with the above "ARM" method, is that you
> could not go recursive... I guess.

The 'standard' way to make it possible to call a subroutine (not just
recursion!) from within a subroutine is to save LR (along with any other
registers that need to be saved) in the first statement of the
subroutine. In the last statement of the subroutine those registers are
restored, but the LR content is restored to the PC:

  stmfd   sp!, { r5-r7, lr }
  ...
  ldmfd   sp!, { r5-r7, pc }

There are other options, like saving lr in a register.

A leaf subroutine (one that calls no further subroutines) need not save
LR, and can end with a simple 'move LR to PC'. For an otherwise fast
subroutine this can be a significant time saving (no need to access
RAM).

> A good compiler should check for the correct saving method,
> depending on
> single cases. Oh, not to mention parameter passing, which
> anyway, again,
> can be handled in different ways.

in registers, in memory (fixed addresses)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\06\15@064610 by Alan B. Pearce

face picon face
>I already have a lookup table on the last page, and that works
>pretty well, but I still have not get some "real" code working
>on the second page :-( Always, when I put code on the second
>page and go there with pagesel xxx and call xxx, PIC does not
>even start.

Are you saving PCLATH in your ISR ??

2007\06\15@075704 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> >
> >        pagesel        pgmcode
> >        goto                pgmcode
> >
> >        org        0x0800
> > pgmcode
> >        .
> >        .
> >        .
> >        goto pgmcode
>
> Hi, glad you solved at least in part.
>
> This pagesel method usually works.
> Of course, are you saving PCLATH in the Interupt? Guess so.

Yes, I do so, but this issue is independent from ISR. I have the same
without ISR in my code.

> The above code is good enough. But, in case you were CALLing,
> you have to remember to go like this:
>
> pagesel        pgmcode
> call        pgmcode
> pagesel $

Never seen pagesel $ before in any sample code ...

Best Jens

2007\06\15@082758 by Alan B. Pearce

face picon face
>> This pagesel method usually works.
>> Of course, are you saving PCLATH in the Interupt? Guess so.
>
>Yes, I do so, but this issue is independent from ISR.
>I have the same without ISR in my code.

Are you doing another pagesel for the next call, that happens to go to the
lower page? If not this will send your code into hyperspace as PCLATH is NOT
restored on the subroutine return.

2007\06\15@090939 by Artem Zezyulinskiy / SEDATELEC

flavicon
face

>  Always, when I put code on the second page and go there with
> pagesel xxx and call xxx, PIC does not even start.
>  

Jens, I'm not sure to understoud your problem,
but try to use
lcall xxx
pagesel xxx
pagesel $

lcall will put PCLATH to the page with xxx subroutine
--
------------------------------------------------------------------------
Logo Sedatelec <http://www.sedatelec.com>
       
Artem ZEZYULINSKIY <EraseMEartemzezspam_OUTspamTakeThisOuTsedatelec.com>
SEDATELEC <http://www.sedatelec.fr/>, Chemin des Mûriers - Irigny 69540
- FRANCE
Tel : +33 [0]4 72 66 33 26






2007\06\15@091207 by Jens M. Guessregen / Mailinglists n/a

flavicon
face

> Are you doing another pagesel for the next call, that happens
> to go to the lower page? If not this will send your code into
> hyperspace as PCLATH is NOT restored on the subroutine return.


Ok, hopefully I have understood:

(on page 0)
       .
       .
       .
       Pagesel code1        ; set PCLATH to page of code1)
       Call        code1
       Pagesel $                ; reset PCLATH to here
       .
       .
       .

(on page 1)
Code1
       .
       .
       .
       Return


Is this correct to do?

Or should I do like this:

(on page 0)
       .
       .
code0
       Pagesel code1        ; set PCLATH to page of code1)
       Call        code1
       .
       .
       .

(on page 1)
Code1
       .
       .
       .
       Pagesel code0        ; set PCLATH to page of code0)
       Return


Best Jens

2007\06\15@102102 by Nicola Perotto

picon face


Jens M. Guessregen / Mailinglists wrote:
{Quote hidden}

Yes! Correct!
{Quote hidden}

No, it works BUT the called code  need to know where is the caller code.
When you change the page of the caller you have another headache to
understood what appened!
The PAGESEL macro take as argument the name of the label that you are
calling or jumping to. And you dont have to remember anything.
>
> Best Jens
>
>  

2007\06\15@114455 by olin piclist

face picon face
Dario Greggio wrote:
> But, in the and, some Stack will always be
> needed in a CPU :)

No, it's not.  There are various existance proofs from history to contradict
this.  Up until the mid 1970s or so it was common for "minicomputers" so
store the return address of a subroutine in the first location of the
subroutine.  Just don't try to do recursive calls.  The PDP-8 was like that
for one.  I've worked with other more obscure machines that also used this
architecture, like a Varian 620-I and a small computer made by Honeywell
that I can't remember the model name of.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\06\15@123325 by olin piclist

face picon face
> No, it's not.  There are various existance proofs from history to
> contradict this.  Up until the mid 1970s or so it was common for
> "minicomputers" so store the return address of a subroutine in the
> first location of the subroutine.  Just don't try to do recursive
> calls.  The PDP-8 was like that for one.  I've worked with other more
> obscure machines that also used this architecture, like a Varian 620-I
> and a small computer made by Honeywell that I can't remember the model
> name of.

And now that I think about it some more, the IBM 360 didn't inherently use a
stack for storing subroutine return addresses.  Subroutines were generally
called with the BALR (branch and link register) instruction, although there
were other subroutine call options.  BALR saved the return address in a
register, and it was up to the subroutine to deal with that and eventually
return to that address.  The 360 may have had auto inc/dec addressing modes,
so that a software managed stack was easily possible, but I don't think the
hardware call or interrupt mechanism assumed the existance of a stack.
Certainly the IBM 360 was about as mainstream as it gets in the early 1970s.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\06\15@131327 by Rikard Bosnjakovic

picon face
On 6/15/07, Jens M. Guessregen / Mailinglists
<jmg_mailinglistsspamspam_OUTmcm-it.de> wrote:

> Ok, hopefully I have understood:
>
> (on page 0)
>         .
>         .
>         .
>
> (on page 1)
>

Sorry for being ignorant, but how you (me) find out which page the
code lies on(in?)?


--
- Rikard - http://bos.hack.org/cv/

2007\06\15@161128 by Jens M. Guessregen / Mailinglists n/a

flavicon
face
> > Ok, hopefully I have understood:
> >
> > (on page 0)
> >         .
> >         .
> >         .
> >
> > (on page 1)
> >
>
> Sorry for being ignorant, but how you (me) find out which
> page the code lies on(in?)?

               ORG                0x1800

Puts the code on page 3 for example.

Pagesel xxx finds the correct address for PCLATH


Jens

2007\06\15@164714 by Jan-Erik Soderholm

face picon face
Rikard Bosnjakovic wrote:

> Sorry for being ignorant, but how you (me) find
> out which page the code lies on(in?)?

The point is that you normaly do not *have* to know.
It's enough if MPASM/MPLINK knows (so that PAGESEL
can do it's magic...). Why do you have to know ?

And are you talking about knowing *in your code* or
like looking in the MAP file ?

Jan-Erik.

2007\06\15@214913 by Dario Greggio

face picon face
Olin Lathrop wrote:

> Dario Greggio wrote:
>
>>But, in the and, some Stack will always be
>>needed in a CPU :)

> [...]Up until the mid 1970s or so it was common for "minicomputers" so
> store the return address of a subroutine in the first location of the
> subroutine. [...]

I see.
I get the point :)
I'll try to consider this as a "1-slot stack", though I know it's not
quite the same...
But I can see it was a simpler solution, by the times...

--
Ciao, Dario

2007\06\16@065619 by Rikard Bosnjakovic

picon face
On 6/15/07, Jan-Erik Soderholm <@spam@jan-erik.soderholmKILLspamspamtelia.com> wrote:

> Why do you have to know ?

In an earlier project I ran into the problem that a look-up-table did
cross two page boundaries, so PCLATH screwed up big time. I think I
want to know how to make sure a LUT does not overlap two pages. I know
I can put it in the beginning of the code (which I did to solve the
last problem), but if there's a neather way - like telling the linker
to making sure the code snippet gets uninterrupted - I wouldn't mind
knowing about it.

I'm not sure if I should consult the mplinker- or the mpasm-manual for
this type of question, but probably the former.


--
- Rikard - http://bos.hack.org/cv/

2007\06\16@150321 by Jan-Erik Soderholm

face picon face
OK. Two things...

Either you decide, using the assmebler directives ORG (or CODE)
MPASM (or MPLINK) to place your table(s) where they do not
cross page boundaries (or rather *256 byte* boundaries with is
the issue with lookup tables, not *page* boudaries).

*Or*, you write your table lookup code so it takes care
if any crossed 256 byte boundaries. That will take a few
more cycles for each lookup, and if that isn't acceptable,
you can use the first method.

If you have multiple tables you can put them each
in a separate 256 byte boundary, and then make sure
that the rest of the code is using a lot od CODE
directives so that MPLINK can make the best of the
"puzzle".

In either case the LST or MAP files will tell you
where the table actualy are.

Using relocatable code makes it all easier to put
together in any case...

Regards,
Jan-Erik.


Rikard Bosnjakovic wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...