XC8 PIC16 Serisi Kütüphaneleri Yol Haritası

[sigmoid]

Merhaba arkadaşlar, Uzun aradan sonra bilgisayarıma MPLABX ve XC8 v1.31 kurdum. PIC16 serisi için kütüphaneler olmadığı için kolları sıvayıp hitech'te yazdığım kütüphaneleri eksikliklerinide gidererek xc8 derleyicisine uyarlıyorum. Çalışmam için bir süre belirlemedim. İşten ve evden bu hobi için vakit ayırdıkça kodları aktaracağım. Çalışmalarımı aynı zamanda da kendi sitemde de paylaşacağım. İlk olarak LCD kütüphanesini aktararak başlıyorum. LCD'ye hem 8bit hem de 4bit erişim seçenekleri, RW pini isteğe bağlı olarak ister toprağa ister PIC'e bağlanabilecek. Birçok kütüphanede olmadığı LCD'den veri okuma ve özel karakter oluşturma fonksiyonlarını da eklemeyi düşünüyorum.

XC8'e aktarmayı düşündüğüm kütüphanelerim.
1. LCD kütüphanesi (8bit,4bit)
2. softUSART
3. softI2C
4. softOneWire
5. USART
6. I2C
7. ADC
8. Grafik LCD

Bunlar dışında eklemem gereken tavsiye ettiğiniz kütüphaneler hangileri olabilir?

[t2]

Hiç birini eklemeye gerek yok. bir kütüphaneye ihtiyaç duyarsanız o kendini belli edecek ozaman eklemeniz gerektiğini hemen anlarsınız.

[Gökhan BEKEN]

pwm, spi, i2c eeprom, spi eeprom, grafik lcd olabilir
bunların hazırları da olması lazım microchip tarafından yazılmıştır illaki.

[sigmoid]

Microchip PIC18 ailesi için yazmış. Benim gibi PIC16 ve PIC12 serisinden vazgeçemeyenler için elimdeki kodları revizyondan geçirip xc8'e uygun hale getirmeye çalışıyorum. MikroC veya CCSC kütüphaneleri sayesinde kullanmak güzel hoş ama ansiC özelliğini desteklemediği için birşeyleri eksik gibi geliyor bana.

[serhat1990]

@sigmoid Hocam , bana kalırsa hiç biriyle uğraşmayın. XC8' de herhangi bir program yazacağınızda bu library'lerden herhangi birini kullanmak gerekirse  projenize dahil edin ve derleyin. Programın verdiği hatalar hi-tech c ile xc8 arasındaki uyuşmazlıklar olacaktır. Bunları düzenleyip tekrar derleyin. Sonrasında library xc8'e uygun hale geldi. Vakit kaybınız hiç olmayacaktır diye düşünüyorum , çünkü hi-tech c ile xc8 arasında fark yok denecek kadar az.

İyi çalışmalar dilerim.

[sigmoid]

İlk LCD kütüphanesi hazır. Vakit bulunca birkaç örnek daha eklerim. Sonra sıra diğer kütüphanelere gelir.

[Mr.Java]

MikroC veya CCSC kütüphaneleri sayesinde kullanmak güzel hoş ama ansiC özelliğini desteklemediği için birşeyleri eksik gibi geliyor bana.

Bu CCS C için;
The compiler is very close to being 100% ANSI compatible. It supports everything a PIC compiler needs. It also supports the necessary superset of ANSI C to work with embedded micros, such as fuse and interrupt level support.

http://www.mikroe.com/mikroc/pic/

Sitelere detaylı bakınca desteklendiğini görebilirsiniz.

[sigmoid]

Hepsi öyle diyor. Yazmış olduğun kodu ANSIC destekleyen farklı bir derleyiciye veya mikrodenetleyiciye taşımak zorunda kaldığında ortada kalıyorsun. İkiside ANSIC olduğundan Hitechde yazmış olduğum kodları kolayca xc8'e taşımış oldum. Birkaç ekleme ve kod testti biraz uzun sürdü. Büyük ihtimal diğer kütüphaneleri daha hızlı taşıyabilirim.

[Gökhan BEKEN]

ANSI C'yi desteklemesi CCS C'nin bir halta yaramaması anlamına gelmiyor.
CCS C de yazdığınız programlar CCS C de kalıyor. Başka bir yere taşımanız için kütüphaneleri baştan hazırlamanız gerekiyor.
en basit iş olan led yakma veya buton okumada bile
output_pin(hede); ya da port_hede(bilmemney);
bu şekilde kod yazıldığından, registerler ile işlem yapmak için tek tek register tanımlamak gerektiğinden, uzak durmak lazım.

[Mr.Java]

Sizin bahsettiğiniz konu ile ANSI C arasında bir bağ kuramadım.Anladığım kadarıyla bahsettiğiniz "taşınabilirlik" sorunu kütüphanelerden kaynaklanıyor.CCC C ile taşıyabilirsiniz sanırım çünkü kütüphane dosyaları açık kaynaklı.Fakat MikroC'de durum böyle değil.MikroC dosyaları tamamen kapalı kod.

[Gökhan BEKEN]

Sizin bahsettiğiniz konu ile ANSI C arasında bir bağ kuramadım.Anladığım kadarıyla bahsettiğiniz "taşınabilirlik" sorunu kütüphanelerden kaynaklanıyor.CCC C ile taşıyabilirsiniz sanırım çünkü kütüphane dosyaları açık kaynaklı.Fakat MikroC'de durum böyle değil.MikroC dosyaları tamamen kapalı kod.

Hayır sadece kütüphane taşımakla bitmiyor.
Register kullanabilmek için datasheetten adreslerini bulup eklemek gerekiyor. Derleyicinin yapacağı işi biz mi yapacağız?

[SpeedyX]

Burada 2002 den beri derleyici yarıştırılıp duruluyor hala en iyisini seçen olmadı.

CCS kullanmayalı uzun yıllar oldu, fakat Mr.Java nın dedikleri doğru diyebilirim. Eskiden yaptığım bir çok kütüphaneyi de şu an ARM ve MSP430 işlemcilerde kullanıyorum. Kütüphane yapmayı bilirseniz problem yok.

Adres bilmeden register kullanımı var;

#byte B_PORTU = getenv(SFR:PORTB)
#byte INTCON_REG =getenv(SFR:INTCON)
#bit GLOBAL_INT_ENABLE=getenv(BIT:GIE)
if(getenv(SPI))   /* Kullanılan PIC'te SPI  var mı? */

Ayrıca örnekteki gibi hazır tanım dosyaları da kullanmak mümkün.
http://www.phanderson.com/PIC/PICC/CCS_PCM/defs_f84.html

Şu an IAR da karşılaştığım saçma derleme problemlerini CCS C de görmemiştim.
IAR çok pohpohlanmasına rağmen yüzlerce bug ile geliyor, while(1) ve for(; yada if(x==5 && y==z%2) gibi kodlarda bile yanlış derleme yapabiliyor. CCS bunları yapmıyordu.
TI CCS de ayrı problemli... TI kendisi önermiyor.

Düz mantık düşünürsek üreticinin derleyicisini kullanmak en güzeli ama bazen de değil (örnek: TI), herşeyden önce iş kullanıcıda biter.

[yldzelektronik]

ANSII C hakim olduğum bir konu değil.

Ancak c standartlarına uygunluk derleyiciler arasında taşıma yapmayı sağlayan tek etken değil.Çünkü örneğin her iki derleyici de int ve char türü tanımlarını yapmıştır.

Veya int ve short int.Standarlarda birden fazla ihtimal var.Ya intten küçük olacak yada int ile aynı boyda olacak.Şimdi derleyicinin biri eşit kullanırken diğeri int büyük olarak tanımlarsa her ikisi de standartlara uyar.Ancak farklılık halen sürer.