STM32CubeMX ten hic birsey anlamadim

[yamak]

Hocam bildiğim kadarıyla bundan sonra HAL kullanılacak.Std perip. librariler birbirleriyle tam uyumlu olmadığı için adamlar HAL i geliştirdiler ve bundan sonra HAL ile devam edecekler diye biliyorum.HAL aslında daha kullanışlı weak fonksiyonlar falan yazmış adamlar.Ama HAL in de bazı sıkıntıları var ilerde düzelteceklerini söylediler.Mesela Systick timer ı direk kendi kullandığı için RTOS kullanırken biraz sıkıntı oluyo.Tüm HAL i systick timer larından arındırmak gerekiyo fakat bu da bazı sorunlara yol açıyo.Adamlar pek önermiyo.Ya da os kullanırken system tick timerdan başka bi timer ın kullanmak gerekiyo.Ya da os systick handler ınını hook u varsa hook da kullanılabilir ama bu her rtos da olmuyo.St neden böyle bi saçmalık yaptı hala anlamış değilim.

[oyaz]

Anladım hocam, daha tam oturmamış gibi dursa da yeni projeleri HAL ile yapmak mantıklı olacaktır. Teşekkürler.

[yamak]

Yani hocam adamlar bundan sonra hal i destekleyeceklerini söylüyolar.Ama std perip library de kullanılabilir neticede adamlar tüm peripheralları destekleyecek şekilde library yazmış.Fakat muhtemelen bundan sonra çıkacak micro lar için sadece HAL yazacaklar.Bu sebeple HAL e şimdiden alışmakta fayda var.

[Karamel]

hocam ben soyle birsey sormak istiyorum. bu hal libraryleri ile yada standart st libraryleri ile atiyorum spi yi hazirlayip ondan birseyler gonderecegimiz zaman. hazir fonksiyonlari cagirip. portu hazirlayip. sonrada gonderme falan yapiyoruz degilmi?

eger boyle ise. libraryler icin bahsettiginiz sorunlari tam olarak anlayamadim..... 

[yamak]

Hocam hangi sorunlardan bahsediyosunuz.Çok büyük bi sorun yok aslında.HAL systick i default olarak kullanılıyor.Bi şekilde HAL systick ten arındırmak gerekiyo.Yad RTOS u timer ını başka bi timer yapmak gerekiyo.Fakat bu iyi bi yöntem değil.

[Burak B]

    @yamak'ın bahsettiği sorun şu CubeMX ile FreeRTOS seçeneğini aktif edip kod ürettiğinizde kod derleniyor ama çalışmıyor(du). Buradaki çalışmamaktan kasıt  RTOS schedulerin başlamadan kilitleniyor olması ve sistemin iş göremez hale gelmesi. Bunun sebebi de daha OS scheduler başlamadan systick içerisinde xPortSysTickHandler() ile işlem yapılmaya çalışılması. Bunu basit bir düzenleme ile aşmak mümkün. FreeRTOS ile tickless olarak çalışılabiliyor. Bu genelde low power sistemler için tercih edilen bir method. Yani systick çok büyük bir sorun değil. Bundan daha büyük sorunlar Ethernet, SDIO, DMA gibi kısımlarda daha çok ön plana çıkıyor.

     Benim kişisel görüşüm önceki mesjaımda da belirttiğim gibi. CMSIS uyumluluğu adına eski librarylerden çok daha esnek olduğu yönünde. Dökümantasyon çok çok daha iyi. Blocking, Non-Blocking(IT, DMA) fonksiyonlar ile esneklik daha da artırılmış. Yine CMSIS-Driver uyumlu olarak çevre donanımları(SPI,ADC,DMA,UART, ...) ile ilgili işlemler sürücü nesneleri üzerinden kontrol edilerek hem RAW(barebone) hem de RTOS ortamlar için daha düzgün bir zemin hazırlanmış.

    STM32F1 desteği daha uzun süre gelmeyebilir. Gelirse ne âlâ.

[CoşkuN]

ST'nin forumunda Cube MX'de STM32F1 desteğinin Ocakta çıkacağı söylenmiş:
"STM32CubeMX clock configuration,  power consumption calculator and code generation for STM32F1 series is planned to be released next January."
https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2FHow%20will%20it%20support%20STM32F1%20in%20STMCubeMX&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=86

[yamak]

    @yamak'ın bahsettiği sorun şu CubeMX ile FreeRTOS seçeneğini aktif edip kod ürettiğinizde kod derleniyor ama çalışmıyor(du). Buradaki çalışmamaktan kasıt  RTOS schedulerin başlamadan kilitleniyor olması ve sistemin iş göremez hale gelmesi. Bunun sebebi de daha OS scheduler başlamadan systick içerisinde xPortSysTickHandler() ile işlem yapılmaya çalışılması. Bunu basit bir düzenleme ile aşmak mümkün. FreeRTOS ile tickless olarak çalışılabiliyor. Bu genelde low power sistemler için tercih edilen bir method. Yani systick çok büyük bir sorun değil. Bundan daha büyük sorunlar Ethernet, SDIO, DMA gibi kısımlarda daha çok ön plana çıkıyor.

     Benim kişisel görüşüm önceki mesjaımda da belirttiğim gibi. CMSIS uyumluluğu adına eski librarylerden çok daha esnek olduğu yönünde. Dökümantasyon çok çok daha iyi. Blocking, Non-Blocking(IT, DMA) fonksiyonlar ile esneklik daha da artırılmış. Yine CMSIS-Driver uyumlu olarak çevre donanımları(SPI,ADC,DMA,UART, ...) ile ilgili işlemler sürücü nesneleri üzerinden kontrol edilerek hem RAW(barebone) hem de RTOS ortamlar için daha düzgün bir zemin hazırlanmış.

    STM32F1 desteği daha uzun süre gelmeyebilir. Gelirse ne âlâ.

Hocam FreeRtos ta o şekilde yapılıp düzeltilebilir.Fakat örneğin rtx'te source kod bize direk verilmiyo ve SysTick_Handler Rtos'un core unda.Tamam direk core daki handler içinde değişiklikler yapılabilir fakat bu da ARM tarafından pek önerilen bişey değil.Ya da RTX in tick timer ı başka bir timer yapılabilir ama bu durumda da HAL'in timer'ının prioritiy'si RTOS'unkinden yüksek olmuş oluyo.Bu da pek hoş bi durum değil.Bence en güzeli HAL i System tick timer dan arındırmak.Bundan da daha iyisi St nin RTOS u göz önünde bulundurarak bi HAL yazması

[Burak B]

@CoşkuN dikkatini çekerim "this January." dememiş "next January." demiş. Yani hani olsa da önümüzdeki aylarda çıksa ama sanmıyorum.

@yamak bu bahsettiğin durumda bir tasarım hatası zaten. CubeMX üzerinden gittiğimiz için kapalı kod RTOS' lar ile ilgili sorunlarına girmedim. Zaten şu anda CMSIS destekleyen RTOS sayısı pek fazla değil. Oturup wrapper modüller yazmak gerekiyor. Ayrıca HAL systick timer ile hangi noktada birleşik tam olarak ? Benim bildiğim kadarıyla systick RTOS için kullanılıyor birtek. HAL ile direkt bir ilişkisi yok.

[yamak]

Hocam CubeMx den direk bir kod üretin.Direk it dosyasında kullanılıyor.Bir tick counter systick handler ın içinde artırılıyor.Ve bazı driverlar gettick şeklinde kullanılıyor.Direkt SysTick_Handler ın içindeki kodlar alınıp başka bir timer interrupt handlerının içine konulunca derleyici sorun çıkarmıyor.Ama büyük projelerde bu bi sorun çıkarır mı biliyorum?Ben sadece deneme amaçlı küçük bi proje üzerinde denedim.

[Burak B]

Hocam CubeMx den direk bir kod üretin.Direk it dosyasında kullanılıyor.Bir tick counter systick handler ın içinde artırılıyor.Ve bazı driverlar gettick şeklinde kullanılıyor.Direkt SysTick_Handler ın içindeki kodlar alınıp başka bir timer interrupt handlerının içine konulunca derleyici sorun çıkarmıyor.Ama büyük projelerde bu bi sorun çıkarır mı biliyorum?Ben sadece deneme amaçlı küçük bi proje üzerinde denedim.

Tamam işte ben deneyime dayanarak yazıyorum. Ben üst-orta ölçekli bir projede (SDIO,DAC,GSM,ETH,UART,v.b. donanımları aynı anda çalıştıran 50-100 cihazlık bir ortamda.) kullandığım için biliyorum. Systickten daha önemli sorunları var. Bahsettiğin sorun yukarıda söylediğim scheduler kontrolü v.s. dışında çok problem olmaz. Mesela ben kodlarken CubeMX' in ürettiği SDIO kodu beni çok yanıltıp zamanımı harcamıştı (1 hafta kadar). Bazı kısımlarını yeniden yazmam gerekti sonradan düzelttilerse bilmiyorum.

Aslında üzerinde çok konuşulacak bir konuda değil seve seve kullanacağız. ST böyle istiyor.

[oyaz]

Aslında üzerinde çok konuşulacak bir konuda değil seve seve kullanacağız. ST böyle istiyor.

Galiba öyle olacak hocam

[oyaz]

F1 Serisi içinde Cube desteği gelmiş.

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF259242?sc=stm32cube

[Gökhan BEKEN]

@Burak BAYRAK hocam, bahsettiğiniz SDIO ile birlikte DMA kullanma sorununu ben de yaşıyorum, çözümünü nasıl yaptığınızı anlatırsanız memnun olurum.

[Burak B]

Donanımın nedir ? Öncelikle donanımının doğru çalıştığından emin olman gerekiyor.