Kim korkar USB den

[z]

Sorularina cevap verecek duruma gelmedim.

Emin olmamakla birlikte bu cipi 3 yada 4 adet FT245 gibi dusunebiliriz.

Fakat kodlara bakarsan cip icinde bayagi bir seyle ugrasiliyor. USB'nin dibine inmek derken  bunlardan bahsediyorum. Bunlari usbyi detayli anlatan bir dokumandan ogrenmek lazim. Bir suru eventler (int benzeri durum) olusuyor ve bu eventlara tek tek cevap vermek gerekiyor.

Bu cipi tanimadan,  FT245 ile kiyaslamaya kalkarsak yanılabiliriz. İceride yazılım anlamında cok hamallik var. Bu hamalligin bir getirisi olmali herhalde.

Bu cipi islemciye takip usb cihazlara patronluk gorevi verebilirmiyiz ben de merak ediyorum.

USBN960X'in işlemci tarafından bakarsak bazı analizler yapma şansımız var. (Host ile aramızda neler olup bittiğini kısmen gözleme şansımız var)

Amacı, Pc'den bana datam gelsin yada datalarım PC'ye gitsinde nasıl oluyorsa olsun beni ilgilendirmez diyorsanız bu yazacaklarımın önemi yok, ancak iki kart yapacak ve bunları biribiriyle USB üzerinden konuşturacaksanız daha derinlere dalmak gerekiyor.

[z]

http://www.lvr.com/usb.htm

http://www.usb.org/developers

http://www.edn.com/article/CA181883.html

http://www.usb-by-example.com/

http://www.usb.org/developers/usbfaq/

Hello everyone. I really need help
It's the first USB device I develop.

I have a PIC16f877 interfaced with a USBN9604 usb controller through SPI interface..

Enumeration sequence fails at the same step on 2 different PCs.

enumeration sequence :
reset
suspend
reset
host sends : getdescriptor
device : descriptor sends first 8 bytes
nak0
nak0
host sends: setaddress
device : performs set the address
host asks for : getdescriptor (18 bytes)
device replies with 8 + 8 + 2 bytes
nak0
nak0
reset
suspend

enumeration stops here.. and device is reported as unrecognized by WinXP
Host HUB type USB 2.0.
Device is self powered.

Has anyone been through this ?
Does anyone have a working enumeration code that works on winXP?
I am using PIC CCS compiler.

thank you so much for your help!

Quote:
host asks for : getdescriptor (18 bytes)
device replies with 8 + 8 + 2 bytes
nak0
nak0
reset
suspend
You might have your MaxPacketSize set to 8 of 16 Bytes for the endpoint and are sending 18 Bytes on the first IN.

Marc Reinig
System Solutions

Bu isler USB 1.1 Spec dosyasini okumadan olmuyor.

Adamlar kod yazmis reglere bir seyler girip cikiyor neden?  Cevabi Spec 1.1 de

[PhD]

... USB'nin dibine inmek derken  bunlardan bahsediyorum. Bunlari usbyi detayli anlatan bir dokumandan ogrenmek lazim. ....

Selam, @bunalmis hocam belki elinde vardır ama ben belki yoktur diye göndermek istedim Jan Axelson denen birinin 571 sayfalık USB Complete isimli dökümanı.

Kolay gelsin.

Jan_Axelson_USB_Complete_2nd_Edition.zip

[z]

Hocam sağol, merak eden arkadaşlar yüklesinler. Bende basılmış kitabı var fakat çok faydasını görmüyorum.

USB 1.1 Dokümantasyonunu öğrenmeden bu işin üstesinden gelinemeyeceğini anladım. Bu önemli bir gelişme.

Dokumanın tamamını okumak çok zor. Dikkat çeken kısımları ara ara yazacağım. konular belli bir sırayı takip etmeyecek, eğer hala azmimiz devam ederse bunları düzenli şekilde sıralayıp doküman haline de getiririz.

USB iletişiminde Host (Karargah vs de deniyor ama bundan boyle patron diyeceğim) ve cihazlar vardır. USB cihazları birbirine bağlayarak kendi aralarında konuşturamayız. Muhakkak patron yeteneğinde bir cihaz gerekmektedir.

USB hattı 4 kablodan oluşur.  Bunlar

+V (Besleme)
D+
D-
Gnd

USB üzerinden konuşan bir çip beslemesini +V ve Gnd den yada tamamıyla ayrı güç kaynağından alabilir.

RS232 iletişiminde interface çipleri gerekirken USB çiplerine interface ünitesi de çipe entegre edilmiştir. (İstisna çipler olabilir)

D+ ve D-  sinyalleri diferansiyel tipte sinyallerdir ve doğrudan çip içindeki usb Transceiver ünitesine girer.  

Transceiver ünitesi transmitter ve receiver ünitesinden oluşur.

D+ ve D- Transmitter ünitesinin çıkışlarına bağlıdır.  Aynı uçlar Receiver ünitesine de girmektedir.  D+ ve D- biribirinin invertidir. Transmitter ünitesi, çıkışları aktif edecek kontrol sinyali verilmedikçe USB hattına sinyal basamaz.

D+ ve D- sinyalleri üzerine ileride tekrar konuşacağız.

D+ ve D- sinyalleri Transceiver ünitesinden geçtikten Physical Layer  Interface ünitesine gelir.

Burası USB iletişim protokollerinin yürütüldüğü, ünitedir ve biz bu kısımla hiç ilgilenmeyeceğiz. (Bu derinlikteki basınca dayanamayabiliriz. Zaten amacımız usb çip tasarımı değil, gene de merak ediyorsunuz aşağıdaki alıntıyı izleyin

Ne tesadüf ki ben de USB protokolünü anlamak için çalışmaya başlamıştım  Üstad USBN'den başlamışsın, ben tam anlamıyla öğrenmek adına IgorPlug'ı inceliyorum.

http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm

Analyzer

)

Fiziksel interface katmanı sonuç olarak hattan gelen veri paketlerini alır, PID, DATA, Address gibi veriler ayiklanir , CRC islemleri yapilir, verilerde hata olup olmadığı anlasilir ve en nihayetinde karşıdan gelen verileri USB registerlerimize yükler. Duruma uygun event uretir. Bu katmana USB Engine de denir.

Ancak buradan elde edilen veriler okunup hemencecik kullanılacak veriler değildir. (Yani gelen verilerle ledi yak söndür vs tipi istediğimiz türde isleri  hemen yapamayiz.)

Devam edecek.

[z]

Host cihaza Patron demiştik, bilgisayara bağlanan USB nesneye de (usb klavye, mause vs) Cihaz diyelim.

Patron ile Cihaz arasında veri aktarımı sağlamak için tek yada çift yönlü Pipe (boru) döşenir. Bu bir sanal tabirdir. Arada kablo var boru bumu derseniz hayır.

Boruların uçlarına End Point denir.

Veriler bir End Pointten girer diğer End Point'den çıkar.

Bir USB çipine birden fazla boru hattı döşenebilir. (Bu çipin yapısıyla (yeteneği ile alakalı) USBN960X bu konuda iyi)

Boru hattından 4 tip veri transferi yapılabilir.

Control Transfer
Bulk Data Transfer
Interrupt Data Transfer
Isochronous Data Transfer


Kontrol Transferi tanisma asamasinda yapilir. USB cihazın ilk bağlantı aşamasında (power on yada kabloyu sokup takma asamasi) Patron degisik sorgulamalar yaparak cihazın ve USB cipini kullanan yazilimin ozellikleri (structure iceriklerini) ogrenilir.

Bulk Data Transferinde zamanlamanın kritik olmadığı  büyük hacimli veriler gönderilir. Yazıcıdan basılması istenen dokümana ait veriler. Yada Scanner cihazından patrona aktarılacak veriler gibi.

Bu tip iletişimde  USB band genişliği o an USB hattı kullanan diğer cihazların aktivitelerine de bağlıdır.

Interrupt Data transferinde, sürekli gönderilecek veri yoktur. Arada bir oluşan tipte verilerin gönderilmesinde kullanılır. (Klavye, Pointing Cihazları (Light Pen yada Tablet gibi))

Isochronous Data transferi, verilerin belirli bir zaman diliminde  kesinlikle iletilmesi gereken uygulamalarda kullanılır. (Zamanlama  kritik olduğu ses, görüntü aktarımı vs gibi)

Devam edecek

[z]

Patron donanımı neler yapar?

USB Cihazın hatta takıldığını ya da hattan söküldüğünü tespit eder.

USB cihazla arasındaki kontrol akışını yönetir.

USB cihazla arasındaki veri akışını yönetir.

USB cihazların Durum ve aktivitelerine ilişkin istatistik bilgileri toplar.

USB cihaz için besleme voltajı (enerjisini) sağlar.

Patron yazılımı neler yapar?

Cihazları konfigüre eder ve sayar.

Isochronous data transferi yapar.

Asynchronous data transferi yapar.

Güç yönetimi yapar.

Cihaz ve Bus yönetimi yapar.

Devam edecek

[z]

END POINT

Veri aktarımı için kurulmuş boru hattının iki ucuna End Point diyorduk.

End Point, veriler için son durak noktalarıdır.

Bir çip içindeki End pointler rakamlarla ifade edilir ve her End Point'e ayrı ayrı (biricik) rakamlar atanır. Bu sayede hedefler (son duraklar) tam olarak belirlenmiş olur.

Bu numaralama USB çipine ait yazılımın tasarımı aşamasında  yapılır.

USB Cihaza atanan adres ve End Point Numarasıyla birlikte son noktalar diğerlerinden kesin olarak ayrılmış olur.

(Aynı anda birden fazla Cihaz Patron portlarına bağlı olabilir her cihaz kendi içinde biricik End Pont numaralarına sahiptir, dolayısı ile Cihazların da ayrı birer adres numarası olmak zorundadır)

End Point'ler arasındaki veri iletişimi tek yönlüdür. (Patrondan Cihaza yada, Cihazdan Patrona doğru) (0 nolu EndPoint'de istisna var)

Her cihaz 0 numaralı End Point (EP0) e sahip olmalıdır. Çünkü yazıllımlar cihazı konfigüre edecek veriyi EP0'a yollarlar. EP0'a sadece ilk bağlantı aşamasında (hatta bağlanma, cihazı çalıştırma, reset etme gibi) kullanılır.

Sıfırdan farklı numaralı End  Point'e de ihtiyaç duyulur

Ancak bu End Pointler, Configuration Process (cihaz şekillendirilmeden, yani initialize işlemleri) yapılmadan kullanılamaz.

PIPES (Borular)

Patron üzerindeki yazılım,  cihazlarla borular üzerinden konuşur. Borudan iki tip haberleşme yapılabilir.

Birisi, USB de speclerde tanımlı standart Structer yapısındaki Mesage (mesaj) gönderimi.

Diğeri de Structer yapısında olmayan tipte Stream (veri dizisi) gönderimi.

0 Numaralı End Pointler (EP0) Default Control Pipe içindir. Yani cihaz enerjilendiğinde EP0 noktalarından haberleşerek cihazları konfigüre ederler. (Bunu hep hatırda tutuyoruz) Diğer borular USB cihaz konfigüre edildikten sonra kullanılabilir.

Devam Edecek

[CoşkuN]

Amacı, Pc'den bana datam gelsin yada datalarım PC'ye gitsinde nasıl oluyorsa olsun beni ilgilendirmez diyorsanız bu yazacaklarımın önemi yok, ancak iki kart yapacak ve bunları biribiriyle USB üzerinden konuşturacaksanız daha derinlere dalmak gerekiyor.

Demişsiniz hocam ama Jan amca kitabında "interface limits " bölümünde şöyle birşey diyor:
"Peer-to-Peer Communications Every USB communication is between a host computer and a peripheral. The host is a PC or other computer with host-controller hardware. The peripheral contains device-controller hardware.Hosts can't talk to each other directly, and peripherals can't talk to each other directly. Other interfaces, such as IEEE-1394, allow direct peripheral-
to-peripheral communications."

Yani anladığım kadarıyla USB de host mutlaka PC olmalı.Yanılıyor muyum?

[z]

Yazar doğru diyor, sorun kullanılan çiplerden kaynaklanıyor. Bizim kullandığımız çipler Cihaz yapmak için, fakat Host özelliğinde kart yapmak için de  çipler var. Forumdaki adını şu anda hatırlayamadığım bir arkadaş ARM-7 nin bu özelliğe sahip olduğundan bahsetmişti.

Yani FT245 çipini iki karta takıp kartları birbiriyle konuşturamayız ama ARM-7 ile konuştururuz. Yada en kötü ihtimal PC motherboarddan USB çipi söker kendi kartımıza takarız.

[CoşkuN]

O zaman şöyle diyebiliriz:Patron bir PC ya da PC gibi davranabilen bir cihaz olmalıdır.

[z]

Şöyle desek daha doğru olur. Patron kartta, PClerdeki gibi Host özelliğinde bir USB çipi olmalı.

[z]

İlk başlarda fazla derinlere girmek istemediğimizi söylemiştik. Ancak ilerleyen dönemlerde PID, ACK, NACK STALL gibi terimlerle karşılaşmaya başlıyoruz.

USB hattındaki verilerin nasıl sıralandığı neler içerdiğini bilmek faydalı. Bu durumda USB 1.1  Spec. dokümanının 8. Bölümüne göz atmanızda fayda var.

Dokümana bakıldığında paket içeriğinin ne olduğu PID değerinden anlaşılmaktadır.

4 Tip PID vardır.

Token
Data
Handshake
Special (Şimdilik ilgilenmiyoruz)

Token tipi PID grubunda OUT, IN, SOF, SETUP
Data tipi PID grubunda Data0, Data1 ....
Handshake tipi PID grubunda  ACK, NAK, STALL

Paketi  tanımlayan PID ye kısaca değindikten sonra ACK, NAK, STALL terimlerine bakalım. (asm yazılımda çok sık geçiyordu)

ACK:  Alınan veri hatasız olarak ulaştıysa ACK cevabı veririz.

NAK: Hatalı veri alındıysa yada veriyi gönderemediysek NAK cevabı veririz.

STALL: End Point çakılır kalırsa istek anlaşılamadıysa STALL cevabı verilir.

Patrona vereceğimiz bu üç cevaba göre Patron verileri bize ulasştırmaya çalışır.

Dokumanda 8.6.4 Corrupted ACK Handshake kısmına bakın.

Açıklamalara resimleri koymak çok iyi olurdu ancak uzun iş. Bunun yerine  USB 1.1 dokumanında bölüm no veriyorum.

Şimdi sayfaları atlayarak  177. sayfaya geçiyoruz.

USB cihaz Patrona takıldığında neler oluyor?

JAN amcanın Türkçeye çevrilmiş kitabında 51-65 sayfaları şimdi çok çok anlaşılır oldu.

Bu kısım önemli çünkü USB çipimizde de adım adım bazı işlemler yapacağız.

Cihazın bağlanması:

HUB porttaki sinyalleri takip eder. Normalde Hub daki  çipin Tranceiver ünitesinde D+ ve D- hatları 15 K lık pull down dirençleri ile  lowa çekilidir.

USB kartımızın D+ yada D- hattı ise 1K5 direnç ile 3v3 hattına bağlıdır.
Bu direncin D+ ya mı yoksa D- yemi bağlı olduğu cihazın hızını HUB'a da tarif etmeye yarar. (Tam hızlı cihazlarda D+ ya bağlı)

İşte Hub bu direncin varlığını D+ ve D- deki voltaj farkından anlar. Bu direnc varsa hatta kart takili demektir.

Hub bu olayı anladıktan sonra BUS'ı beslemeye devam eder ve Patrona durumu izah eder.

Patron da HUB'a, şu bulduğun cihazı bir resetle bakalım der.

HUB, kartımıza gelen USB hattında D+ ve D- kablolarını en az 10 ms boyunca lowda tutar. (Normalde bu hatlar biribirinin zıttıdır ve reset durumu özel bir durumdur.)


Patron cihaza GET_PORT_STATUS komutu yollar. Verilecek cevapta bir bit reset durumunu gösterir. Eğer cihazımız artık resette değilse Patron bunu gelen verideki bite bakarak anlar.

Artık End Point 0 da varsayılan boru hattı üzerinden haberleşme başlayabilir. Bu esnada cihaz usb port beslemesinden 100mA den daha az akım çeker.

HUB reset işlemi sonrasında Gene hattaki voltaja bakarak cihazımızın  hızını tespit eder ve Patronun  ilk GET_PORTSTATUS_ isteğine cevap olarak bildirir.

Patron Cihazla arasında kurulduğu varsayılan boru hattının maximum paket büyüklüğünü öğrenmek için kartımıza GET_DESCRIPTOR ısteği yollar. Bu istek kartımızdaki çipin End Point 0'ına gider.

Not:Yazılanları okuduğunuzda bölük börçük ilerlediğimizi farkedeceksiniz, ancak asm den C ye çevirdiğimiz programı biraz inceleyin. Burda söylenenlere benzer açıklamalar en azından terimler orda da geçiyor ve çok yakında taşlar oturmuş olacak.

C programı incelemek için tıklayın

Devam edecek

[z]

Daha önce usb cihazımıza (kamera mouse vs) Cihaz diyeceğimizi söylemiştik fakat kart desek daha iyi olacakmış. Bundan böyle kart diyeceğiz.

Patron kartımıza Get_Desriptor isteğinde bulunur demiştik. (Desriptor içeriği USB 1.1 Spec. sayfa 197 de.)

Descriptor incelenirse max paket boyu bilgisinin 8. sırasında da saklı olduğu görülecektir. Windows işletim sisteminde Patron 64 byte istemesine rağmen aradığı bilgi ilk 8 byte içinde var olduğundan paket boyunu okuyup hemen mevcut işlemi tamamlamadan terkeder.

Patron kontrol transferini yarıda keserse kartımız bunu anlar (event larımıza değineceğiz), bir sonraki adımda, daha onceki istegin geregi (verilerin tamami gonderme islemi) tamamlanmadigi halde  Patronun yeni isteğine cevap vermek zorundadır. Dolayısı ile yukarıdaki terkediş sürecinden sonra Patronun kartımıza reset atması gerekmez.

Programi inclediginizde yazilimin, klasik program yazim mantigindan biraz farkli oldugunu daha cok state machine mantigina benzedigini goreceksiniz. Bu yontem bu tip uygulamalarda cok buyuk kolayliklar saglar ve daha kisa program yazimina imkan verir.

Şimdiki aşama kartımıza bir adres ataması yapılması aşamasıdır. Patron, kartımıza Set_Address isteğine bulunur. Kartımız veriyi okur ve tastik bilgisi gönderir ve adresi saklar. Cihaz sökülene kadar artık bu adres geçerlidir.

Adres yuklenmesinden sonra artik veriler bu adrese gelir. Atiyorum Patron 13 numarali adresin 0 numarali boru hattina veri gonderirir yada 13 numarali adresden x numarali botu hattindan veri almissa haa su bizim paralel portta USBN9604 calismasi yapan kisilerin kartindan bu veri gelmis der.  Patron pek cok usb cihazla tek basina konusmaktadir. PC icindeki USB cipi ile PC icindeki HUB arasiundaki  USB baglantisi tekdir ve butun veriler burdan akar (Manyak bir trafik) Eger USB interface'ini tasarlayanlar PCmizde tek USB port olacagini ve sadece tek usb cihaz baglanmasini ongorselerdi bu adres verme islemine ihtiyac kalmayacakti)

Neyse devam edersek;

Patron kartımızın yeteneklerini öğrenebilmek için  daha önce yarım bıraktığı işlem olan Get_Descriptor'u bir daha yollar.

Desriptorde 17.Byte da saklanan konfigürasyon sayısına bakar ve  birden fazlaysa hepsinin (alt konfigürasyonların tamamının) ilk 9 bytlarını  ister. Böylece bütün alt konfigürasyon bilgileri bulunur.

Daha sonra FF bytea kadar toplam uzunluk istenir...  Tabiki Patron 256 adet veri istiyor diye Romumuzdan 256 veri okuyup gondermeyecegiz.

Kontrol desriptorlerden baslayarak altlara dogru butun veriler paket paket gonderilir. Bu verilerin sayisi 256 dan kucukse (bizde kucuk en son veriden sonra uzunluk paket boyunu tamamlasin tamamlamasin yollanir.
Patron eksik paketin tam dolu olmadigini gorunce haa adamdaki veriler bitmis der. (Eger sansimiza en son veri ile paketi tam doldurduysa paket gonderilir ardindan 1 bos paket yollanir) Dolayisi ile Patron bizden 256 veri gelmesini beklemez.

Artık Patron, kartımıza en uygun sürücüyü yükleme aşamasına gelmiştir. Bunun için karttan istemiş olduğu konfigürasyon bilgilerinden satıcı, üretici kimlik bilgisi, sürüm numarası, cihaz sınıfı  verilerini,  sistemde bulunan INF dosyalarındaki verilerle mukayese eder. Uygun surucuyu bulduysa sorun yoktur bulamadiysa bizden surucunun bulundugu yeri gostermemizi ister. Zaten bunu windows kullanicisi olarak derinlerden gelisen bu olaylarin farkinda olmadan  zaman zaman yapiyoruz.

Devam edecek.

[z]

Su anda kartimiza ait surucu Patron tarafinda yuklenmis durumdadir.

Surucu sayesinde Patron, kartimizdaki konfigurasyonlardan uygun birisinin secilmesini ister. Biz uygulamamizda tek konfigurasyonla calisacagimiz icin burdaki detaylarla ilgilenmeyelim.

Simdi bozuk plak gibi ayni seyleri tekrar tekrar soyleyecegiz ama;

Device Decriptor bilgisine tekrar geri donelim.

17 Byte'dan olusan verilerin  formati bellidir. Bu veriler bir tabloda tutulur.

Kartimizdaki islemci bu tabloyu okuyarak USC cipimizin uygun registerlerine yazar ve istendiginde Patrona yollar.

Patron Get_Descriptor dediginde kontrol transferine basvurur.

Simdi daha onceki C programinda ilgili bolumu bulalim. Neler yapilmis anlamaya calisalim.

Oncelikle 0 nolu End Point registerlerinden TX ile ilgili reglerin neler oldugunu soyleyelim.

TXD0 Transmit Data Registeri
TXC0 Transmit Command Registeri
TXS0 Transmit Status Registeri

Aslinda bu reg isimlendirmesi, asenkron iletisimde kullandigimiz reg isimlendirmesiyle aynidir.

Cipimizde yukaridaki registerlerin herbirinden 4 tane var.
Mesela TXD0, TXD1, TXD2, TXD3 gibi.

(Cipimizde 6 + 1 ayri endpoint olabiliyor)

Asagidaki kodlamada TXC0 ve TXD0 kullanilmis. TXD0 8 bit verinin yazildigi 8 bytlik derinlikte FIFO dur.  Gonderilmek istenen veriler buraya yazilir.

TXC0.3  (0 dahil 3. bit)  FLUSH bitidir. Bu bit set edilirse FIFO index sayicilari basa (en tepeye) alinir. Buffer icerigi cope gitmis olur. Bu islem iletisim esnasinda yapilirsa sozu edilen temizlik islemleri transfer bitiminde  yapilir.

TXC0.2 Toggle bitidir. 0 ise PID icin Data0 degeri, 1 ise Data1 degeri kullanilir.

unsigned char tx_setup() // The transmission routine for desriptor
{
char boy,Finish;

     Finish=0x00;
     wr(TXC0,0x08); // Reset FIFO Pointer
     boy=usb_length-usb_pac_count;
     if (boy)
	{
	 if (boy<9) usb_byte_offset=boy; else usb_byte_offset=8;
	 do
	    {
	      if (usb_mode_flags==0x01)
		 {
		   usb_tx_reg=DevDescripter[usb_pac_count-1];
		 }
	      else if (usb_mode_flags==0x11)
		 {
		   usb_tx_reg=ConDescripter[usb_pac_count-1];
		 }
	      else if (usb_mode_flags==0x11) // sanirim burda hata yapmislar
		 {
		   usb_tx_reg=Signature[usb_pac_count-1];
		 }
	      else { usb_mode_flags=0x00; return(0); }
	      wr(TXD0,usb_tx_reg); // TXD0 FIFO
	      usb_pac_count++;
	      usb_byte_offset--;
	    } while (!usb_byte_offset);
	 Finish=0x01;
	}

     if (!Finish) usb_mode_flags=0x00;
     if (usb_flow_flags&1) wr(TXC0,0x05); else wr(TXC0,0x01);
     usb_flow_flags^=1;
     return(0);
}

Not: Kodlama tarafimdan yapilmistir ve hata icerebilir.

Yukaridaki kodda usb_mode_flags 1 degeri iceriyorsa  Device Decriptor tablosundan 8 byte yollanmaktadir.

usb_mode_flags, programi yazan kisinin program yaziminda kendi olusturdugu bir degiskendir. O halde bu degiskene  kim 1 degeri veriyor da Device Descriptor gonderilsin istiyor ona goz atalim.

Devam edecek.

[z]

Gercektende olaylar daha once anlattigimiz gibi (kitaplardan okuyup yazdigim gibi gelismektedir)

usb_mode_flags degiskenine 1 degerinin atildigi yer

req_device_setup fonksiyonudur.

char req_device_setup()
{
     if (Signature[bmRequestType]&0x80)
	{

//	  Device to host

	  if ((Signature[bmRequestType]&0x60)==0x00) // Standart
	     {
	       if (Signature[bmRequest]==0x06)
		  {
		    usb_flow_flags|=0x81;
		    if (Signature[wValue_h]==0x01)
		       {
			 usb_mode_flags=0x01;
			 usb_length=DevDescripter[0x00];
			 desc_cntl();
			 return(0);
		       }
		    else if (Signature[wValue_h]==0x02)
		       {
			 usb_mode_flags=0x11;
			 usb_length=ConDescripter[0x02];
			 desc_cntl();
			 return(0);
		       }
		  }
	     }
	  stall(EPC0);
	  return(0);
	}
     else
	{

//	  Host to device

	  if ((Signature[bmRequestType]&0x60)==0x40) // Vendor
	     {
	       if (Signature[bmRequest])
		  {
		    if (Signature[bmRequest]==0x81)
		       {
			 led=1;
		       }
		    else if (Signature[bmRequest]==0x80)
		       {
			 led=0;
		       }
		    else { stall(EPC0); return(0);}
		    wr(TXC0,0x0D);
		    wr(RXC0,0x01);
		    return(0);
		  }
	       else
		  {
		    usb_flow_flags|=0x01;
		    usb_mode_flags=0xFF;
		    Signature[wLength_l]=8;
		    usb_length=8;
		    desc_cntl();
		    return(0);
		  }
	     }

	  if ((Signature[bmRequestType]&0x60)==0x20) // Class
	     {
	       stall(EPC0);
	       return(0);
	     }

	  if ((Signature[bmRequestType]&0x60)==0x00) // Standart
	     {
	       if (Signature[bmRequest]==0x09)  // Set Configuration
		  {
		    wr(RXC0,0x08); // Flush
		    wr(TXC0,0x0D); // Flush and send
		    wr(RXC0,0x01); // Re-enable receving
		    return(0);
		  }
	       else if (Signature[bmRequest]==0x05)  // Set Address
		  {
		    wr(TXC0,0x08); // Flush
		    wr(TXC0,0x01); // Send
		    wr(EPC0,0x40);
		    wr(FAR,Signature[wValue_l]|0x80);
		    usb_mode_flags=0x00;
		    usb_flow_flags|=0x04;
		    wr(RXC0,0x01);
		    return(0);
		  }
	       else if (Signature[bmRequest]==0x01)  // Clear Feature
		  {
		    if (Signature[wValue_l]==0x01)
		       {
			stall(EPC0); // device wakeup
			return(0);
		       }
		    unstall(EPC0);
		    wr(TXC0,0x0D);
		    wr(RXC0,0x00);
		    return(0);
		  }
	     }
	  stall(EPC0);
	}
     return(0);
}

Ara not:

Programda RXC0 register iceriginin sik sik kontrol edildigi gozleniyor.
RXC0 da 6 nolu bit setup bitidir ve bu bit set olmuş ise setup paket alindigini soylenmektedir.

USB 1.1 Spec 185.sayfa da Request kodlarini goruyoruz.

Sik sik karsilastigimiz karsilastirmalarda kullanilan karsilastirma degerlerinin kaynagi sanirim belli oldu.


Devam edecek.