**CLUB İçerisinde Paylaşım Yaparken Dikkat Edilmesi Gereken Önemli Hususlar.** - Paylaşım yaparken Türkçe kurallarına olabildiğince uyulması, sorunuzun rahat anlaşılması ve en hızlı cevabı almanız adına, dikkat edilmesi gereken en önemli husustur. - Paylaşımlarınız da kibar ve yalın bir dil kullanmanız ve gerekirse resim ile eklenti yapmanız, doğru ve hızlı cevap almak adına önemli hususlardır. - Paylaşımları olabildiğince uygun bölümlere açarak, konu ile ilgili kişilerin daha hızlı görmesini sağlamak adına çok önemlidir. - Paylaşımlarda etiket kullanmak o sorunun daha sonra tekrar aranması adına çok önemlidir.
0 beğenilme 0 beğenilmeme
1,373 kez görüntülendi
Geliştirme Ortamları kategorisinde (290 puan) tarafından
tarafından düzenlendi

Merhaba arkadaşlar,

Birkaç gündür kafamı kurcalayan bir proje fikri var. Malum gömülü yazılım geliştirirken sağlıklı bir test ortamı için kodun çalışacağı PCB'yi bulundurmak gerekiyor. Fakat donanım tarafında oluşabilecek aksaklıklar ve geç iterasyonlar sebebiyle yazılım geliştirme kısmı sekteye uğrayabiliyor.

Bir de uzaktan çalışıyorsanız PCB'nin üretimi, dizginin yapılması ve size gönderilmesi zaman alırken donanımsal bir hata yüzünden işin ortasında tıkanıp kalmanız an meselesi.

Bu sebeple şöyle bir proje düşündüm, yazacağımız kodun test senaryolarını gerçekleyebileceğimiz bir geliştirme ortamı üretebiliriz. Elimize herhangi bir donanım geçmeden bile elektronik şema kurallarını ve davranış biçimlerini burada simüle edebilirsek kodu yazacağımız işlemcinin geliştirme kartı (veya pinout kartı) ile uygulama kodunun tamamına yakınını geliştirebilir ve test edebiliriz.

Eğer senaryoda bir değişiklik olursa bunu da arayüzden kolayca değiştirip yeni test senaryolarıyla devam edebiliriz.

Düzenleme : 23/04/2020

Çalışma diyagramı:
run diagram

Sizin düşünceleriniz nedir bu konuda ?
Böyle bir sistem olsa para verip kullanır mısınız ?

İyi çalışmalar,
Ömer

5 Cevaplar

2 beğenilme 0 beğenilmeme
(180 puan) tarafından

Android işletim sistemli cihazları donanım ve emulatörleri de test aracı olarak düşünebiliriz. Bu durumda MCU lar için böyle bir araç kullanışlı olur. Bu tür araçların çokça eksikliğini hisseden ve mevcut Proteus, Fritzing gibi araçları kullanan biri olarak projeniz için tebrik ederim.

Böyle bir uygulamanın açık kaynak olması harika olurdu :) Böylelikle sizin adınıza çalışacak yüzlerce kişi bulabilirdiniz.

(290 puan) tarafından

Bu konuyu picproje, embeddedrelated , reddit, linkedin gibi birçok mecrada paylaştım. Sonunda işin nasılına takılmayıp sağlayabileceği katma değeri gören bir yorum aldım. Teşekkür ederim.

Kafamdaki iş modeli şu şekilde;

Açık kaynak olmasına katılıyorum. İnsanlar alıp kendi sunucularında özgürce koşturabilmeli, sunucu maliyetlerini göze almayanlar için, bir örneğini kendi sunucularımda koşturup subscription bedeli ile hizmete sunmayı hedefliyorum.

1 beğenilme 0 beğenilmeme
(220 puan) tarafından

Genel geçer bir cihaz olmamakla birlikte yazılan programın donanım üzerinde istenilen şekilde çalıştığının test edilmesi için çeşitli yöntem ve kavramlar var.

Yöntem için 3 anatar kelime; CI(Continuous Delivery), DC(Continuous Integration), TDD(Test Driven Development)

Eğer yazılımınızı TDD'ye uygun şekilde gerçekleştirir ve sunucunuzda CI, CD kurulumlarınız tamamlanırsa her commit otomatik olarak derlenir, hedef cihaza yüklenir ve testler çalıştırılır. Eğer testler esnasında herhangi bir test kalırsa (fail) ilgili rapor mail olarak size gelir ve arayüzden ayrıntılara ulaşabilirsiniz. Ama gömülü sistemler için target(hedef cihaz, kart) üzerinde test yapmak biraz zahmetli olacaktır. Bunu yerine sistemin buissness(donanımdan bağımsız yazılım modülleri) logic kısmını TDD'ye göre yazar ve dual targetting yaparsanız da yeterli olacaktır.

https://software.intel.com/content/www/us/en/develop/blogs/continuous-delivery-embedded-systems-and-simulation.html

(290 puan) tarafından

Anahtar kelimeler ve yorum için teşekkürler.

0 beğenilme 0 beğenilmeme
(1,140 puan) tarafından

Esen olsun.

Ne demek istediğinizi tam anlamamış olmakla beraber, sizin bu isteğinizi karşılayan çözümler zaten piyasada bulunmaktadır.
Yani geliştirme kartları.
Geliştirme kartları üzerinde istediğiniz gibi oynayabiliyorsunuz.
Ancak siz daha kapsamlı (generic) bir çözüm arıyorsanız, yani çapraz-donanım çalışacak bir deneme ortamı, o zaman ona özel bir çerçeve (framework) ya da işletim düzeni geliştirilmesi gerekir.
Konuyu yanlış anlamış olabilirim.

Esenle kalın, saygılarımla...

(290 puan) tarafından

Merhaba,
Cevabınız için teşekkür ederim.

Doğru, geliştirme kartlarımız var. Fakat PCB deki fonksiyonları üretmek için geliştirme kartı ile bir takım kurulum yapmamız gerekiyor. Bazen pasif komponentler yetersiz kalabiliyor.

Örnek bir senaryo ile açıklamaya çalışayım.

Diyelim ki, bir projede işlemcinizdeki P1 pinini yukarı çektiğinizde bir DC motor çalışacak ve bu motor bir potansiyometreyi döndürecek. Potansiyometre 30° açısından başlıyor 150° dereceye geldiğinde P1 i aşağı çekip motoru durdurmanız gerekiyor. Sistemde bir takım dişliler var ve potansiyometre 30° den 150° ye 40 saniyede gelecek şekilde tasarlandı. İşlem tamamlanınca da pot bilgisini başka bir birime UART ile göndereceğiz.

Şimdi burada uygulama kodunu yazmak istiyorsak, geliştirme kartının etrafına spesifik bir donanım kurulumu yapmamız ve pin yukarı çekildiğinde potansiyometrenin dönmesini simüle edip UART bilgisinin doğru formatta iletildiğinden emin olmak durumundayız. Ve eğer proje isterlerinde bir değişiklik olursa kurulumumuzu tekrar gözden geçirmek durumundayız.

Bunun yerine şöyle bir çözüm sunuyorum, internete bağlı bir emülatör işlemcimiz olduğunu düşünün, bilgisayarda bir arayüz üzerinden test senaryolarımızı yazıyoruz ve sonrasında bu senaryolar bir sunucuda test koduna dönüştürülüp emülatör işlemcimize gönderiliyor. Sonrasında uygulamayı yazdığımız hedef işlemciyi emülatör işlemciye bağlayıp kodumuzu yazıyor, hızlı bir şekilde test ve iterasyon yapabiliyoruz.

Eğer senaryoda bir değişiklik olursa bunu da arayüzden kolayca değiştirip yeni test senaryolarıyla devam ediyoruz.

(1,140 puan) tarafından

Esen olsun.

Ne demek istediğinizi şimdi daha iyi anladım.

Yukarıdaki gibi durumlarda, bir tane daha geliştirme kartınız olmalıdır.
Ancak bu geliştirme kartında ek donanımlara gereksiniminiz olmayacak.
Bu ek kartın, bütün IO pinleri kullanılabilir durumda olmalıdır.
Ek geliştirme kartının pinlerini, normal geliştirme kartının gerekli pinlerine bağlayıp, istediğiniz gibi bir benzetim yapabilirsiniz.
Yukarıdaki gibi bir senaryoyu yerine getirecek olan kodu yazıp, ek geliştirme kartına yüklerseniz sorun çözülür.
Böylelikle ek donanım (motor, potansiyometre vb.) geliştirmesi yapmak zorunda kalmamış olursunuz.
Ek donanımın işlevlerini yerine getirecek kodları çalıştıran bir MCU ile sorunu çözmüş olursunuz.

Esenle kalın, saygılarımla...

(290 puan) tarafından

Evet anlatmak istediğim tam da bu şekilde bir test ortamı, fiziksel bir emülatör işlemci ile tüm test senaryolarını gerçekleştirmek.

Uygulama diyagramını gönderiye ekledim.

Sorum şu :

Böyle bir ürüne siz kendi geliştirme ortamınızda ihityaç duyuyor musunuz ? böyle bir ürün olsa satın alıp kullanır mısınız ?

İyi çalışmalar dilerim.

(1,140 puan) tarafından
tarafından düzenlendi

Esen olsun.

Böyle bir deneme cihazını, ticari ürünler geliştirenler elbette almak isteyecektir.
Ancak çoğu dizi üretim yapan firma, bir şekilde kendi çözümlerini geliştiriyorlardır.
Düşünsenize, her ay yüzlerce ya da binlerce modül üretip satıyorsunuz.
O kadar çok modülü tek tek el ile denemek ne kadar maliyetli olur?
O yüzden öyle bir durumda, üretilen modülü deneyecek olan bir donanım daha geliştirilip, bütün modülleri tek tek o cihaza bağlayıp deneme yapılır.

Böyle bir proje geliştirilecek ise oldukça kapsamlı olması gerekir.
Bilgisayar üzerinde hızlıca bir senaryo oluşturabileceğiniz bir arayüz uygulaması geliştirilmelidir.
Çoğu donanımı (MCU) desteklemelidir.
Bu bahsettiğim arayüz uygulaması, aşağıdaki örnekler gibi olabilir;

Scratch (mBlock)

Blockly@rduino

Esenle kalın, saygılarımla...

0 beğenilme 0 beğenilmeme
(4,270 puan) tarafından

Uzunca bir süre kodlarla, mcularlar uğraştım. İlk başlarda proteus, oshonsoft gibi benzetim araçlarıyla çalışmak daha efektif geliyordu. Sonradan aslında bunların bana daha fazla zarar verdiğini, illaki PCB donanım kısmında problemler yaşadığımı gördüm.
Bu yüzden herhangi bir benzetim programı kullanmıyorum. Önce starterkit/discoveryboard vb ile yazılımı, sonrasında pcb ve donanım gerçekleşmesiyle donanım+yazılımı test ediyorum.

(290 puan) tarafından

Anladım, öncelikle şunu belirtmek isterim burada yazılımsal bir emülatörden farklı olarak fiziksel bir emülatörden bahsediyorum. (hibrit de olabilir tabi), konsept grafiğini konuya ekledim.

Burada bahsettiğim ürün/konsept, geliştirme kartı (starterkit/discoveryboard) ile geçirdiğiniz süreci iyileştirmeye yönelik. Yani geliştirme kartı ile yazdığınız kodu test ederken fiziksel bir test düzeni kurmanız gerekiyorsa amaç bu zahmeti minimuma indirgemek ve farklı test senaryolarını hızlı bir şekilde uygulamanızı sağlamak.

İyi çalışmalar dilerim,
Ömer

0 beğenilme 0 beğenilmeme
(3,790 puan) tarafından

Gomulu sistemlerden ziyade tum platformlarda kullanilabilen Jenkins diye bir tool var. Ne yapar bu Jenkins,

1- Client bir makinede kodunuzu sizin verdiginiz komutlar ile derler ve derleme ciktilarini kayit altina alir.
2- Diyelim ki kodunuzu github veya kendi git serverinizda tutuyorsunuz

  • Her gelen committe ustteki islemi yapar boylelikle kodun Jenkins clientinizda derlenebilen konfigurasyonda oldugunu yani sizin makinenize ozel bir path tutmadigini gorursunuz.
  • Eger scriptlerinizi dogru duzenlerseniz clienta bagli bir cihazla teste tabi tutabilirsiniz. Boylelikle her commit \degisiklik otomatik teste tabii tutulmus olur.
...