• AVR Freaks

Helpful ReplyHot!MPLABX 5.40 out, MPASM dead

Page: < 12345 Showing page 5 of 5
Author
dan1138
Super Member
  • Total Posts : 4243
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/01 20:25:38 (permalink)
+3 (3)
Mark Yampolsky
The conversation went into nostalgia far from the essence of the issue.

Oh I would submit that this topic began to stray when it became a discussion on the merits of assembly language project versus targeted use of in-line assembly code in a C language project.

The original event at issue is that Microchip has dropped support for the MPASM tool chain and offered as a replacement the pic-as tool chain.

There are many aspects of this move by Microchip, but so far you have not shown a keen interest in discussing any that seem relevant to me.

The relevant issues I perceive are:
  • Is there a large enough body of useful MPASM source code for a third party to create and maintain a tool chain to keep that code usable?
  • Is MPLABX v5.40 and the pic-as(v2.20) tool chain a usable enough development environment to support 8-bit PIC assembly language projects?
  • Are 8-bit PIC controllers worth the time and effort needed to gain the expertise to write good assembly code for now?
I would be glad to discuss any of these issues.
#81
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 12032
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/01 21:03:09 (permalink) ☄ Helpfulby Jim Nickerson 2020/06/02 06:17:05
+6 (6)
Are 8-bit PIC controllers worth the time and effort needed to gain the expertise to write good assembly code for now?

 
Not in my experience. I've been working with 8-bit PICs for 22 years, with somewhere between 150-200 commercial projects.  The PICs ranged from the PIC10F200 up to the biggest PIC18.  Every one of those projects was written in C, starting with Hi-Tech version 8 back in the '90s.  There was never an upsizing of the PIC because of "C overhead".
 
But you still need to be familiar with the instruction set so you can learn which C constructs yield the best code (and intelligently report the occasional compiler bug).
#82
dan1138
Super Member
  • Total Posts : 4243
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/01 23:57:37 (permalink)
+2 (4)
I have taken a serious look at what is involved with porting an MPASM project to build using the pic-as(v2.20) tool chain. The actual translation from MPASM syntax to something that pic-as can build is simple enough, but it's the tool chain integration in the development environment that is just dumb.

In my experience what Microchip has offered is an insult to developers. Suffice it to say I do not like it. Source level In-Circuit-Debug cannot be done with this tool chain, symbolic debug is even broken for the simulator.

There nothing here that Microchip cannot fix, but will they bother?

If they can kill all assembly coding for 8-bit PICs they will not have to. In hindsight it would have been a better choice to just kill the 8-bit assembler altogether than release something this lame.

To answer my own question "Are 8-bit PIC controllers worth the time and effort needed to gain the expertise to write good assembly code for now?" I would say no. In fact I would go farther saying that 8-bit PIC controllers are not relevant for any new embedded design. Technical inertia is perhaps the key reason that anything new is designed with an 8-bit PIC. This is perhaps why Microchip acquired Atmel.
#83
LamdaElectronics
Assembly_For_Ever
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2010/07/23 04:04:41
  • Location: Hellas-Greece
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 00:00:16 (permalink)
+2 (4)
As a University professor I believe that Assembly is the background knowledge for someone to understand what microprocessors - microcontrollers are, what memory is, what interrupt is, etc..
I haven't written myself a compiler, but everyone knows that it translates the high language code to "core instructions" which are in total 75 for the PIC18 μCs. Each one of the core instructions has a unique Mnemonic, forming this way the Assembly set of instructions.  So, not including in an IDE the Assembly language is purely programmer's incompetence!
I'm repeating again and again: <<Microchip goes from one failure to another!>>
That leaves a huge gap, which should be filled by 3rd party developers: a free version of Assembly and a free limited capabilities C compiler. Or even an open project like the Arduino IDE.
Microchip IDEs are dead along with MASM
#84
NorthGuy
Super Member
  • Total Posts : 6523
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 06:46:52 (permalink)
+4 (4)
lamdaelectronics
That leaves a huge gap, which should be filled by 3rd party developers: a free version of Assembly and a free limited capabilities C compiler.



3-rd party developers won't work for free.
 
I have an assembler (PIC16 only though), but there's work involved in commercializing and publishing software - you need to clean it up, you need to write docs, most importantly you need to work on part support. But I cannot work for free and there's not enough demand to cover even a fraction of my costs. So, a chance that there's going to be any third-party development in this area is slim to none.
 
post edited by NorthGuy - 2020/06/02 06:50:45
#85
NorthGuy
Super Member
  • Total Posts : 6523
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 06:48:47 (permalink)
+1 (1)
Mark Yampolsky
NorthGuyIn case of C, the task was to simplify programming without applying too much restrictions.

Is it an objection or consent?



It's a fact.
#86
mlp
boots too small
  • Total Posts : 1005
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: previously Microchip XC8 team
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 07:42:46 (permalink)
0
crennolet
In assembly I managed to use 11 bytes of RAM and 187 words of flash. In xc8 (C99) it needed 30 bytes of RAM (even though there were fewer variables) and, at optimization level 2, 242 words of flash. I have no doubt that with higher levels of optimization the flash requirements could be reduced a bit more. RAM? I doubt it, given the requirement for a stack.

Oh, FFS. The C language has no "requirement for a stack".
The language requires a call-return mechanism that behaves like a stack, and it requires that each instantiation of a function have its own copy of any auto variables that do not share storage with those of any other currently-active function. Yes, you can implement these requirements with an explicit in-RAM stack, but you don't have to, and XC8 does not always do so. A compiled and fully-optimized C program should not use any more RAM than that necessary for all of its simultaneously-live variables (including those within any called library functions) plus a couple of temporaries.

Mark (this opinion available for hire)
#87
dan1138
Super Member
  • Total Posts : 4243
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 08:24:08 (permalink)
+1 (1)
mark.pappin
crennolet
In assembly ... blah blah blah ...

Oh, FFS. The C language ... blah blah blah ...

Why are we circling back to the <My language> vs <Your language> debate?
 
This topic is about a specific choice that Microchip has made in regards to the support of one code development tool.
#88
Mark Yampolsky
Super Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2009/04/03 18:50:36
  • Location: Russia Fryazino Moskow reg
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 11:07:05 (permalink)
-3 (5)
lamdaelectronics
As a University professor I believe that ...
So, not including in an IDE the Assembly language is purely programmer's incompetence!

A university professor should become familiar with the subject of discussion before giving assessments. The microchip REPLACED one assembler for another. And this other is different in that it is much deeper integrated into the C compiler than the former. And only a comparison of one assembler with another is the subject of discussion.
NorthGuy
 
But I cannot work for free and there's not enough demand to cover even a fraction of my costs.

This is an honest recognition of the ONLY reason why this topic appeared and is still supported.
But the thing is that the NEW 8-bit Microchip controllers began to differ radically from the old ones. Previously, it was a core supplemented by some peripherals, but now it has become a rich periphery with a core added to it. That is, the task of writing effective code has become marginal. Initialization does not require efficient code. A small amount of computing changes priorities in the architecture of embedded code.
As regards the 8-bit Microchip controllers, you have lost the tasks demanded by the market. And on the contrary, I acquired a very effective family of microcircuits in the design of radio circuits.
This is what I hinted about earlier, saying that development often requires a change of profession ... Alas.
post edited by Mark Yampolsky - 2020/06/02 11:09:06
#89
Mark Yampolsky
Super Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2009/04/03 18:50:36
  • Location: Russia Fryazino Moskow reg
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 11:17:33 (permalink)
-2 (4)
dan1138
There nothing here that Microchip cannot fix, but will they bother?

Wait and see.
When X IDE appeared, only the lazy did not scold this environment. However, nothing terrible happened and there was only a grumbling ...
There is a Russian proverb: "...before, the water was wetter, the sky bluer, and watermelons sweeter ..."
This is about grumbling.
#90
Mark Yampolsky
Super Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2009/04/03 18:50:36
  • Location: Russia Fryazino Moskow reg
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/06/02 11:57:31 (permalink)
-5 (9)
It's fun to watch how reflective losers minus my messages ...)))
I'm used to telling the truth. Even if it causes a hysteria of the interlocutor.
Yyyeeesss!!!
#91
sdn_
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/03/08 02:14:28
  • Location: 0
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/01 09:51:08 (permalink)
-1 (1)
To start the simulator and the assembler output to the listing.disasm file, download the updated to version 1.0.1 toolchain picasm plugin via menu MPLAB X 5.40 plugins.
#92
domble
Super Member
  • Total Posts : 196
  • Reward points : 0
  • Joined: 2007/01/25 04:11:53
  • Location: UK
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/03 08:06:54 (permalink)
+1 (1)
jswanson
I have some old code that I have to maintain and have no intention of rewritig it, so this is not good news.  Incidentally, you can still load the C18 tool chain in 5.40 and that uses MPASMWIN as the assembler.  However, if you change from MPASM to C18 it loses the settings such as MACRO definitions.
I can't see why MC don't do a 64bit version of MPASM, but maybe it is written in FORTRAN or something similar.


Thankyou!  MPASM installed with C18 works.  That's saved me hours of trying to re-write multiple (many, many...) MPASM projects into PIC-AS.  Until Microchip break it again. 
 
dom.
#93
JimDrew
Super Member
  • Total Posts : 344
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/12 04:31:20 (permalink)
+3 (3)
Holy crap!  I designed a new product (where I will need a few hundred thousands 16F18323 parts), and find that the normal assembler doesn't work anymore under 5.40!  What the hell, Microchip?  I have purchased literally millions of PIC parts over the last 2 decades for commercial products, and this is the thanks I get?  I write everything in assembly (only) to meet strict DOB and other requirements.  I don't have time to go jump through hoops to learn a new assembler (which seems to have some really horrible restrictions dealing with memory placement).  It seems like every time I turn around the MPLABX saga takes a new turn (for the worse).  Do you know how much existing example code will no longer run?   Clearly this was a bad financial decision.  The profit from just my project alone would have easily paid an employee's salary for a year to just update MPASM.  I am going to look at other brand options.
 
 
 
 
post edited by JimDrew - 2020/08/12 04:38:43
#94
ric
Super Member
  • Total Posts : 29919
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: MPLABX 5.40 out, MPASM dead 2020/08/12 04:48:27 (permalink)
+2 (4)
Jim, submit this as a Support Request, and that should force a response from them...
 

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!
#95
Jerry Messina
Super Member
  • Total Posts : 668
  • Reward points : 0
  • Joined: 2003/11/07 12:35:12
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/12 05:15:46 (permalink)
+2 (2)
The 16F18323 is supported in MPASM 5.87, so download MPLABX 5.35 and you'll get the last version of MPASM.
 
Doesn't help much going forward, but they don't seem to care. They obviously thought PIC-AS was an acceptable  solution.
 
 
#96
JimDrew
Super Member
  • Total Posts : 344
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/13 17:40:46 (permalink)
+1 (1)
@ric - Trust me, I am all over this.  This affects my operations going forwards so it has to be resolved.
 
@Jerry - Yeah, I went back to v5.35 so I could at least complete the prototype and provide samples to the client.  I am looking at other 8 bit micros though for this and future projects, but there are dsPIC33CH/K and PIC24EP/F/HJ based products that we will need to continue support for so I would prefer if Microchip would just restore MPASM.
 
 
 
 
#97
zdenekjs
Super Member
  • Total Posts : 202
  • Reward points : 0
  • Joined: 2013/02/13 23:04:26
  • Location: 0
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/13 18:05:41 (permalink)
+3 (3)
ric
Jim, submit this as a Support Request, and that should force a response from them...
 



That'll be a response from the wrong end of the chain.  I'll bet there's a lot of engineers at MCHP who aren't happy with losing MPASM either. (full disclosure: former one here unhappy with this call too)
 
It's got to turn into a problem at the VP level before the company will change directions.  Everyone who has $$$ behind them should find a way to get in contact with the VP of Dev tools and the division making the parts they use.  Don't just pass it on to your sales person, make sure you talk to their boss and their boss's boss.
#98
Jerry Messina
Super Member
  • Total Posts : 668
  • Reward points : 0
  • Joined: 2003/11/07 12:35:12
  • Status: offline
Re: MPLABX 5.40 out, MPASM dead 2020/08/14 02:54:37 (permalink)
+5 (5)
JimDrew
...but there are dsPIC33CH/K and PIC24EP/F/HJ based products that we will need to continue support for so I would prefer if Microchip would just restore MPASM.

Those parts don't use MPASM, they use the assembler that's part of xc16.
 
MPASM is only for the 8-bit parts (PIC10/12/16/18)
#99
Page: < 12345 Showing page 5 of 5
Jump to:
© 2021 APG vNext Commercial Version 4.5