• AVR Freaks

Hot!PIC-AS Midrange porting from MPASM.

Page: 12345.. > >> Showing page 1 of 6
Author
Anobium
Super Member
  • Total Posts : 172
  • Reward points : 0
  • Joined: 2013/07/15 00:47:49
  • Location: 0
  • Status: offline
2021/02/18 04:39:25 (permalink)
3 (1)

PIC-AS Midrange porting from MPASM.

Background: I have created a port for Great Cow BASIC for the 18F chips to PIC-AS.  Works very  nicely. see  github.com/Anobium/PIC-AS-Source for examples.
 
I am doing this work so that we can use PIC-AS and MPLAB-X as resource (as we could for MPASMx and MPLAB-X)... new chips need PIC-AS.  And, this works very well for the 18Fs.
 
----
 
So, Midrange chips.  Really stuck.   I have commenced the port for midrange and it works for small programs but there is something that I am not understanding about PSECTs on the midrange chips for large programs.
 
I cannot understand the correct parameters to use when using a larger program on midrange
  1. I know I have working ASM. Proven on real silicon and hardware using MPASMx or GCASM.
  2. I have ported many `small` programs - see github.com/Anobium/PIC-AS-Source/tree/main/16F18855 - so, this proves the basics of the process.
The ASM is essentially the same - the key is ABSolute mode as we need to keep the Great Cow BASIC compiler doing its job (libraries, memory, pages etc) and PIC-AS generating the HEX from the .S source.   
 
Anyone know of a good resource to help me get the larger midrange programs working?  Currently, I have the hex being changed (many of these) `hexfile data at address 0x1000 (0xAD) overwritten with 0x00` and the FCALLs are not correct, getting PSECTs looking OK for the 16F18855 I am testing.
 
Psect Usage Map:

 Psect | Contents | Memory Range | Size
---------|----------|---------------|--------------
 config | | 8007h - 800Bh | 5 words
---------|----------|---------------|--------------
 progmem | | 0000h - 17FFh | 1800 units
---------|----------|---------------|--------------

 
 
Very willing to post .S source/or a project, but, really looking for experience on MidRange ASM to PIC-AS program porting.
 
Evan
 
 
#1

105 Replies Related Threads

    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 08:05:02 (permalink)
    +1 (1)
    Anobium
    Very willing to post .S source/or a project, but, really looking for experience on MidRange ASM to PIC-AS program porting.

    I have not ported any MPASM to PIC-AS and probably never will. ;)  But I can look at your .S file so post your code.
    #2
    atferrari
    Super Member
    • Total Posts : 1464
    • Reward points : 0
    • Joined: 2004/07/08 13:09:24
    • Location: Buenos Aires - Argentina
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 09:07:02 (permalink)
    +3 (3)
    Anobium
     
    Very willing to post .S source/or a project, but, really looking for experience on MidRange ASM to PIC-AS program porting. Evan

     
    Hola Evan
     
    All in this post comes from my own experience and a bit of help from member dan1138 in this forum.

    Ranting is not in my plan. What is gone, is gone and, if I mention something that you already know, it could help somebody else reading this in the future. I hope.

    Worked in Assembler for many years (starting with PIC16C57) and I am not C conversant. Currently using Win 10, MPLABX 5.45, Assembler pic-as 2.31, PICkit 4 and 18F family. Last projects, maybe four or five, with the 18F2321.
    ---------------------------------------------------------------------------------------------------------------------------------

    a) XC8 does not come bundled with MPLABX. You download XC8 later. It includes pic-as 2.31 assembly.
    To work in Assembly, when starting a new project you select explicitly pic-as 2.31. Spent one full day trying with XC8 until I realized so.

    Check the attached picture somewhere below.

    b) Until meeting pic-as 2.20, relocatable mode did not exist for me.

    Now, relocatable is the de-facto mode. You use ORG when you need to establish an absolute location, quite infrequent in common applications. I've seen somebody asking this, but trying to force the whole in aboslute mode is pure nonsense. Kiss it good bye and forget.

    c) Until starting with pic-as 2.20, I had no idea of what the Psect directive was.

    Program sections (psect for short) group data or code. After struggling with the concept and actual usage, I managed to compile this list of predefined ones, which seems to cover most of it:

    /* Psects du jour as suggested by the Chef:

    Data in RAM
    Full: psect..udata,global,class=RAM,SPACE_DATA,delta=1,noexec
    Use: Psect udata

    Full: psect udata_acs,global,class=COMRAM,SPACE_DATA,delta=1,noexec
    Use: Psect udata_acs

    Full: psect udata_bank0,global,class=BANK0,SPACE_DATA,delta=1,noexec
    Use: Psect udata_bank0

    Full: psect..udata_bank1,global,class=BANK1,SPACE_DATA,delta=1,noexec
    Use: Psect udata_bank1

    Data in EEPROM
    Use: Psect eedata,global,class=EEDATA,space=SPACE_EEPROM,delta=2,noexec

    Data in program memory
    Use: Psect data,global,class=CONST,space=SPACE_CODE,delta=1,noexec

    Code - absolute
    Use: Psect code,abs,global,class=CODE,space=SPACE_CODE,delta=1,reloc=2

    Code - relocatable
    Full: Psect code,global,class=CODE,space=SPACE_CODE,delta=1,reloc=2
    Use: Psect code

    Flags in RAM (Access bank)
    Use: Psect bitflags,bit,global,space=SPACE_DATA,class=COMRAM

    Flags in RAM (BANKX)
    Use: Psect bitflags,bit,global,space=SPACE_DATA,class=BANKX
    */

    d) In the XC8 PIC Assembler User's Guide for Embedded Engineers (current version - verified five day ago - the paragraph 7.2 Defining And Using Bits, explains how to define a bit object inside a specific Psect, fitting the "bit" flag which means "this Psect holds bit objects". Those objects are just 1 bit wide.

    The guide shows these two examples for defining flag needCopy

    BANKSEL (needCopy/8)
    bsf BANKMASK(needCopy/8),needCopy&7

    or

    #define NEEDCOPY BANKMASK(needCopy/8),needCopy%7

    Please note that mod 7 IS WRONG. The right divisor for it is 8, thus the proper calculation must be:

    BANKSEL (needCopy/8)
    bsf BANKMASK(needCopy/8),needCopy mod 8

    or

    #define NEEDCOPY BANKMASK(needCopy/8),needCopy mod 8

    I opened a ticket on this subject and MCHP acknowledged the error.

    e) Related to the above, unless I find a reason / need to go that way, I define flags as follows:

    ;FLAGS
    ;All flags are defined in Access, here.

    global FLAGS_TB,FLAGS_KP

    FLAGS_TB: DS 1
    FLAGS_KP: DS 1

    #define TBASE_FAST_ELAP FLAGS_TB,0
    #define TBASE_SLOW_ELAP FLAGS_TB,1
    #define KP_NEEDS_1stREAD FLAGS_KP,4
    #define KP_ENABLED FLAGS_KP,3


    f) Debugging - There is a flaw in debugging mode: the name of variables defined in absolute RAM location is not visible.

    In spite of variables being duly defined with DABS and made public using the global directive twice, they appear properly listed in the respective .lst file, with label and address; their values are visible in the GPRs block in "hex" or "symbol" format, but their label is not shown.

    The rest of the RAM variables do exhibit their value and name (label).

    Opened a ticket on this subject; MCHP acknowledged the flaw.

    g) Assembly Header file (otherwise known as "PIC 18F2321.inc")

    To get the specific .inc file for your particular micro, go to (in my PC at least, this is the right path):

    C: \ Program files \ Microchip \ xc8 \ v2.31 \ pic \ include \ proc \ pic18f2321.inc - make sure you do not enter Program files (x86).

    I recall someone posting that the old .inc file (MPASM) could be used. With the current micro, found one (or two?) register names altered so you must use the file in the path above.

    Amongst other things, the directive #include <xc.inc>, allows the assembler to recognize psect's / memory spaces' names defined in the .inc file.

    h) I strongly suggest you peruse the .inc file above in full. Make sure you read it down to the very end so you will understand what I am explaining in point g.

    i) Porting existing projects was simple for me. After completing my first project with pic-as, I rewrote my whole library, in less than three days IIRC. After that I reworked my basic "template".

    Hope some of this is useful to you.
     
    post edited by atferrari - 2021/02/18 09:12:34

    Attached Image(s)


    Agustín Tomás

    In theory, there is no difference between theory and practice. In practice, however, there is.

    http://cablemodem.fibertel.com.ar/atferrari/
    #3
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 09:37:31 (permalink)
    +1 (1)
    atferrari
    Data in EEPROM
    Use: Psect eedata,global,class=EEDATA,space=SPACE_EEPROM,delta=2,noexec

    Shouldn't that have a delta value of 1 ?
    #4
    Anobium
    Super Member
    • Total Posts : 172
    • Reward points : 0
    • Joined: 2013/07/15 00:47:49
    • Location: 0
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 10:04:07 (permalink)
    +1 (1)
    Code is in GitHub.  That way I can keep updated: here
     
    This is generated from the GCB compiler.  There is no hand cranking.  So, this code works as expected with MPASM or GCASM.
     
    Currently,
    1. The hex file is being overwritten during compilation in MPLAB-X. See below
    2. The hex does not work... and, the debugger shows the issue.  The FCALL INITSYS goes to an address of 0x811 where INITSYS is actually at 0x1022 ( factor 2 out ).  This can be seen by debugging in MPLAB-X
     
    I have tickets open with Microchip but nothing has come from support in days.  
     
    What have I done that to bust the compilation process when the code is a tad larger than the examples...
     
    Evan
     
     
     
    ----  messages from compilation process (subset)
     
     
    C:\Users\admin\AppData\Local\Temp\sl9c.2::: warning: (1343) hexfile data at address 0x1000 (0x3E) overwritten with 0x00
    C:\Users\admin\AppData\Local\Temp\sl9c.2::: warning: (1343) hexfile data at address 0x10B8 (0xF9) overwritten with 0x88
    C:\Users\admin\AppData\Local\Temp\sl9c.2::: warning: (1343) hexfile data at address 0x12AA (0xEA) overwritten with 0xA8
     
    Memory Summary:
    Program space used 1800h ( 6144) of 2000h words ( 75.0%)
    Data space used 0h ( 0) of 400h bytes ( 0.0%)
    EEPROM space used 0h ( 0) of 100h bytes ( 0.0%)
    Configuration bits used 5h ( 5) of 5h words (100.0%)
    ID Location space used 0h ( 0) of 4h bytes ( 0.0%)


    #5
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 10:05:28 (permalink)
    +1 (1)
    atferrari
    Data in program memory
    Use: Psect data,global,class=CONST,space=SPACE_CODE,delta=1,noexec

    And shouldn't that have a reloc value of 2 on a PIC18?
    #6
    Lulu04
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2021/01/31 03:20:21
    • Location: Earth
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 10:29:16 (permalink)
    +2 (2)
    Hello, I'm not very experimented, but after few try, I success to convert my MPASM project to PIC-AS.
    I use absolut mode. Here an example how to declare things in your program (I don't know if this is the right way, but it work for my project on PIC16F877 and PIC16F1825.
     
    PROCESSOR 16F1825
    RADIX DEC
    #include <xc.inc>

    // AREA for your EQU
    SomeDeclaration EQU 100

    // VARIABLE IN SHARED MEMORY
    PSECT udata_shr
     variable1: DS 1 // 1 byte
     variable2: DS 3 // 3 bytes length

    // VARIABLE IN BANK0
    PSECT udata_bank0
     _value_track1: DS 1
     _value_track2: DS 1
    #define value_track1 BANKMASK(_value_track1)
    #define value_track2 BANKMASK(_value_track2)

    // VARIABLE IN BANK1
    PSECT udata_bank1
     parametersb1_effect: DS 26 * 3 // 78 bytes length

    // VARIABLE IN BANK2
    PSECT udata_bank2
    ...
    // VARIABLE IN BANK3
    PSECT udata_bank3
    ...

    // Declaration of the reset vector in absolute mode (abs)
    PSECT resetVec,class=CODE,delta=2, abs
        GLOBAL resetVec
        ORG 0 // start adress on reset
    resetVec:
        PAGESEL init //jump to the main routine
        br init


     org 0x004 // adresse d'interruption
    #ifdef __16F877
     movwf w_temp // sauver registre W
     swapf STATUS,w // swap status avec résultat dans w
     movwf status_temp // sauver status swappé
     movf FSR,w // charger FSR
     movwf FSR_temp // sauvegarder FSR
     movf PCLATH,w // charger PCLATH
     movwf PCLATH_temp // le sauver
    #endif
     clrf PCLATH // page 0
     banksel PIR1
    ...
    ...test your interrupts and jump to the code that process it
    ...
    restorereg: // return here after each processed interrupt
     #ifdef __16F877
     movf PCLATH_temp , w
     movwf PCLATH
     movf FSR_temp , w
     movwf FSR
     swapf status_temp,w
     movwf STATUS
     swapf w_temp,f
     swapf w_temp,w
     #endif
     retfie

    // MAIN PROGRAM
    init:
     clrf value_track1
    ...
    END ResetVec // end followed by the same name as declared in previous PSECT

     
    I try to port some macro to compute value for timers, but without success cause to the limitation of the PIC-AS compilation directive...

    bad english, sorry
    #7
    Anobium
    Super Member
    • Total Posts : 172
    • Reward points : 0
    • Joined: 2013/07/15 00:47:49
    • Location: 0
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 10:32:44 (permalink)
    0
    The condition is larger programs only. Lots of small programs all work including interrupt routines.
    #8
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 11:50:35 (permalink)
    0
    Anobium
    The condition is larger programs only. Lots of small programs all work including interrupt routines.

    I have not figured out a workaround yet, but it seems there is a limit on psect code:
     
    psect "code" in class "CODE" (largest unused contiguous range 0x800)
    #9
    Anobium
    Super Member
    • Total Posts : 172
    • Reward points : 0
    • Joined: 2013/07/15 00:47:49
    • Location: 0
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 11:59:09 (permalink)
    0
    @1and0
     
    Do you have an open Support ticket on this? or, a resource that explains the constraint?  I will update my tickets with Support.
     
    This is a constraint that cannot not be worked around? or, by the creation of PSECT in each page would resolve ?  I have tried the latter, a PSECT on each page (therefore 0x800) and this did not resolve all the issues.
    post edited by Anobium - 2021/02/18 12:03:59
    #10
    ric
    Super Member
    • Total Posts : 29917
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:12:22 (permalink)
    0
    I beleive you do need a PSECT for each page.
    Their intention is that you do not have a PSECT crossing a page boundary.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #11
    Anobium
    Super Member
    • Total Posts : 172
    • Reward points : 0
    • Joined: 2013/07/15 00:47:49
    • Location: 0
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:16:31 (permalink)
    0
    @Ric.  I have tried psects per page but seemed to make no improvement, however, I will retry.
     
    What is the correct method, or, psect convention to use?  Any advice?
    #12
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:18:53 (permalink)
    0
    Anobium
    Do you have an open Support ticket on this? or, a resource that explains the constraint?  I will update my tickets with Support.
     
    This is a constraint that cannot not be worked around? or, by the creation of PSECT in each page would resolve ?  I have tried the latter, a PSECT on each page (therefore 0x800) and this did not resolve all the issues.

    I don't bother with support or support ticket. ;)
     
    As for the constrain, I only learn of this after playing around with your code. I will continue when I get some free time.
     
    With that said, it seems to me you don't know much about the FCALL and LJMP instructions; for example, this from your code:
        PAGESEL    GLCDPRINT32
        FCALL    GLCDPRINT32
        PAGESEL    $

    will generate this
        PAGESEL    GLCDPRINT32
        PAGESEL    GLCDPRINT32
        CALL    GLCDPRINT32
        PAGESEL    $
        PAGESEL    $

    Similar for LJMP.  I see there's a lot of this in your code, wasting lot of code memory and cycle time.
    #13
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:21:14 (permalink)
    0
    ric
    I beleive you do need a PSECT for each page.
    Their intention is that you do not have a PSECT crossing a page boundary.

    Agreed, since PIC-AS supports only relocatable mode and has no "absolute" mode.
    #14
    Anobium
    Super Member
    • Total Posts : 172
    • Reward points : 0
    • Joined: 2013/07/15 00:47:49
    • Location: 0
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:26:06 (permalink)
    0
    @1and0.  These duplicates are error in my port.  I will resolve in the next revision of the ASM to .S translator.  I had spotted the duplication in the disassembly but I had not resolve in the translator.
     
    This does raise is really good point.  Each page is optimised within Great Cow BASIC, but, with duplication the page size may be exceeded when compiling with PIC-AS.
     
    I recommend I resolve this duplication to ensure the page size is not exceeded, meanwhile, it may be easy to delete the initial pagesel.
     
     
    #15
    Anobium
    Super Member
    • Total Posts : 172
    • Reward points : 0
    • Joined: 2013/07/15 00:47:49
    • Location: 0
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:28:32 (permalink)
    0
    1and0
    ric
    I beleive you do need a PSECT for each page.
    Their intention is that you do not have a PSECT crossing a page boundary.

    Agreed, since PIC-AS supports only relocatable mode and has no "absolute" mode.


    If there is no absolute addressing mode... what does 'abs' do?
     
     
    #16
    ric
    Super Member
    • Total Posts : 29917
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:29:43 (permalink)
    0
    Anobium
    @Ric.  I have tried psects per page but seemed to make no improvement, however, I will retry.
    What is the correct method, or, psect convention to use?  Any advice?

    I should have been clear, this is my impression from using MPASM in relocatable mode. I have no experience with getting PIC-AS going.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #17
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:30:27 (permalink)
    +1 (1)
    A series of FCALL instructions like this:
    ;START OF PROGRAM MEMORY PAGE 0
    ORG    5
    GLOBAL    BASPROGRAMSTART
    BASPROGRAMSTART:
    ;CALL INITIALISATION ROUTINES
        FCALL    INITSYS
        FCALL    INITPPS
        FCALL    HI2CINIT
        FCALL    INITGLCD_SSD1306
        PAGESEL    $

    also wastes code memory.
     
    #18
    1and0
    Access is Denied
    • Total Posts : 12095
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:32:41 (permalink)
    0
    Anobium
    1and0
    ric
    I beleive you do need a PSECT for each page.
    Their intention is that you do not have a PSECT crossing a page boundary.

    Agreed, since PIC-AS supports only relocatable mode and has no "absolute" mode.

    If there is no absolute addressing mode... what does 'abs' do?

    ric
    Anobium
    @Ric.  I have tried psects per page but seemed to make no improvement, however, I will retry.
    What is the correct method, or, psect convention to use?  Any advice?

    I should have been clear, this is my impression from using MPASM in relocatable mode. I have no experience with getting PIC-AS going.

    AFAIK, Ric and I know about as much as you do regarding PIC-AS. I maybe less. ;)
    #19
    ric
    Super Member
    • Total Posts : 29917
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: PIC-AS Midrange porting from MPASM. 2021/02/18 12:34:02 (permalink)
    0
    Indeed. The best way to optimise that is to NOT use FCALL.
    Remove all but the last PAGESEL $
    Remove intermediate PAGESELs if they are to the same page as before.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #20
    Page: 12345.. > >> Showing page 1 of 6
    Jump to:
    © 2021 APG vNext Commercial Version 4.5