从程序运行到SOOO正常吗？

嗨，对我来说，在我的PC上编译超过1MN的和声项目是很正常的。在编译这个处理器时，你会看到和其他处理器的编译相比有什么不同吗？



      以下为原文

    Hi,
It's normal for me to compile for more than 1mn Harmony projects on my PC.
Do you see a difference when compiling for this processor compared to compiling for other processors.
Regards
 

这不是编译，而是调试器速度。



      以下为原文

    This isn't compiling, rather debugger speeds.

也许它是相关的-我也看到奇怪的行为，在一些目标上-特别是与PIC24FJ256GA704，MPALBX 4.01和ICD3。在点击调试按钮，我的代码编译在第二，然后调试器采取控制，没有发生在输出窗口15秒，然后目标被突然擦除和在两到三秒内编程。我的程序主要功能是空边循环。其他目标没有长期的“死期”。我也尝试过PICTIT3，但它甚至比ICD3还要慢。我尝试过MPLABX 3.65，但它是一样的。我尝试通过IPE编程，但它同样慢。这里是从IPE20170928 19:56:15+15- 0200编程-设备擦除…编程的样本…下面的内存区域将被编程：程序存储器：起始地址＝0x0，结束地址＝0x3FFP编程/验证完成2017—09 28 19:56:34 + 0200 -编程完成表计数：6IT花费MO编程之间的时间…和设备擦除…线。然后运行相对较快。但无论如何，19秒的程序100B的代码。这种缓慢的动作是可重复的，而不仅仅是单次故障。我可以承受100B代码的三秒编程，但是等待15秒太多了。我知道制作通用和可靠的程序员不是简单的任务，在那里，做了这一点-对于8位PIC，16位的，以及摩托罗拉HC08或现在的Microchip AVRS。我们有神奇的硅产品，这个特殊的PIC可以擦除它的闪光灯在几十毫秒，并通过高速USB端口的ICD3传输100B，加载到目标，并写闪存内容应该发生在其他几十毫秒，最坏的。一切都低于100Ms。



      以下为原文

    Perhaps it's related - I'm seeing weird behavior too, on some targets - particularly with PIC24FJ256GA704, MPALBX 4.01 and ICD3.
After hitting Debug button, my code compiles in a second, then debugger takes control, nothing happens in output window for 15 seconds, then target is suddenly erased and programmed in two or three seconds. My program is main function with empty while loop. Other targets do not have such as long "dead periods". I tried PicKit3 too, but it's even slower than ICD3. I tried MPLABX 3.65, but it does the same.
I tried programming through IPE, but it's equally slow. Here is sample from IPE
 
2017-09-28 19:56:15 +0200 - Programming...
Device Erased...
Programming...
The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
Programming/Verify complete
2017-09-28 19:56:34 +0200 - Programming complete
Pass Count: 6
 
It spends most of the time between Programming... and Device Erased... lines. Then it runs relatively fast. But anyway - 19 seconds to program 100B of code. This slow action is repeatable, not just single-time glitch.
 
I could suffer the three seconds of programming for 100B of code, but waiting another 15 seconds is way too much. I know making universal and reliable programmer isn't simple task; been there, done that - for 8-bit PICs, 16-bit ones, as well as Motorola HC08 or now Microchip AVRs. We have fantastic silicon products, this particular PIC can erase it's FLASH in few dozens of miliseconds and transferring 100B through high-speed USB port of ICD3, loading into target and writing the FLASH content should take place in another few dozens of miliseconds, as worst. Well under 100ms for everything.

什么时候编程？只需花多长时间？



      以下为原文

    What portion of that time is programming?  How long does it take to just program? 

离我近一分钟。我猜是3/4的编程，剩下的是配置位。



      以下为原文

    Close to a minute for me.  I'd guess 3/4's programming, remaining on config bits.

阅读ICD4论坛中的线程。



      以下为原文

   
Read the threads in the ICD4 forum.

好的，我想现在我更喜欢稳定性比速度。如果把1芯片送到铸造厂的努力可以投入到MPLABX和DEV工具……



      以下为原文

    Ok, I think I prefer stability over speed for now.
 
If the effort it took to take 1 chip to the foundry could be put into MplabX and the Dev tools......

对于PIC32 MZ2048 EFH60%使用的第二编译时间从点击到我的程序Stista RealEcice程序：32秒调试：39秒



      以下为原文

    For a PIC32MZ2048EFH

• 60% used
  
• Second Compile
  
• time from Click to my program starts
  
• a RealIce
  

Program: 32 Seconds
Debug: 39 seconds

我认为问题的一部分可能是对MPX所做的无关的DV工具的搜索。点击时间在这里运行超过一分钟。Wi7x64上的32GB RAM Xeon应该足够快。



      以下为原文

    I think part of the problem could be all the searching around for unrelated dev tools that mpx does.

Time from click runs well more than a minute here. 32gb ram xeon on win7 x64 should be fast enough.

如果启用了每次生成后不重新连接的选项，则可以加快速度。



      以下为原文

    You can speed it up if you enable the option to not reconnect after each build.

“NKurzman，到目前为止我还没有找到这样的选择。



      以下为原文

    @NKurzman, I'm not finding any such option so far.

现在我意识到，MPLAX在加载符号方面的问题更大。从构建结束到加载符号需要花费大约22秒的时间。



      以下为原文

    I realize now that the problem is more with mplab X at loading symbols.
 
It takes around 22 seconds from build end, to done with Loading symbols.

切换到SkyLaK-X的时间。他们通常称之为Skylake，但随后将其改名为SkyLaK-X以匹配MPLAB X命名约定：



      以下为原文

   


Time to switch to Skylake-X. They used to call it simply Skylake, but then they renamed it to Skylake-X to match MPLAB X naming conventions :)

核心，他们无法处理它船长。她要吹了。



      以下为原文

    The Cores, They can not handle it Captain.  Shes gonna blow.
 

太多的泄漏抽象，船她提示与Java。



      以下为原文

    Too many leaky abstractions, the ship she tips with java.

所以，如果你把它们融合在一起，你会选择Kylab吗？）



      以下为原文

   
So if you melded them, would you have Skylab  ;)
 

Skynet甚至更好！



      以下为原文

    Skynet is even better!