neden stm32 veya türevlerini yazılım olarak tercih etmeliyim

[fay_elektronik]

sayın site ahalisi ve meslektaşlarım aklımı kurcalayan bazı sorular var neden arm cortex tabanlı işlemciler kullanmalıyım veya neden bu kadar populer bu işlemciler 8 bitlik işlemcilerden bunların farkları sadece 32bit işlem ve hız faktörümü fiyat faktörüde önemli tabi

arm cortex tabanlı işlemcileri size çekici kılan nedir ben pic ve atmel programlamada orta seviyenin biraz üstündeyim şu ara pic leri çok kullanmıyorum geçmişteki emk problemlerinden dolayı atmeli atmel studio ile low level programlamayı ögerndim ve epey  bir kütüphane oluşturdum lakin sadece bendemi sizdede varmı bilmem bi doyumsuzluk yeni işlemcilerle çalışma hevesi stm32 mcu biraz çalışma yaptım kendim frekans confg. yaptım blik buton kontrol vs programıda yazdım lakin low level yazmak cok zor datasheet inanılmaz bir sürü register var program yazmak ve cözmesi uzun sürüyor hall kütüphanesini kullanmalımıyım onuda bilemedim birsürü kolaylığı var esasında ama işlemciye hakim olmayı seviyorum

esasında benden istenen projelerde 8 bitlik işlemciler yetiyor (öyle ufak tefek devrelerde değil ) bir neden varmıdır 8bitliği bırakıp 32 bit işlemcilere dönmeye nedenlerini yazarsanız sevinirim
iyi çalışmalar

[Okan AKÇA]

En yakin yol bildiğin yoldur. Hayat kısa ilk önceliğimiz ticari başarı yaptığınız ürünün hangi işlemci ile yapıldığının müsteri tarafinda hic bir önemi yoktur.

[fay_elektronik]

En yakin yol bildiğin yoldur. Hayat kısa ilk önceliğimiz ticari başarı yaptığınız ürünün hangi işlemci ile yapıldığının müsteri tarafinda hic bir önemi yoktur.

dediğiniz doğru ama illaki bazı işlemcilerin artıları eksileri vardır birbirleri üzerinde

[Tagli]

Yaptığın işler için yeterli geliyorsa alıştığın işlemciden ayrılman için bir sebep yok.

Benim PIC'leri terk edip STM32'lere geçmeme (ve orada kalmama) sebep olan birkaç etken oldu:

1) Bedava ve tam donanımlı derleyici: Microchip'in ücretsiz derleyicilerinde optimizasyonlar kapalı. Ama bence bununla da kalmıyor, XC'lerin bedava versiyonları kasıtlı olarak kodu şişirip yavaşlatıyor gibi geldi bana. STM32'de ise gcc var. Bedava ve her yerde kullanılan standart bir derleyici.

2) C++ seçeneği: STM32 için aynı zamanda g++ derleyicisi de mevcut. Yakın zamanda C++'a geçiş yaptım. Daha yeni yeni öğreniyorum ama açıkçası C'ye geri dönmek gibi bir niyetim yok. Bildiğim kadarıyla AVR'ler de bu derleyiciyi kullanıyordu, ama Microchip alınca durum ne oldu bilmiyorum.

3) Gelişmiş çevre birimleri: STM32 çok daha esnek olarak ayarlanabilen donanımlar sunuyor. PIC16'ların timer prescaler ayarlarından bıkmıştım. Mesela 1:2, 1:4, 1:16 falan ayarlayabiliyorsun, başka seçenek yok. STM32'de 1'den 65536'ya kadar istediğin değeri verebiliyorsun. Ayrıca sayacı istediğin yerden kesebiliyorsun (PIC16'larda sadece TMR2'de olan özellik). Ya da GPIO'da istediğin pine pullup veya pulldown bağlayabiliyorun, veya open drain yapabiliyorsun. Yeni modellerde biraz daha rahat olsa da özellikle eski PIC'lerde bu çok sıkıntılı idi. DMA'lar da program geliştirmeyi oldukça kolaylaştırıyor (bazı gelişmiş PIC modellerinde var gerçi bu özellik).

4) Debug rahatlığı: STM32'lerde daha hızlı bir şekilde debug yapılabiliyor. Ayrıca sanırım breakpoint sayısı da daha fazla. Eclipse IDE'nin konforuyla birleşince çok daha iyi bir debug deneyimi sunuyor. Tamam, Netbeans IDE tabanlı MPLAB X de çok kötü değildi ama Eclipse tadı vermiyor işte.

5) Programlayıcı fiyatı: ST-Link klonları ile PicKit'leri veya ICD'leri kıyaslayın. Orijinalinin bile fiyatı gayet uygun sayılır.

6) Yüksek performans ve bellek: Aslında çoğu zaman çok yüksek hızlara ihtiyaç olmasa da sonuçta 32 bitlik bir işlemcinin bu konuda sağladığı avantajı göz ardı edemeyiz. Ben PIC kullanırken özellikle RAM'i çabuk bitiriyordum. STM32'ye geçince genel olarak rahatladım. Sanırım AVR'lerin RAM boyutları PIC'lere kıyasla daha iyi.

7) RTOS olanakları: Bugünlerde FreeRTOS'a da geçiş yaptım. Bence büyük ve karmaşık projelerde mutlaka gerekiyor. Tamam, PIC'lerde çalışan RTOS'lar da var ama işlemcinin kapasitesi belli zaten... Özellikle 8 bit işlemciler RTOS için iyi adaylar değil.


Peki STM32'lerin PIC'lere göre hiç mi eksisi yok? Var tabi. Aklıma ilk gelenler şunlar:

1) Proje ilk oluşturma zorluğu: MPLAB X'de çok kolaydı, yeni proje oluştur deyip hemen main() yazmaya başlıyordum. Bir de tabi config bitleri ayarlarını bir header'a koyup projeye ekliyordum, onları da zaten IDE otomatik oluşturuyordu. STM32'de ise HAL ve Cube kullanmadığım için ilk proje oluşturma kısmı zahmetli oluyor. Boş proje oluşturuyorum, CMSIS ve ST headerlarını ekliyorum. Kullanacaksam FreeRTOS'u ekliyorum. Sonra proje ayarlarından tek tek include klasörlerini gösteriyorum. Zaman alıyor.

2) Karmaşık yapı: Evet PIC'lere çok daha karmaşık bir donanımı var ve referans dokümanını uzun uzun okumak gerekiyor. Çok daha fazla register ve bit var öğrenilmesi gereken. Ama bir süre sonra alışıyorsunuz. Ben HAL ve Cube hiç kullanmadan sıfırdan USB kodu bile yazıp çalıştırdım C++ ve FreeRTOS kullanarak. Ama tabi baya zamanımı aldı.

[magnetron]

@Tagli hocam

bende bu HAL' ı bir türlü öğrenemedim

biliyorsanız CubeIDE de SPL kütüphaneli proje nasıl oluşturulur

anlatabilir misiniz ya da bildiğiniz video var mı

teşekkür

[fay_elektronik]

Yaptığın işler için yeterli geliyorsa alıştığın işlemciden ayrılman için bir sebep yok.

Benim PIC'leri terk edip STM32'lere geçmeme (ve orada kalmama) sebep olan birkaç etken oldu:

1) Bedava ve tam donanımlı derleyici: Microchip'in ücretsiz derleyicilerinde optimizasyonlar kapalı. Ama bence bununla da kalmıyor, XC'lerin bedava versiyonları kasıtlı olarak kodu şişirip yavaşlatıyor gibi geldi bana. STM32'de ise gcc var. Bedava ve her yerde kullanılan standart bir derleyici.

2) C++ seçeneği: STM32 için aynı zamanda g++ derleyicisi de mevcut. Yakın zamanda C++'a geçiş yaptım. Daha yeni yeni öğreniyorum ama açıkçası C'ye geri dönmek gibi bir niyetim yok. Bildiğim kadarıyla AVR'ler de bu derleyiciyi kullanıyordu, ama Microchip alınca durum ne oldu bilmiyorum.

3) Gelişmiş çevre birimleri: STM32 çok daha esnek olarak ayarlanabilen donanımlar sunuyor. PIC16'ların timer prescaler ayarlarından bıkmıştım. Mesela 1:2, 1:4, 1:16 falan ayarlayabiliyorsun, başka seçenek yok. STM32'de 1'den 65536'ya kadar istediğin değeri verebiliyorsun. Ayrıca sayacı istediğin yerden kesebiliyorsun (PIC16'larda sadece TMR2'de olan özellik). Ya da GPIO'da istediğin pine pullup veya pulldown bağlayabiliyorun, veya open drain yapabiliyorsun. Yeni modellerde biraz daha rahat olsa da özellikle eski PIC'lerde bu çok sıkıntılı idi. DMA'lar da program geliştirmeyi oldukça kolaylaştırıyor (bazı gelişmiş PIC modellerinde var gerçi bu özellik).

4) Debug rahatlığı: STM32'lerde daha hızlı bir şekilde debug yapılabiliyor. Ayrıca sanırım breakpoint sayısı da daha fazla. Eclipse IDE'nin konforuyla birleşince çok daha iyi bir debug deneyimi sunuyor. Tamam, Netbeans IDE tabanlı MPLAB X de çok kötü değildi ama Eclipse tadı vermiyor işte.

5) Programlayıcı fiyatı: ST-Link klonları ile PicKit'leri veya ICD'leri kıyaslayın. Orijinalinin bile fiyatı gayet uygun sayılır.

6) Yüksek performans ve bellek: Aslında çoğu zaman çok yüksek hızlara ihtiyaç olmasa da sonuçta 32 bitlik bir işlemcinin bu konuda sağladığı avantajı göz ardı edemeyiz. Ben PIC kullanırken özellikle RAM'i çabuk bitiriyordum. STM32'ye geçince genel olarak rahatladım. Sanırım AVR'lerin RAM boyutları PIC'lere kıyasla daha iyi.

7) RTOS olanakları: Bugünlerde FreeRTOS'a da geçiş yaptım. Bence büyük ve karmaşık projelerde mutlaka gerekiyor. Tamam, PIC'lerde çalışan RTOS'lar da var ama işlemcinin kapasitesi belli zaten... Özellikle 8 bit işlemciler RTOS için iyi adaylar değil.


Peki STM32'lerin PIC'lere göre hiç mi eksisi yok? Var tabi. Aklıma ilk gelenler şunlar:

1) Proje ilk oluşturma zorluğu: MPLAB X'de çok kolaydı, yeni proje oluştur deyip hemen main() yazmaya başlıyordum. Bir de tabi config bitleri ayarlarını bir header'a koyup projeye ekliyordum, onları da zaten IDE otomatik oluşturuyordu. STM32'de ise HAL ve Cube kullanmadığım için ilk proje oluşturma kısmı zahmetli oluyor. Boş proje oluşturuyorum, CMSIS ve ST headerlarını ekliyorum. Kullanacaksam FreeRTOS'u ekliyorum. Sonra proje ayarlarından tek tek include klasörlerini gösteriyorum. Zaman alıyor.

2) Karmaşık yapı: Evet PIC'lere çok daha karmaşık bir donanımı var ve referans dokümanını uzun uzun okumak gerekiyor. Çok daha fazla register ve bit var öğrenilmesi gereken. Ama bir süre sonra alışıyorsunuz. Ben HAL ve Cube hiç kullanmadan sıfırdan USB kodu bile yazıp çalıştırdım C++ ve FreeRTOS kullanarak. Ama tabi baya zamanımı aldı.

uzun uzadıya cevap verdiğiniz için teşekkür ederim
beni sadece burda cezveden rtos rtos bildiğim kadarı ile yaniş değisem aynı anda birkaç işlem yapabilmesi galiba mcu nun geri kalanlar bir şekilde aşılıyor

[RaMu]

Misal ile açıklayacak olursam:
5 kavanozu 100TL karakavon balının
hakikat bulmuş hali CubeMX + hangi ide hoşuna gidiyorsa o, ben Keil 5.25 kullanıyorum.

Uzun uzatıya dahada ballandırmaya gerek yok.
Kısaca şu ana kadar harcadığın emeğin %5'ini harcayıp 20 katı iş yapıyorsun.
Öğrendiğine hiçbir zaman pişman olmazsın.
Dspic ve altı piclere asm ile kallavi programlar yazmış biri olarak tavsiyemdir.

[Tagli]

@magnetron hocam ben SPL de kullanmıyorum 

Doğrudan register'lara yazıyorum. Gerçi tabi CMSIS var, onun bazı standart fonksiyonlarını kullanıyorum. Sık yaptığım bazı işlemler için ise (pin ayarları gibi) kendi ufak C++ kütüphanelerimi oluşturmaya başladım. Pin ayarları farklı register'lara bölündüğü için derli toplu yazmak zor oluyordu. Gerçi şimdi daha çok yer kaplayıp daha yavaş çalışıyorlar ama pin ayarı genelde başta bir kez yapılır zaten.

FreeRTOS'un AVR portu var. Ama dediğim gibi, ne kadar performans alınır şüpheli. Bir de bence AVR'lerin en büyük sıkıntısı ekonomik bir debug cihazının olmaması. Zamanında bir kez proje yapmam gerekmişti AVR ile. Elimde programlayıcı da yoktu, Arduino Uno'nun içine bir kod atıp programlayıcıya dönüştürmüştüm. Debug imkanı olmadan çok zor oldu ama. Tam anlamıyla kör oluyor insan.

[fay_elektronik]

FreeRTOS'un AVR portu var. Ama dediğim gibi, ne kadar performans alınır şüpheli. Bir de bence AVR'lerin en büyük sıkıntısı ekonomik bir debug cihazının olmaması. Zamanında bir kez proje yapmam gerekmişti AVR ile. Elimde programlayıcı da yoktu, Arduino Uno'nun içine bir kod atıp programlayıcıya dönüştürmüştüm. Debug imkanı olmadan çok zor oldu ama. Tam anlamıyla kör oluyor insan.

genelde pek debug yapmıyorum prototip hazırlayıp üzerinde çalışıyorum olmadı isis in debug unu kullanıyorum yeni teslim ettiğim işi pek isis te debug edemedi 31kb üzerinde kod vardı baya zor oldu hata ayıklaması

Misal ile açıklayacak olursam:
5 kavanozu 100TL karakavon balının
hakikat bulmuş hali CubeMX + hangi ide hoşuna gidiyorsa o, ben Keil 5.25 kullanıyorum.

Uzun uzatıya dahada ballandırmaya gerek yok.
Kısaca şu ana kadar harcadığın emeğin %5'ini harcayıp 20 katı iş yapıyorsun.
Öğrendiğine hiçbir zaman pişman olmazsın.
Dspic ve altı piclere asm ile kallavi programlar yazmış biri olarak tavsiyemdir.

usta işin aslı yeniden kütüphane oluşturmak gözümü korkutuyor avr de yol aldım baya endüstriyel işlerimde beni hiç üzmedi tek sıkıntım mcu bulmak malesef türkiyede mcu su çok az bazen port yetmiyor mecbur port coğullamak zorunda kalıyorum buda bazı işlerde feedback konusunda sıkıntıya sokuyor

[Erol YILMAZ]

Stm32 günümüzde idealdir.
Birçok ihtiyaca kolayca cevap verir. Iyi debug / fiyat vs saglar...

Ögrenip kullanmak lazim.

[fay_elektronik]

Peki ufak tefek işler için stm firmasının düşük pin sayısına sahip işlemcileri yok galiba stm8 ide si farklı bildiğim kadariya

[MC_Skywalker]

STM32F030F4  serisi TSOP20 kılıfta. küçük işler için ideal.

şöyle minik bir kit almıştım Aliexpress ten

[RaMu]

...
usta işin aslı yeniden kütüphane oluşturmak gözümü korkutuyor avr de yol aldım baya endüstriyel işlerimde beni hiç üzmedi tek sıkıntım mcu bulmak malesef türkiyede mcu su çok az bazen port yetmiyor mecbur port coğullamak zorunda kalıyorum buda bazı işlerde feedback konusunda sıkıntıya sokuyor

Onlar dert değil, çok çabuk alışır her şeyi stm ye taşımak istersin zaten.

En azından klon bir stlink ve bluepill al kesinlikle,
3-5 $ tutmuyor.
Sonra niye bu kadar inat etmişim hiç sormaya gerek yokmuş, alıp denesem zaten gönlüm kayarmış der bizi anarsın.

Bunun yanında kütüphanelerini C ile yazdıysan
mümkün olduğunca düzgün şekilde donanımla katman olarak ayırdıysan
o mcu bu ide şu derleyici farketmez
ordan buraya aktarırsın.
Kütüphanesi olmayan deneyeceğim basit şeyleri nerede kütühanesi varsa alıp dönüştürüp deniyorum,
herkes yapıyor bunu.

[kantirici]

@Tagli genel olarak durumu özetlemiş. Cortex-M destekleyen bir mikrodenetleyici günümüz itibariyle Taglinin yazısını genel olarak kapsıyor.

Çevre birimi yapılandırılması için tüm üreticiler artık iyi yada kötü bir alt yapı sunuyorlar. ST için bu CubeMx, renesans için X, atmel için Y. Yani artık girişi nasıl pull-up yapacağım diye datasheet araştırmak yerine iki tıkla GUI üzerinden işler hallediliyor.

Ben burada farklı bir konuya değinmek istiyorum, business-logic (asıl iş) denilen kısım. Burada artık iş C, C++ ve algoritma/programlama bilgimize kalıyor. O halde STM öğrenmek, "ARM" öğrenmek pek bir anlam ifade etmiyor. Odaklanmak gereken yerler C, C++ ve algoritma/programlama olmalı.

Eskiden "gömülü sistem müh. unvanı" çok kullanılırdı/aranırdı. Şimdilerde ise durum "gömülü yazılım müh." olmuş durumda.

[fay_elektronik]

yazılımlarımı c ile yazıyorum cubeide kullandım biraz yorum satırlarını silip cubemx giris cikislari degistirince yazdıgın uygulama siliniyor cubeide nin belirlemiş oldugu yorum satırlararı arasına yazman gerekiyor çok saçma birkaç uygulama ve cubmx hataları yapıp uygulamalar gidince bir an için soğuyup yine avr ye döndüm işin aslı