基於 HJ-5G 開發板的研究

為何建立這個倉庫

這是另一個關於學習單片機的記錄，也算是因FT-897 收發機的顯屏問題引伸出來的分支吧。話說2020年10月艱辛地完成硬件組裝，代用顯屏竟然成功了。雖然一知半解，但也曉得它用PIC單片機來實現。單片機五花八門，當時對本人簡直等同劉姥姥入大觀園，每樣都想知多點。已經涉足過STM32，多少有些底氣吧。2021年底向原創者BG4IFX取得原始碼，結果半點頭緒都無。與STM32配置環境大不同，需另行搭建編繹系統。既然它是用上這PIC芯片來實現，該型號給初學者的教學指引不多，唯有還原基本步從零開始，買了一款採用老舊PC16F877A芯片的HJ-5G開發板來研習吧。雖說老舊，古早年代也曾經熱買過，海量資料相當齊備。

跟板附贈的資料，多得沒時間看完，也學會些基礎的。硬件資料齊全，有電路原理圖，也有相關芯片資料。可惜配搭的例程實在夠古，必需使用早已停止支援的舊款IDEMPLAB IDE 8.92，配搭HITECH PICC編繹器。最要命是袛支援Windows。無論如何，手把手地照住去做，真的成功編繹，感覺比STM32容易上手.

要研究下去，還得升級去MicroChip支援16/32bit MCU的下一代IDE。在Windows下安裝了MPLAB X IDE的5.50版本，跟MPLAB IDE有明顯不同，現代化很多了，順住走沒太大問題。由於XC8編繹語法稍有不同，實作過的舊原始碼都需要調整，於是就産生現時這倉庫的版本。之後又有了新的與趣，就停下沒搞了，也沒進一步研究當時取得的代用顯屏原始碼。

MicroChip實在值得讚，它的MPLAB X IDE是由第一個版本就支援Linux。最近整理各樣曾經研究的玩意，也順理成章把它滙到GitHub上保存記錄。也作為練習git操作等等，十分實在。

倉庫的目錄結構

HJ-5G.X/
├── assets/         圖片展示及PDF文件
│   ├── Firmware    可用的固件
│   └── PIC16F877A  用於PICC舊源碼及固件
├── inc/            *.h文件
├── nbproject/      専案資料
├── src/            *.c文件
├── tools/          用PK2CMD進行燒錄
├── Makefile        IDE的自動化文件
└── README.md       本說明文件

使用說明

• 不昰大型専案，就袛是一唯原始碼。
• 在IDE裏設定包含那些相關的 .h/.c，然後編繹燒錄。
• 主程序放到main.c，自由組合就完事。

補充一些事故/遺漏/錯誤

近日拿它實驗試用 pk2cmd 做燒錄，錯當 Arduino Uno 般順手把9V上電到DC插座，差點把板子燒掉。急急翻看資料，板子的使用說明書註明5V供電，結果確定紅外線元件壞了。以前就覺得供電的原理圖不妥，但未有深究。那個DC插座是DC005，按其工作原理，這裏並無使用開關腳功能，那USB亦袛作供電用途，以自鎖開關來切換兩者，說為了避免需斷電時拔供電線，設計思路實在點奇怪。

記憶出錯！事實上舊源碼並未全部調整完成就給閒置了，看那main.c明顯不妥。如今袛能靠留下的固件去做推理，以補齊這庫倉作為記錄的目的。在舊源碼目錄下保留的實驗固件共三個，試運行得出以下推斷。

• ir1838.hex 透過led數碼管顯示讀取IR遙控碼。
• LCD.hex 使用 I2C LCD 顯示。
• test.hex 程式模組集合使用，以 LCD1602 顯示時鐘/温度/解讀IR遙控碼/實驗以IR進入選單及其他可行性。

另外3個固件，是刻意保存的，有參考價值吧，因為功能正常。用 stat 查看建檔資料，作出以下推理。

• Clock_IR.hex 應是由舊源碼main.c較早生成的保存版本。
• IR_check.hex 由上述的舊源碼省去其他功能，袛作IR遙控碼之檢測。
• DHT11.hex 唯一以XC8寫的代碼所生成的固件，且成功運行的。舊源碼未曾搞過 DHT11 濕温檢測元件，所以這點可以肯定。當時應是參考 Arduino 代碼所建立的DHT11.c模組，亦到此為止，之後忙別的了。

尚有一事未解，原來的XC8項目，亦驗証了項目下的固件，跟 DHT11.hex 相同。今次袛是把源碼搬來，重新布置目錄，但以 MPLAB X IDE v6.15 XC8 v3.0 重新生成的固件郤出問題，未能將檢測數據正常顯示，LCD不斷打出亂碼。那時使用 IDE v5.50 XC8 v2.32，會否是造成出錯的原因，暫時未清楚。先記錄在此，找到原因再說了。

找出問題處

意想不到的結果，竟然問題出在 printf()。配合AI大時代，請教它好了。問的是 Microsoft 的基本版 Copilot，回覆結果製成了 printf_problem。解決方法有好幾種，將它們記錄在 DHT11.c 作結，其他源碼保持原樣，不作任何修改了。

舊源碼大量使用 printf()，目的便利顯示輸出，從未想過它是問題所在。這次探究實在長智識，凡事不該理所當然，需保持懷疑求証的態度。利用AI，整理了一份升級至 XC8 v3.00 筆記。

配套這開發板的 HJ-kit2 是PICKIT2的clone，MPLAB X 不支援了。雖然也有PICKIT3的clone，但想以原裝配搭來燒錄，故採用仍在開發，而又支援舊燒錄器的 pk2cmd。另以 DeepSeek 製作一個 Makefile 樣辦 來操作，但未驗証，記錄於此作參考。

再次補充

那個樣辦 Makefile，事實錯漏百出。與DeepSeek再次討論，它終於自首。AI 時代，某程度上省時省力，確實好幫得手。但濫用結果，可能帶出不可逆轉的破壞。以 Copilot 幫手修改，反反覆覆詢問後完成可用的版本，放到 tools/，驗証可用。這些知識在書本上有記載，網路上亦多不勝數，袛是實在太花時間去閱讀消化。問AI好比上一課雞精班，即學即用去應付一些事，但基礎永遠掌握不好。就是太方便了，一切變得理所當然，導致思考的缺乏，令殘留的記憶沒多少剩，慎用AI至為重要。

上述驗証亦包含先前分析過的固件備份，每個都做一次 make BUILD_DIR=../assets/Firmware F=xxx burn 或 make BUILD_DIR=../assets/PIC16F877A F=xxx burn，結果産生另類迷思。除了 DHT11.hex 和 IR_check.hex，其餘未能順利通過 verify。換言之，當時雖然固件是成功生成，也能夠執行，但確實存在問題的，袛是沒有察覺而已。是何原因呢，現在也不深究了，相信是某項設定出錯吧 原因是配置字用了1832，啓用了CP及CPD，令讀取被保謢，所以未能驗証。這個「記念」倉庫，就到此為止。

Makefile 的使用方法：

cd ./tools
make help
make status
make burn