Gömülü Sistemlerde RAM Organizasyonu

Günümüzde gelişmiş işlemcilerde farklı tipte RAM organizasyonları bulunsa da genel ve yaygın olan yaklaşıma göre bu yazı hazırlanmıştır.

Gömülü sistemlerde RAM organizasyonunda 3 temel alan bulunur. Bunlar statik, stack ve heap alanlarıdır.

Safety ve Security Kavramları

Bu yazıda safety ve security kavramlarını inceleyeceğiz. Türkçede emniyet ve güvenlik şeklinde yer yer ifade edilse de net bir karşılık olmadığı için bu yazıda ingilizce terimler kullanılacaktır.

Safety, emniyette olma ve potansiyel tehlikelerden korunma durumudur. Safety, kabul edilebilir bir risk düzeyine ulaşmak için bilinen tehlikelerin kontrolünü de ifade eder. Safety, genellikle sistemlerin kendileri kaynaklı oluşabilecek tehlikeli durumlarını ve bu durumlardan kaçınmayı ifade eder.

Security, sistemin dışından gelecek, sistemin doğal işleyişini bozmak veya sistem içerisinde tutulması gereken her türlü bilginin, sistemin izni haricinde alınması/erişilmesi durumudur. Security açısından sistemler değerlendirilirken riskler, tehdit modelleri ve saldırı yöntemleri analiz edilir. Sonrasında sistem security açısından da güvenli bir noktaya gelmesi gereken aksiyonlar planlanır ve devreye alınır.

C dilinde, İyi Yazılmış, Taşınabilir Bir Sensör Sürücü Paketi İncelemesi

Bu yazıda gömülü sistemlere düşük seviyede sürücü geliştiren kişilere referans niteliğinde olan, BOSCH'un  sıcaklık, nem ve basınç sensörü BME280 için geliştirdiği, github üzerinden yayınladığı açık kaynak kütüphaneyi [1] inceleyeceğiz. Başlıkta da belirttiğim gibi kütüphane gerçekten çok modüler bir şekilde oluşturulmuş. Geliştirilen kütüphane platform-bağımsız olduğu için herhangi bir altyapıya adapte edilebilir. Bu yapıyı herhangi bir mikrodenetleyicide veya OS ile çalışan bir gömülü yapıya entegre edebilirsiniz.

Kütüphane geliştirilirken low-coupling, high-coherence kavramlarını başarılı bir şekilde uygulamış. Kütüphane içerisinde herhangi bir dış bağımlılık olmadığı gibi kendi içerisindeki fonksiyon ve veri setleri de tam olarak amaca yöneliktir.

Öncelikle kütüphanenin güzel bir README.md dosyası var. İçerisinde bu kütüphanenin nasıl kullanılabileceği detaylı bir şekilde anlatılmıştır.

Bu yazıda, ilgili kütüphaneyi SPI üzerinden nasıl kendi sisteminize entegre edeceğinizi yine README.md deki örnek üzerinden ele alacağız.

Kütüphane bme280_dev structure'ı üzerinden çalışıyor. Bu yapı aşağıda verilmiştir.

Bu yapıda öncelikle ilgili sensörün hangi arayüz ile hangi modda kullanılacağı çeşitli değişkenlerle seçilir. Bu seçimler değişken isimleri ve gerekli yorumlarla desteklenmiş ve açık bir şekilde belirtilmiştir.

Bunun haricinde taşınabilirlik açısında bizim en çok işimize yarayan kısım fonksiyon pointer yapılarıdır. SPI örneği üzerinden devam edecek olursak bme280_dev yapısı içerisinde okuma yazma fonksiyonları için dev.read ve dev.write fonksiyon pointerlarına ilgili platforma ait SPI yazma okuma fonksiyonları atanır. SPI okuma ve yazma fonksiyonları kendi içerisinde CS operasyonunu gerçekleştirmelidir. Fonksiyonel olarak yazılmış sensör sürücüsü soyutlanmış okuma, yazma fonksiyonları üzerinden çalışır. Bu iki fonksiyona ek olarak kütüphane içerisinde kullanmak üzere 1 ms çözünürlüklü bir delay fonksiyonunun da pointerı structure'a atanır.

Bu noktada önemli bir parantez olarak ilgili fonksiyon pointerları mevcut altyapınızla birebir uyumlu olmayabilir. Hatta muhtemelen farklıdır. Bu noktada sizin altyapınız ile kütüphane arasına bir adaptör katmanı yazmanız gerekebilir. Örnek olarak aşağıdaki fonksiyon incelenebilir. myusleep fonksiyonu platform tabanlı bir fonksiyondur. Örnek olarak ms gecikmesi için STM32 altyapısında HAL_Delay fonksiyonunu düşünebilirsiniz. Arduino altyapısında buna delay fonksiyonu karşılık gelir. Biz her iki platformda da mevcut fonksiyonun adresini aşağıdaki gibi bir adaptör vasıtasıyla bme280_dev yapısına atanır. Böylece kütüphane fonksiyonları platform bağımsız çalışır.

Bu kütüphane kullanılarak oluşturulmuş tam bir örneğe aşağıdaki linkten erişebilirsiniz. En başta da ifade ettiğim gibi gömülü sistemlerde sürücü seviyesinde yazılım geliştiriyorsanız bu kütüphaneleri hiç bir zaman başka bir platformda kullanmayacaksanız bile bu yaklaşımla geliştirmenizi öneririm. Kodun okunabilirliği, güncellenebilirliği ve bakım yapılabilirşliği açısından da oldukça faydalı olacaktır.

https://github.com/BoschSensortec/BME280_driver/blob/master/examples/bsd_userspace.c

Referanslar

[1] https://github.com/BoschSensortec/BME280_driver/

Coupling ve Cohesion Kavramları

Yaızlım geliştirme süreçlerinde belli bir metedoloji veya tekniği takip etmediğiniz zaman işin sonunda veri yapıları ve fonksiyonların fazlaca birbirine girmesi kaçınılmaz bir durumdur. Özellikle OOP odaklı olmayan C gibi dillerde bu konu daha bariz şekilde kendini göstermektedir. C++ gibi OOP odaklı bir dilde mecburen de olsa bazı düzenlemeler doğal olarak kendiliğinden gelişiyor ancak C gibi dillerde özellikle planlanmadığı zaman gerçekten düzenli ve sistematik kod yazmak zor oluyor.

Bu yazıda, yazılımda genel kavramlardan olan coupling ve cohesion kavramları hakkında temel bilgileri paylaşacağım. Bu kavramları zihninizde canlandırmak için aşağıdaki görsel iyi bir örnektir. Burada birbirine benzer yapıların bir grup şeklinde durduğunu ve bu gruplar arası geçişlerin basit birkaç yol/arayüz vasıtası ile olduğunu görüyoruz.

Öncelikle coupling ve cohesion kavramlarının genel tanımını yapalım.

Coupling, modüller arasındaki karşılıklı bağımlılık derecesinin ölçüsüdür. Couplingin düşük olması kodun taşınabilirliğini arttırır. Platformlar arası geçiş rahatlıkla sağlanır.

İyi bir yazılımda bu ölçü düşük olmalıdır. [2]

Cohesion, modül öğelerinin işlevsel olarak ilişkili olma derecesinin bir ölçüsüdür. Bunu OOP bir dilde class olarak, C dilinde ise bir *.c ve *.h dosya çifti olarak düşünebilirsiniz. Tek bir görevi yerine getirmeye yönelik tüm unsurların bileşende yer alma derecesidir. Temel olarak cohesion, modülü bir arada tutan içsel ilişkidir. 

İyi bir yazılım tasarımı, yüksek bir bütünlüğe sahip olacaktır. 

Örnek olarak inputlara göre bir hesabı gerçekleştiren fonksiyon sadece o işi yapmalıdır. Bu fonksiyonun içerisine bir de print fonksiyonu eklemek veya gömülü yazılım tarafında kullanılan bir haberleşme protokolü üzerinden göndermek cohesion açısından olumsuz bir örnektir.

İkinci bir örnek verecek olursak, örneğin bir arayüz tasarımı yapıyorsanız ve arka planda çeşitli hesaplar yapılıyorsa bu hesaplar arayüz fonksiyonları içerisinde yer almamalıdır. Bu tarz hatalı kurulmuş düzenler uzun vadede yazılımı kontrol edilebilirlikten çıkartan etkenlerdir.

Referanslar:

[1] https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/

[2] https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/

[3] https://stackoverflow.com/questions/3085285/difference-between-cohesion-and-coupling

ADC Nedir? Analog to Digital Çevrim İşleminde Karşılaşılan Hatalar Nelerdir?

 ADC (Analog-to-digital converter, Analogtan Dijitale Çevirici) analog verileri dijital verilere çeviren çevre birimleridir. ADC yapıları gerçek dünyadan dijital dünyaya veri almanın en bilinen yöntemidir. ADC yapıları sinyalleri tanımlanmış zaman aralıklarında alır ve ADC çözünürlüğü ölçüsünde quantize eder. Böylece ADC yapıları, dijital hesaplamalar için zamanda ve genlikte quantalanmış/ayrılmış veriler sağlar.

ADC işlemine örnek olarak ses verisinin dijitale çevrilmesi verilebilir. Ses sinyali ile mikrofon üzerindeki gerilim değişir. Bu gerilim değeri ADC tarafından okunarak ses sinyali dijitalleştirilmiş olur. İşlemciler üzerinde bu dijital veri işlenerek anlamlı bir bilgiye çevrilir.

ADC farklı tiplerde tasarlanabilir. Mikrodenetleyicilerde en yaygın kullanılan ADC tipleri SAR ve ΔΣ ADC tipleridir.

Farklı ADC çözünürlük ve ölçüm frekanslarına ait tablo aşağıdaki gibidir.ADC'nin çözünürlüğü Vcc/(2^bit) formülü ile bulunur. Örneğin 5 V ile çalışan 12 bitlik bir ADC'nin çözünürlüğü;

5 V/(2^12) = 5 V/4096 = 1,22 mV'dur.

Kısa bilgi olarak ADC'nin tersi yönde çalışan DAC yapıları da vardır. DAC yapıları işlemciler içerisindeki dijital verilerin analog verilere döndürülmesi için kullanılır. Bu iki yönlü dönüşüm aşağıdaki görselde verilmiştir.

ADC Hata Tipleri

ADC ölçümlerinde, ölçüm yapılan ADC yapısına göre çeşitli hata tipleri oluşabilir. Bu hatalar 3 ana başlıkta toplanabilir.

Doğrusallık Hatası

İdeal durumda ADC'nin normalde gerilime göre oransal bir çıkış vermesi gerekir. ADC'nin iç yapısına ve çevresel etkilere göre ADC üzerinde farklı aralıklarda farklı oranlar ortaya çıkabilir. Bu durumda doğrusallık hatası ortaya çıkar. Bu etkinin grafiksel gösterimi aşağıdaki gibidir.

Kazanç Hatası

ADC üzerinde kazanca bağlı değişen bir kazanç hatası ortaya çıkabilir. Bu ADC'nin o anki değerine göre oransal olarak artan bir hata tipidir. Bu durumda kazanç hatası ortaya çıkar. Bu etkinin grafiksel gösterimi aşağıdaki gibidir. Bunu kompanze etmek için ADC ölçümü bir katsayı ile çarpılabilir.

Dengeleme Hatası

ADC üzerinde belli bir dengeleme/ofset hatası ortaya çıkabilir. Bu ADC'nin herhangi bir andaki değerine göre sabit bir değer ekler. Bu durumda dengeleme hatası ortaya çıkar. Bu etkinin grafiksel gösterimi aşağıdaki gibidir. Bunu kompanze etmek için ADC değerine belli bir sabit değer eklenebilir.

Referanslar:

[1] https://en.wikipedia.org/wiki/Analog-to-digital_converter

Varyans, Standard Sapma, Kovaryans, Korelasyon Kavramları

 Çeşitli istatistik hesaplamalara dair aldığım notlar aşağıdaki gibidir. Bu fonksiyonların bir kısmının C dilinde gerçeklenmiş halleri de https://github.com/enginsubasi/esclib/blob/master/src/math/statistic.c adresindedir.

Finite Impulse Response (FIR), Infinite Impulse Response (IIR) Yapılarının Zaman ve Frekans Domaininde Tanımları