Teorik menzili bu. Pratikte olculen bacaktaki voltaja (yani devrenin iyi tasarlanip dogru kurulmus olmasina) ve ADC’deki gurultuye bagli.
Koddaki kosullar deger = 11’den basliyor; belki potansiyometrenin alt bacagi ile 0V arasinda (parazitik) bir direnc vardir ve 20’nin altina inmiyordur?
Her halukarda boyle bir kodu debug ederken ilk yapilmasi gereken girdi degerine bakmak, OP’ye onu ogretmeye calisiyorum.
Eger mesela deger 500 olmasina ragmen 7 HIGH degilse, analogRead(A0)'i 500 ile ve digitalWrite’lari println ile degistirip soruyu “bu kod neden ‘7, HIGH’ yazmiyor” sekline cevirebiliriz. Elektronik devresi ve haliyle devredeki butun olasi veya gercek hatalardan arinmis, ve herhangi bir C veya C++ bilenin cevaplayabilecegi bir soru haline gelir.
Veya mesela deger 800’un ustune asla cikmiyor ise potansiyometrenin 3.9V’un uzerine cikamiyor olabilecegini anlayip elektronik kismindaki sorunlari gidermeye koyulabiliriz.
Kodda problem cozmenin temel iki adimi kodu/sistemi parcalara bolmek ve varsayimlari gozden gecirmek. deger’in degerini okumak burada ikisini birden yaptigi icin ozellikle kritik.
Evet arduino ide kullansaydı tereddütsüz seri port monitörden değerleri görmek isterdim. Ama Tinkercad üzerinde bunu tarif etmek istemedim.
Sadece buna da bağlı değil, voltaj referansına da bağlı, hatta voltaj referansına gürültüden daha fazla bağlı. Ama burada ADC den endişelenmek yerine potansiyometreden endişelenmeyi tercih ederdim. İhtimal sıralaması yapsam, kaba bir potansiyometre hatası dururken, üzerinde ams1117 gibi bir regülatör ve filtre kondansatörleri varken gürültüye gelene kadar potansiyometre problemleri daha ciddi hatalara neden olabilir.
ADC nin yüksek frekanslı gürültüden etkilenecek kadar hassas olduğundan emin değilim. Referans voltajı da aynı yerden besleniyorsa, comparatör devresi arada fark olmadığında zaten sıfıra getirecektir.
Bu üzerinde durduğunuz önemli bir konu.
Ama buna bile bakmadan kodun hiç bir yerinde 7. pini LOW a çeken bir satır olmaması zaten pini high bırakacağından ve durduk yerde state değiştirmeyeceğinden ilk olağan şüpheli olmalı mıdır?
Yani evet, potans, besleme, gürültü gibi ihtimallere geçmeden yada ADC den ne okuduğumuza bakmadan hemen önce, acaba biz bu pini hiç LOW 'a çekmişmiyiz diye koda göz gezdirmek daha kolay olmaz mıydı?
Yine de evet inputları ve outputları seri bir monitörde gözlemlemek faydalıdır ama söylediğim gibi Arduino ide, yada atmel studio kullanan biri olarak, Tinkercad de bu konuyu tarif etmekle uğraşmak istemem şahsen.
Şahsi kanaatim, range belirlemek için adc değeri okumak bu işin kolay kısmı. Kaldı ki bu pottan gelen bir gerilim değeri. Potun doğru çalışmama ihtimali ve diğer faktörler de olsa istisnai bir durum yok ise ki olabilir, led de patlak çıkabilir yada ortak anot katot bağlama gibi bir devre hatasıyla hepsi sürekli yanık yada sönük de kalabilir ama ilk bakılacak yer acaba ben bir yerde bu led yanık kalırken sönmesi için bir komur vermiş miyim diye bakmak olmalıdır diye düşünüyorum.
Söylediğim gibi, önce söndürmek için bir komut verdimmi diye bakmak bana biraz daha öncelikli gelid. Sonrasında dediğiniz diğer değişkenleri etkileyen faktörleri incelmeye geçebiliriz diye düşündüm.
Tabi ki değer okumak gerekir, ama o değer gelse dahi o işlevi tanımlamamışsak başa döneriz.
Olayın özeti. Arduino GPIO pinleri bir durum verildiğinde durumunu muhafaza eder. LOW verdiysek LOW da kalır HIGH verdiysek HIGH durumunda kalır. Peki dört koşullu ilk kodda herhangi bir koşul veya nedenle 7. PIN hiç LOW’a çekilmiyorsa, ona gelen ADC devresindeki A0 inputundan gelen değerin bir anlamı kalır mı?
Ben bu durumda çoğunlukla size katılmakla beraber, öncesinde bir de mantık hatalarına göz atmanın faydalı olacağını düşünüyorum.
Mantıken hiç bir yerde 7. pini low a çekip ledi söndürecek bir girişim yok iken doğrudan devre elemanlarından şüphelenmek yada gelen datadan şüphelenmek sıralama açısından doğru olmayabilir gibi geldi.
Beş durum var; 0, 1, 2, 3, 4. Buna göre:
1024 / 5 ≈ 204
Her 204 değerde bir led durum değiştirecek.
Alttaki linkte üç farklı örnek yazdım. Uygun
olanını alırsınız.
Gerçek devrelerde analog değerler okunurken
yazılımsal ve/veya donanımsal alçak geçiren
filtre uygulanmalıdır. Bu simülasyon olduğundan
bu durum göz ardı edilmektedir.
Motora göre mi, ledlere göre mi 5 durum var? Zira dört led ve serov motor için de 180 derece açı var. Burada esas olan 1024 bit aralığı 180 dereceye bölüyoruz.
Ledler için de 4 aralık var neden 5 state üzerinde girelim. birinci sınırı aşarsa birinci led, ikinci eşiği aşarsa ikinci led ve üçüncü sınırı aşarsa üçüncü led şeklinde gidecektir. Koda dikkat ederseniz, kendi ledler için eşik değerler vermiş 180 derece yada sıfır için bir durum daha tutmak gibi bir durum göremedim.
Sadece karar aşamasında, ledin birini sönderümeyi unutmuş. Ben o if kullanmadan her loop ta tüm, ledleri zaten low a çeker ve koşullarda 5 koşul yapmaya da bilirdim.
Gerçek devredeki dalgalanmaları gerçekten merak ettim. Bir ara kurup bakacağım, ne tür bir güç kaynağı kullanıyorsunuzda low pass filter gerektirecek kadar analog sinyaliniz yükseliyor merak ettim. Evet regülatör entegrelerinde biraz gürültü vardır, ama dahili beslemesi olan bir kartta ne kadar bir dalgalanma bekliyorsunuz ve gelen analog değer ne kadar dalgalanıyor merak ettim.
Low pass filter ın R kısmı potanstan, C kısmı da dahili olarak bile çıkabilir. Ölçelim bakalım. 1024 bit değerde ne kadar gürütü kaynaklı sapma öngördünüz merak ettim.
Yani potansın beslemesi, arduino üzerinden sonra da input’a giriyor. low pass filter gerektirecek kadar nasıl bir dalgalanma olabilir? yani motor açısına 50 ms de bir değer gönderdiğinde o motorun titremesini beklememiz gerekir, çünkü pwm sinyalide sürekli oynuyor olmalı.
Tabi bir kaç farklı kart ve besleme ile deneyelim bakalım, bu hassasiyetiniz gerektirecek bir durum var mı görmüş oluruz.
Bu arada sorun ne state sayısı ne devre şeması ile alakalı değil. Oratadaki problem kodun hiç bir aşamasında yanık kaldığı 7. Pine bağlı ledin low a çekilmemiş olması. Baştan beri tek sorun bu başka da bir sorunu yoktu soruyu soranın.