sonraki »

[Skate]

@delimawi: diyorsun ki byte'ı sıralı getirtmem. bit pairler halinde gelen bitleri bir buffer'a shift ede ede yolumu bulurum.

[i_r_on]

Burada amaç asenkron bir byte transferini optimize etmek. Microcontroller tarafı da hesaba katılmaya çalışılırsa işler karışır. Atmega328'in realtime hassasiyeti ile sallıyorum esp8266'nın yahut başka bir kontrolcünün hassasiyeti farklı olacaktır.

Kodu asenkron çalışmaya müsait yazıp senkronu sağlayan bekleme noktalarını ihmal etmek gerekiyor.

Ben bu şekilde bir rutini mesela önce yüksek bekleme süreleri ile deniyorum. Tatlı noktayı bulacak delay değerleri ile sonra uğraşıyorum. Burada amaç o tatlı değerlerin 0 olduğunu kabul etme üzerine. Ama kod asenkron transfer düşünülerek yazılacak.

Nmi senkronizasyonu ile mesela bir byte transferi page sınırları içinde 38 cycle civarı. Page aşılınca bunun biraz üstüne  çıkıyor. Ekstra sinyal kullanıldığı için daha hızlı olacağı düşünülebilir ancak interrupt'a girip çıkmanın da bir overhead'i var. Bu sorunun cevabı biraz da bunu bulacak.

[i_r_on]

@delimawi : Senkron transfer söz konusu değil. Ama dersin ki, benim gönderdiğim data öyle encode edilmiş ki senkronizasyona ihtiyacı yok. Ben işlem yapıp ayıklayacağım. O olur.

Bu durumda da yine her bir burst için tatlı bir senkronizasyon gerekecektir ancak buffer bazlı asenkron denebilir.

[Skate]

@i_r_on, peki kodun uzunluğunu geçtim, memory usage limitimiz nedir? $0800-f7ff dışındaki hafızaya müdahele edebiliyor muyuz istediğimiz gibi? kod yine 128 bytedan kısa olacak ama ek hafıza kullanacak. uygundur di mi?

[eins]

Kodu yazmadım ama algoritma şu şekilde. Olur dersen yazacağım.

bekle:
Port değişti mi?
Hayır, goto bekle

decode_sign++

Port 0 mı? Evet, goto bekle

deger=port xor decode_sign
goto bekle


Bu kodda amaç şu: uC her seferinde bir önceki byte'tan farklı bir deger göndermeli. Bu ayede receiver asenkron olarak yeni byte geldiğini anlıyor. Şöyleki decode_sign diye bir sayaç var. Bu iki tarafta da var ve 0 ile başlayıp gönderilen her byte için 1 artıyor. Gönderilen veri bu sayaç ile xorlanıp gönderiliyor. Öneğin arka arkaya 0 gönderilecek ise bile xorlanan deger değiştirildiğinden her seferinde byte değişiyor.

Püf nokta da şu, uC eğer yeni hesapladığı xorlanmış veri bir önceki ile aynı ise, ki olabilir, bir adet 0 gönderiyor. REceiver 0 görünce bunu discard ediyor, ama counter arttırılıyor, bir sonraki transferde xorlanmış değer artık 0 olamaz...

Son olarak ya gerçekten xorlanmış değer 0 ise ne olacak. Aynı mantık, uC 0 göndericek ama bir sonraki byte için tekrar aynı veriyi gönderecek bu sefer başka bir değer ile xorlanacağından 0 dışında bir değer elde edilecek.

Şimdi istatistik olarak tamamen aynı değeri içeren 256 byte transfer edilse, hiç bir xorlanmış değer bir önceki ile aynı olmayacak ancak bir adet 0 değer için ekstra bir byte gönderilecek. Yani kayıp oranı 1/256 ...

Eğer 1,2,3,4 ... şeklinde sıralı bilgi gönderilecek olsa sanki tamamı yeniden gönderilecek gibi geliyor ama ilk çakışmada xor counter değeri ile data pointer senkronu bozulmuş olacağından, sadece 1 adet tekrar veri + 0 için bir adet gönderim, 2/256 oluyor.

Bence verimli.

[i_r_on]

@skate : İstediği kadar ram kullanabilir. Bir kısıt yok. 128 byte sınırı da öylemesine konulmuş bir sınır. Daha fazlasına daha hızlı bir çözüm varsa duymak isterim.

@delimawi : Evet bu çözüm olur

[Skate]

Ancak benim anladığım porta bit bit yazıldığından bir atomic time problemi var burada. XOR ile gönderilen datada bu çözülmüş oluyor mu? Okunan değerde bir bit değişti ancak henüz diğer bitler değişmedi durumu yani.

Edit: Bunu i_r_on'ın "port tam set edilmemişken erişme durumunu bertaraf etmek için bir daha okuyoruz." commentinden çıkarım yaparak yazdım.

[eins]

Aslında atomik ama gene de onu iron ikinci kez okuyarak çözmüş.
Bir bit bile değişse, port değişti/değişiyor demek. Tetiklenmek için yeterli.
İkinci okumada zaten net değeri alıyorsun.

[Skate]

Anladım, sonuçta yine 2. kez okuyorsun yani. Ok.

[eins]

O kısma takılmayın demiş ya. Yani aslında örneğin benim kullandığım pic mikrolarda 8 bit birden aynı anda değişir. Ama böyle olmak zorunda değil. Misal donanım gereksinimlerinden ötürü 8 bit bilgi işlemcinin farklı port bacaklarından çıkıyorsa atomik olmaz. Yada 8 bitin kablo uzunluklarının yada empedanslarının farklı olmasından dolayı bile nano sn bazında farklılıklar oluşabilir. Bu da tam c64 örnekleme anına denk gelirse karışık bir değer okunabilir.

EDIT: @skate, bu arada ben uygun bir zamanda kodu yazar post ederim de, sen de dakikasında kodu kuşa çevirip atarsın... Korkuyorum. Hiç yazmasam mı...

[i_r_on]

Benim kodumda olan ikinci okumayı kodunuza koyabilirsiniz isterseniz ama cycle hesabında dikkate almayın. Uygulamada zaten işin içine bir miktar delay mikrokontrolcü tarafında girecek.

Pratikte bir bit değiştiğini anladıktan sonra yaptığınız okuma her zaman gerçek değeri verecek.

[Skate]

O zaman diyorsun ki

-
lda cartport
cmp cartport
beq -

ile bekletebiliriz bir nevi.

Edit: "bir nevi"nin nedeni bu kodun kullanılmayacak olması tabii ki.

[Skate]

Teorik çalıştığım için test yapamadan gönderiyorum ulaştığım noktayı ama çalışır gibi duruyor.

Bitleri 7 bit - 1 bit şeklinde gönderiyoruz. Gönderen kod şu şekilde;

Kod:

void CartInterface::TransmitByteAsync(uint8_t value)  {
  /* Cart software waits for data while page is negative */
  SetPage(0x80);
  
  /* Delay a bit to keep the pace */
  myDelay();
  
  /* Send the upper 7 bits as [0XXXXXXX], a positive value */
  SetPage((value >> 1) & 0x7F);
  
  /* Delay a bit to keep the pace */
  myDelay();
  
  /* Cart software waits for data while page is negative
     with 8th bit value as [X000000X] */  
  SetPage(0x80 | (value & 0x01));
  /* Delay a bit to keep the pace */
  myDelay();
}

C64 tarafındaki kod;

Kod:

; load stub
	ldx #$00
	
asynctransfer
-	lda cartport
	bmi -
	sta tapebuffer,x
-	lda cartport
	bpl -
	lsr
	rol tapebuffer,x
	
	inx
	bne asynctransfer	

ROL sonrasında porttaki value hala negatif olacağı için ek bir kontrole gerek kalmıyor.

Gönderen koddaki ilk;

SetPage(0x80);

de sadece ilk gönderimde işe yarıyor. Kaldırılabilir ancak ilk giriş değeri olarak set edilmesi lazım.

Not: Delimawi'nin xor yöntemini kafamda canlandırdım, bundan çok daha efektif gözüküyor. Bu benim çözümüm olarak dursun kenarda, Delimawi'nin çözümünü bekliyoruz.

[i_r_on]

Ödül belli oldu bu arada

Kazanan kendi transfer yöntemini kullanan bir IRQHack64 kartuşa sahip olacak

[Skate]

@i_r_on: Benim teori pratikte çalışıyor mu, denedin mi?