IPE command line interface有加速版本，我用PICkit 3測試過燒PIC18F26K20，從18秒減少到12秒，大概少1/3 的時間。

因為用PICKit 4燒Hex因為<1秒，速度加快的改變看不出來。我就沒測了。

但是command line interface開啟IPE的時間是少不了的的。

加速版本的command line interface如果您想知道的話，我下週一再回覆您。

原本我是使用PICKit 3做測試, 為了要跟您一樣, 我這次換了PICKit 4.

兩者的差異在於, PICKit 3是使用HID class, 速度64K/sec. PICKit 4是使用WinUSB driver, 速度可以到1.2MByte/sec.

下面是我測試燒錄PIC18F26K20 (64KByte)的數據.

1. IPE : 1秒
2. IPE Command line 呼叫 IPE : 扣除開啟IPE的時間後, 也是1秒

我們兩個的IPE command line時間差很多(你的10秒, 我的一樣是1秒)~ 兩個應該一樣, 不應該差這麼多, 這不make sense.

請問您的MPLAB X IPE版本? 還有您是怎麼算IPE command line所需要的時間? 我是從附圖紅色框Device Erasing的時間開始計算~

Attach file:

---

  Programming Time by IPE command line.jpg (74.47 KB)

因為我手上沒有PIC16F18345(28KByte), 所以我使用PIC18F26K20(64Kbyte)來做測試.

下面是我的測試結果(PICKit 3)

1. IPE 燒錄時間: 扣掉開啟IPE的時間, 大約18秒
2. IPE Command line: 扣掉開啟IPE的時間, 大約14秒.

雖然每次使用IPE command line都會啟動MPLAB X IPE, 但是以Erase/Program/Verify的時間, command line還是快一點.

以下是美國論壇的相關討論

https://www.microchip.com/forums/m948727.aspx

之前您有提到過MPLAB X IDE/IPE是否有相關的Dll可以透過您們自己的寫程式呼叫調用來做燒錄. 是有的, 叫做mdbCOR.

您可以參考一下下面MPLAB X SDK網站來下載.

http://www.opensource4pic.org/content ... t/mplab-x-sdk-mplab-x-ide

這部分我沒有測試過, 您可以參考一下~

Attach file:

---

  PIC18F26K20_Flash_64KB_Prgramming_Time_18sec_IPE.jpg (82.53 KB)

請問您使用的MCU是哪一顆? 跟flash的大小有關係.

請問您用command line燒錄hex的時間要多久?

或者是先把IPE開啟, 之後用command line燒也縮短開啟時間.

您可以參考一下 MPLAB X IDE 5.40安裝路徑下的CommandLineReadmes.htm檔案 -> Release Notes for IPE Command Line Interface.

小弟之前使用的範例如下: (燒錄器PICKit 4 , MCU: PIC18F26K20)

java -jar ipecmd.jar -P18F26K20 -TPPK4 -F"c:/PIC18F26K20_APP_Demo.hex" -M

Attach file:

---

  IPE_Command_Line_Interface_PIC18F26K20.jpg (82.88 KB)

const int status __at(0x2F);

1. MCC Generate出來的I2C slave default是使用中斷.
2. PIC16F系列只有一個中斷向量, 只能給Bootloader或是Application其中一個使用
3. 問題3, 在MCC generate的Bootloader code就有了~ 看一下附圖. 我剛剛測試是可以的~ 您試一下!

Attach file:

---

  (0.00 KB)

如果您只單純將Application做code offset到0x600, 也不和Bootloader Project combine在一起的話, 那就要在您的Application自行remap Reset Vector到0x600.

請問您是怎麼Remap中斷的?

MCC所產生的UART Bootloader並沒有使用Interrupt mode, 而是使用polling的方式, MCC已經將Reset Vector與Interrupt Vector幫您Remap到Application的起始位址(0x700)了.

所以您在Bootloader FW無法使用中斷. 因為開中斷的風險是當Flash在做Erase或是Write時, 萬一中斷發生了, 會導致Flash操作異常. 所以UART Bootloader才使用polling mode, 再者也不佔用Application會使用到PIC16的唯一中斷向量.

除非您的Application code沒有使用到中斷, 就可以再Bootloader使用中斷.(但記得把那段Remapped Reset Vector & Interrupt Vector的code註解掉)

檢查一下GIE 與 PIE是否有Enable.