MPLABX Assembler - Worried

[tumbleweed]

If you're porting an existing program I would think you'd want to stay with MPASM instead of re-writing the whole thing for PIC-AS, but that's just me.

The PIC16F18323 is supported by MPASM v5.87 and MPLABX 5.35. That should take about 5 mins to get working, not 15 hours.
Granted, MPLABX is a big change from the old MPLAB8, so getting used to THAT part could take 15 hours easily.

 

[Mike - K8LH]

As MPLAB X versions above 5.35 are a pure 64-bit application, and MPASM is a purely 32-bit application, and Microchip has dropped all further development for MPASM (so there will never be MPASM-64), support for MPASM was dropped in the later 64-bit releases of MPLAB X. As was mentioned earlier, you can still install MPLAB X 5.35, which comes with the latest version of MPASM, by downloading it from the MPLAB archive.

Just like MPLAB 5.40 and 5.45, MPLAB X 5.30 and 5.35 support the new DFP system (Device Family Pack). This enables adding support for newer devices by installing a DFP's for the new devices through MPLAB X. However, according to the 5.35 Release Notes, not all new devices added by a Device File Pack are guaranteed to work in these versions of the IDE .

I tried to add DFP 1.9.175 to my MPLABX v5.30 install to gain support for 18F16Q40 but that particular DFP is "unsupported" in v5.30... Bummer!

 

[tumbleweed]

I haven't had much luck either (using MPLABX v5.35). I can install the DFP's but I can't get it to add debug support.

 

[atferrari]

ChrisP58

I'm interested.

All in this post comes from my own experience and a bit of help from a member in the Microchip forum.

Ranting is not in my plan. What is gone, is gone.

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.

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 pre-defined 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 this morning), 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 and 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 better you 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.