ICD3 Issues swithcing between MPLAB8 and MPLABX - Page 1
Forum section: electronics / general

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 30, 2016, 02:19:29 pm
content: Just spent a couple of hours figuring out a nasty issue, thoygh I'd mention it here in case anyone else encouters itToo lengthy to go into details, but if you use ICD3 with PIC32MZ under MPLABX 3.45, it breaks something that then prevents it subsequently working correctly with MPLAB8,The fix is to force MPLABX to load PIC32MX firmware ( or other family that MPLAB8 knows about), e.g. by running MPLAB IPE and selecting a device in the ol familyThis is not related to the driver switching stuff, and only appears to be an issue with MPLABX 3.45 ( ICD3 firmware 1.45.41), was OK with MPLABX 3.20 ( ICD3 FW 1.40.13)

author: Howardlong
author_rank: Super Contributor
timestamp: November 30, 2016, 03:38:02 pm
content: I'm not sure if I've encountered your error, but there is a feature in the installer they managed to introduce where in certain circumstances where the planets are out of alignment it decides removes the switcher even though you still have MPLAB 8.92 installed.Barely a day goes by these days without me finding another undocumented feature in Microchip's stuff somewhere, particularly anything to do with automated code generation including both MCC and MHC, as well as anything to do with Harmony. :-(Yesterday it was the EBI peripheral headers, they work for the 144 pin MZ devices, not the 100 pin devices: the headers refer to registers of unimplemented peripheral instances.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 30, 2016, 04:53:51 pm
content: Not a problem for me because I couldn't wait to ditch MPLAB8. I say good riddance to that pile of crap.

author: JPortici
author_rank: Super Contributor
timestamp: November 30, 2016, 06:26:00 pm
content: Quote from: mikeselectricstuff on November 30, 2016, 02:19:29 pmsame shit that happens to me everytime with the pickit3. if i'm using it with X and then i open a project on mplab using a different family, mplab will download an older firmware to the PK3 and break everything until i reprogram it with the IPE or XQuote from: Sal Ammoniac on November 30, 2016, 04:53:51 pmtrue that, whenever i have some time i port old projects of active products to X /XC8/XC16 so i won't get infuriated when i will eventually have to update it

author: Howardlong
author_rank: Super Contributor
timestamp: November 30, 2016, 09:52:34 pm
content: I still use both 8.92 and MPLABX, although I'm on MPLABX about 85% of the time now.My biggest complaint remains, after several years, that almost everything is markedly slower on MPLABX, particularly debugging. It's one of the compromises of a cross-platform IDE that has to jump between native code (to access the hardware debugger) and Java I guess.There are a few minor benefits in MPLABX that I miss in v8 such as auto-completion and definition navigation, but if you've been programming stuff as long as I have (and others I am sure) I find these features are largely trivia and prove the law of diminishing returns. I'd much rather have a fast edit-compile-build-program-run/debug turnaround given the choice.It would also be nice if you could turn off background project parsing, but I think that's a bloat feature of Netbeans that you aren't able to turn off as far as I can see. While it's fine on a reasonably good machine with plenty of RAM and CPU plus SSD, it's not always the case that you have that luxury.If I had a choice, I would still be using MPLAB 8 for all my projects despite its own foibles and oddnesses.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 30, 2016, 10:04:23 pm
content: If I had a choice, I'd have migrated across completely to STM32.Unfortunately, no STM32 will run off 5V at 150 deg C.

author: Howardlong
author_rank: Super Contributor
timestamp: November 30, 2016, 10:09:50 pm
content: Quote from: AndyC_772 on November 30, 2016, 10:04:23 pmA case of the grass always being greener!From what I hear about STM32Cube I think I'll pass, Harmony is bad enough ;-)

author: AndyC_772
author_rank: Super Contributor
timestamp: November 30, 2016, 10:21:18 pm
content: I do use STM32 regularly, and you're right, ST's support package isn't great - but nor is it necessary to use it beyond the header definitions.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: November 30, 2016, 10:54:49 pm
content: Quote from: Howardlong on November 30, 2016, 09:52:34 pmI run MPLABX on a screamingly fast machine, so I don't notice any speed issues while debugging.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 30, 2016, 11:16:54 pm
content: At least it's good the Microchip still support MPLAB8 at all, though hard to see why they couldn't have made drivers automatically compatible with both.I default to 8 mostly because it's what I know - only used MPLABX when I had to do a very small PIC32MZ job and it wasn't worth trying to bodge MPLAB8 to do it.

author: Howardlong
author_rank: Super Contributor
timestamp: December 01, 2016, 12:34:24 pm
content: Quote from: Sal Ammoniac on November 30, 2016, 10:54:49 pmI run MPLABX on two reasonably decent machines, both I7 quad cores, 16GB RAM, SSD, and I still prefer MPLAB8 for its speed in the development cycle. Occasionally for one particular project for various reasons to do with a client requirement for environment segregation I run MPLABX on a Surface 3 (4GB RAM, "SSD", Atom quad core), and it's so slow it's almost unusable. Aside from the OS (x64 Windows 10) only the development environment is installed. I suspect the main bottleneck is its SSD that I believe is really an eMMC drive.

author: JPortici
author_rank: Super Contributor
timestamp: December 01, 2016, 02:04:25 pm
content: really? in the brief period i had a surface 3 (the 64 GB ssd, 2GB ram i believe... Had it for a couple of months) i was also running X on it, i don't remember having all these problems

author: Howardlong
author_rank: Super Contributor
timestamp: December 01, 2016, 02:51:51 pm
content: Quote from: JPortici on December 01, 2016, 02:04:25 pmTo be fair, the projects on that laptop are Harmony ones, so have well over 100 source files :-(

author: JPortici
author_rank: Super Contributor
timestamp: December 01, 2016, 05:53:40 pm
content: and each time i'm even more glad i never touched that stuff

author: Howardlong
author_rank: Super Contributor
timestamp: December 01, 2016, 07:24:24 pm
content: Quote from: JPortici on December 01, 2016, 05:53:40 pmYou got that right. When I first started to use it there was no code generator, but they still practically forced you into a strait jacket of code layout. The code generator, MHC, is a double edged sword. Sure, you can generate an enormous project with it... to do a blinky. Still pretty much the only way to build something that relies on non-trivial peripherals like Ethernet or USB is to use their code generator and accept the gazillions of bugs it generates that you have to hack around. It is very difficult to maintain, you continually risk blowing away your own code as it doesn't properly differentiate between its own code and yours, you have to manually choose whether it blows away your code every single build.It doesn't port at all well between versions of Harmony or MPLABX, hence using a standalone laptop to maintain a static build environment. Why not use a VM? Because it breaks the compiler licensingSo, yes, if you can avoid, do so!