2020/10/08 08:20:22
First let me say, this is a pain in the butt!  I have a PIC10F220 project that I needed to make some modifications to.  I've recently updated to MPLAB X v5.40.  Of course the project was written in assembly for this tiny PIC.  I tried compiling and I get some error about MPASM not being in the tool chain.  As I see now, there is no longer any such thing a MPASM.
I just want to work on my code.  I've downloaded MPLAB v8.92 just to get MPASM. Now I am just trying to get MPLAB X to recognize it as a tool chain.  I have yet to figure out how to tell MPLAB X to use MPASM (Like it always has up to this point) to assemble my project.
I did try assembling with XC8, but it had several syntax errors that were not straight forward.  It seems like any direction I go this is a time sink and is quite aggravating.
I would be happy to be able to push the compile button in MPLAB X, and get a hex file I can load on my PIC in the most painless way.  Can anyone please help me figure this out or at least point me in the right direction?
2020/10/08 08:35:47
MPLABX 5.35 is the last with MPASMX support. From 5.40 forward it will have PIC-AS which I think is basically ASPIC (which has been part of XC8 for years) tweaked for better manual assembly usage. Those who have worked with it have posted negatively about PIC-AS compatibility with MPASMX based code.
I don't know if it's possible to add MPASMX to MPLAB 5.40, but it's certainly easy enough to download an older version of MPLABX.
For such an ancient device, however, I think a lot of people would recommend using MPLAB 8.92 (if you are using Windows) which is the last version of the old tool. I have no experience with this, but apparently MPLAB was better at assembly development and debugging.
2020/10/08 08:54:13
These tiny PICs have a good and unique purpose of being able to do small custom jobs on an end product.  In our case it is reading AC line voltage on the line side of our product and then sending that voltage reading serially across an optoisolator to a PIC32MM.  It works great, except now Microchip has cut off the best tool for writing code for this device.
I guess I will go back to MPLAB X v5.35 for now...  So my long term solution is to figure out how to use ASPIC?  From briefly looking at other posts it seems this is not a small or easy task.
2020/10/08 10:01:36
... It works great, except now Microchip has cut off the best tool for writing code for this device. ...

Microchip has stopped maintaining MPASM largely because they do not want to port it to the 64-bit execution environment of Mac OS, Windows OS and Linux OS.
What Microchip has done is offer the pic-as(v2.xx) tool chain for assembly language development.
So far Microchip has done an awful job of integration of this tool chain with MPLABX. To compound this the documentation is terrible.
The pic-as(v2.xx) assembler IS NOT COMPATIBLE with the MPASM syntax. There are a lot of odd differences that make porting MPASM code to pic-as(v2.xx) a lot of trouble.
If the only way you have used MPASM is in absolute mode you are so screwed. You will not have enough experience with PIC assembly language to even begin to comprehend what the pic-as(v2.xx) assembler is complaining about.
If you are going on to learn how to write pic-as(v2.xx) assembly language code you will need to manually add the pic-as(v2.xx) tool chain to the MPLABX environment.

Then you need some pic-as(v2.xx) assembly language examples to study.
I created a PIC10F220 project just for you. Please find it on my git repository here.
2020/10/08 13:03:05
You can use MPASM with MPLAB 8.92. I do. I'm working on a new project right now. Works great.
2020/10/08 13:15:23
For any PIC devices that are supported by MPLAB v8.92, it's best to use it for MPASM programming because it is better at it than MPLAB X. ;)
2020/10/08 16:07:43
The long term solution ...
... might be to use one of the latest 5-digit PIC16s (e.g. PIC16F15213): somewhat cheaper, way better specs and programmable in C (due to significantly more Flash and RAM). These days, C would make for better serviceabiliy of the code.
2020/10/09 06:20:21
Thanks for all the feedback.
@dan1138, thank you for the example project.  That gives a nice jump start, though it does feel like I am going backwards and reinventing the wheel.  You have at least started rounding the edges of the wheel for me!
@1and0 and @NorthGuy, I agree that the old MPLAB 8 was better at assembly.  MPLAB X had gotten good enough... until they did this.  I don't feel good about relying on MPLAB 8 for a long term solution.  In my opinion if Microchip is going to sell these little PICs then it should have a tool to support them.  C is not the right tool when you only have 265 bytes of program space and 16 bytes of ram.  For us, this was the right PIC for the job, Microchip should support developing code for it.
@du00000001, we use a lot of different PICs, from this PIC10F to the PIC32MZ2048EFG064 and many in between.  We only have two projects in assembly.  One legacy product that we still support in assembly because it is working well and it is a reatively big effort to switch it over to C. Then we have this product which has this little PIC10 doing a little job (only uses 2 pins and needs to be small) and on the receiving end we have a PIC32MM running C.
2020/10/09 07:42:41
I don't feel good about relying on MPLAB 8 for a long term solution.

It is very typical for companies to overdevelop their software products, or remove useful features, or changing the user interface so that it becomes unusable. If this happens to a software program which I use, I keep the last useful version and stop upgrading. This way, I always have software programs I like, some even from last millennium. This is my long term solution.
If some of my software outlives itself, I typically switch to something completely different, or even write a substitute by myself.
2020/10/09 07:45:14
@du00000001, I took time to look at the PIC16F15213...  the 3mm x 3mm DFN package might be a good alternative if I were starting the project over, but those are brand new and weren't available when this project was started.  It would be about the same space as the SOT-23-6 package.  I like the SOT package better, because it is easier if rework is needed, but that is a minor issue as very few ever need rework.
© 2021 APG vNext Commercial Version 4.5

Use My Existing Forum Account