EEVblog® Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Fire Doger on May 18, 2023, 12:42:44 pm
-
Somehow I stumbled across this link https://www.microchip.com/en-us/development-tool/PG164150 (https://www.microchip.com/en-us/development-tool/PG164150)
and this https://www.microchip.com/en-us/development-tool/DV164055 (https://www.microchip.com/en-us/development-tool/DV164055)
Didn't found any mention so I guess it's just released. ;D
-
Interesting. I'll probably get one to try when they are available.
However I have to say we have become so fed up with the reliability of the PICkit4's that we purchased an NSDSP-2-X from Northern Software. Its not only reliable its way faster than the PICKIT4 - so we bought a number of them. Fingers crossed the PICKIT5 will be better than the PICKIT4.
-
@woofy,
Can that Northern Software programmer do hardware debugging with a Microchip development suite? Related to that, is it just for burning in a finished hex file?
-
Never actually tried. We use them for low volume production programming (higher volume stuff is purchased pre-programmed).
I'm still using a pickit4 here for development (working from home).
Their website says they can
- Can program and debug most Microchip PIC® microcontrollers.
However you should probably contact them directly.
-
Just ordered one of each. Will report.
My experience of ICD/Pickit 4 is they are significantly faster, and advantage over ICD4 over pickit 4 for just programming is way less than ICD3 vs. PICKit3.
Although it appears to have more protection, I've managed to kill one Pickit4 (vs many Pickit 3's & clones).
-
Same experience as mike.
I deem the BLE+App to upload imaged wirelessly very interesting. Sometimes you can't have a bootloader. It could be that we get a PK5 to try pretty soon.
I wonder what's under the hood, did they use a polarfire for the ICD5 this time?
-
Same experience as mike.
I deem the BLE+App to upload imaged wirelessly very interesting. Sometimes you can't have a bootloader. It could be that we get a PK5 to try pretty soon.
I wonder what's under the hood, did they use a polarfire for the ICD5 this time?
I'd be happy if you could put a .hex file on the SD card - the way Pickit 4 does programmer-to-go seems unnecessarily cumbersome
-
answering my question: the ICD5 uses a microsemi FPGA, everything is built inhouse
https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/UserGuides/MPLAB_ICD_5_In-Circuit_Debugger_Users_Guide_50003529.pdf
-
Pickit 5, compared with pickit 4.
Only immediately obvious differences are USBC connector and Bluetooth module.
-
ICD5 internals
Nothing too surprising, though having 3 connectors on different sides is a bit ugly
Ethernet (with PoE) is handy for anyone wanting isolation.
-
Ok so not going so well - Tried Pickit5 on a couple of projects that work fine with Pickit 4, but just geting "Transmission on endpoint 2 failed"
Tried the firmware recovery option in IPE, pickit5 now appears dead.
And now MPLABX IDE and IPE 6.1 just crash as soon as I plug the programmer in..
-
Same "Transmission on endpoint 2 failed" error with ICD5. Looks like a USB driver issue.
-
OK some progress...
Installed MPLABX 6.1 on a Win10 laptop. Connected ICD5 and it did a firmware update that I did not see happenning under Win7.
After this, ICD5 works on both Win7 and Win10 machines.
Also tried ethernet mode, which works nicely, though I could only get to to work when powered by PoE - seems like it should be possible to use USB power but I couldn't get this to work
Managed to recover PICkit5 after a few attempts, and got it working on Win10
Still getting "transmission failed on endpoint 2" on Win7. Currently installing MPLAB 6.10 on another laptop to see if issues is Win7 or just my PC.
-
The ICD5 looks interesting, I like the idea of PoE, quite handy for me that.
-
Too bad MPLAB has become a disaster. :-//
-
@mikeselectricstuff
If you get the pickit5 going, I'd be interested in how the programming speed compares with the pickit4.
I suspect identical.
-
Too bad MPLAB has become a disaster. :-//
in what way?
-
Too bad MPLAB has become a disaster. :-//
in what way?
it doesn't have that vintage VB6 feeling?
it doesn't lack of most IDE features from this past two decades?
it IS a disaster to work with if you're using assembly exclusively, but that's it
-
death of mpasm was a tough one to swallow
-
Microchip's response
If you are using a Windows 7 machine, I would recommend using 3rd Gen tools (MPLAB PICkit 3 and MPLAB ICD 3).
Running MPLAB ICD 5 on a Windows 7 is neither tested nor supported. It may cause incorrect driver updates and brick the unit, beyond repair.
Disappointing as everything else works. And if it can brick hardware then that's just piss-poor design.
-
Many professionals, including me, still run Win7 due to its rock-solid reliability and stability. Microchip needs to insure compatibility with Win7, period. There's just too many people out there who run it.
-
@IDEngneer
While that is true, Microchip ignored similar pleas to keep MPASM alive and allow users to add to chips to MPLAB IDE.
-
Then this is a great opportunity for them to learn from past mistakes!
-
@IDEngneer
While that is true, Microchip ignored similar pleas to keep MPASM alive and allow users to add to chips to MPLAB IDE.
it was not possible to get to a 64bit executable of MPASM without a complete rewrite. We've been through this many times.
At that point they had no incentive to do so as they had a currently mantained assembler used by the compiler, and a legacy assembler. They had two and dropped the old one. Makes sense.
It's not like they forbid you to have different versions of the tool installed at the same time.
and ALL past versions are currently available through the microchip download archives.
Many professionals, including me, still run Win7 due to its rock-solid reliability and stability. Microchip needs to insure compatibility with Win7, period. There's just too many people out there who run it.
see above regarding the possibility to use older versions of the tools.
i don't miss win7. One week after being forced to use it at work i was smiling because how better it was at many little things.
i don't miss PK3, PKOB or even the ICD3. And there were a number of people reporting that 3rd gen tools didn't work anymore under linux since 6.00, some even earlier (who knows what internal library had changed that broke it)
Then this is a great opportunity for them to learn from past mistakes!
From what I know, one of their biggest customers still use some ancient parts with MPLAB 8 and MPASM. If their biggest customers are unable to change microchip's mind it's either not a problem, or actually not a mistake
-
They suggested sticking to pickit3/icd3 for win7.
Ime pk4/icd4 work fine, and are significantly preferable as they don't need fw updates when switching device families.
It is good that they do still support icd3 on mplab8, via
The driver switcher,though it can be a mighty faff in practice.
-
Too bad MPLAB has become a disaster. :-//
in what way?
In almost every way. But considering what had just be pointed out earlier, the infamous "transmission failed on endpoint 2" is absolutely nothing new. It has plagued MPLAB X for years with several different generations of ICDx and Pickitx, which would point to MPLAB itself rather than the hardware, especially since those communication issues are almost non-existent using IPE.
I've seen this problem for years on various OSs and various versions of MPLAB and programming probes.
This thread came at a funnily appropriate time: https://www.eevblog.com/forum/microcontrollers/flashing-pic-uc-without-mplab-(i-have-a-pickit)/ (https://www.eevblog.com/forum/microcontrollers/flashing-pic-uc-without-mplab-(i-have-a-pickit)/)
Anyway, it's really about flashing devices, and there is IPE for this. Otherwise one can absolutely do without MPLAB to develop for all they MCUs, something that a few of us here recommend on a regular basis. It's not specific to Microchip, most vendor-provided IDEs are crap.
-
It is good that they do still support icd3 on mplab8
That's only a "sorta." The chip I was using for a just finished project was 16F1789 ( I wanted extra pins for routing). That chip has a glaring error in the MCC .inc file. Moreover, programming with the most recent .jam file and ICD3 was problematic. My correspondence generally began with MCC telling me to install MPLAB X. Later, a kind agent gave me a link to a legacy .jam file and everything has worked since.
-
They suggested sticking to pickit3/icd3 for win7.
I'm happy to follow their advice. Where on their website do I purchase new ICD3's to do so?
-
it was not possible to get to a 64bit executable of MPASM without a complete rewrite.
Was it written entirely in assembly language? Otherwise I'm not sure I understand how that's possible!
We've been through this many times.
Reference? (I don't recall seeing the discussion.)
Not being backwards-compatible with 30-odd years of existing assembly code seems like a huge mistake.
Who knows how long the older MPASM toolchain will continue to run on "modern" PCs.
(Is there a third-party (preferably open source) MPASM-compatible available? After all, there are at least 3 Atmel-compatible AVR assemblers...)
-
it was not possible to get to a 64bit executable of MPASM without a complete rewrite.
Was it written entirely in assembly language? Otherwise I'm not sure I understand how that's possible!
We've been through this many times.
Reference? (I don't recall seeing the discussion.)
Not being backwards-compatible with 30-odd years of existing assembly code seems like a huge mistake.
Who knows how long the older MPASM toolchain will continue to run on "modern" PCs.
(Is there a third-party (preferably open source) MPASM-compatible available? After all, there are at least 3 Atmel-compatible AVR assemblers...)
"We've been through this" over at the microchip forum, at least. It's written in a flavour of pascal for which the compiler has been defuct for ages, and that couldn't be compiled directly with another compiler that was able to produce a 64bit executable (and i believe they tried. As you and others pointed out over the years there is a ton of legacy code written for MPASM that can't be easily translated into PIC-AS, i also mentioned i know of very big customers of them that still use MPASM to date)
i believe GPUTILS/GPASM is what you're looking for?
-
Interesting link. I found this comment encouraging:
Source:
https://gputils.sourceforge.io/
Jan 30, 2022 -- gputils-1.5.2 Released
New experimental gplink features: banksel, pagesel and pcallw
Support for more PIC16F184XX devices.
A few minor bugfixes.
So, although development may be slow and apparently led by only one person, it is not dead.
-
I'm happy to follow their advice. Where on their website do I purchase new ICD3's to do so?
I suspect new ones will be very hard to fine. eBay may be your only choice.
-
The micro USB connector is garbage on the PICKit 4, I've gone through replacing three of them at the office. USB C is much better. I still use the old reliable ICD3 sometimes.
-
The micro USB connector is garbage on the PICKit 4, I've gone through replacing three of them at the office.
true. replaced yet another one today. I wish they'd update the PK4 with a USB-C connector, for those who don't care about the bluetooth part
I also wish someone would release a drop-in type C connector for USB 2.0 with the same pinout as the Micro B/C, with integrated 5.1k resistors
-
Just got my PICkit 5 today, not sure how useful Bluetooth is yet as it's currently only programmer to go app iPhone / Android; the USB C connector is a win for sure.
-
not sure how useful Bluetooth is yet as it's currently only programmer to go app iPhone / Android
I think that's the idea, what were you expecting?
-
I think that's the idea, what were you expecting?
I guess I was hoping you could program & debug from MPLABX using Bluetooth, similar to Ethernet on the ICD5.
-
"We've been through this" over at the microchip forum, at least. It's written in a flavour of pascal for which the compiler has been defuct for ages, and that couldn't be compiled directly with another compiler that was able to produce a 64bit executable (and i believe they tried. As you and others pointed out over the years there is a ton of legacy code written for MPASM that can't be easily translated into PIC-AS, i also mentioned i know of very big customers of them that still use MPASM to date)
The deprecation of MPASM really bothered me, but I've gotten more or less used to PIC-AS since. The issue above with the Pascal variant and support for x86-64 is fascinating. It's crazy how quickly software can go out of date... There's probably also an argument to be made for using open toolchains whenever possible in there somewhere.
-
"We've been through this" over at the microchip forum, at least. It's written in a flavour of pascal for which the compiler has been defuct for ages, and that couldn't be compiled directly with another compiler that was able to produce a 64bit executable (and i believe they tried. As you and others pointed out over the years there is a ton of legacy code written for MPASM that can't be easily translated into PIC-AS, i also mentioned i know of very big customers of them that still use MPASM to date)
The deprecation of MPASM really bothered me, but I've gotten more or less used to PIC-AS since. The issue above with the Pascal variant and support for x86-64 is fascinating. It's crazy how quickly software can go out of date... There's probably also an argument to be made for using open toolchains whenever possible in there somewhere.
then you're free to use GNUASM :D (I'm joking, I 100% agree on the necessity to always have a usable open source tool, but at least microchip doesn't have a track record of being huge dicks to customers so i have no problem in using their tools exclusively for the time being)
IIRC the real nail into the coffin was the PIC18 Q series. MPASM had a harcoded maximum number of configuration words, which the PIC18 Q exceeded. At that point they had to change and recompile the thing, couldn't to it anymore, and threw the towel. Or something like that
-
then you're free to use GNUASM
I don't think gnuasm supports PIC8...
at least microchip doesn't have a track record of being huge dicks to customers
I've seen conflicting opinions. Deprecating an assembler without a compatible replacement seems pretty bad. Hardware programmers also seem to have a pretty short life. (PicKit4 just declared EOL, for instance.)
Then there's the privatization of OSSW (gnu C for AVR, and 16 and 32bit PICs), the disappearance of avr-libc, and the occasionally VERY sub-optimal "free" versions of 8bit PIC C compilers.
-
then you're free to use GNUASM
I don't think gnuasm supports PIC8...
at least microchip doesn't have a track record of being huge dicks to customers
I've seen conflicting opinions. Deprecating an assembler without a compatible replacement seems pretty bad. Hardware programmers also seem to have a pretty short life. (PicKit4 just declared EOL, for instance.)
Then there's the privatization of OSSW (gnu C for AVR, and 16 and 32bit PICs), the disappearance of avr-libc, and the occasionally VERY sub-optimal "free" versions of 8bit PIC C compilers.
Yes, it was GPASM, my bad
https://gputils.sourceforge.io/
For the rest, i don't have the energy to repeat myself again but i'll try.
you should install the latest compilers, write some meaningful code (something that uses pointers, mixed address spaces, interrupts, not bullshit tests to see how fast you can flip a pin), remind yourself that you are writing C and not assembly (of course with assembly you can write it "better") and really tell me it doesn't produce good code. If not, enable -O1 or -O2 and retry.
MPLABX 5.35, always available at the microchip archives, has the latest MPASM in it.
PK4 EOL didn't make sense, they should have just sold it as PK5 without the BLE module, for the rest is same board, same firmware.
-
Many professionals, including me, still run Win7 due to its rock-solid reliability and stability. Microchip needs to insure compatibility with Win7, period. There's just too many people out there who run it.
In mid 2023? Windows 7 was essentially discontinued in 2012 and even extended support ended at the end of 2019. Whilst I can really sympathise with people needing to support their legacy assembler products, anyone using MPASM for new designs or using Windows 7, 8 or 10 machines for their new designs are just asking for trouble. There's no need to create a time capsule environment when developing new designs.
Whilst Windows 8 was a bit of a miss, Windows 10 has been a pleasure and I now enjoy productive development on Windows 11 for a variety of hardware design and both embedded and desktop software. Equally, anyone still using assembly to write code for PICs in 2023 are probably missing a trick. I am just working on a project written in 2015 in assembler. It was written in assembler for no reason at all and is now just a pain to maintain. No assembler IDE has ever been very good. No assembler build process has ever been very good. I'd say that even with a poor modern compiler, using assembly has been questionable for the last 15 years.
Let's hope Microchip release the PicKit3 as an open source project like they did with the 1 and 2. At least then it could be used with a VM or workstation that isn't connected to the network to maintain older code that isn't worth rewriting.
-
In mid 2023? Windows 7 was essentially discontinued in 2012 and even extended support ended at the end of 2019. Whilst I can really sympathise with people needing to support their legacy assembler products, anyone using MPASM for new designs or using Windows 7, 8 or 10 machines for their new designs are just asking for trouble.
Has nothing to do with Assembler, and everything to do with a stable environment that the USER controls. My wife and son both use multiple Win10 and Win11 PC's and they are constantly plagued by "updates" at inconvenient times, with those updates often "helpfully" changing system settings in an "I know better than you do" fashion that can take hours to unravel.
Another example: I have a friend with a private medical practice that runs on software hosted on Windows. A network of PC's, one in each exam room plus the front desk and individual doctor's and nurse's offices. When that medical office software package forced them to upgrade to Win10 (and now Win11) his totally stable environment went to @#$^& and now, every time Microsoft deems it useful to them to upgrade their machines, their office more or less shuts down for half a day while the staff sits on the phone with the app vendor resetting everything that the Microsoft "upgrade" changed.
This isn't a religious thing for me. I just want tools that *I* control, that *I* can configure and which stay that way, so that my tools don't get in the way of what I'm actually trying to accomplish. I don't get paid to handle Microsoft's decisions but I and others often DO lose valuable time having to unwind the damage those decisions cause. I don't mind the GUI changes (though those often seem gratuitous too). If Microsoft would stop compelling "updates" and other post-Win7 behavior I'd happily update every machine I own/control.
-
True to form, Microsoft provides another example just yesterday!
In this link:
https://arstechnica.com/gadgets/2023/12/microsoft-releases-downloadable-tool-to-fix-phantom-hp-printer-installations/
...we read "Affected PCs were seeing an HP printer installed, usually an HP LaserJet M101-M106, even when they weren’t actually using any kind of HP printer. This bug could overwrite the settings for whatever printer the user actually did have installed and also prompted the installation of an HP Smart printer app from the Microsoft Store."
Note that you get the machine mods without request, but YOU have to research the fix, then manually download and run it.
Yes, it was "just the printer". This time.
How many professionals want this happening to a key tool upon which they rely every day? Why would you willingly subject yourself to this if you could avoid it?