Should I upgrade from MPLAB 8.92?

[rovtech]

Some time ago I tried MPLAB X but could not understand it. It seemed very user unfriendly. Now I am loading a new (for me) computer, Win7, and tried searching this site to see what everyone is using. Wikipedia says 8.92 is obsolete and not supported.
Any suggestions? Any reason to change?

[temtronic]

Well I'm using MPLAB v8.86 without any problems....

My standard is to NOT 'upgrade' if the version of the program is working fine for you. I'm also still using XP home as to 'upgrade' to an OS higher, I'd need new hardware($$$$) to run the new OS.......as it needs far more memory and I'd lose my real comports in the process....


Jay

[Ttelmah]

MPLAB-X, is not an upgrade.
It functions poorly, is bulky, slow, full of errors. If you think MPLAB is hard to use, MPLAB-X launches a whole new world of user hostility.
(I see you have found this already...).


Where it is needed is for support for newer chips.

Most people who use the environments at all seriously, install MPLAB-X 'as well', and then use MPLAB for the older chips, only using X 'if they have to'....

[rovtech]

Thanks Ttelmar and temtronic.
That is what I suspected.
If it ain't broke don't fix it (are you listening Microsoft and all you others who keep fiddling until their product is improved to the point of being useless, like Yahoo).

[asmallri]

To add to the comments from Ttelmah and temtronic,

Things get even worse when Microchip forced the migration of users to their Harmony framework for new PIC32 series processors abandoning their existing peripheral library and replacing them with a rewritten, incomplete and incompatible implementation.

MPLAB-X is diabolical by itself but when combined with Harmony it pushed development back into the stone ages.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

Don't insult Stone Age man!....

I don't think even they would have been that bad. They were smart you know, just lacked knowledge.

What amazes me, is that it must be hitting MicroChip actual product sales. Some of the alternatives for other chips are comparatively just so much more friendly. I must admit that if I went and tried the MicroChip PIC tools 'now', I'd probably just throw them away and use another chip....

The real pity is that the only really key things missing from the CCS IDE, are the simulator, and the abilities to do things like merge two hex files and output them as a single file (for initial 'single stage' programming of chips using a boot loader for example), and (of course) the disassembler. If CCS were really 'on the ball', they could have added these, and become the best tools for all PIC development.

[temtronic]

hmm.. Don't insult Stone Age man!....

Gee Mr. T. I though you were talking about me, since I've had CCS since V2.452 ! Back then you got a nice spiral wound hardcopy manual. Yes, CCS could add a few things BUT consider the effort(time and $$$) that goes into fixing a bug or adding a new PIC to just one compiler.
Yes a PROPER simulator would be nice but the shear number of different PICS and peripherals makes that a daunting challenge. As for the bootloader/program 'merge' that would be a great addition and probably the easiest to do. A disassembler might be useful to any of the 'senior' programmers but the listings do give the machine code and really any 'senior' should be able to understand the code. With so few instructions, 'low level' code for PICs isn't that hard to comprehend.

Jay

[Ttelmah]

I always describe myself as a 'short hairy Neanderthal', so 'Stone age man' is one up on that.... I too go back to the V2.something CCS versions. Can't remember the exact version. What would be complex for the simulator, is not the simulator itself, but the 'rule set' for each processor. Now if this was done using CSV rules, with a tool to compile these, and launched with a set for the half dozen most common chips, it'd be something the users here could expand.
The disassembler is actually very useful, have found a couple of bugs in CCS with this (a long time ago though), where the actual code generated did not agree with the list file...

[guy]

I could never figure this out in the 20 years working with Microchip - silicon production is ten times more difficult than software development! But Microchip was always about the hardware, they could never do software properly. Poor interface, poor stability. If I remember correctly, before version 5.xx or 6 MPLAB wasn't even reasonably stable and would crash...

I thought I was the only one with Win XP and MPLAB 8.91. Glad to know I'm in good company. I mostly use the simulator when measuring timing-critical ISRs. Wouldn't want to lose it.

[temtronic]

Guy, you're right about Microchip being GREAT at the hardware end of things...let's face it early PICs had <35 instructions so assembler was real easy say compared to the Z80.That allowed OEMs and 3rd parties to cut code at the lowest level, no 'need' for higher level like C, or dare I type BASIC.
Given the huge number of type and sub types of PICs ,I find it impossible that ANYONE could come up with proper tools in a 'one-size-fits-all' package.
CCS has done a great job in trying to keep up with the hardware.

Jay

[Ttelmah]

You put an interesting point on this.
CCS is _not_ a "one size fits all package". They have kept the components separate. So though they have a single 'wrapper' (if you use the IDE), the compilers are all separate. PCB, PCM PCH, PCD. Individual core compilers for each of the families. They use the same database for the chips, and lots of common components, but keep the compilers distinct, which is easier and safer. The same approach would be the way to go for any extensions to the IDE, such as a dis-assembler.

[asmallri]