Ama medium ve high byte'ların hesabında sağa bit kaydırma yapılıyor. Bunlar matematiksel olarak 2^8 ve 2^16'ya bölme işlemine tekabül ediyor. Anladığım kadarıyla hardware multiplier sadece integer'ları çarparken işe yarıyor. Bölme işleminde kullanamıyoruz. |
Mcu nun komut setinde sola veya sağa bit kaydırma (Rotate Left ve Rotate Right) komutları var. Fakat bu mcu 8 bitlik olduğu için, buradaki 1 cpu zamanı 8 bitlik değişkenler üzerinde işlem yapıldığında geçerli. Sizin örnekdeki eeprom adresini tuttuğunuz değişken gibi 16 bitlik veya 32 bitlik bir değişkenin bitlerini sağa veya sola kaydırmak istediğinizde bu daha fazla cpu zamanına mal olacaktır çünkü aynı anda sadece 8 bit üzerinde işlem yapma kapasitesine sahip. Bu durumda adres değişkeni içerisindeki byte lara erişmek için pointer kullanmak daha hızlı bir yöntem olacaktır. 8 e veya 16 ya bölme işlemlerinde derleyicinin Rotate komut setlerini kullanması beklenir. (Ondalık / floating point çarpma ve bölme işlemleri farklı bir konu) Birde hız herşey demek değildir, yerine göre bir işlemin 10us de bitmesi ile 80us de bitmesi çokda önemli değildir, fakat aradaki farkları bilmek ve gerekli olduğu zamanlarda doğru yöntemi tercih edebilmek önemli / avantajlı hale gelecektir. < Resime gitmek için tıklayın > Not: Doğrudan assembler yazmıyorsanız, araya kullandığınız compiler ve onun ayarları, optimizasyon yetenekleri devreye girecektir. Çıkan makine kodu ve performansı değişecektir. Assemblerde yazdığınız kodlar gördüğünüz şekilde işlenecektir. İyi yazdıysanız iyi, kötü yazdıysanız kötü performansda çalışacaktır. Derleyici farkına örnek olaması açısından, geçmişte elimdeki mcunun bir pininden aşağıdaki gibi basit bir kod ile kaç Hz sinyal alabilirim diye test yapmıştım. pseudo code while(1) { pin1 = H; pin1 = L; } Aynı kod aynı mcu, aynı configrasyonda çalıştırıldığında Derleyici 1 : 1.2 Mhz Derleyici 2 : 6.0 Mhz C ile kodlama yapıyorsanız kullandığınız derleyicinin kabiliyetlerine ve optimizasyon seçimlerine göz atmanızda fayda var. |
Teşekkürler. MPLAB IDE üzerinde C18 C Compiler'ını kullanıyorum. Programdan aldığım hafıza kullanım görüntüsü, sağdaki data memory yazan bölüm ağzına kadar dolu şu anda. < Resime gitmek için tıklayın > Şu anda test etmeye hazır bir hex üretmeyi başardım. AddrExtEE fonksiyonunda arka arkaya üç adet if kullandım. Bunun yerine switch case kullansam daha mı olurdu? https://drive.google.com/file/d/1y9LSFFje1e4tEY6b-C0LzeERDQc587vY/view?usp=drive_link |
if(deger == kosul1) { // yapılacaklar } else if deger == kosul2) { // yapılacaklar } else if (deger == kosul3) { // yapılacaklar } şeklinde bir kullanım ile switch case kullanım arasında bir fark yok. Kod okuma kolaylığı açısından hangisi sizin kolayınıza geliyorsa onu kullanın. 3 adımlı karşılaştırma çok uzun değil onun için fark etmez ama çok uzun karşılaştırmalarda switch case yapısınını kullanmayı tercih diyorum. if(deger == kosul1) { // yapılacaklar return; } if deger == kosul2) { // yapılacaklar return; } if (deger == kosul3) { // yapılacaklar return; } bu tarz bir kullanımda (else if yapısını kullanmıyorsanız) koşul1 sağlandığında diğer durumları kontrol etmesine gerek kalmadan alt programdan çıkacaktır. Koşulların durumuna göre bir nebze performans kazancınız olur ama sizin projenizde aradaki farkı fark etmezsiniz :) Bu durumda en çok sorguladığınız koşulu en başdaki if yapısına almak mantıklı olacaktır. Her seferinde 3 koşuluda sorguluyorsanız, koşulların sırasının bir önemi yok. |
Teşekkürler. Burada return nereye dönüyor?
Anladım galiba. AddrExtEE fonksiyonunda ilk ifte bulduğu değeri döndürüp, AddrExtEE'den çıkıyor. Diğer iflere bakmıyor. |
Altprogramdan çıkmaya yarıyor. Aşağısındaki kodlar çalışmıyor. |
PICkit2'ye winbond SPI flash bağladım. Pk2go ile PIC18F2455'e hex atmaya çalışarak ilk denemelerimi yaptım. Bir yerler çalışmıyor. Butona bastıktan kısa bir süre sonra busy üçlü atımlar halinde yanıp sönmeye başlıyor. İlk şüphelendiğim yer silme rutini. Daha önce SPI flashlar ile çalıştığım için biliyorum. Flashların dahili silme prosesi en az 5 10 saniye süren bir işlem. Ama hex dosyasını gönderip sonraki sayfada download yapınca hemen işlem tamamlandı PICkit2'yi çıkarın diyor. Normalde en az 5 10 saniye sürmesi gereken işlem 1 saniye bile sürmüyor. Kullandığım SPI flash'ı çıkarıp dışarda okuttuğumda içerisindeki eski verilerin silinmemiş olduğunu gördüm. < Resime gitmek için tıklayın > Videoyu izlemek için tıklayınız Olağan şüphelilerden biri de TXS0108E lojik seviye dönüştürücü. SPI flash 3.3v olduğu için 5V'a çevirmek için araya dönüştürücü atmak gerek. |
Adım adım hatayı arayın bence. İçine silmeyi test edeceğiniz bir kod ekleyin. Pc yazılımı ile uğraşmadan silme işleminden emin olun. Sonra diğer aşamalara geçersiniz. Evet dediğiniz gibi bende yanlış hatırlamıyorsam 25QXX serilerinde silme işlemi 5-10 saniye kadar zaman alabiliyor. TXS0108E dokümanı pusp-pull ve open-drain çalışmada hız farklılığından bahsediyor. Bir kontrol etmenizde fayda var. 1.2mbit yavaş kalıyor olabilir. |
Son anda bir şeyi fark ettim. TXS0108E'nin OE pini yüksekken çalışıyormuş. Normalde OE pinleri active low olur. Böyle olmasına alışkınızdır. Ben de bu şekilde düşünüp OE'yi gnd'ye bağlamıştım. Bu nedenle modül iletim yapmıyormuş. Datasheeti dikkatli inceleyince jeton düştü. Burayı düzelttim. TXS0108E'yi dışarda test ettim, çalışıyor. Txs0108e push-pull modunda 100mb'lere kadar çıkabiliyormuş. Ama genel sorun halen devam ediyor. Bu sefer seviye dönüşümünü gerilim bölücü ile yapacağım. PIC'e giren hatta da tekli tristate buffer koyacağım sadece. Ekleme: Diğer PICkit2'nin lojik tool'u ile test PICkit2'sinin SPI sinyallerini yakalamaya çalıştım. Hiç bir sinyal göremedim. Özellikle Download to PICkit2 aşamasında bir sinyal almam gerekirdi. EEEPROM çıkışlarında sinyal yok. Neden böyle oldu? |
Üstadım özel mesaj gönderdiniz ama benim özel mesajlari okuma ve cevap verme yetkim kapali. Sakıncası yoksa konu içerisinden veya yeni konu açarak devam edebiliriz |
Pk3 devre kartının önlü arkalı net resmini gönderebilir misin? Onun da klonunu yapmak istiyorum. Kart üzerinde çok fazla parça olduğundan, eleman dizimi konusunda orjinal karttan kopya çekmek istiyorum. Özellikle arka yüzü önemli, şemadaki bazı parçalar ön tarafta görünmüyor, muhtemelen arka taraftalar. |
Teşekkürler. Detaylı yakın çekim resimler de atarsan güzel olur. Bir de hafıza çiplerinin kodları şemada yazmıyor. Onları da paylaşabilir misin? |
< Resime gitmek için tıklayın > Bu kadar yapabildim. |
Type-C düşünebilirim, ama bacak arası çok dar olduğu için elde lehimlemesi zor olur. Daha birtakım eksiklikler var gibi. Onları da tamamlamam lazım. |
Hocam siz ikisini de kullanmış adamsınız. PICkit™2 ile PICkit™3 (MPLAB olmayan) arasında hız ve genel performans olarak fark var mı? PICkit™3'te target LED'ini kaldırmışlar. Onu geri eklemeyi düşünüyorum. |
Uzun zamandır microchip ürünleri ile pek işim olmuyor ama, elimde her iki programlayıcıda çok uzun zamandır var. Elim sürekli Pickit2 ye gidiyor(du), desteklediği işlemcilerde bana görer daha pratik (yazılım yükleme ve seri debug ekranı). Sanırım v3 de seriport debug kısmı yok diye hatırlıyorum. V2 deki seri debug ekranını zamanında çok fazla kullandım. Harici bir seriport dönüştürücüye gerek kalmadan geliştirme aşamasında bazı durumları "print" edip sonucu zahmetsiz görmek büyük kolaylık sağlıyordu. Birkaç projede pickit2 nin desteklemediği mcular ile işim olmuştu o zamanlarda v3 ü kullandım. (V2 nin device list dosyası editlenip yeni mcu eklenebiliyor, bir iki sefer yaptım sonra uğraşmamak için v3 temin ettim) V3 ü ilk zamanlar mplab arayüzü ile kullandım, sanırım ondan dolayı bir ön yargı oluştu, sonradan pickit2 yazılımına benzer bir tool geliştirmişler ona geçtim, ama microchip ile işim olunca hemen "siyah" olana elim gidiyor ![]() Bende hala v2 favori :) Her iki programlayıcıda led sayıları ve konumları aynı ama kapak üzerindeki isimlendirmeleri farklı V2 led > V3 led Power > Power Target > Active Busy > Status |
Çok birşey kaybetmiş değilsiniz aslında. Alışkanlıkdanmıdır yazılımının kolay ve hızlı kullanılmasındanmıdır pickit2 yi daha çok tercih ediyorum. Diğeri pickit2 nin desteklemediği (device list dosyasını düzenleyerek eklemek bir yöntem ama her zaman için optimum yöntem olmuyor) bazı mcular olduğunda arada bir kullanıyorum.
Evet hardware multiplier den bahsediyoruz ama yukarıdaki mesajda hatalı ifade ettim (o mesajı yazarken 32bit arm mimarisi gibi düşündüm bir an için). 1 cycle de çarpma işlemini 8 bitlik işaretsiz sayılarda yapabiliyor. Aşağıdaki tablo çarpma işleminin donanımsal olup olmamasının ROM ve cpu zamanı kullanımı açısından karşılaştırmasını veriyor. Tablo 18f2550 nin pdf inden alındı.
Tablonun ilk satırı için unsigned 8 bit işlemlerde 26byte (13 word) daha az ROM kullanıyor ve 69 kat daha hızlı işlemi sonuçlandırıyor.
Diğer veri tipleri için tabloya aynı mantıkla bakabilirsiniz.
< Resime gitmek için tıklayın >
Bu mesaja 1 cevap geldi. Cevapları Gizle