Searching \ for '[PIC] Computed GOTOs and memory' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=memory
Search entire site for: 'Computed GOTOs and memory'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Computed GOTOs and memory'
2005\01\26@221851 by SO-8859-1?Q?Hern=E1n_Freschi?=

picon face
Hi all. I'm writing my first program that has over 256 lines. At the
beginning the simulator showed some very strange stack underflows
which just happened to be computed gotos crossing PCL boundaries.
So the question is, is there a way to see those cases in MPLAB? The
only way I know is looking at the program memory and checking if my
table stays within 0xNN00 and 0xNNFF. But that is rather difficult. Is
there an easier way?

BTW the project is a clock. With PWM brightness control, rotary
encoder control, multiple alarms, among other things. I'm trying to
use as many features of the '877 as I can find useful. Any ideas are
welcome.

hjf

2005\01\27@044529 by Andrew Warren

flavicon
face
Hernán Freschi <spam_OUTpiclistTakeThisOuTspammit.edu> wrote:

> I'm writing my first program that has over 256 lines. At the beginning
> the simulator showed some very strange stack underflows which just
> happened to be computed gotos crossing PCL boundaries. So the question
> is, is there a way to see those cases in MPLAB? The only way I know is
> looking at the program memory and checking if my table stays within
> 0xNN00 and 0xNNFF. But that is rather difficult. Is there an easier
> way?
Hernan:

There are a couple of ways...

If you want your computed GOTOs to work no matter where they and their destinations are located, you can adjust PCLATH appropriately before changing PCL.  There was a Microchip appnote (AN555 or 556, I think -- it's been a few years) that demonstrated the technique.  If you're using relocatable mode or just want to do things "right" (and you can spare a little code space and a few execution cycles), this is by far the best way to solve the problem.

If you simply want an assemble-time warning about the page crossings so you can manually shuffle your code around and assemble again, something like this will work:    
   MYTABLE:
       ADDWF   PCL
       RETLW   1
       RETLW   2
       RETLW   3
       ....
       RETLW   98
       RETLW   99
       RETLW   100

       IF ((HIGH ($-1)) != (HIGH (MYTABLE)))
           ERROR "'MYTABLE' TABLE IS CROSSING A PAGE-BOUNDARY!"
       ENDIF

-Andy

=== Andrew Warren - .....aiwKILLspamspam@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
=== === Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\01\27@054804 by Roland

flavicon
face
At 01:46 AM 27/01/05 -0800, you wrote:
>Hernán Freschi <piclistspamKILLspammit.edu> wrote:
>
>> I'm writing my first program that has over 256 lines. At the beginning
>> the simulator showed some very strange stack underflows which just
>> happened to be computed gotos crossing PCL boundaries. So the question
>> is, is there a way to see those cases in MPLAB? The only way I know is
>> looking at the program memory and checking if my table stays within
>> 0xNN00 and 0xNNFF. But that is rather difficult. Is there an easier
>> way?
>
>Hernan:
>

Hi

'Redrock' posted some code just the other day on this, which I presume is
in the archives;

Here is a snippet from his mail;

______________________________
Hi Everyone,
Here is my latest code for large tables.
I know it's rough and needs some clean up.
It allows me to put text strings anywhere
in memory as long as they are above
(higher in memory then) "TABLE_START".
Comments?
Thanks
Al
-----------------------------------------------------------------------
-----------------------------------------------------------------
DXTron Technology Inc
Atlanta, Ga
PCB Assembly
TH and SMT
PIC Chip Programming
-----------------------------------------------------------------
.....redrock8KILLspamspam.....dxtron.com
http://www.dxtron.com
--------------------------
______________________________________________________________________________


Regards
Roland Jollivet

2005\01\27@085607 by Harold Hallikainen

face picon face
A technique posted quite a while back by someone else that I thought was
quite clever and is shown below is to check for page cross as you go
along.

    movlw high(table)  ; Get high byte of table address
    movwf pclath       ; and set up pclath for computed goto
    movf  offset,w     ; get offset into table (do shift left if using 18)
    ; possibly put andlw here to mask out invalid states
    addlw low(table)   ; add in low byte of table address
    btfsc STATUS,C     ; don't increment if no carry
    incf  pclath,f     ; went over page boundary, add in carry
    movwf pcl          ; jump into table
table
    goto or retlw
    goto or reltw
    goto or retlw


Harold

> Hi all. I'm writing my first program that has over 256 lines. At the
> beginning the simulator showed some very strange stack underflows
> which just happened to be computed gotos crossing PCL boundaries.
> So the question is, is there a way to see those cases in MPLAB? The
> only way I know is looking at the program memory and checking if my
> table stays within 0xNN00 and 0xNNFF. But that is rather difficult. Is
> there an easier way?


--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\01\27@122518 by Jan-Erik Soderholm

face picon face
> Hernán Freschi <EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu> wrote:
>
> > I'm writing my first program that has over 256 lines. At
> > the beginnin the simulator showed some very strange
> > stack underflows which just happened to be computed
> > gotos crossing PCL boundaries. So the question
> > is, is there a way to see those cases in MPLAB?

Why do you have to see that in MPLAB ??
You have two options, as far as I can see :

1 - Write your code so it can handle tables crossing "PCL boundaries".
2 - Put your tables so they don't cross PCL boundaries.


Andrew Warren wrote :

>
> Hernan:
>
> There are a couple of ways...
>
> If you want your computed GOTOs to work no matter where they and
> their destinations are located, you can adjust PCLATH appropriately
> before changing PCL.  There was a Microchip appnote (AN555 or 556, I
> think -- it's been a few years) that demonstrated the technique.

Yes, and that app note was more or less correct in the descriptive
text, but the code examples was buggy and did not work in some
cases (I think it was if you called the table subrutine with h'00' in W,
but I'm not sure I remember correctly).

> you're using relocatable mode or just want to do things "right" (and
> you can spare a little code space and a few execution cycles), this
> is by far the best way to solve the problem.

Or, still if you are using reloc code, and wants fast table lookup, put
the table on an even 256 byte boarder (so you do not need any
PCLATH calculations) and let the linker spread the rest of the
code arount the table. If the code is written with small code
segments, this works quite well (not much code space lost).

>
> If you simply want an assemble-time warning about the page crossings
> so you can manually shuffle your code around and assemble again,
> something like this will work:

"Trial and error" development. Better do it right from the beginning.

Regards,
Jan-Erik>

2005\01\27@142032 by Andrew Warren

flavicon
face
Jan-Erik Soderholm <piclistspamspam_OUTmit.edu> wrote:

> > adjust PCLATH appropriately before changing PCL.  There was a
> > Microchip appnote (AN555 or 556, I think -- it's been a few
> > years) that demonstrated the technique.
>
> Yes, and that app note was more or less correct in the descriptive
> text, but the code examples was buggy and did not work in some
> cases (I think it was if you called the table subrutine with h'00'
> in W, but I'm not sure I remember correctly).

   The worst bug that I remember from that appnote WAS in the
   descriptive text, where it was claimed that interrupts had to be
   disabled during table reads in order to prevent your ADDWF PCL
   from erroneously jumping to one address BEYOND your desired
   table offset.

   This was nonsense, of course (if it were true, interrupts would
   also have had to be disabled around GOTOs and CALLs), so the text
   was removed from the appnote back in 1997 or so.

   The appnote's at Revision E now; I hope that means that they've
   also fixed the code-example bugs.

   -Andy

=== Andrew Warren -- @spam@aiwKILLspamspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\01\27@145504 by Jan-Erik Soderholm

face picon face
Andrew Warren wrote :

{Quote hidden}

I was refering to AN556/DS00556E, "Implementing a Table Read".
If that one is still at rev E, it still have the same bugs
in the code examples as before. And AN556 doesn't say a word
about interrupts, so that must have been some other doc...

Anyway, the last thread on this issue ended with an understanding
about some error in (most of) the code examples. Now, I havn't
looked deep into this again, but it had something with the placement
of the "Table:" label with regard to the first entry in the table, I think...

But, I might b wrong... :-)

Jan-Erik.



2005\01\27@153428 by Andrew Warren

flavicon
face
Jan-Erik Soderholm <RemoveMEpiclistTakeThisOuTspammit.edu> wrote:

> I was refering to AN556/DS00556E, "Implementing a Table Read".

   Me too.

> If that one is still at rev E, it still have the same bugs in the
> code examples as before.

   Eew, really?  That's sad.

> And AN556 doesn't say a word about interrupts, so that must have
> been some other doc...

   No, it was AN556.  As I said in the one paragraph you didn't
   disable-interrupts-around-table-reads text was removed in 1997.

> Anyway, the last thread on this issue ended with an understanding
> about some error in (most of) the code examples. Now, I havn't
> looked deep into this again, but it had something with the
> placement of the "Table:" label with regard to the first entry in
> the table, I think...

   Yeah, I just looked at the appnote.  The bug is in Example 5; the
   simplest way to fix it would be to move the "Table" label down
   one line.

   -Andy

=== Andrew Warren -- spamBeGoneaiwspamBeGonespamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

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