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

Don't you know, nsaspook, that it is far more fun to rant about a product you know nothing about in a public forum that has nothing to do with it before ever contacting the manufacturer???

Hey, that's what my customers do!

The purpose of this thread was (originally) to document my trials & tribulations as I migrated to a new development platform for those who may (or may not!) care.

I also like discovering things on my own before reading the manual (what fun is it if all the answers are just laid out in front of you -- in black and white -- like you're an idiot or something?).

I have already perused many of the MPLAB X discussion boards, both in and outside of the Microchip corporate domain.

I have discovered that, yes, .asm is not as well supported by X as it could be, and, yes, Microchip is aware of the issues, and, yes, they will get around to improving support at some later date in a new release. There doesn't seem to be much urgency, though.

I am in an experimental stage right now. When these issues become important, I will start beating on the doors and windows at Microchip.

 

Has Dave Jones done a 'Rant' on MPLAB X yet, if so, point me to it.
Max.

 

Don't you know, nsaspook, that it is far more fun to rant about a product you know nothing about in a public forum that has nothing to do with it before ever contacting the manufacturer???

Ring the bell early and often. It never hurts to have one more (valid) ticket in the barrel. All the tools are command based so you don't really have to use the Java based IDE. Emacs can handle anything but most people don't like it.

http://www.emacswiki.org/emacs/AssemblyProgramming
http://www.emacswiki.org/emacs/EmacsNiftyTricks

 

Playing around some more, I discovered that the floating point deficiencies of the MPLAB X watch window extend to C (at least the C8 compiler) as well.

As best I can tell, you cannot type a float into a float variable watch. It will only take an integer value (in the float field) and fill the bytes with that value (not the floating point representation of it).

The only way I can figure out how to enter an actual floating point value into a floating point variable is first convert it to hex (or integer) notation, and then type that into the hex field (or the float or integer field). This is nuts! Especially since MPLAB does this just fine.

BTW, it is possible that this is a bug only in Linux. Can anyone here confirm that it is the same in Windows?

Secondly, C8 *only* supports at most single precision floats (either 24 or 32 bits), but nothing better. This makes C programming (at least wrt C8) DOA for me.

PS -> I examined the resulting asm code from a simple build. Horrid!

Granted, I did not purchase the optimization license (nor did I activate the stock 30 day evaluation), but, so far, I don't like what I see.

 

Have a look at MikroC PRO, the free "demo" version comes fully functional apart from a 2k ROM limit and a RAM limit, but since you said you cram a lot of features into small PICs that should be enough to do some of your smaller PIC apps and see if you like it.

Still limited to 32bit floats (I believe) but then most embedded compilers will be the same there. With MikroC PRO you can build (and compile!) your own library objects which then appear in the IDE along with the standard libraries. That might suit your programming style.

 

PS -> I examined the resulting asm code from a simple build. Horrid!

Granted, I did not purchase the optimization license (nor did I activate the stock 30 day evaluation), but, so far, I don't like what I see.

One thing to try is enabling the "jump-to-jump optimizations:"

The assembler's jump-to-jump optimizations, which previously was only available with a licensed compiler operating mode, is now available in Free mode. By default, this optimization is disabled, but it can be enabled from the --OPT option or the Optimization category in MPLAB X IDE in the usual way. If enabled, this optimization reduced the size of code output by the compiler.

The readme is located at ...\Program Files (x86)\Microchip\xc8\v1.20\docs

At this time I do not know where to enable this switch (my default optimization is still within the time limit).

 

Have a look at MikroC PRO...

One thing to try is enabling the "jump-to-jump optimizations:"...

I've come to the conclusion that, save for the .asm file tab formatting problem, the limitations I have discovered with X are universal, regardless of either .asm or any given C compiler.

I have also concluded that C provides no benefit to me for embedded programming, for all same reasons that I avoided using C for many years. As far as embedded programming goes (wrt PIC), I am an assembly programmer. And shall continue to be.

With that said, I *like* MPLAB X, and I would like to use it for my .asm projects. Hopefully, they will fix the problems I identified so that I can.

I will soon be hammering Microchip to try to get these issues fixed.

 

After reading many negative reports on MPLAB X I wondered if anyone has tried the new V2.05?
If so is it worth transfer from MPLAB 8 yet?
Max.

 

Been using v2.0 for some weeks now. I like the interface and haven't run across anything that doesn't work (using 64-bit windows) I've compiled old programs and did a little debug. I really don't use all the features of an IDE. Mostly just compile, download, test, repeat. But so far, no issues.

 

Can anyone here confirm that it is the same in Windows?

It looks like the same in Windows (Win7-64) MPLABX 2.00 XC8 Ver 1.21.

Both 24 bit floats and 32 bit doubles (after configuring the linker) zero the RAM allocated to the vars when the value is changed in the watch or variables windows. Ints and chars work OK.

It doesn't seem matter which float format (IEEE or Microchip) is selected.

I don't know about MPLAB 8.x either. HiTech PICC-18 V8.35-PL3 also has problems displaying and modifying floats/doubles, at least for me.

Searching 'help' on various permutations of 'changing watch variable values' yielded nothing.

EDIT: Ticket submitted. We'll see what they say.

 

The question submitted on the ticket:

Problem Description:
XC8 Ver 1.21. When debugging with the simulator at a breakpoint, modifying any float or double (24 or 32 bit, IEEE or Microchip format) by double clicking and entering a new value e.g. 1.234, the value of the variable is set to zero instead. The variable's RAM is confirmed cleared to 00 00 00 00. Modifying ints/chars works fine.

How can these values be modified?

The answer:

Hi John,
We are able to duplicate it and logged this in our internal database for developers to look into.
Thanks for bringing this to our notice.

Regards,
Compiler Analysis and Assistance Team

Pretty quick response - on a weekend yet. The ticket is still open so more detail may follow.

FWIW: If the original question (no labels in the watch window) is still an issue, the answer is here (explicit setting of absolute mode in the project).

 

John: I was thinking on my drive to work today and I wonder if you can create a dummy union for your floats with the real float and something like a char array. Mebby it can set the char's correctly and not just zero out the variable.

Just a thought I didn't try. ;-)

 

John: I was thinking on my drive to work today and I wonder if you can create a dummy union for your floats with the real float and something like a char array. Mebby it can set the char's correctly and not just zero out the variable.

Just a thought I didn't try. ;-)

Its a good thought.. I think Joey said something about converting the IEEE float to hex and beating it in that way. Don't know if it would work as you say. I just figured I'd ping uCHIP while everyone was hollerin' to see what they said.. In the end, they seem to agree that it doesn't work like it should. They'll fix it and we'll go on..

Best,
JiTX

 

A couple weeks ago I choose to use MPLAB-X on a new project to see how it was coming. Heck, I might even try XC8 (over C18) as the compiler.

One thing FIXED in MPLAB-X 2.05 was the damn arrow key scrolling. That's how I inspect long section of code: with the up & down arrow keys. I just upgraded to that this weekend over v1.8 or 1.8 or such.

MPLAB-X would queue these things up as it took longer to scroll then a keypress took... so when you finally got to the place you sought and lifted your finger from the scroll key the damn display would keep on scrolling right past your place.

New version stops scrolling as soon as the arrow key is released. Only 40 revisions to get a most basic part of the UI correct.

 

Its a good thought.. I think Joey said something about converting the IEEE float to hex and beating it in that way. Don't know if it would work as you say. I just figured I'd ping uCHIP while everyone was hollerin' to see what they said.. In the end, they seem to agree that it doesn't work like it should. They'll fix it and we'll go on..

Best,
JiTX

Yes, that works...but it's a pain.

BTW, as long as you are hammering them, IEEE754 supports floats of arbitrary precision. Seems MPLabX natively (and not so well) only supports 24 and 32 bit floats. I suppose this is because the C compilers only support these lengths. Not a good enough reason in my book for the following two reasons:

1) Some of us don't use C, and are therefore not limited by the compilers' implementations;

2) Many times, 32 bits does not provide adequate precision for some operations. For instance, my polynomial regression library can support polynomials of arbitrary order. The limiting factor is the precision of the numbers used for intermediate results in the computation. I've discovered that for polynomials of order 3 or greater, I need at least 56 bit floats so as not to introduce significant errors in the result.

Have you ever tried debugging 56 bit floats by hand? Not fun.

Per Wikipedia, an arbitrary length float is defined by only two parameters, p and emax. It'd be nice to be able to specify these two parameters in the variable properties box in the watch window.

Bring it up if you like.

 

FWIW: If the original question (no labels in the watch window) is still an issue, the answer is here (explicit setting of absolute mode in the project).

This does not solve the problem for legacy code that uses equ or cblock directives.

 

FWIW - Received final notification on the ticket I submitted about modifying floats writing all zeros.

Problem Description:
XC8 Ver 1.21. When debugging with the simulator at a breakpoint, modifying any float or double (24 or 32 bit, IEEE or Microchip format) by double clicking and entering a new value e.g. 1.234, the value of the variable is set to zero instead. The variable's RAM is confirmed cleared to 00 00 00 00. Modifying ints/chars works fine.
How can these values be modified?

Hi John,
This issue has been fixed with MPLAB X 2.10.
Also we would suggest you to use the latest Xc8 compiler.

Onwards!

 

FWIW - Received final notification on the ticket I submitted about modifying floats writing all zeros.

Onwards!

Now, if only the watch window would recognize labels as addresses....

 

I'd like to bump this thread.

MPLabX is now up to version 5.0, and I would like to consider modifying some of my projects to work with it. MPLab 8.93 is getting pretty long in the tooth, and support for newer PICs is non-existent.

Originally, the main reason for rejecting MPLabX was its lack of support for .asm programming -- especially in the debug window.

I do lots of floating point math -- and I need the debugger to parse, display, and allow me to modify floating point values. As there is no floating point type definition in .asm, the debugger was not able to manage these types (which is very easy in MPLab).

Does anyone know: has this changed? Can raw-memory locations -- identified by labels -- be cast into floats and other data types in the debugger window?

Yes, I could spend the time to determine this for myself, but maybe someone has a quick answer.

Thanks in advance.

 

Wrote some really small code:

I can view custom length and format:



But I cannot manually edit the values in the watch window, whether integer or float. I can type in a value, but the original value is "sticky".

Am I doing something wrong?