Forum: Duyurular RSS
siPIC-D: Başlıyor...
D için PIC benzetimi ve yorumlayıcısı
Avatar
Salih Dinçer #1
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Konu adı: siPIC-D: Başlıyor...
Merhaba,

Üniversitede, 2001 yılında PIC'ler ile tanışmıştım. O zaman piyasada çok fazla benzetim (simulation) yazılımları yoktu. Hatta üst seviye diller ile programlama yapmak için bir elin parmaklarını geçmeyen kabuk derleyiciler vardı. Şimdi artık Linux dahil her platformda kolay mikrodenetleyici uygulamaları yapabiliyoruz.

D dili genç ve şeffaf olması yanında yaşlı benzerleri göre (yamalı ve şişman bohçalar) etraflıca düşünülerek oluşturulmuş mükemmele giden bir programlama dili. Her ne kadar zamanla emekliye ayrılan (deprecated) bölümleri olsa da bunlar D'yi geliştirmekten öte, eskilerden yapışmış kayaları atarak adeta koltukları altında gelecek için yer açıyor. Attığı kaya yerine de aynı işlevi görecek küçük taşlar koyuyor. Hatta çekirdeğe dahil ederek sık kullandığı cebine alıyor. Hal böyle olunca gelecek vaadeden bir dil olmaya yolunda emin adımlarla ilerliyor.

İşte zamanında üniversitede, Delphi ile başladığım elektronik projesini, tıpkı D gibi emin adımlar ile ilerleyen bir biçimde yeniden başlamak istiyorum. Henüz mimariye tam olarak karar vermedim çünkü bilmediğim çok şey var. Ancak bunlar çekirdek (core) yapıyı kurma ve gözde (poplarity) mikrodenetleyicilerin yapısını kodlara dökmeye engel değil. Zaten 16 bitlik SFR yapısını struct ve benzeri veri yapılarını kullanarak meydana getirmek bile bütün bir ayımı alabilir. Yine yol planım kısaca şöyle:

? Mimariyi tasarlamak (RISC ile en iyi haberleşecek çerçeve)
- Çekirdek yapıyı kurmak (16 bit komut seti uyumlu)
- Gerçek zamanlı hafıza yansısı ve hata ayıklayıcı (Debugger)
- Başlık dosyalarını oluşturmak (18F ailesinden başlayarak)
- Benzerim arabirimine başlamak (Simulation GUI)
- D'yi daha çok temsil eden assembly kod parçalarını arttırmak
- Basitten karmaşığa proje örneklerini geliştirmek (Tutorial)
- Geriye uyumluluk (16F ailesi ve sadece 35 komut için)
- Gerçeğe uyumluluk (Fiziksel benzerlik testleri ile)

Dip Not: Her türlü öneri ve desteğe açığım.

İlginize teşekkür ederim...
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
Bu mesaj Salih Dinçer tarafından değiştirildi; zaman: 2012-03-01, 07:33.
Avatar
Salih Dinçer #2
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Bugün çerçeveye (MVC) karar verdim sanırım bir haftadır düşünüyorum...:)

Çok aptal değilim ama mükemmeliyetçi bir yapım var herhalde. Dolayısıyla, kuramsal açıdan ilk maddedeki soru işaretini kaldırıyorum. Uygulamaya dökmeme az kaldı ve zannedersem yapının özelliği gereği beni yarı yolda bırakmayacak. Çekirdek yapı içinde hazırlıklarım tamam ve zaten yukarıda listelediğim bir çok maddeye kısmen çekirdek tasarlanırken başlamış olacağım. Birbiriyle ilintili çok şey var; örneğin:

stdout akımıyla uyumlu bir yapı kurdum, write() ile çıkışa veri gönderirken PIC'in bitlerine çeşitli şekillerde (writeport, writeserial veya writestream gibi) alt yordamlar da yapılacak. Tabi bir yandan da çıkış E²PROM olacağı zaman, çekirdeki bekletme (zamanla alt yordamını) geliştirmeliyim ya da çekirdek dışında bir alt yordam oluşturmalıyım. Belki benzetim (simulation) sırasında zamanın hiç bir önemi olmayacak ve/veya hızlandırılıp azaltılabilecek. Ancak PIC ile gerçek zamanlı (-bknz. yol planı, son madde) ve %100 uyumlu olması da gerekiyor. Yoksa yüklenecek HEX kodları saat frekansı ile uyumlu olmayacak ve belki de en çok seri haberleşmede sorun çıkaracak.

Şimdilik bu haftanın notları bu kadar...
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
Avatar
Salih Dinçer #3
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Bu projeyi rafdan indiriyorum çünkü işlerim dolayısıyla rafa kaldırmıştım...

Aslında hala düşünüyorum, çünkü gerek derlenmiş HEX koduyla çalışan, gerekse C kodunu derlemeden PIC üzerinde gösteren (örn. Proteus gibi) yazılımlar var. O yüzden raftan inerken evrim geçirmiş bir şekilde masaya koyabilirim...:)

Bir kaç gündür şuna karar vermeye çalışıyorum:

Acaba bir 'emulator'den önce 'micro kernel' mı üretsem? Yani alıştığımız D ile elektronik projeleri geliştirebileceğimiz, sonra bunları assembly koduna çeviren bir şey düşünüyorum. Ancak kısıtlı belleğini (RAM) iyi şekilde kullanabilmek için bir kernel'a ihtiyaç var sanki.

Yani en basitten 'new' ile bir sınıf oluşturduk (örn. USB Buffer Stack*) ve onun içerisindeki üyeler için hafızadan bir alan tahsis edilmesi gerekecek. Ancak PIC içerisine gömülen yazılım derlendiği için önceden tüm bellek bir yazılım tarafında 'reserved' yapılmalı. Aksi halde çalışma anında bir sınıf kurup, sonra belleği daha etkin kullanabilmek için sınıfı imha edip başka bir sınıf kurabilmeliyiz. Bildiğim kadarıyla piyasadaki diller OOP mantığı ile çalışmıyorlar. Bu ilk olabilir...

(*) Örnek senaryo şu:

Farz edelim USB üzerinden veri alan bir PIC projesi var. Veri büyük ve işlenmeden önce bir yığında biriktirilmeli. Hardstack, bunun için yeterli olamayacağına göre basit bir yığın sınıfı kurulur, veri biriktirilir ve işlenir. Ham ve işlenen veri hala hafızada yer kaplıyordur. Yığın sınıfı imha edilir. Böylece başka bir sınıf (örn. LCD Print) hafızada yer açılır.

Çözüm: Memory Manager
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
Doğrulama Kodu: VeriCode Lütfen resimde gördüğünüz doğrulama kodunu girin:
İfadeler: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Özel Karakterler:
Forum: Duyurular RSS
Bağlı değilsiniz. · Şifremi unuttum · ÜYELİK
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Şu an: 2017-11-23, 23:37:22 (UTC -08:00)