Geliştirme takımını Zephyr’e geçirmek bence 2 ana açıdan çok mantıklı.
Bu yazı ikisini de arkalarındaki kanıtlarla birlikte ele alıyor; sonra geçişle birlikte başka nelerin geldiğine ve son olarak planlamanız gereken maliyetlere bakıyor, çünkü maliyetleri de var.
1. Zephyr hızla yaygınlaşıyor#
Zephyr şu an bir Linux Foundation projesi. Nordic, ST, Intel, NXP gibi büyük mikroişlemci ve entegre devre üreticileri Zephyr’e destek vermek için kendi bünyelerinde takımlar kurmuş durumda. Uzun vadede sektörden geri kalmamak istiyorsan bu trendi görmezden gelmek zor.
Proje 2016’da Linux Foundation çatısı altında başladı ve üye listesi her yaygınlık grafiğinden daha çok şey söylüyor. Ekim 2026 itibarıyla platinum üyeler arasında Analog Devices, Antmicro, CARIAD, Google, Infineon, Intel, Meta, Nordic Semiconductor, NXP, Qualcomm, Renesas, Silicon Labs, Texas Instruments, Wind River ve ZEISS var. Texas Instruments ve Infineon bu seviyeye tam da o ay çıktı.
Listenin uzunluğundan çok karışımı önemli. Bu yalnızca parçalarının desteklendiğinden emin olmak isteyen çip üreticileri değil. CARIAD, Volkswagen Grubu’nun yazılım şirketi; Google ise yeni Chromebook tasarımlarının embedded controller firmware’ini 2021 civarından beri Zephyr üzerine kuruyor: güç sıralamasını, batarya şarjını, klavyeyi ve USB Power Delivery’yi yöneten çip. Bunlar Zephyr üzerinde ürün çıkaran şirketler.
Üreticilerin kendi SDK’ları da aynı yönü gösteriyor. Nordic yeni geliştirmesini Zephyr tabanlı nRF Connect SDK’ya taşıdı ve eski nRF5 SDK’yı 2021’de bakım moduna aldı. Radyonuzun üreticisi SDK’sını bir RTOS üzerine kuruyorsa, en yeni özellikler de önce o RTOS’a geliyor.
Planlama açısından release süreci de en az bu ivme kadar önemli. 2026’dan itibaren Zephyr altı ayda bir release çıkarıyor. Birkaç yılda bir, bir release Long Term Support olarak belirleniyor ve en az beş yıl bakımı yapılıyor: mevcut LTS olan 3.7 Temmuz 2029’a kadar destekleniyor, bir sonraki LTS olan 4.6 ise Nisan 2027 için planlanmış. Bir ürün takımı bir LTS’ye sabitlenip ne kadar süre düzeltme alacağını bilebiliyor.
2. Donanım bağımlılığı artık stratejik bir risk#
Son yıllarda yaşadık: ani fiyat artışları, ürün bulunamaz hale gelmesi, tedarik zincirleri alt üst oldu. Zephyr’in getirdiği donanım soyutlama ve uygulama katmanı ayrımı bu riski ciddi ölçüde azaltıyor. Bir mikroişlemciden diğerine geçmek, uygulamayı baştan yazmak anlamına gelmiyor.
Zephyr’de bir kartın aslında ne olduğunu görmek faydalı. ST’nin Nucleo F401RE kartının bütün portu dokuz dosya ve 386 satır:
| Dosya | Satır | İçinde ne var |
|---|---|---|
nucleo_f401re.dts |
206 | Devicetree: clock’lar, pinler, LED’ler, butonlar, UART, I2C, SPI |
st_morpho_connector.dtsi, arduino_r3_connector.dtsi |
108 | Konnektör pinout’ları; shield’lar da tarif edilebilsin diye |
nucleo_f401re.yaml |
22 | Test koşucusu için metadata |
nucleo_f401re_defconfig |
16 | Varsayılan Kconfig değerleri |
Kconfig.nucleo_f401re, Kconfig.defconfig |
18 | Kartın hangi SoC’u kullandığı ve karta özel varsayılanlar |
board.cmake |
10 | Nasıl flash’lanıp debug edileceği |
board.yml |
6 | Kartın adı, üreticisi ve SoC’u |
Bu dosyaların hiçbiri C değil. Bir kart portu kod değil, bir tarif; sizin kendi PCB’niz de aynı şekilde ele alınıyor. Üstelik Zephyr’in bir fork’unda değil, uygulamanızın yanında, kendi reponuzda durabiliyor.
Bir parça değişikliğinde uygulamanın ayakta kalmasının sebebi bu. Aynı
main.c, kodun adını hiç anmadığı ve devicetree’nin seçtiği tamamen farklı üç
GPIO driver’ı üzerinden bir LED’i sürebiliyor;
Zephyr’i neden kullandığımı anlattığım yazı
tam olarak bunu adım adım gösteriyor.
Yine de sınırı net koymak gerekiyor. Aynı aile içinde, örneğin bir STM32F4’ten diğerine geçmek büyük ölçüde bir devicetree değişikliği. Başka bir üreticinin çipine geçmek ise kullandığınız her çevre biriminin driver’ının yeni SoC için mevcut olması demek. Bunu ihtiyaç duymadan önce kontrol edin, bir kıtlığın ortasında değil.
Bunlara ek olarak#
Bir sürü şeyin hazır gelmesi geliştirme süresini kısaltıyor. MCUboot, kripto kütüphaneleri, network stack, BLE stack: bunları sıfırdan yazmak ya da entegre etmek yerine üzerine inşa ediyorsun. Liste devam ediyor: USB cihaz desteği, dosya sistemleri, kalıcı ayar saklama, logging, etkileşimli bir shell ve bir test altyapısı. Bunların her biri, takımınızın sahiplenmek zorunda olmadığı bir bileşen.
Zephyr takımı modüler kod yazmaya zorluyor. Bu başta ağır gelebilir ama uzun vadede bakımı kolay, test edilebilir bir kod tabanı ortaya çıkıyor.
Aktif topluluk ve düzenli release’ler sayesinde uzun vadeli destek konusunda da rahat ediyorsun.
Güvenlik ve Cyber Resilience Act#
AB’de bağlantılı ürün satan herkes için artık üçüncü bir sebep var ve tarihleri belli. Cyber Resilience Act Aralık 2024’te yürürlüğe girdi. Açık ve olay bildirim yükümlülükleri 11 Eylül 2026’dan beri geçerli; düzenlemenin tamamı ise 11 Aralık 2027’den itibaren uygulanıyor. Üreticilerin, diğer yükümlülüklerin yanında, en az beş yıllık bir destek süresi boyunca açıkları ele alması ve açık kaynak dahil, ürüne koydukları üçüncü taraf bileşenler konusunda özen yükümlülüğünü yerine getirmesi gerekiyor.
Bir RTOS bir ürünü uyumlu hale getiremez. Yapabileceği şey işi küçültmek ve Zephyr parçaların birçoğunu beraberinde getiriyor:
- Bir güvenlik müdahale süreci. Zephyr’in yayımlanmış hedefleri olan kendi PSIRT’ü var: bildirene 7 gün içinde geri dönüş, 30 gün içinde düzeltme ve üreticilere bildirim, en fazla 90 günlük ambargodan sonra kamuya açıklama. Ürün üreticileri, ambargolu açıkları kamuya açılmadan önce öğrenmek için projenin açık kaydına başvurabiliyor.
- Her release’te düzeltilen CVE’lerin listesi; böylece bir güncellemenin sizi ilgilendirip ilgilendirmediğini anlayabiliyorsunuz.
- En az beş yıl bakımı yapılan Long Term Support release’leri; bu da düzenlemenin beklediği destek süresiyle örtüşüyor.
- Yerleşik SBOM üretimi.
west spdx, gerçek build’iniz için SPDX formatında bir yazılım malzeme listesi yazıyor.
Zephyr dokümantasyonunun CRA için ayrı bir sayfası var; hem üreticiler için ne anlama geldiğini hem de projenin bir “open-source software steward” olarak kendi yükümlülüklerini anlatıyor. İyi bir başlangıç noktası ve, sayfanın kendisinin de söylediği gibi, hukuki tavsiye değil.
Maliyeti#
Bir takımı geçirmek bir yatırım ve maliyetleri sonradan keşfetmektense baştan planlamak daha iyi.
Öğrenme eğrisi. Bare-metal’den ya da FreeRTOS’tan gelen mühendisler Device Tree, Kconfig, driver modeli ve build sistemiyle aynı anda karşılaşıyor. Bunu haftalarla değil aylarla hesaplayın. Serinin ilk yazısı tam olarak o duvarla ilgili.
Upstream sürekli hareket ediyor. API’lar release’ler arasında değişiyor. Her release bir migration guide ile geliyor ve bunlar iyi, ama yükseltmek yine de iş. Sürümü sabitleyin ve birisi update çalıştırdığında değil, bilinçli olarak yükseltin.
Üretici SDK’ları upstream’in gerisinde kalıyor. Bir üreticinin Zephyr tabanlı SDK’sı üzerine kurarsanız onların ek özelliklerini ve desteğini alıyorsunuz, ama upstream’in bir sürüm gerisinde çalışıyorsunuz. Hangisini takip edeceğinize erken karar verin.
Build’in bir sahibi olmalı. West, CMake, Kconfig ve CI artık ürünün bir parçası. Takımda en az bir kişinin orada rahat olması gerekiyor.
Nasıl başlanır#
- Kritik yolda olmayan bir şey üzerinde pilot yapın, hedef donanımınıza yakın ve iyi desteklenen bir kart üzerinde.
- Zephyr sürümünü ilk günden bir west manifest’inde sabitleyin ve sahaya çıkıp bakımı yapılacak her şey için bir LTS seçin.
- İlk kart gelmeden CI’ı kurun. native_sim ve Twister ile testler hiç donanım olmadan her commit’te çalışıyor.
- Kartlarınızı ve uygulamanızı Zephyr’in bir fork’unda değil, kendi reponuzda, ağaç dışında tutun. Yükseltmeler bir merge değil, bir sürüm değişikliği olarak kalır.
- Takımı teslim tarihinden önce eğitin, teslim tarihi sırasında değil.
Bu sırayla yapıldığında maliyetler en ucuz oldukları başlangıçta oluşuyor, faydalar ise ürün yaşadığı sürece gelmeye devam ediyor.