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
 
 

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.
 

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%)

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...

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)

I beleive you do need a PSECT for each page.
Their intention is that you do not have a PSECT crossing a page boundary.
 

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.

@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.
 
 

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.
 

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. ;)