Geçen ay Kadıköy’de bir kahve dükkânında, cebimdeki Raspberry Pi 4B ile uğraşırken aklıma şu takıldı: Neden küçük bir OLED ekranda saat, sistem bilgisi ya da basit bir uyarı göstermek için her seferinde aynı kablo karmaşasını ve aynı Python iskeletini baştan yazıyoruz? İşin aslı şu — çoğu mini ekran projesi ilk bakışta “hızlı kurulur” gibi görünür, ama birkaç denemeden sonra insanın canını sıkan, iyice alışkın olduğun bir kopyala-yapıştır rutinine dönüşüyor.
Andre Faria’nın ortaya koyduğu rpi-display-core tam da bu dertten doğmuş (ki bu çoğu kişinin gözünden kaçıyor). Açık konuşayım, böyle — en azından ben öyle düşünüyorum — projeleri seviyorum; çünkü küçük ama gerçek bir sorunu hedefliyorlar. Büyük laf etmiyor, sadece “aynı kodu yeniden yazma” diyor. Ve bazen en işe yarar araçlar zaten böyle çıkıyor ortaya — sessiz sedasız, gösterişsiz.
Nerede Can Sıkıyor? Eski OLED Kodlarının Derdi
Küçük ekran projelerinde hep aynı sahneyi görürsünüz. Önce I2C açılır, sonra SSD1306 nesnesi kurulur, ardından PIL ile görüntü oluşturulur… sonra çizim yapılır ve en sonunda tüm yapı kapatılır. Bir saatlik örnek için? Sorun yok. Ama ikinci ekrana geçince işler değişiyor.
Bunu biraz açayım.
Bu kez tarih göstermek istiyorsunuz. Sonra ağ durumu geliyor aklınıza. Ardından küçük bir animasyon… ve hop, yine aynı iskelet dökülüyor önünüze, sanki hiç ilerlememiş gibi. Buna ben geçen sene Şişli’de çalıştığım mini IoT demo masasında birebir takıldım; tek amaçlı bir sıcaklık ekranı yapmıştık, güzel çalıştı, ama ürün sahibinin “buna Wi‑Fi ikonu da koyalım” demesiyle neredeyse kodun yarısını söküp yeniden kurduk. Hani yazılımda sık duyulan o cümle var ya, “biraz daha ekleyelim” — işte bazen o “biraz daha” kelimesi, iki günlük teknik borca dönüşüyor — itiraf edeyim, beklentimin üstündeydi —. Neyse, tam da öyle.
Problem sadece tekrar değil aslında. Bakım maliyeti de yüksek oluyor; her örnekte başka yerde kurulan benzer şeyler test etmeyi zorlaştırıyor, hata ayıklamayı uzatıyor. Yeni widget eklemeyi gereksiz yere sancılı hale getiriyor. Küçük proje diye başlanıyor, kısa sürede minik bir çorba tenceresine dönüyor.
Aynı Kodun Beş Kez Yazılması Ne Demek?
Şöyle düşünün: Her yeni OLED ekran fonksiyonu için masa düzeninizi sıfırdan kuruyorsunuz, oysa aslında ihtiyacınız olan tek şey defterdeki son sayfanın hazır gelmesi. Çizim yüzeyi hazır olsun, siz içine saati ya da sensör verisini basın yeter. Bu kadar.
Durun, bir saniye.
Şunu söyleyeyim, Bu yüzden framework yaklaşımı burada bayağı anlamlı duruyor. Display ayrı, widget ayrı, render döngüsü ayrı… Böyle olunca hem okunabilirlik artıyor hem de proje büyüyünce panik azalıyor. Ciddi fark var.
rpi-display-core Ne Yapıyor?
rpi-display-core, Raspberry Pi üzerinde çalışan SSD1306. SH1106 tabanlı OLED ekranlar için hafif bir Python çatısı sunuyor. En hoş tarafı da şu: Kullanıcıya “önce altyapıyı elinle ör” demek yerine hazır sınıflar veriyor, sen oradan devam ediyorsun.
from rpi_display.displays.ssd1306 import SSD1306Display
from rpi_display import Runner
from rpi_display.widgets.clock import ClockWidget
Runner(
SSD1306Display(),
ClockWidget()
).run()Şahsen, Dört satırda çalışan saat fikri kulağa biraz fazla iyi geliyor olabilir. Ama pratikte gerçekten sadeleştirici etkisi var, bunu inkâr etmek zor (ben de ilk duyduğumda şaşırmıştım). Mantıklı değil mi? Tabii bu kadar kısa olması her şeyi çözdüğü anlamına gelmiyor; hâlâ donanım bağlantısı düzgün olacak, I2C aktif edilecek ve ekran modeliniz doğru seçilecek — bunlar hep sizin işiniz.
| Bileşen | Klasik yaklaşım | rpi-display-core yaklaşımı |
|---|---|---|
| Ekran başlatma | Her örnekte yeniden yazılır | Sınıf içinde soyutlanır |
| Çizim alanı | PIL/ImageDraw elle yönetilir | canvas bağlam yöneticisiyle gelir |
| Döngü mantığı | Script’e gömülür | Runner yönetir |
| Sahte test ortamı | Zor bulunur veya yoktur | MockDisplay var |
Kanvas Mantığı Neden Güzel?
Bana göre burada en temiz fikirlerden biri canvas. Çoğu kişi bu kısmı gözden kaçırıyor — ama esas fark burada oluşuyor, bence. Ekranı çizmek için önce yüzeyi alıyorsun, işini bitirince otomatik olarak ekrana gönderiliyor; tıpkı mutfakta yemeği tabağa koyup servis etmek gibi, uğraşı pürüzsüzleşiyor. Gereksiz adımlar kayboluyor.
Editör masasında bunu anlatırken hemen kendi ev lab’ime döndüm, İstanbul-Bahçelievler’deki rafta duran Pi’ye bağlandım. Denedim — evet, biraz nerdçe, gece yarısı testi oldu. Sonuç fena değildi; özellikle küçük arayüzlerde bu soyutlama bayağı rahatlatıcı. Şaşırdım açıkçası, bu kadar temiz olmasını beklemiyordum. Daha fazla bilgi için Git’le Kavga Edenlere GitNova: CLI Asistanı Sahneye Çıkıyor yazımıza bakabilirsiniz.
Peki Nerede Güçlü, Nerede Zayıf?
Eh, Açık konuşayım. Bu tür çatıların güçlü yani hız kazandırmasıdır; zayıf yani ise — dur bir saniye, bunu doğru söylemek lazım — her şeyi sihirli biçimde çözmemesidir. Eğer display sürücünüz yanlışsa ya da donanım bağlantınız gevşekse, framework size ancak sınırlı ölçüde yardım eder. O kısmı yine siz çözeceksiniz.
Küçük startup senaryosunda bu yapı çok iyi oturuyor çünkü ekip genelde hızlı prototip istiyor; saati gösterir misin, gösteririz, ağ durumunu ekler misin, ekleriz, birkaç widget daha gelir mi, gelir… Ama enterprise seviyesinde mesele biraz farklı; orada loglama disiplini, cihaz yönetimi. Uzaktan güncelleme tarafını ayrıca düşünmeniz gerekiyor. Neyse, uzatmayalım.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
- Küçük ekip: Hızlı deneme yapar, düşük bakım maliyeti ister.
- Bireysel maker: Az kodla sonuç görmek ister.
- Kurum içi kullanım: Test altyapısı ve standartlaşma önem kazanır. — ciddi fark yaratıyor
- Kritik eksik: Bazı gelişmiş dashboard ihtiyaçları için hâlâ sizin ekstra widget yazmanız gerekebilir.
Doğrusu, E tabi bu kötü mu? Değil. Ama “her derde deva” da değil. İşte dürüst resim bu. Eğer beklentiniz yalnızca basit statik veri ya da hafif animasyon ise gayet yeterli duruyor; fakat çok katmanlı grafikler ya da yoğun veri akışı istiyorsanız işler biraz ağırlaşabilir. Ben olsam bunu kontrol panelinin ön yüzü gibi kullanırım, ana sistem monitörü değil belki.
Dikkat Etmeniz Gereken Donanım Tarafı ve Kurulum Gerçekleri
Kaldığımız yerden devam edelim. OLED tarafında genelde üç şey belirleyici oluyor — bağlantının sağlamlığı, I2C’nin açık olması, bir de voltaj uyumu. Pi 5 önerilmiş olsa bile eski modellerle çalışmak mümkün; ben RPi 4B üzerinde daha önce iki farklı SH1106 modülünü sorunsuz kullandım. Hatta geçen yıl Ankara’da yaşayan arkadaşım Murat, ofis masasındaki mini göstergeyi dört jumper kabloyla ayağa kaldırınca baya şaşırmıştı (yanlış duymadınız). “Bu kadar mıymış?” dediği an hâlâ aklımda.
Buradaki tablo net: SSD1306 modeller daha yaygın, SH1106 modeller ise bazı kasalarda fiziksel olarak daha iyi oturabiliyor. Yalnız şunu unutmamak lazım — ucuz modüllerde görüntü kayması veya kontrast dalgalanması görülebiliyor. Yani kutudan çıkan her parça kusursuz olmuyor. Biraz naz gerekiyor. Bu konuyla ilgili API Anahtarı Olmadan LLM: Ollama ile Yerelde Başlamak yazımıza da göz atmanızı tavsiye ederim. Semantic Search Ölçekte Neden Zorlaşıyor? RAG’in Dersi yazımızda bu konuya da değinmiştik.
Benim deneyimime göre OLED projelerinde sorun çoğu zaman koddan değil kablodan çıkıyor; özellikle SDA/SCL hattında minicik temas problemi varsa saat su gibi akar gider ama ekran bomboş kalır!
Maliyet Tarafına Kısaca Bakalım — Ne Kazandırıyor?
| Senaryo | Tahmini Etki | Açıklama |
|---|---|---|
| Maker projesi | Zaman tasarrufu | Aynı iskeleti tekrar yazmazsınız |
| Küçük startup prototipi | Daha hızlı demo, daha az hata | Daha kolay test |
| Kurumsal kullanım | Standartlaştırılmış mimari | Yeni cihaz eklemek nispeten rahatlar |
Bu tabloyu bilerek biraz sade tuttum (bizzat test ettim). Burada rakamdan çok ritim önemli: az kod, az sürpriz; daha net test, daha az gece mesaisi. Basit ama gerçek.
Neden Test Edilebilir Olması Önemli?
Bir dakika şunu da ekleyeyim. MockDisplay desteği benim gözümde ciddi artılarından biri — çünkü gerçek donanıma bağımlılığı azaltıyor. 2023’te kendi side project’imde buna benzer bir şeyi eksik bırakmıştım; sonuç? Her test için masaya fiziksel cihaz koymam gerekti, ve doğal olarak süreç hantallaştı. Gereksiz yere.
Mock katmanı sayesinde geliştirme hızlanıyor; özellikle CI/CD içinde bunun değeri büyük, bence küçümsenmemesi gereken bir detay bu. Eğer ekip kalabalıksa biri widget yazarken öteki mock üstünden davranışı doğrulayabiliyor — bayağı pratik, valla işe yaramış.
Ha bu arada, eğer senin kullanım alanın sürekli değişiyorsa — mesela hava durumu artı IP artı CPU artı özel uyarılar — framework tarzındaki yapı sana nefes aldırır. Tek dosyalık script yerine genişleyen ama dağılmayan bir düzen elde edersin. Hmm, nasıl desem, bir nevi büyüyen ama şeklini koruyan bir şey.
Nerede Kullanılır?
Bazıları bunu sadece masaüstünde duran minik süs ekran sanabilir. Ama iş öyle değil.
- Tiny home server monitörü kurarsın.
- Lokal ağ durumunu gösterirsin. — ciddi fark yaratıyor
- Basit nöbetçi paneli yaparsın.
- Coffee corner’a zarif saat koyarsın.
- Masa üstünde CPU/RAM takibi yaparsın.
Daha ileri gidelim: Bir SaaS startup’ında ofis içi operasyon ekranına çevirebilirsin; kurumsalda ise toplantı odası doluluk göstergesi gibi kullanabilirsin. Ama burada sınırı doğru çizmek gerekiyor — bu yapı veri ambarının önüne konacak dev dashboard değil; minyatür ama kullanışlı arayüzlerin işi. Tam da öyle.
Neyse, uzatmayalım: bence rpi-display-core‘un asıl kıymeti estetikten ziyade mühendislik disiplininde yatıyor. Kod tekrarı azalınca hata ihtimali düşüyor, okuması kolaylaşıyor, sonradan gelen geliştirici de neyin nerede olduğunu hızlı anlıyor. Bu küçük ama kıymetli bir şey.
Bi saniye — Sadece şunu söylemeden geçmeyeyim: Proje güzel başlamış, ama henüz pişmeye açık tarafları var (şaşırtıcı ama gerçek). Mesela widget çeşitliliği arttıkça API’nin ne kadar tutarlı kalacağı önemli olacak — kağıt üstünde temiz olan birçok mimari pratikte ufak detaylarda tökezleyebiliyor. Bunu zaman gösterecek.
Sıkça Sorulan Sorular
Piyasadaki sıradan scriptlerden fark eden şey; Python’la Günlük İşleri Otomatikleştirin: Evde, İşte, Hayatta yazımızda da bu konuya değinmiştik. iPad Air 11 (M4): Fiyatına Göre İyi mi, Fazla mı İddialı? yazımızda da bu konuya değinmiştik.
ortak işleri merkezileştirip tekrar kullanılabilir hale getirmesi’dir.
Yani her seferinde baştan display kurmak yerine hazır sınıflarla ilerlersiniz.
İkisi de küçük OLED dünyasının popüler seçenekleri,
ama sürücü taraflarında ufak farklar vardır.
Bazı kasalar veya paneller fiziksel boyutta benzer görünse de piksel hizalama davranışı değişebilir.
Evet, özellikle temel Python bilenler için uygun görünüyor.
Ama I2C aktivasyonu, GPIO bağlantısı paket kurulumu konusunda çok az da olsa el kirletmek gerekiyor.
Donanımsız test yapmayı sağlıyor; yani geliştirme süreci kilitlenmiyor.
CI ortamında bile render mantığını kontrol etmek mümkün oluyor bu da bayağı rahatlık veriyor.
rpi-display-core GitHub Sayfası (ciddiyim)
Raspberry Pi Resmi I²C Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
