gnupic: Thread: Help needed

Im doing a project with the PIC16F871, and I am using a number of lookup
tables that uses computed goto.  Is there a way of getting the linker to
chose an address for the table that does not cross page boundaries?

e.g.

CRC16_Lookup:
    global  CRC16_Lookup

    movwf   temp

    movlw   High($)
    movwf   PCLATH

    movfw   temp
    ANDLW   0x1F
    ADDWF   PCL, F

    RETLW   0x00		; LOW Byte Data
    RETLW   0x21
    RETLW   0x42
    RETLW   0x63
    RETLW   0x84
    RETLW   0xA5
    RETLW   0xC6
    RETLW   0xE7
    RETLW   0x08
    RETLW   0x29
    RETLW   0x4A
    RETLW   0x6B
    RETLW   0x8C
    RETLW   0xAD
    RETLW   0xCE
    RETLW   0xEF
    RETLW   0x00		; HIGH Byte DATA
    RETLW   0x10
    RETLW   0x20
    RETLW   0x30
    RETLW   0x40
    RETLW   0x50
    RETLW   0x60
    RETLW   0x70
    RETLW   0x81
    RETLW   0x91
    RETLW   0xA1
    RETLW   0xB1
    RETLW   0xC1
    RETLW   0xD1
    RETLW   0xE1
    RETLW   0xF1

Many thanks

Julian

On Mon, 13 Sep 2004, Julian Green wrote:

> Im doing a project with the PIC16F871, and I am using a number of lookup
> tables that uses computed goto.  Is there a way of getting the linker to
> chose an address for the table that does not cross page boundaries?


The only way I know of (to make the linker get an address which won't
cross a table boundary) is to put your table in its own CODE segment and
force its address:

CRC16_Lookup CODE 0x0100
     global  CRC16_Lookup

     movwf   temp

     movlw   High($)
     movwf   PCLATH
....

Another option, which I implemented for a previous employer using an
18F8520 (?) part, is to calculate whether the table lookup is going to
cross a page boundary and then increment the high and upper PC addresses
as necessary. Since I don't work there anymore, I don't have access to the
code (and couldn't copy the relevant portion anyway, even if I did have
access to it). But the basic idea is this:

- reserve enough registers to hold all bits of the program counter (3
registers on the 18F series I worked on; I think it's 2 on the 16F's)
- initialize both registers:
  movlw   LOW CRC16_Lookup
  movwf   reg1
  movlw   HIGH CRC16_Lookup
  movwf   reg2
- add the address of the table to your offset and store to one register
  addwf   reg1,f
- test for overflow in that addition. (confirm.. use btfsc or btfss here?)
  btfsc   status,c
  incf    reg2,f
- repeat (test for overflow, carry it into the next register) on devices
with more that 16 bits of program counter
- move registers into PC
  movf    reg2,w
  movwf   PCLATH
  movf    reg1,w
  movwf   PCL

This code example probably won't work out-of-the-box, as it's been a while
since I did PIC at all and even longer since I did a 16F project.
Hopefully it'll be enough to get you started in the right direction.

Greg

On Mon, 13 Sep 2004, Julian Green wrote:

> Im doing a project with the PIC16F871, and I am using a number of lookup
> tables that uses computed goto.  Is there a way of getting the linker to
> chose an address for the table that does not cross page boundaries?

Rather than answer your question, I'll suggest an alternative. If you need 
to implement a CRC algorithm, you may wish to check out:

http://www.dattalo.com/technical/software/pic/crc.php

And in particularly:

http://www.dattalo.com/technical/software/pic/crc_1021.asm

There's an inline assembly routine there that implements the polynomial 
you have in your look up table. This routine only takes 18 instructions.

Scott

Julian Green wrote:

>Im doing a project with the PIC16F871, and I am using a number of lookup
>tables that uses computed goto.  Is there a way of getting the linker to
>chose an address for the table that does not cross page boundaries?
>
>  
>
The linker script has one CODEPAGE per page of memory on the device.  
The linker will attempt to relocate a section to the smallest location 
that satisfies its memory requirements, without crossing a boundary.  
This guarantees each program memory section will be on one page.  So 
make sure your lookup table is in one section.

 From the 16f871.lkr file, I would guess that this device one has one 
page of memory.  So you will run out of memory before you have to worry 
about page switching.

>e.g.
>
>CRC16_Lookup:
>    global  CRC16_Lookup
>
>    movwf   temp
>
>    movlw   High($)
>    movwf   PCLATH
>
>    movfw   temp
>    ANDLW   0x1F
>    ADDWF   PCL, F
>
>    RETLW   0x00		; LOW Byte Data
>    RETLW   0x21
>    RETLW   0x42
>    RETLW   0x63
>    RETLW   0x84
>    RETLW   0xA5
>    RETLW   0xC6
>    RETLW   0xE7
>    RETLW   0x08
>    RETLW   0x29
>    RETLW   0x4A
>    RETLW   0x6B
>    RETLW   0x8C
>    RETLW   0xAD
>    RETLW   0xCE
>    RETLW   0xEF
>    RETLW   0x00		; HIGH Byte DATA
>    RETLW   0x10
>    RETLW   0x20
>    RETLW   0x30
>    RETLW   0x40
>    RETLW   0x50
>    RETLW   0x60
>    RETLW   0x70
>    RETLW   0x81
>    RETLW   0x91
>    RETLW   0xA1
>    RETLW   0xB1
>    RETLW   0xC1
>    RETLW   0xD1
>    RETLW   0xE1
>    RETLW   0xF1
>
>Many thanks
>
>Julian
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>
>
>  
>

Hi every body,
I'm writing and IDE for Pic (asm) development. My IDE is Eclipse based, so 
it's fully written in Java and is fully portable (Windows, Linux and 
MacOSX).
The IDE is almost finished  - Project management, source code editing (80%) 
and MPASM/GPasm interfacing(75%).
What I need now is help for interface it with Gpsim. I need to reuse gpsim 
to simulate programs (debug and step by step walking trough source codes).
Has any body tried the socket API of gpsim ?
What I Need :
    1- any body is intereested in writing a java wrapper arround gpsim api ?
    2- or if Nobody interrested, is there any body interrested in writing a 
full PIC simulator in JAVA ?

Sincerely, my hope is to find developpers for the first solution, because 
rewriting gpsim is a wast of energy, gpsim is mature and support most pics, 
and I prefer not to wast time in reinventing the weel.

Any body can help ?

Best regards
octal