參照：

上面已經提到了。BANK的切換是無法避免的,根本談不上浪費指令時間。相信OP就是因爲沒有處理好BANK才會發生問題的。實際的課題是要如何有效的處理和操作BANK的切換，那當然是有牽涉到如何寫代碼（哪一個先哪一個后），RAM運用的策略（放在哪一個BANK才能比較有效的處理中斷）等等...

參照：

那麽遇到沒有通用區的PIC時，該當如何？

參照：

和上面一樣。

還有一點，我有Explorer16演示板。上面提到的第4項也可以配合Explorer16板子試驗的。用的是PICTail Plus接口。但是v1.0-3.8裏還沒有提供16位的支持。所以現在只能等。

能不能說說你用的是什麽板子？上面好像有提到UZ2400的RF子板。那是哪裏買的？能配合PICDEM-Z來做實驗嗎？

我用的多數是微芯提供的：

1）PICDEM-Z演示板（用CC2420的）
2）ZENA Network Analyser DM183023
3）CC2420 RF Daughter Card
4）MRF24J40 RF Daughter Card

我買的時候1和2是分開裝的。現在1和2已經變成了DM163027-4，那是用MRF24J40的。買這個包裝比分開來買比較划算。包裝裏有2套母板+2套MRF子板+ZENA硬件軟件。

3好像斷貨了，微芯似乎也不想賣了。

現在微芯宣傳的是利用MRF的4。這個子板基本上和DM163027-4裏的是一樣的。我做了一些自製的板子，配合3和4來做試驗。

在美國微芯網站有流傳着一則KB：

Why does MPLAB warn me about using internal MCLR and internal RC oscillator mode when I'm using an MPLAB ICD2 programmer?


Resolution: It is important to be very careful when using internal MCLR and internal RC oscillator mode on a device when using the ICD2. Since the ICD2 can not control the MCLR and it can not control the Vdd supply voltage of the part, a device programmed for internal MCLR and internal oscillator mode will often start running before the programming sequence begins. This can cause programming to fail, or in other cases, cause all manner of unusual behavior to be observed.

For example, one customer was using a PIC16F688 with an ICD2 and programmed the configuration bits to set the part to internal MCLR and internal oscillator mode. They also had code configured to write to the EEPROM memory on startup. The result was the EEPROM was written before the ICD2 could verify the EEPROM, and the device would appear to fail verify for what seemed like a mysterious reason. Disabling either or both internal options (setting them for external mode) cleared up the issue.

In other cases, a customer may find that the device can only be programmed with their code one time, and after that, the device will not respond to further programming attempts. Most likely they read an unusual target ID such as 0x0 or 0x3FF from the ICD2 unit. This is because when their code ran, it set the pins used for programming (usually GP0 and GP1 or RA0 and RA1) to outputs, and this conflicted with the programming sequence. The conflict occurs since the part start up faster than the programming sequence from the ICD2. The end result is the part can not be reprogrammed unless a different programmer, such as a PM3 is used. The other programmer is needed, since it can control Vdd directly and prevent the part from starting up before its programmed. As mentioned earlier, the ICD2 does not control Vdd directly, and even if it is programmed to supply Vdd, it does not control the time the Vdd appears to the device.

A good workaround to this is to either not use both internal MCLR and internal RC oscillator mode. However, if that is not a reasonable solution, than another good option is to simply program a small delay into the code that the PIC will run on startup. The delay will prevent the I/O lines from becoming outputs too soon after power-up and that will allow the ICD2 to still be able to reprogram the device. Finally, if that is also not an option for your design, use a production programmer such as a PM3. You can find out more about the PM3 at:
http://www.microchip.com/PM3

參照：

就如OP的帖子里，DECFSZ COUNT0,F 那行就有問題了。就算COUNT是在通用存儲區里，那也是暫時逃過劫數而已。再看下去，PORTC那行就有50-50的機會發生災難。再看PIR1, 災難指數已經提升到了75%了...

再說一遍：怎么會麻煩？是遲和早的問題而已。

參照：

怎么會麻煩？BANK的切換基本上是避免不了的！

參照：

Function哪有寫在頭文件里的？

這是我以前做過的，僅供參考。你還需要依照你的FOSC改一改。

參照：

第一，調試期間，從來不曾開啟過Code Protection，但問題還是發生了。所以無法接受上面的解析。

第二，即使開啟了Code Protection，所有的PM讀取時都是“0"，除了地址0x03FF。有關的細節可以參閱：

http://ww1.microchip.com/downloads/en/DeviceDoc/41191D.pdf


參照：

既然是不同的設計，那當然沒有類似OP提到的問題。

參照：

Microchip有聲明在先：ICD2只供開發用途，不是生產級編程器！

參照：

用ICD2調試時，切記要先把OSCCAL的廠方校正值先讀出來，然后紀錄下來。我用過的經驗告訴我：雖然Microchip說他們的工具都會保留校正值，但是很多時候ICD2把這個校正值弄丟了！