Aşama 3: Elektronik ve Mekanik Tasarım

15 Ağustos 2025

V’nin “Sol Kanadı”)

Artık işin ellerimizi kirleteceğimiz eğlenceli kısmına geliyoruz: gerçek donanımı tasarlamak! Aşama 3 tamamen elektronik ve mekanik tasarımla ilgili — ki bu ikisi genellikle el ele gider. Mühendislikteki V-modelini duyduysanız (klasik bir geliştirme süreci modeli), “V”nin sol tarafı tamamen tasarım ve uygulamayla ilgilidir — ve şu an tam olarak oradayız. Başka bir deyişle, daha sonra V’nin sağ tarafında doğrulanacak ve geçerlenecek donanımı tasarlamaya odaklanıyoruz. (V-modeline aşina değilseniz dert etmeyin; asıl fikir şu: donanım tasarımı, özenle yaklaşmanız gereken sıralı bir süreçtir. Bir devre kartını bastırdıktan ya da plastik bir kasayı kalıpladıktan sonra değişiklik yapmak zordur — anlayın: pahalıdır 😬).

Aşama 3 birkaç alt adıma bölünebilir. Önemli bir nokta: burası aynı zamanda donanım ve yazılım geliştirmenin paralel çalışmaya başladığı aşamadır (yazılım tarafı için detaylar bir sonraki aşamada). Donanım hattında işler genellikle şöyle ilerler:

Şematik Çizimi: Elektronik Plan

Her elektronik ürün bir çizim olarak başlar — sanatsal olanından değil, şematik olanından. Şematik çizimi, elektrik devre tasarımının özel CAD araçları (Altium, Eagle ya da KiCad gibi) kullanılarak detaylıca çizildiği adımdır. Şematiği devrenizin planı olarak düşünün: her bileşeni (mikrodenetleyici, sensörler, kondansatörler, konnektörler ve daha fazlası) ve hepsinin net’ler (kablolar) aracılığıyla elektriksel olarak nasıl bağlandığını gösterir. Her bileşenin bir bina, net’lerin de onları bağlayan yollar olduğu bir elektronik şehri haritalamak gibidir.

Bu adım kritik, çünkü hataları bir çizim üzerinde düzeltmek fiziksel bir kart üzerinde düzeltmekten çok daha kolay (ve ucuz). Şematik taslağı hazır olduğunda, titiz bir gözden geçirme şart. Genellikle mühendis şematiği PDF’e aktarır ve akran incelemesi için dolaştırır. Taze gözler sizin kaçırdığınız bir şeyi yakalayabilir — örneğin “Eyvah, sıcaklık sensörünün güç pini bağlı değil!” ya da “LED akım sınırlayıcısı için şu direnç değeri tuhaf duruyor.” Bu sorunları şimdi yakalamak, ileride büyük baş ağrılarından kurtarır.

Bu aşamada bazı ekipler, güç kaynağı ya da güvenlik devreleri gibi tasarımın kritik kısımlarında bir FMEA (Hata Türleri ve Etkileri Analizi) de yapar. FMEA aslında “Bu devrenin arızalanabileceği tüm yolları hayal edelim ve ne olacağına bakalım” demenin havalı bir yolu. Örneğin, sıcaklık sensörü kısa devre olarak arızalanırsa (yani iki ucu içeriden yanlışlıkla birbirine bağlanırsa) ne olur? Bu yalnızca sensörün uç bir değer okumasına mı yol açar, yoksa fazla akım çekerek tüm karta zarar verebilir mi? Bu korkutucu “ya olursa” sorularını erken sorarak koruma ekleyebilir ya da riskin kabul edilebilir olup olmadığına karar verebilirsiniz. Bu tür ileri görüşlülük, cihazı uzun vadede daha güvenilir kılar.

Bu arada — işte paralel çalışma burada devreye giriyor — yazılım/firmware ekibinin donanımın bitmesini boş boş beklemesi gerekmiyor. Şematiğe dayanarak firmware mühendisleri bir HAL (Hardware Abstraction Layer) ya da en azından iskeletini oluşturmaya başlayabilir. Esasen, mikrodenetleyicinin çevre birimleri için yazılım arayüzlerini kurarlar (timer’lar, o sensörler için I2C ya da SPI gibi haberleşme arayüzleri vb.). Bu sürücüler için PC üzerinde unit test’ler ya da simülasyon kodu bile yazabilirler. Bir geliştiricinin, sadece mantığı test etmek için sahte sensör okumaları üreten kod yazdığını hayal edin — bu sayede firmware ekibi temeli şimdiden atıyor. Böylece gerçek devre kartı geldiğinde, kod yapısının büyük kısmı hazır olur ve gerçek donanımda denenmeyi bekler. Bu paralel çaba, yazılımcıların boş oturmadığı anlamına gelir; ileride donanımı ayağa kaldırmayı kolaylaştıracak zemini hazırlıyorlar.

PCB Layout: Şematikten Fiziksel Karta

Şematik tasarım tamamlanıp gözden geçirildikten sonra, sıra o elektronik planı gerçek hayattaki bir devre kartına dönüştürmeye gelir. Bu, PCB layout aşamasıdır. Başka bir CAD araç setiyle (çoğunlukla şematik için kullanılan Altium ya da KiCad gibi aynı paketin layout moduna geçilerek), mühendis her bileşenin footprint’ini sanal bir kart üzerine yerleştirir ve her şeyi birbirine bağlayan bakır izleri çekmeye başlar. Şematik plansa, PCB layout o bileşen şehrinin fiziksel olarak tam olarak nasıl görüneceğine karar verdiğiniz adımdır — her binanın nereye oturacağına ve yolların (kabloların) kartın gerçek arazisinde aralarından nasıl geçeceğine karar vermek gibi.

PCB layout’un çıktısı, üreticilerin kartı imal etmek için kullandığı bir dosya seti (meşhur adıyla Gerber dosyaları). Bir diğer faydalı çıktı da kartın 3D modelidir (genellikle bir STEP dosyası). Bu 3D model, mekanik tasarım tarafı için süper kullanışlıdır — kasa tasarımınıza aktarıp kartın ve üzerindeki tüm bileşenlerin, ürünün muhafazasına çarpışma olmadan sığdığını kontrol edebilirsiniz (kimse kasada deliği olmayan bir yerden dışarı fırlayan bir USB konnektörü istemez!).

PCB layout sırasında Design for Manufacturing (DFM) ve Design for Test (DFT) ilkelerini akılda tutmak kritiktir. Basitçe söylersek DFM, kartın güvenilir ve maliyet etkin bir şekilde üretilebilmesi için tasarlanması; DFT ise ileride kolayca test edilebilmesi için tasarlanması demektir.

Örneğin:

DFM: Bileşenleri kartın kenarına çok yakın ya da dizgi makinelerinin lehimlemekte zorlanacağı kadar sıkışık yerleştirmekten kaçının. Layout’un sorunsuz üretilebildiğinden emin olun.
DFT: Üretimde karta test ekipmanı ya da programlayıcı bağlayabilmek için test pad’leri ya da özel bir konnektör ekleyin. Bu sayede hattan çıkan her ünite kolayca kontrol edilebilir (her cihazda firmware programlamak ya da sinyal ölçmek için kullanışlı bir soket hayal edin).

Bu önlemleri şimdi eklemek, elinizde tam çalışıp çalışmadığını doğrulamanın kolay bir yolu olmayan bin adet bitmiş ünite olduğunu sonradan fark etmekten çok daha kolaydır!

Birçok ekip, layout sırasında hiçbir şeyin unutulmadığından emin olmak için bir kontrol listesi kullanır — fiducial’lar eklemek (otomatik dizgi makinelerinin kartı nasıl hizalayacağını bilmesine yardımcı olan küçük işaretler), yüksek gerilimli kısımlar arasında uygun mesafeleri korumak, önemli konnektörleri etiketlemek gibi şeyler.

Donanım ekibi iz çekmek ve kartın detaylarıyla boğuşmakla meşgulken, paralel yazılım çalışması devam eder. Şematikten sensör modellerini ve bileşenleri tam olarak bilen firmware ekibi, o bileşenlerin datasheet’lerine dayanarak gerçek sürücü kodunu (ya da en azından yer tutucularını) yazmaya başlayabilir. Sensör emülatörleri kullanabilir ya da sensörün ne yapacağını taklit eden sahte kod yazabilirler. IoT ürününüzde varsa cloud/backend ekibi de öne geçebilir: örneğin cihazdan veri almak için temel bir cloud veritabanı ve API endpoint’leri kurmak. Esasen herkes yapbozun kendi parçasını hazırlıyor ki ilk fiziksel kartlar geldiğinde ekibin geri kalanı için soğuk bir başlangıç olmasın. PCB tasarımı üretime gönderildiğinde, firmware’inizde kart için hazır bir “hello world” olabilir ve cloud’unuzda cihazın ilk veri noktasını kaydetmeyi bekleyen küçük bir test sunucusu bulunabilir. Bu eşzamanlı geliştirme, ileriki iterasyon döngüsünü ciddi biçimde kısaltır.

Prototip Üretimi: Donanıma Hayat Vermek

PCB layout bitip kontrol edildikten sonra, artık dijital dosyalardan fiziksel nesnelere geçme zamanı. İlk adım kartları ürettirmek. Genellikle o Gerber dosyalarını bir PCB üreticisine gönderirsiniz (kartları günler içinde üretebilen birçok hızlı PCB üreticisi var). Paralelde, karta takılacak tüm bileşenlerin (mikrodenetleyici, sensörler, çipler vb.) elinizin altında olduğundan emin olmak isteyeceksiniz. İpucu: Kritik ya da uzun tedarik süreli parçaları, şematiğinize ve bileşen seçiminize güvendiğiniz anda sipariş edin! Küresel çip kıtlıkları döneminde birçok ekip bunu acı yoldan öğrendi — kartlarınız boş boş beklerken belirli bir sensör ya da radyo çipi için 12 hafta beklemek istemezsiniz.

Boş PCB’ler ve tüm parçalar elinize ulaştığında, birkaç prototip ünite monte edersiniz. Bu, iyi donanımlı bir laboratuvarınız ve lehimde titremeyen bir eliniz varsa şirket içinde yapılabilir; ya da o minicik bileşenlerin hepsini lehimletmek için bir dizgi servisi kullanabilirsiniz. Sonuç, bir set (genellikle 1 ila 5 kart gibi küçük bir avuç) prototip cihazdır.

Şimdi donanım geliştirmenin en heyecanlı (ve gergin) anlarından biri geliyor: bring-up — kartı ilk kez çalıştırıp çalışıp çalışmadığına bakmanın havalı adı. Bunu dikkatli yapmak yaygındır — örneğin bir yerde kısa devre varsa bir şeyleri yakmamak için akım limitli bir masaüstü güç kaynağı kullanmak. Anahtarı çevirirken laboratuvardaki herkes nefesini tutabilir. Kart, yanmış bileşenlerin o efsanevi mavi dumanını salmadan açılıyor mu? (Umarız evet!)

Güç verdikten sonra temelleri metodik olarak doğrularsınız. Tüm güç hatları beklenen gerilimlerde mi? (Multimetre ya da osiloskopla kontrol edin.) Mikrodenetleyici (MCU) uyanıp kod çalıştırıyor mu? Klasik bir ilk test, bir LED yakıp söndüren ya da seri porttan “Hello, world” mesajı gönderen basit bir firmware’in çalışıp çalışmadığını kontrol etmektir. O LED’in yandığını görürseniz ya da o mesaj bilgisayarınıza düşerse, bu büyük bir zaferdir — kartınızın kalbinin atıp durduğu anlamına gelir.

Sırada kilit çevre birimleriyle haberleşmeyi test etmek var: MCU, planlandığı gibi I2C ya da SPI üzerinden sensörle konuşabiliyor mu? Sensörler makul veriler döndürüyor mu? Sorunları keşfedebileceğiniz aşama burası. Belki bir sensör, bir bağlantı hatası ya da ince bir firmware bug’ı yüzünden okumuyor. Bring-up bir dedektiflik oyunudur; donanım ve firmware mühendisleri sorunları çözmek için birlikte çalışır. Örneğin sıcaklık okuması hep sıfırsa, firmware mühendisi kodu debug ederken donanım mühendisi bağlantıları multimetreyle yoklar — birlikte bunun bir yazılım başlatma sorunu mu, yoksa sensörün SDA ve SCL hatlarının PCB’de yer değiştirmiş olması mı olduğunu çözerler.

Prototip bring-up’ı sırasında olası güç ya da ısıl sorunlara da göz kulak olursunuz. Olması gerekenden daha sıcak çalışan bir şey var mı? (İpucu: çiplere dikkatlice dokunarak ısıyı hissetmek ya da bir kızılötesi kamera kullanmak sıcak noktaları yakalayabilir.) Kart beklenenden fazla akım mı çekiyor (bu, bir şeyin yanlış bağlandığına ya da bir bileşenin arızalı olduğuna işaret edebilir)? Bu testler, prototipinizin yalnızca çalıştığından değil, aynı zamanda güvenli olduğundan ve beklenen parametreler içinde performans gösterdiğinden emin olmanızı sağlar.

Cihazınız kablosuz haberleşecekse ya da belirli düzenleyici standartları karşılaması gerekiyorsa (ABD’deki kablosuz cihazlar için FCC emisyonları gibi), bu prototip aşaması biraz ön uyumluluk testi yapmak için iyi bir zamandır. Bu, büyük sorunları erken yakalamak için cihazı bir laboratuvara götürüp radyo frekansı emisyonları için ön tarama yaptırmak anlamına gelebilir. Kartınızın onaysız bir frekansta kazara radyo vericisi gibi davrandığını nihai sertifikasyon testinde öğrenmek istemezsiniz!

Donanım ekibi bring-up ile meşgulken, firmware ekibi artık kodlarını gerçek cihaz üzerinde tüm hızıyla test etmektedir. Daha önce başladıkları tüm o sürücüler ve HAL bileşenleri gerçek karta yüklenebilir. Firmware’in biraz ayara ihtiyaç duyabileceği yer burasıdır — belki zamanlama varsayımları biraz yanlıştı, ya da gerçek silikon üzerinde bir interrupt’ın ayarlanması gerekiyor. Mikrodenetleyicide bir RTOS (Real-Time Operating System) kullanıyorsanız, görev önceliklerini ya da zamanlamayı ayarlamaya başlayacağınız an budur; çünkü gerçek donanımda gerçek performansı gözlemleyebilirsiniz. Cloud ekibi de sistemden gelen ilk gerçek verileri görebilir! Örneğin prototip, bir test sunucusuna gerçekten bir sıcaklık okuması gönderebilir ve tüm uçtan uca akışın (cihaz -> cloud -> veritabanı) en azından küçük ölçekte çalıştığını doğrulayabilir.

Aşama 3 genellikle birkaç iterasyon içerir. Her şeyi ilk denemede mükemmel yapmak nadirdir — ve bu son derece normaldir. Kartta prototipler üzerinde küçük bir cerrahi müdahale gerektiren bir hata bulabilirsiniz (yanlış çekilmiş bir iz ya da bir bileşen footprint hatası gibi — merhaba jumper teller ve yamalı düzeltmeler!), ya da hata bir sonraki prototip turu için revize bir PCB bastırmayı gerektirecek kadar ciddi olabilir. Her iterasyon bir iyileştirme fırsatıdır: belki ulaşması zor bir konnektörün yerini değiştirirsiniz, belki bir sensör okumasındaki gürültüyü azaltmak için devrede ince ayar yaparsınız vb. İterasyon gerektiği için cesaretiniz kırılmasın; donanım geliştirmede bu beklenen bir şeydir.

Bu aşama boyunca donanım ve yazılım ekipleri arasında yakın iş birliği hayati önem taşır. Bir sorun çıktığında, iki taraf da dedektif şapkasını takıp birlikte çalışmak zorundadır. Sensör okumuyorsa bu firmware’in hatası mı, yoksa PCB’de bir şeyi kısa devre yapan bir lehim köprüsü mü var? Bulguları ve hipotezleri paylaşarak ekip, soruna daha hızlı odaklanabilir. Bu ortak sorun giderme, sürecin en öğretici kısımlarından biridir — ve genellikle ekibin ürünü bir bütün olarak kavrayışını güçlendirir.

Ayrıca bir gözünüz gelecekte olsun: bu ürünü nihayetinde ölçekli üretmeyi planlıyorsanız, bu prototip evresini uzun vadeli üretim ve test konularını düşünmek için kullanın. DFM ve DFT’yi hatırlıyor musunuz? O kararları doğrulamanın zamanı geldi. Örneğin bir programlama header’ı eklediyseniz, simüle edilmiş bir üretim testinde kullanmayı deneyin: karta kolayca bağlanıp programlayabiliyor musunuz? Test pad’leri eklediyseniz, bir bed-of-nails test cihazının bunlara erişimi var mı? Tasarımınızı test edilebilirlik için şimdi ayarlamak, çalışan bir üretim hattınız varken ayarlamaktan çok daha kolaydır.

Aşama 3’ün sonunda elinizde bir ya da daha fazla çalışan prototip cihaz ve bir yığın öğrenilmiş ders olmalı. Performans hakkında ilk verilere sahip olacaksınız (cihazınız gerçekte ne kadar güç çekiyor? Sensör gerçek dünya koşullarında doğru performans gösteriyor mu gibi). Muhtemelen bir sonraki sürüm için düzeltme ya da iyileştirme listeniz de olacak. En önemlisi, IoT ürününüzün fiziksel temelini inşa ettiniz — elinizde tutabildiğiniz ve gerçekten çalışan bir şey. 🎉

Ve bakın, o ilk prototip nihayet hayata gelip beklendiği gibi veri gönderdiğinde, laboratuvarda “Yaşıyor!” diye bağıran Dr. Frankenstein gibi hissetmenizde hiçbir sakınca yok. Bring-up başarısında hepimiz küçük bir mutluluk dansı yaparız. Yalnız laboratuvar komşularınız ya da etrafta stajyerler varsa belki gerçekten çok yüksek sesle bağırmayın — kimseye kalp krizi geçirtmek istemezsiniz! Ama kutlamak için mutlaka bir an ayırın — donanım zordur ve fikirden gerçeğe uzanan yolculuğunuzda devasa bir kilometre taşını az önce geride bıraktınız.