Bilmediğim MCU'yu kullanmak

[mr.engineer]

Merhaba, ST veya TI veya PIC gibi yaygın olan MCU'lar dışında bir MCU kullandığınızda nasıl programlamayı tercih ediyorsunuz? Genellikle üreticinin sağladığı örnekler, demo projeler dışında internette pek bir şey bulunmuyor. SiliconLabs'e ait bir MCU yu kullanmaya çalıştım. Sadece ADC, GPIO, Timer vs. bakıyorum. ST'dekine benzer SPL tarzında bir kütüphanesi var fakat dökümantasyonda 1000 tane fonksiyon vermişler. Biraz gelişmiş bir MCU çevre birimleri için fazla fonksiyon var. ST'de de SPL'i hiç sevmemiştim zaten:) Bunlara bakmak bir yerden sonra çok sıkıyor bir de tabi datasheet de bakmak gerekiyor. CubeMx veya MCC tarzı düzgün bir code generation sistemi de yok.
En sonunda döküman bakmak yerine direk register'ları açıp register seviyesinde kodlamaya başladım. Acaba yanlış bir yol mu izliyorum? Tecrübeli büyüklerimiz bu gibi durumlarda (bilmediğiniz bir üreticinin dünyasında) nasıl yol izliyor acaba merak ettim.

[Tagli]

En sonunda döküman bakmak yerine direk register'ları açıp register seviyesinde kodlamaya başladım.

Bence en doğrusunu yapmışsın. Gerçi benim PIC ve STM32 dışında bir işlemci ile deneyimim yok 

Ben C++ ve FreeRTOS kullanmaya başladıktan sonra donanımın etrafına ufak wrapper class'lar yazmaya başladım. Gerçi henüz tam donanım bağımsızlığı sağlamadı ama yine de bir derece faydası oldu. Sarmalama işlemi yeterince iyi yapılırsa eğer, projelerin işlemciler arasında taşınması kolaylaşacaktır. Şimdilik STM32 aileleri arasındaki geçişlerde (F0, F1, F4) bu konuda kısmi bir başarı sağlayabildim. Yine de elbette işlemci dokümanını okuyup donanımlar arasındaki farklara hakim olmak gerekiyor.

[mustafacan]

Merhaba, ST veya TI veya PIC gibi yaygın olan MCU'lar dışında bir MCU kullandığınızda nasıl programlamayı tercih ediyorsunuz? Genellikle üreticinin sağladığı örnekler, demo projeler dışında internette pek bir şey bulunmuyor. SiliconLabs'e ait bir MCU yu kullanmaya çalıştım. Sadece ADC, GPIO, Timer vs. bakıyorum. ST'dekine benzer SPL tarzında bir kütüphanesi var fakat dökümantasyonda 1000 tane fonksiyon vermişler. Biraz gelişmiş bir MCU çevre birimleri için fazla fonksiyon var. ST'de de SPL'i hiç sevmemiştim zaten:) Bunlara bakmak bir yerden sonra çok sıkıyor bir de tabi datasheet de bakmak gerekiyor. CubeMx veya MCC tarzı düzgün bir code generation sistemi de yok.
En sonunda döküman bakmak yerine direk register'ları açıp register seviyesinde kodlamaya başladım. Acaba yanlış bir yol mu izliyorum? Tecrübeli büyüklerimiz bu gibi durumlarda (bilmediğiniz bir üreticinin dünyasında) nasıl yol izliyor acaba merak ettim.

Şu işlemci bu programlayıcı o dil bu yol...
hiçbirinin önemi yok.
Amacınızı yerine getiren en basit çözümleri gerçekleştirin.

Bu konudaki en büyük tecrübe şudur;
Araçların önemi yok
Amaca başarıyla ulaşmak.

[Tagli]

@mustafacan 'ın dediklerinde katıldığım ve katılmadığım noktalar var.

İşlemci ve dil seçiminde mevcut duruma en uygun olan seçilir. Bu noktada fanatiklikten uzak durmak lazım. Ancak yine de belli bir dile veya işlemciye olan aşinalık ve bunlara yönelik olarak elde daha önceden hazır olan yazılım kütüphaneleri ve metodolojilerin bulunması bu tercihlerde etkilidir.

Örneğin ben C++ ve FreeRTOS kullanarak epey bir sorunumu çözmüşsem, yeni bir işlemciye geçerken bu ikiliyi destekleyen bir ürün ararım. Bunların olmamasını bir eksi olarak değerlendiririm. Ama tabi ki de bu tek etken değil. Mesela adetli ve basit bir proje var ve işi yapabilecek çok ucuza bir PIC modeli buldum. O zaman bu artısı, alıştığım altyapıyı desteklemiyor oluşu eksisine karşı ağır basabilir.

Amacınızı yerine getiren en basit çözümleri gerçekleştirin.

Bu noktada dikkatli olmak lazım. Bugün en basit ve hızlı olan çözüm yarın başınıza iş açabilir. Amacı iyi tanımlamak gerekli. Uzun vadede sorun çıkarmayacak ve gerektiğinde geliştirilebilir ve sorun çıkardığında kolaylıkla onarılabilir bir proje yapmayı amaçlamışsanız eğer, en basit ve hızlı çözüm doğru yol olmayabilir. Yani her ne iş yapılırsa yapılsın, amaç ve başarının tanımları önemli. Ve bunlar her projeye göre ayrı tanımlanabilir.

Konuyu biraz dağıttık korkarım...