Stm32F4 Tek Kanal ADC Okuma Problemi

[OptimusPrime]

Sensor cevre birimleri ile haberlesir SPI, I2C, 1WIRE gibi. Bunlar ise ARM mimarisinin bir parcasi degildir. Bunlar ozel bir bus uzerinde bulunan slave cihazlardir. ARM cekirdegi ile ozel bir protokol uzerinden haberlesirler.

Eger ben ARM dan daha yuksek performans alayim, isimi daha hizli goreyim dersen bu durumda ASM yazman icap eder ki isin tam da bu kisminda mimariye hakim olman gerekir.

Fakat senin sorunun baska gibi duruyor. Yazdiklarindan anladigim kadariyla sen driver yazmayi bilmiyorsun. Dogru mu anliyorum?

[SahinCeylan]

Sensor cevre birimleri ile haberlesir SPI, I2C, 1WIRE gibi. Bunlar ise ARM mimarisinin bir parcasi degildir. Bunlar ozel bir bus uzerinde bulunan slave cihazlardir. ARM cekirdegi ile ozel bir protokol uzerinden haberlesirler.

Eger ben ARM dan daha yuksek performans alayim, isimi daha hizli goreyim dersen bu durumda ASM yazman icap eder ki isin tam da bu kisminda mimariye hakim olman gerekir.

Fakat senin sorunun baska gibi duruyor. Yazdiklarindan anladigim kadariyla sen driver yazmayi bilmiyorsun. Dogru mu anliyorum?

Doğru hocam yeni başladım ben daha öğrenmeye kendi araştırmama göre önce hal kütüphanesi gibi kütüphaneler ile sistemi öğrenip sonrasında yaptığım projede kullanacağım mcu veya Sensor farketmeksizin projeyi yapabilmeyi istiyorum. Bi sensörün kütüphanesi yok diye kullanamamak bana doğru gelmiyor. Bu durumda nasıl bir yol haritası çizmek doğru olur?

[OptimusPrime]

@SahinCeylan

 

Kabaca soyle. Programi yazdigin en ust katmana kullanici katmani, seni donanimdan soyutlayan katmanada HAL katmani dersek, aslinda driver/surucu bu ikisi arasinda yer alan baska bir katman oluyor. Bu katman kullaniciya (kullanici katmani) sensorden kolayca veri alip vermesinde yardimci oluyor. Simdi bu genel resme baktiginda senin ihtiyacin olan kullanici katmaninda ne tur bilgiye ihtiyacin oldugunu belirlemek ve buna uygun fonksiyonlar yazarak HAL in senin yerine sensor ile iletisim kurmasini saglamak (Donanim uzerinden).

Diyelim ki: Elinde I2C sicaklik sensoru olsun. Datasheetine baktiginda sensorun I2C uzerinde bir adresi ve birde sicaklik bilgisinin icerisinde sakladigi bir registeri oldugunu goreceksin. Datasheetin bir yerlerindede bu register dan nasil veri okuyabilecegini anlatan bir kisim olmali.

Ornegin; sensor 0x80 adreside olsun. Sicaklik bilgisininde 0x17 adresli bir registerde saklandigini dusunelim. Datasheet de bu adrese erisebilmek icin yapman gerekenleri soyle anlatsin:

- Hatta start ver
- Cihaz adresini gonder ve cihazi yazmak icin ac (0x80 + W)
- Cihaza sicaklik bilgisinin bulundugu register adresini yaz ki ic adres sayaci bu noktaya gitsin
- Hatta restart gonder
- Bu sefer cihazi okumak icin ac (0x80 + R)
- Basla okumaya (1 Byte oku)
- Iletisimi sonlandir

Bu yukaridaki isleri yapan bir veya birden fazla HAL fonksiyonu olmali. Bu fonksiyonlari cagirarak ilk once sicaklik okuyabiliyor musun buna bak. Bu islemler basarili oldugunda tum bu isleri yapan kodlari bir fonksiyon icerisine yazip buna gerekli parametreleri gec ve sana sicaklik bilgisini geri dondurdugu tekrar kontrol et. Iste bu senin driver inin  bir parcasi.

Bu gozle yazilmis driver lari incelersen bir driver in az cok nasil yazilmasi gerektigini anlayabilirsin. Birkac deneme yaptiginda artik kimseye muhtac olmadan kendi driver ini yazabilecek duruma gelebilirsin.

[SahinCeylan]

@SahinCeylan

 

Kabaca soyle. Programi yazdigin en ust katmana kullanici katmani, seni donanimdan soyutlayan katmanada HAL katmani dersek, aslinda driver/surucu bu ikisi arasinda yer alan baska bir katman oluyor. Bu katman kullaniciya (kullanici katmani) sensorden kolayca veri alip vermesinde yardimci oluyor. Simdi bu genel resme baktiginda senin ihtiyacin olan kullanici katmaninda ne tur bilgiye ihtiyacin oldugunu belirlemek ve buna uygun fonksiyonlar yazarak HAL in senin yerine sensor ile iletisim kurmasini saglamak (Donanim uzerinden).

Diyelim ki: Elinde I2C sicaklik sensoru olsun. Datasheetine baktiginda sensorun I2C uzerinde bir adresi ve birde sicaklik bilgisinin icerisinde sakladigi bir registeri oldugunu goreceksin. Datasheetin bir yerlerindede bu register dan nasil veri okuyabilecegini anlatan bir kisim olmali.

Ornegin; sensor 0x80 adreside olsun. Sicaklik bilgisininde 0x17 adresli bir registerde saklandigini dusunelim. Datasheet de bu adrese erisebilmek icin yapman gerekenleri soyle anlatsin:

- Hatta start ver
- Cihaz adresini gonder ve cihazi yazmak icin ac (0x80 + W)
- Cihaza sicaklik bilgisinin bulundugu register adresini yaz ki ic adres sayaci bu noktaya gitsin
- Hatta restart gonder
- Bu sefer cihazi okumak icin ac (0x80 + R)
- Basla okumaya (1 Byte oku)
- Iletisimi sonlandir

Bu yukaridaki isleri yapan bir veya birden fazla HAL fonksiyonu olmali. Bu fonksiyonlari cagirarak ilk once sicaklik okuyabiliyor musun buna bak. Bu islemler basarili oldugunda tum bu isleri yapan kodlari bir fonksiyon icerisine yazip buna gerekli parametreleri gec ve sana sicaklik bilgisini geri dondurdugu tekrar kontrol et. Iste bu senin driver inin  bir parcasi.

Bu gozle yazilmis driver lari incelersen bir driver in az cok nasil yazilmasi gerektigini anlayabilirsin. Birkac deneme yaptiginda artik kimseye muhtac olmadan kendi driver ini yazabilecek duruma gelebilirsin.

Hocam çok güzel bir açıklama olmuş bende 2*16 lcd için kütüphane nasıl yazıldığını araştırıyorum şuan yazılmış kütüphaneyi çıkardım. LCD ait datasheet karşımda yine karşılıklı karşılaştırıp mantığı anlamaya çalışıyorum. Fakat yaşadığım problem şu lcd ile ilgili bazı adresleri .h kütüphanesi içinde tanımlama yapılmış bazılarında tanımlama yapmamış hangi adresi neye göre hangi mantığa göre tanımlıyor bunu çözemiyorum. Çözmek için nasıl bir yol izlemek gerekir. Nereden başlamalıyım?

[OptimusPrime]

@SahinCeylan

Cozemedigin kismi o driver i yazana sormak lazim 

Bir driver i ayni ismi tasiyan .c ve .h uzantili modul haline getirdiginde, okuyan icin anlasilabilir olmasi icin, bu tip sihirli sayilarin .h dosyasi icerisinde uygun bir aciklama ile tanimlanmasi gerekir.

Kisaca .h ve .c dosyasinda bulunmasi gerekenler
.h
- include dosyalari
- tipler ve yapilar
- tanimlamalar
- makrolar
- globaller
- prototipler
vs vs

.c
- degiskenler (sadece modul icerisinde kullanilanlar static ile tanimlanmali)
- fonksiyonlar (sadece modul icerisinde kullanilanlar static ile tanimlanmali)
vs vs

gibi.
 

[SahinCeylan]

@SahinCeylan

Cozemedigin kismi o driver i yazana sormak lazim 

Bir driver i ayni ismi tasiyan .c ve .h uzantili modul haline getirdiginde, okuyan icin anlasilabilir olmasi icin, bu tip sihirli sayilarin .h dosyasi icerisinde uygun bir aciklama ile tanimlanmasi gerekir.

Kisaca .h ve .c dosyasinda bulunmasi gerekenler
.h
- include dosyalari
- tipler ve yapilar
- tanimlamalar
- makrolar
- globaller
- prototipler
vs vs

.c
- degiskenler (sadece modul icerisinde kullanilanlar static ile tanimlanmali)
- fonksiyonlar (sadece modul icerisinde kullanilanlar static ile tanimlanmali)
vs vs

gibi.
 

Teşekkür ederim bilgiler için    biraz daha uğraşıp emek vermek lazım takıldığım farklı konu olursa sorarım tekrar eğer daha önce sorulmamış ise. 

[OptimusPrime]

 

Aklinda bulunsun. Her yazilan driver calissa bile dogru olmayabilir. Mesela, sag eliyle sol kulagini tutmustur,  icinden gelmistir baska fantaziler eklemistir, tam olarak yapilan dogru degildir ama bir sekilde donanim onu tolere ediyordur vs vs. 

Yuzeysel bak mantigini anla yeter.