PICkit4与ICD3，功能和编程速度比较？

不反对ICD2 OT PK2，但我确实在几周前在PK4上针对PK3和ICD3做了一些工作。在我尝试的PIC16设备上，我找不到任何特别的速度效益，直到今天，我仍然使用了几十个不同的PIC16设备。也可以在下面的几篇文章中看到，在很多情况下，速度问题纯粹是在大多数芯片没有编程时使用的算法，而不是调试器/程序员的问题。换言之，Microchip可能不只是卖给我们一个新的程序员，而是用简单的编程算法简单地更新现有的调试器/程序员。DGE“如全速调试和调试头等的情况下，您将远远好于PK3/ICD3/Realice。我希望有一天，他们能完成ICD4和PK4，达到一个合理的标准，但五年前左右，我也说了关于MPLAX和和谐的事情。ICD3和PK3几乎支持从第一天起的整个线路，与ICD4和PK4相距甚远。



      以下为原文

    Not against the ICD2 ot PK2, but I did do some work a few weeks ago on PK4 against PK3 and ICD3. I couldn't find any particular speed benefit on the PIC16 devices that I tried, and to this day that remains the case, and I've used a couple of dozen different PIC16 devices in that time.
 
https://www.eevblog.com/forum/microcontrollers/should-i-consider-buying-the-pickit-4/msg1461050/#msg1461050
 
plus also read my post a couple of posts down, where it transpires that for many scenarios, the speed problem is purely down to the algorithm used when most of the chip isn't programmed, and it's not down to the debugger/programmer. In other words, rather than selling us a new programmer, for many scenarios Microchip could have simply updated the existing debugger/programmers with smarter programming algorithms.
 
I'll be honest with you: in practice until there is comprehensive device coverage with ICD4 and PICkit4, including "edge" cases such as debugging at full speed and debug headers etc, you're far, far better off with PK3/ICD3/RealICE.
 
I live in hope one day they'll finish the ICD4 and PK4 up to a reasonable standard, but then five years ago or so I said the same thing about MPLAB X and Harmony. ICD3 and PK3 pretty much supported the entire line up from day one, a far cry from ICD4 and PK4.

PICIT4比PICTIT3快得多。ICD4仍然更快。比ICD3快，可能禁食TGaN真正的冰。但是在MPLabX，设置时间越慢，PIC越小，你就越不注意它。



      以下为原文

    The PICKit4 is much faster than the pickit3. The icd4 is faster still. Faster than the icd3 Probably fasted tgan the Real ICE. But with the slow setup time in MPLabX the smaller the pic, the less you will notice it.

嗨，另一个重要的点是当前PACKIT4和ICD4处于“改进”模式，我的意思是它们目前不覆盖所有PIC/DSPIC（与PICTIT3/ICD3相比）。因此，在选择之前，请确认已经使用的PIC（S）已经被支持。每一个新的MPLAX版本都增加了很多。（只需创建一个项目或检查您的当前项目，它们在项目Projices最后一个点有黄色或绿色的“气泡”，ICD4/CIPIT4具有“调试连接器”，准备好了8个引脚……这意味着将来它们还可以覆盖JTAG/AVR支持；同样也是ICD4。



      以下为原文

    Hi,
Another important point is that currently Pickit4 and ICD4 are in "improvement" mode, I mean they currently do not cover all PIC/dsPIC (compared to pickit3/ICD3).
So make sure before to chose that the PIC(s) you use are already supported. Each new MPLAB X version adds lots of them. (Just create a project or check with your current project that they have yellow or green "bubbles" for these tools in the project properties
Final point, ICD4/pickit4 have "debug connector" ready for 8 pins...meaning in the future they may also cover JTAG / AVR support ;=)
Pickit4 is faster than ICD3 as is also ICD4.
Regards

是的，我认为在MPLAX X中，芯片4和ICD 4仍然是许多芯片的测试阶段。Microchip有太多的东西需要改进：MPLAB XPICIT 4ICD 4等等。



      以下为原文

    Yep I think Pickit 4 and ICD 4 is still in beta stage for many chips in MPLAB X. 
Microchip has too many things need to be improved:
MPLAB X
Pickit 4
ICD 4 and so on

似乎Sigger-J-Link与PIC32 MX和PIC32 MZ产品很好地合作，甚至在某些方面比ICD4更好：http://www. McCux.com……1041933.ASPX？树=真



      以下为原文

    And it seems Segger J-Link is working very well with PIC32MX and PIC32MZ products, even better than ICD4 on some aspects:
https://www.microchip.com...1041936.aspx?tree=true
 

重述这一点，而PK4比PK3快，魔鬼就在细节中，正如我在EVBooX线程中提到的那样，所以我将重构我在那里写的东西，使它更清晰。我用PIC32 MX1／2/5启动工具包使用BLIMKY，用1K字节的代码进行了测试。现在是几秒钟的时间。现在看来，ICD4和PK4在前面的街道上。但是它们是吗？让我们改变程序使用500 K字节的程序Flash，所以在PK4/ICD4和ICD3/Realice之间，事情并不是那么枯燥。对于PKOB/PK3/ICD3/RealICE，程序是否有1K程序或500 K程序的编程时间几乎没有变化。为什么会这样呢？事实上，对于许多设备来说，默认的.LD链接器文件在用户程序和“μBaseX”地址之间的闪存中造成了很大的空白。四个较旧的调试器的MPLAB X驱动程序不够智能，忽略空白，而ICD4和PK4跳过这个空白区域编程。因此，如果我返回到1K字节的BLIMKY文件，并将.LD链接器文件移动到程序代码的上方，则说：请参见此：因此，我建议在旧编程设备的非优化编程算法中浪费大量的时间，而不是设备本身。对于较大的程序，是的，ICD3/RealIC/ICD4/PK4肯定会赢得PKOB/PK3。不管怎样，对设备的补丁支持，在PIC32 MZ上全速中断调试，并且没有对调试头的当前支持意味着ICD4和PK4仍然聚集灰尘。我关心的是，在PIC32 MZ上进行全速调试的问题可能是ICD4/PK4中的一个基本硬件缺陷，而不是软件问题，但我希望被证明是错误的。



      以下为原文

    Revisiting this, while the PK4 is faster than the PK3, the devil is in the detail, as I noted in the eevblog thread I mentioned, so I'll restructure what I wrote there to make it clearer.
 
I did a test with PIC32MX1/2/5 Starter Kit using a blinky, with 1k bytes of code. Here are the times in seconds.
 

PKOB    47
PK3     50
ICD3    17
RealICE 20
ICD4     8
PK4      8

 
Now, it would seem that the ICD4 and PK4 are streets ahead. But are they? Let's change the program to use 500k bytes of program  flash.
 

PKOB    48
PK3     47
ICD3    20
RealICE 21
ICD4     20
PK4     20

 
So things are not quite so cut and dry between PK4/ICD4 and ICD3/RealICE. And the programming time has barely changed whether there was 1k to program or 500k to program for the PKOB/PK3/ICD3/RealICE.
 
Why is this? Well, it turns out that for many devices the default .ld linker file creates a large gap in the flash between the user program and _ebase_address. The four older debuggers' MPLAB X drivers are not smart enough to ignore the blank space, whereas the ICD4 & PK4 skip programming this blank area.
 
So, if I go back to the 1k byte blinky file and alter the .ld linker file to move _ebase_address to just above the program's code, say 0x9D001000, we see this:
 

PKOB     8
PK3      8
ICD3     8
RealICE  7
ICD4     8
PK4      8

 
So, I'd suggest that a significant amount of time is wasted in non-optimum programming algorithms for the older programming devices, rather than the device itself.
 
For larger programs, yes, the ICD3/RealICE/ICD4/PK4 will certainly win over the PKOB/PK3. Irrespective, the patchy support for devices, the broken debugging at full speed on PIC32MZ, and no current support for debug headers means the ICD4 and PK4 remain gathering dust. What concerns me is that the problem of full speed debugging on PIC32MZ might be a fundamental hardware flaw in the ICD4/PK4 rather than a software problem, but I'd love be proven wrong!

不是一个ICD4问题，但仍然是一个编程时间问题：我意识到编程PIC确实需要比编程AVR更长的时间。但是：在任何调试开始之前，与ELF文件的极端长加载时间相比，多少秒看起来很少。在我的情况下超过90秒，JavaW.EXE在这个期间消耗25%。95%的CPU时间。没有MCHP的回答，我把问题放在这里：在程序暂停之前有任何经验吗？有什么聪明的办法来修补这个吗？PIC32 MK0512GPD100，~128K闪存使用



      以下为原文

    Not an ICD4 problem but still a programming time issue:
I realized that programming the PIC indeed takes considerably longer than programming the AVRs.
But: Some seconds more or less look minimal compared to the extreme long loading time of the .elf file before any debugging can begin. Takes over 90 seconds in my case and javaw.exe consumes 25%..95% CPU time during this period.
Having no answer from MCHP i place my question here: Any experience with this before-program-pause? Any clever trick to mend this?
PIC32MK0512GPD100, ~128k flash used

Ifthige:这是一个很长的时间：HTTPS://www. McCHIP.COM/FoMss/FuntP/1030668 MyDealPosiver（基于PIC16F1454芯片）在11秒内运行512K PIC32 MX570，几乎快两倍，它将在1秒内编程1K BLIMKY。虽然部分地，MPLAB X有它自己的开销，它不应该被归咎于ICD4。这是非常有趣的，小PIC16F1454设计优于（SPARTAN-6+300 MHz山姆）设计几乎两倍。在任务上抛出大量硬件并不总是产生最好的结果：



      以下为原文

   


I figured it was the case long time ago: https://www.microchip.com/forums/FindPost/1030668
 
My programmer (based on PIC16F1454 chip) does 512K PIC32MX570 in 11 seconds, almost twice as fast, and it would program 1K blinky in a fraction of a second. Although, partially, MPLAB X has its own overhead which shouldn't be blamed on ICD4.
 
It's quite interesting, little PIC16F1454 design outperforms (Spartan-6 + 300MHz SAM) design almost by a factor of two. Throwing lots of hardware on the task doesn't always produce the best results :) If ever ...