#1869 [PIC16F1938] FSR->FSRx,INDF->INDFx and Interrupt

closed-fixed
5
2013-05-25
2011-10-31
Gál Zsolt
No

SDCC : pic14 3.0.6 #6994 (Oct 30 2011) (Linux)

This enhanced PIC14 has no FSR reg and INDF reg. It has two FSRx and INDFx registers. When I try to compile the attahed file, I get error message about missing INDF and FSR. Probably it is my fault, because I made some modification on the SDCC code to compiling code for 16F1938 device.
The problem is the same with the interrupt routine. The compiler want to save registers ( including FSR ) which are automaically saved by the hardware.

Discussion

  • Gál Zsolt
    Gál Zsolt
    2011-10-31

     
    Attachments
  • Gál Zsolt
    Gál Zsolt
    2011-10-31

     
    Attachments
  • Gál Zsolt
    Gál Zsolt
    2011-10-31

     
    Attachments
  • Raphael Neider
    Raphael Neider
    2011-10-31

    The interrupt context saving code had already been dropped for enhanced cores in r6998.
    Indirect memory access via FSR (now FSR0L, FSR0H) has now been fixed in r6999.

    Beware, though: Memory initiaization code from libsdcc (idata.c) needs to be recompiled for enhanced cores, otherwise, only the first memory bank will have its data initialized (and probably with wrong/mixed data from subsequent banks). As a workaround, you should be able to include _sdcc_gsinit_start() in your project, compile and link it along with your source file(s).

    Good luck,
    Raphael

     
  • Raphael Neider
    Raphael Neider
    2011-10-31

    • milestone: --> fixed
    • status: open --> closed-fixed
     
  • Gál Zsolt
    Gál Zsolt
    2011-10-31

    That is great! I simply run over the message about missing _FSR and _INDF register in gptrget1.o by defining two variables with that names and the compiler done succesfully. So this side is ready.

    The other side, when I tried to compile the whole library for the PI16F1938 processor is failed. The problem takes place at compiling asincos.c. The message is:

    ../build/libm/asincosf.asm:835:Error [113] Symbol not previously defined (FSR).

    So I tried to compile it manually with this command:
    /sdcc/device/lib/pic14/libm$ sdcc --debug --verbose --fverbose-asm --i-code-in-asm -mpic14 -p16f1938 -c ./asincosf.c

    and I found in the compiled assembly code this:

    ; >>> gen.c:5188:setup_fsr
    ;; BANKOPT1 BANKSEL dropped; FSR0H present in all of FSR0L's banks
    MOVWF FSR0H
    ;; *** genNearPointerGet 5501
    ; >>> gen.c:5507:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; INDF0 present in all of FSR0L's banks
    MOVF INDF0,W
    ; >>> gen.c:5511:genNearPointerGet
    ;; 1110 rIdx = r0x104F
    ;; BANKOPT1b BANKSEL dropped; r0x101B present in all (of FSR0L's) banks
    MOVWF r0x101B
    ; >>> gen.c:5514:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; FSR present in all of FSR0L's banks
    INCF FSR,F
    ; >>> gen.c:5507:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; INDF0 present in all of FSR0L's banks
    MOVF INDF0,W
    ; >>> gen.c:5511:genNearPointerGet
    ;; 1110 rIdx = r0x1050
    ;; BANKOPT1b BANKSEL dropped; r0x101A present in all (of FSR0L's) banks
    MOVWF r0x101A
    ; >>> gen.c:5514:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; FSR present in all of FSR0L's banks
    INCF FSR,F
    ; >>> gen.c:5507:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; INDF0 present in all of FSR0L's banks
    MOVF INDF0,W
    ; >>> gen.c:5511:genNearPointerGet
    ;; 1110 rIdx = r0x1051
    ;; BANKOPT1b BANKSEL dropped; r0x1019 present in all (of FSR0L's) banks
    MOVWF r0x1019
    ; >>> gen.c:5514:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; FSR present in all of FSR0L's banks
    INCF FSR,F
    ; >>> gen.c:5507:genNearPointerGet
    ;; BANKOPT1 BANKSEL dropped; INDF0 present in all of FSR0L's banks
    MOVF INDF0,W
    ; >>> gen.c:5511:genNearPointerGet
    ;; 1110 rIdx = r0x1052
    ;; BANKOPT1b BANKSEL dropped; r0x1018 present in all (of FSR0L's) banks
    MOVWF r0x1018

    You can see that FSR appeared somehow in the code.

     
  • Raphael Neider
    Raphael Neider
    2011-11-01

    As of r7002, FSR has been told not to intrude into assembly files targeted at enhanced cores. Let's hope it complies ;-) Interesting enough, during the development of r7001, this bug never surfaced during library builds ...

    As of r7001 (a rather large commit), SDCC provides separate libsdcce.lib and libme.lib libraries compiled for the enhanced cores (note the trailing 'e'). When sdcc calls the linker itself, it will link with libsdcce.lib if it is targetting an enhanced device, libsdcc.lib otherwise. This solves all the problems related to generic pointer access within the library and allows us to benefit from the new moviw/movwi instructions for indirect memory access.

    Note, however, that sdcc does *not* link with libme.lib by default (just as it did and does not link with libm.lib on its own). If you develop for enhanced devices and want to use libm, you need to link with libme.lib instead!
    Similarly, if you link on your own, do not forget to use libsdcce.lib when targetting enhanced cores. Otherwise you might get a link-time error (if you are lucky) or ... interesting runtime behaviour ;-)

    r7001 also includes device libraries for the 12f1822 and 16f1934/6/7 devices. 16f1938 should follow shortly.

    Hope that helps (and eager to hear about it)
    Raphael

     
  • Raphael Neider
    Raphael Neider
    2012-02-12

    • assigned_to: nobody --> tecodev