MPASMWIN - Adios, it was great to know ya

Thread Starter

JohnInTX

Joined Jun 26, 2012
4,787
Beginning with MPLABX 5.40, MPASMWIN for PICs is no longer supported or included with the download. The only assembler option is to use the XC8 assembler with not nearly the language features provided by MPASM.
https://www.microchip.com/forums/m1140119.aspx
The migration document is here:
http://ww1.microchip.com/downloads/en/DeviceDoc/MPASM to MPLAB XC8 PIC Assembler Migration Guide 50002973A.pdf
A quick read shows lots of missing features in the macro language and assembly operators. Totally unusable for those of us that actually craft large programs in assembler.

At least there are older versions of MPLAB(x) available.
https://www.microchip.com/development-tools/pic-and-dspic-downloads-archive

I guess we're all supposed to be XC8 programmers, now.

Yay.
 

jpanhalt

Joined Jan 18, 2008
11,087
Sad. MPLAB 8.92, which I use, came with MPASM 5.49. Maybe someone will hack it so newer chips can be added. Not so worried about the simulation, but simply being able to program.

1596226950980.png
 
Last edited:

OBW0549

Joined Mar 2, 2015
3,566
Same here: tried MPLABX, decided it was a PITA for assembly language, and went back to MPLAB 8.92.

Yeah, there are a few of the newer chips I'd like to play around with that aren't supported by 8.92; but since I'm retired and therefore a hobbyist once again, no big deal.
 

jpanhalt

Joined Jan 18, 2008
11,087
Same here. I am definitely EOL. A project I started about 2 years ago for my children has migrated to the 16F1789 for its geometry and number of pins. I don't think they will notice the difference between that and the newest lot of 8-bit chips.

I am just waiting for Summer and early Fall to end so I can assemble a PCB and send out a prototype.
 

geekoftheweek

Joined Oct 6, 2013
1,202
Maybe some folks will update gputils to handle the newer stuff and keep assembly alive! It is what I used from the beginning and still do when I can, but some of the newer chips aren't supported.
 

atferrari

Joined Jan 6, 2004
4,764
Beginning with MPLABX 5.40, MPASMWIN for PICs is no longer supported or included with the download. The only assembler option is to use the XC8 assembler with not nearly the language features provided by MPASM.
https://www.microchip.com/forums/m1140119.aspx
The migration document is here:
http://ww1.microchip.com/downloads/en/DeviceDoc/MPASM to MPLAB XC8 PIC Assembler Migration Guide 50002973A.pdf
A quick read shows lots of missing features in the macro language and assembly operators. Totally unusable for those of us that actually craft large programs in assembler.

At least there are older versions of MPLAB(x) available.
https://www.microchip.com/development-tools/pic-and-dspic-downloads-archive

I guess we're all supposed to be XC8 programmers, now.

Yay.
Hola John

In the middle of the development of a project, I downloaded MPLABX 5.40 (using 5.25 at the moment) expecting to get visibility of my variables while debugging Assembly code. Found that pic-as 2.20 was to be used and that MPASM was gone.

Instead of going back and reinstalling 5.25, which I deleted by mistake, I decided to bite the bullet and went ahead with the porting of my code to the format of the new pic-as 2.20. This ones forces you to relocatable instead of absolute mode, but, being honest, there is not much you need to do and it works. As long as my source is not scrambled , I couldn't care the less. I still can control that. So, one worry less and out of my way forever.

The new syntax change is trivial so, porting was pure clerical work. Once I found what types of psect are required for each part of code, everything went faster. Look below:

Code:
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
Full: Psect  eedata,global,class=EEDATA,space=SPACE_EEPROM,delta=2,noexec
-----------------------------------------------------------------------

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

Absolute code
Full:  Psect code,abs,global,class=CODE,space=SPACE_CODE,delta=1,reloc=2

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

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

Flags in RAM (BANKX)
Full:  Psect  bitflags,bit,global,space=SPACE_DATA,class=BANKX
------------------------------------------------------------------------------
*/
There is a novelty: you can define bits as single entities and the code to handle them is based on this (I do not intend to explain why's and how's):

BANKMASK(needCopy/8),needCopy&7

The day you run across the above in the point 7.2 Defining And Using Bits (Guide for Engineers) please remember that it should be

BANKMASK(needCopy/8),needCopy mod 8.

After raising a ticket with MCHP, it took me some few emails and one Excel to convince the guy at the other end, that it should be 8 instead of 7.

Word of caution: when you create a new project (in Assembly) please select the pic-as 2.20 toolchain as shown below. For lack of information I spent a full journey trying to debug using XC8.

Assembly toolchain.png

It is good to keep in mind that the difficulties in debugging are basically caused by MPLABX and, AFAIK, not the new assembler. Visibility of variables in RAM, MCHP promised to correct it in the new version.

After a change in my personal life philosophy, I decided to stop any kind of rant at personal level and in forums. Following that, I started to raise tickets for those points where I believe something is going wrong or acting funny. MCHP support seems much more responsive than in the past, say some six years ago. Too much people in their forum ranting full time. No benefit for me from there.

BTW, my project worked OK little after I did the porting.

Wish you all, good luck.
 
Last edited:

Thread Starter

JohnInTX

Joined Jun 26, 2012
4,787
After a change in my personal life philosophy, I decided to stop any kind of rant at personal level and in forums. Following that, I started to raise tickets for those points where I believe something is going wrong or acting funny. MCHP support seems much more responsive than in the past, say some six years ago. Too much people in their forum ranting full time. No benefit for me from there.
Agreed and I didn't mean to come across as a rant - more of a head's up. The post does sound peevish - you should see what I deleted :eek:. After 30 years (this month!) with uCHIP, it's not the first time I've been gob-smacked at some of their decisions.
That said, I disagree that using the compiler's assembler is a satisfactory substitute. The stripped down macro and operator set and loss of absolute mode are a deal-breaker for serious assembly language programming. But like everyone else, I'll just archive the last MPLABX and go from there.
It's probably time to move to ARM anyway..

Onward!
 

atferrari

Joined Jan 6, 2004
4,764
Agreed and I didn't mean to come across as a rant - more of a head's up. The post does sound peevish - you should see what I deleted :eek:. After 30 years (this month!) with uCHIP, it's not the first time I've been gob-smacked at some of their decisions.
That said, I disagree that using the compiler's assembler is a satisfactory substitute. The stripped down macro and operator set and loss of absolute mode are a deal-breaker for serious assembly language programming. But like everyone else, I'll just archive the last MPLABX and go from there.
It's probably time to move to ARM anyway..

Onward!
John, sorry!! I was not qualifying yours as a rant. I feel myself frustrated as well but nothing I would do could change all that.

I was planning to post a comment here more or less like yours.
 

upand_at_them

Joined May 15, 2010
940
I happened upon this thread while looking into compiling an assembly program for the PIC16F1778. MPASMWIN.EXE (which comes with MPLAB8) won't compile it, because that PIC is too new. But I see that there's a newer version of MPASM in my MPLABX directory; called mpasmx.exe. Executing it at a command prompt says that it's MPASM version 5.77. And I am able to compile my 16F1778 assembly program with it.
 

jpanhalt

Joined Jan 18, 2008
11,087
Well, if you want to brag, I am running the same on Win7. ;)

The problem is that some of the newer chips has enhanced memory and programmable pins that I might want. So far, my needs for peripherals or alternative pin assignments have been met by what 8.92 offers, but the latter chips are quite an attractive option. Ignoring, of course, the glitzy datasheet for one I recently reviewed.

To put that another way, I am still using the same hammer and plane I have had for more than 50 years. In fact, I still use tools inherited from my uncle that at >100 years old.
 
Top