If my understanding is correct, MPLAB IDE is going the way of the dodo. MPLAB X is the way of the future.

I've dottered with X for the last year or so, and finally decided to dig deep enough to start using it for some of my projects. So far, I am not happy.

Here are my two major complaints so far:

1. ICD3 support (and perhaps other ICD/Development Boards/ICE) don't work under 64 bit Linux (only 32 bit!). Who works with 32 bit OS's anymore? Is the 21st century for Pete's sake!

2. The debugger watch window is *horrible*! For the following reasons so far:

First, it won't work with any of my legacy absolute code. The assembler will not recognize labels as register addresses like the old MPLAB did. So far, the only way to watch values in this case is to use their register address, not the label name. And only 8 bits at a time can be seen! No words or floats or anything!

Second, assuming you change your perfectly good absolute code to relocatable (changing all your cblocks to udatas and adding res directives), it still only recognized one byte at a time. You must *manually* set the byte size. But you can *only* change the data in the watch window in *hex*, not in another format (like, for instance, float).

Initially, I assumed that I must be doing something wrong, but a quick Google search told me that, not only are these major issues, but also that a lot of good folks are having problems with them.

I am sure I will find lots of other problems with X as I go reluctantly forward. As I do, I intend to update this thread with my findings.

For those using X, I'd be happy to learn your experiences as well. Or, solutions, if you have them.

 

I have only ever used MPLAB X, so I'm afraid I can't compare it with previous versions of MPLAB. There have been other threads on this forum of a similar nature, and they all complain of the changes in MPLAB X as compared to "the old trusty MPLAB ***.*" ..... "at least I knew where it was"..... "why isn't it the same?"..... It isn't, it's new software, things change, get used to it!

You quote :-

Is the 21st century for Pete's sake!

And yet you use absolute code? WTF!

I, for one, am happy that a major MCU manufacturer has deemed fit to offer their development software in a truly cross platform media. I agree it has a way to go, but a start is a start....

PS. Linux user since XP was introduced, and flat refuse to pay for software.

Regards Steve.

 

I far prefer software that works well on a single platform then something that does equally poorly over many platforms.

I wonder how many people have been fired over the X mess? Actually, I suspect no one, least this piece of dogware be retired and non-X reinstated.

Microchip seems to be making mistakes on the order of "A Bridge Too Far" with their software, rewriting several major tools into new wonderful blight shiny all things to all peeples versions... meanwhile leaving the (quite excellent IMHO) MAL application library in the dark. Tutorials, example code, and development board code all broken.

Go ahead, buy a PICkit III kit and see if you can get anything to run when you explicitly follow the user's guide instructions.

I got used to my code breaking when a major compiler change was made. Spent about a month reworking things when I upgraded to both a revised compiler AND revised MAL. I knew it would hurt so I took two steps at once. Now you go thru the pain to find tools lacking basic functionality.

 

1. ICD3 support (and perhaps other ICD/Development Boards/ICE) don't work under 64 bit Linux (only 32 bit!). Who works with 32 bit OS's anymore? Is the 21st century for Pete's sake!

For those using X, I'd be happy to learn your experiences as well. Or, solutions, if you have them.

The ICD3 works with 64 bit Linux (Debian AM64) because that's what I use at work for internal projects.

http://microchip.wikidot.com/mplab:linux64

http://microchip.wikidot.com/mplab:_start

 

I'm writing software using MPLABX ,but the MPASM part included in the package, and I must say that I had at least 1 surprise. The BRZ command isn't even implemented in my 16FXXXX processors. But if you put it in your code MPLABX will re-write the code to make it work like BRZ is there . That was a bit of a surprise.

Dan

 

Assembler is getting pretty old these days, and is more reserved for very very small projects or occasional asm snippets in C code (for speed).

I think if this is about the real future of embedded programming then you can see why they won't care too much about those few people, beginners etc trying to use assembler in a free program.

Think forward to 5 years or so, the "popular" micros will have even more ROM and even faster speeds than they do today! So more ROM makes C even more attractive than asm than it already is, and faster speeds mean the one slight advantage of asm (speed) is even more meaningless than today.

I'm sure these facts have not escaped Microchip, so why would they invest big time in assembler users?

 

I'm writing software using MPLABX ,but the MPASM part included in the package, and I must say that I had at least 1 surprise. The BRZ command isn't even implemented in my 16FXXXX processors. But if you put it in your code MPLABX will re-write the code to make it work like BRZ is there . That was a bit of a surprise.

Dan

BRZ is NOT a statement or command. BRZ is a macro.

MPLAB X or non X does not do a thing with the BRZ macro. It is the assembler that does that work, and they do their function independently of whatever IDE invokes them.

MPASM has always had some macros built in, check out the help file under "12-Bit/14-Bit Instruction Width Pseudo-Instructions."

 

The ICD3 works with 64 bit Linux (Debian AM64) because that's what I use at work for internal projects.

http://microchip.wikidot.com/mplab:linux64

http://microchip.wikidot.com/mplab:_start

Thanks.

On a goof, I decided to update my MPLAB X install, and, lo and behold, ICD 3 now works on my 64 bit desktop. I don't believe I have the 32 bit JRE drivers installed, so maybe Microchip fixed something.

 

I have only ever used MPLAB X, so I'm afraid I can't compare it with previous versions of MPLAB. There have been other threads on this forum of a similar nature, and they all complain of the changes in MPLAB X as compared to "the old trusty MPLAB ***.*" ..... "at least I knew where it was"..... "why isn't it the same?"..... It isn't, it's new software, things change, get used to it!

My complaint isn't that is is different. It's that some things simply don't work well enough to make it useful for *me*.

My biggest complaint right now is the watch window (ICD3 now seems to be working). Sorry, but no matter what I do, I can only view, but not modify, IEEE float values (in asm, regardless of re/non-relocatable code). I can only type in their hex representations! If you've got a solution for that, I'd really -- really! -- like to know.

You quote :-
And yet you use absolute code? WTF!

There is a method to my madness, and I don't wish to get into a debate on this subject. But, at least one reason is: I've got thousands of man-hours (over 23 years!) of legacy code and libraries that I simply do not want, or need, to re-write.

I, for one, am happy that a major MCU manufacturer has deemed fit to offer their development software in a truly cross platform media. I agree it has a way to go, but a start is a start....

Fine. But can we work the bugs out prior to discontinuing support/updates for the tools that actually work? And, perhaps, confirm that it properly builds (or at least accurately translates) existing projects built on the legacy platform? It's not like the silicon changed or anything, just the development environment.

PS. Linux user since XP was introduced, and flat refuse to pay for software.

I agree with you in principle (but, based on Freedom, not price). There is *some* proprietary software that I do purchase, because its productivity value exceeds the cost of the freedom I lose by using it.

BTW, I was excited about the introduction of X. MPLAB is one of the few programs for which I need to keep an XP box on standby.

 

Assembler is getting pretty old these days, and is more reserved for very very small projects or occasional asm snippets in C code (for speed).

Assembly is just as useful today as it has ever been. The projects I do need speed and compactness. I could not do what I do without also including massive amounts of inline asm code. So what's the point? Besides, my libraries take care of the complexity for me, so, in the end, my app code tends to be very simple.

For example:

	pushfl	x	;put x on stack		
	call	pushcp	;  and a copy	

	poly	fmnum	;compute numerator polynomial -- value on stack
	call	swapxy	;swap numerator and x
	poly	fmden	;compute denominator polynomial -- value on stack
	call	divf	;divide -- result on stack

	popfl	y	;get result from stack

That small snippet of code computes the floating point quotient of two polynomial functions, each function of arbitrary order. I'd like to see something so simple in C!

I think if this is about the real future of embedded programming then you can see why they won't care too much about those few people, beginners etc trying to use assembler in a free program.

Well, I guess after 23 years I am still a beginner!

And, what about legacy code? Should we have to dump all that just because the tools change?

Think forward to 5 years or so, the "popular" micros will have even more ROM and even faster speeds than they do today! So more ROM makes C even more attractive than asm than it already is, and faster speeds mean the one slight advantage of asm (speed) is even more meaningless than today.

Low capacity parts will *always* have a price advantage, especially if you are shipping tens of thousands of parts. Low speed hardware will also always have a power advantage over high speed hardware. You pick the right tools for the job at hand. Remember, when all you've got is a hammer, everything looks like a nail.

I'm sure these facts have not escaped Microchip, so why would they invest big time in assembler users?

Who's talking about big time? I'm just suggesting that the new tools should work seamlessly with legacy projects (and that the basic functionality should work as expected). This is not rocket science!

 

I got used to my code breaking when a major compiler change was made...

Ha! And one of the major points of C is that it's supposed to be portable, not over just hardware, but tool chains and libraries also.

Go figure.

 

New issue:

How the heck do I set the editor tab size for .asm files to be 10 spaces? If I set it in options to 10, and press tab, I get two 4 character tabs followed by 2 spaces!

 

How the heck do I set the editor tab size for .asm files to be 10 spaces? If I set it in options to 10, and press tab, I get two 4 character tabs followed by 2 spaces!

MPLAB non-X has the option to use spaces instead of tabs, you would think they would bring that feature forward.

 

Assembly is just as useful today as it has ever been. The projects I do need speed and compactness. I could not do what I do without also including massive amounts of inline asm code. So what's the point? Besides, my libraries take care of the complexity for me, so, in the end, my app code tends to be very simple.
...

I too started out as an "old timer" asm user, and did a lot of commercial projects squeezing the max out of tiny PICs, even OTP devices with limited pages (can only use goto on some pages, not call etc).

My projects also need speed and compactness, but asm is not the only way. I had been a C user on PCs etc for many years but really resisted going to C in embedded designs for many years (for a lot of the reasons you mention). So I do understand where you are coming from.

...
Well, I guess after 23 years I am still a beginner!

And, what about legacy code? Should we have to dump all that just because the tools change?
...

I was aware of your skill level. My "beginner" comment was aimed at Microchip, in that a free assembler is more a beginner oriented platform and that with the reduction in the popularity of asm coding (and the very real FUTURE reduction in the popularity of asm coding) they are unlikely to "invest big time" in this free entry-level "beginner" etc assembler by putting a lot of manpower into it.

Re dumping your legacy code, in my experience that was a non event. Code tricks of my own that were procedural were very easy to re-write in C, and for general stuff like peripheral driving etc a decent C compiler will already have good libraries.

Even the opposite of your argument, most peripheral devices I buy these days like comms modules or TFT displayes etc come with source code examples all in C. And the future will get even more so.

...
Low capacity parts will *always* have a price advantage, especially if you are shipping tens of thousands of parts. Low speed hardware will also always have a power advantage over high speed hardware. You pick the right tools for the job at hand. Remember, when all you've got is a hammer, everything looks like a nail.

Even in C I'm still designing apps that use the cheapest/smallest parts and pushing performance to the limit. As an asm expert, you can write simple C, and check the compiler asm output to see if it made good code. That gives you an advantage over a pure C user (because you can get smaller faster C code), and an advantage over a pure asm user (because you can code complex apps much faster in C).

It won't take you long to get code that is very close to the speed and size of pure asm but you are reaping a heap of advantages. I call it C-- as you can use a simple vertical C style (much like asm) and directly check the compiler's asm output as it will maintain the simple vertical instruction style. This allows you easy cross checking of your C:asm so you utilise the best performance of both.

You avoided the main point (which is more on-topic!), which is that chips ARE getting faster, cheaper and more ROM/RAM, people ARE coding more and more in C or ArduCino, and less and less people are using asm. So a free assembler compiler IS going to become a lower and lower priority for a chip manufacturer!

The big chip customers who provide the bulk of Microchip's profit are hardly likely to care about MPLABX. And beginners starting now are probably going to start with C or BASIC, or switch from MPLABX to free C or paid C after a real short time.

 

As the OP began this thread to discuss (disgust!) MPLAB-X perhaps we should leave the whole asm vs. high level language debate for another thread.

MPLAB (X or not) are design environments or programs that do several things, but one of them is NOT creating or assembling code on any level. Those elements are separate plug in components capable of being replaced at the user's whim.

 

As the OP began this thread to discuss (disgust!) MPLAB-X perhaps we should leave the whole asm vs. high level language debate for another thread.

Yes, Ernie. That was my intention. But, now I see the two issues are, in fact, intertwined.

Initially, I thought moving from MPLAB to X would simply be a matter learning the new platform. But it seems that X has little native support for asm code.

This would not be an issue, *except* that MPLAB support is being discontinued. So I will not, in the future, be able to maintain my existing code base and applications with the new tool!

Don't get me wrong: Yes, X will import the projects and properly assemble them to hex code for programming -- I've already figured out how to do that quite quickly.

The problem is one of maintenance. As new silicon is introduced, I like to port my existing code to less expensive parts as they become available. Generally, this is easy -- just assemble against the new target processor, program, and test.

But, sometimes, the hardware is slightly (or dramatically) different, and some code modification and debugging is necessary. My major complaint (i.e. the watch window) is that X seems not to be geared towards debugging asm code (or even formatting it properly!) (why?).

One option is to continue to use MPLAB for legacy code maintenance. But I will not be able to target new processors. And, I will need to develop a whole new set of C libraries for future projects (see below as to why).

The alternative would be to rewrite (and debug!) all my perfectly functioning legacy code (dozens of applications, each with many thousands of lines of code) for continued maintenance under the new platform. This is an outrageous proposition!

MPLAB (X or not) are design environments or programs that do several things, but one of them is NOT creating or assembling code on any level. Those elements are separate plug in components capable of being replaced at the user's whim.

Yes, but it is the integration that makes the platforms useful. In the old days, I'd assemble using a command line assembler, burn the code into a windowed DIP, and test actual hardware. Rinse and repeat. The simulator and hardware debugger (whether ICE or ICD) now make this process effortless. But X doesn't seem to support this process for asm code (why????).

If you know of an X plugin that seamlessly supports asm, please tell me where to find it!

I was aware of your skill level.

I knew you were. I just wanted to clarify for others who might be following this thread.

My "beginner" comment was aimed at Microchip, in that a free assembler is more a beginner oriented platform and that with the reduction in the popularity of asm coding (and the very real FUTURE reduction in the popularity of asm coding) they are unlikely to "invest big time" in this free entry-level "beginner" etc assembler by putting a lot of manpower into it.

Microchip has spent many a PR dollar over the years to convince us developers that there would always be a sane migration path forward as their technology and tools improved. But now they have killed legacy support for no apparent reason.

Re dumping your legacy code, in my experience that was a non event.

For one application, *maybe*. For dozens spanning many years and many thousands of lines of code, absolutely not! I run a *small* business. Do you really think I have a budget for rewriting dozens of already perfectly working applications?

Code tricks of my own that were procedural were very easy to re-write in C, and for general stuff like peripheral driving etc a decent C compiler will already have good libraries.

Even the opposite of your argument, most peripheral devices I buy these days like comms modules or TFT displayes etc come with source code examples all in C.

I'm going to disagree with you here. I've perused the stock libraries included with the various compilers. Aside from each compiler having its own proprietary set of functions (so much for portability!), the libraries simply do not do what I need. Here are some examples:

-- Good, non-blocking interrupt driven drivers with no hard coded delays;

-- Interrupt based SPI libraries that seamlessly and simultaneously supports multiple SPI devices (each with its own pluggable library), each with it's own timing characteristics and command set;

-- Character LCD drivers that inherently (and in the background) support internationalization, scrolling, flashing, and alternating messages, menus, data entry, and automatic updating for dirty data;

-- Multiplexed LCD drivers that sanely and automatically map segment registers to segment/backplane pins, provide support for numeric data conversion including digit blanking and mixed numeric/alpha data, provide automatic updates for dirty data, and seamlessly support power management;

-- Stack based (very important!) floating and fixed point math libraries including, but not limited to, statistical analysis and signal processing;

-- Etc. (I can go on and on!) And, do all this without being beholden to a EULA for the use and production of the libraries themselves or the whims of the library programmers!

And the future will get even more so.

I'll hold my breath!

Granted, I might successfully rewrite my libraries in C. But why? They already exist, are proven in production, and they simply work as is.

...I call it C-- as you can use a simple vertical C style (much like asm) and directly check the compiler's asm output as it will maintain the simple vertical instruction style. This allows you easy cross checking of your C:asm so you utilise the best performance of both.

Oh, the horrors! You wish me to babysit the compiler to be sure that it writes asm code the way I would have done it had I wrote it myself originally? Talk about inefficient!

Also, for me, C provides *no* performance advantage, whether speaking of code performance or coding performance. I can write both just as quickly, and I can write asm more efficiently (both code and execution speed) than a compiler can, regardless of the optimizations that I may, or may not, wish to pay for.

You avoided the main point (which is more on-topic!), which is that chips ARE getting faster, cheaper and more ROM/RAM, people ARE coding more and more in C or ArduCino, and less and less people are using asm. So a free assembler compiler IS going to become a lower and lower priority for a chip manufacturer!

And you avoided my main point that legacy support is just as important as new applications, especially for those of us that have pushed Microchip products on our customers over many years!

The big chip customers who provide the bulk of Microchip's profit are hardly likely to care about MPLABX. And beginners starting now are probably going to start with C or BASIC, or switch from MPLABX to free C or paid C after a real short time.

Understood. But not an acceptable answer.

 

You want to know what is really crazy?

We are having this lengthy, drawn out discussion, when all I really need to make X 100% usable for me are three things:

1. Format the tabs properly for .asm files.

2. Allow the watch window to display data based on labels (as opposed to "variables") -- and to allow the specification of byte size and data format wrt those labels.

3. And, For the Love Of God, let me type a freakin' floating point number into a floating point watch column!

EDIT: Oh, and while I am at it, give me an assembler directive that converts a floating point number into its IEEE representation. Even MPLAB doesn't do that.

 

http://www.microchip.com/forums/m743418.aspx

If you have an issue, report it.
http://www.microchip.com/support/hottopics.aspx

 

http://www.microchip.com/forums/m743418.aspx

If you have an issue, report it.
http://www.microchip.com/support/hottopics.aspx

Downloaded and installed. None of the issues I mentioned have been addressed.

 

Downloaded and installed. None of the issues I mentioned have been addressed.

Create a support ticket with your issues if you haven't already. Maybe someone already has the answer.