Re: [usb] Handshake to OUT transaction

[ilja_alekseev@mail.ru]

Hi Vikas T RAO!!! an thanks!

----- Original Message ----- 
From: "Vikas T Rao " <vikasraot@m... > 
To: <usb@o... > 
Date: Fri, 17 Jan 2003 14:30:26 +0530 
Subject: Re: [usb] Handshake to OUT transaction 

> 
> 
> ** Proprietary ** 
> 
> hi, 
> 
> from ur mail, i feel u r the user(on OS side) of that core. 
> 
> as far as i understand, core functionality might be like below. 
> 
> whenever the FIFO is full, a FIFO full signal(let's say fifo_full) 
> will be active. this signal might be causing an interrupt to the 
> core processor(CPU). upon receivng this interrupt, CPU might be 
> halting it's present operation and responding to this interrupt by 
> jumping to a sub-routine(Interrupt Service Routine). in that ISR, 
> NAK reply instructions might be present. so, u r seeing this NAK as 
> a reply to the last 64byte OUT transaction. "fifo_full" signal will 
> not be active if only 63 bytes are sent. 

thanks for so clear decribing of handshake logic

Before write to EP, EP's FIFO was absolutly empty! fifo_empty signal
was 'Hi' state. While 4time OUT transaction was processed device MCU
not read from FIFO. at end of OUT transactions i hope get 256 bytes in
EP's FIFO and "fifo_full" flag must be Hi. 


> 
> now the question is why it has to NAK? the answer can be as 
> follows. 
> 
> normally cores provide FIFO depth which is greater than their max 
> packet size. here it's 256 though max packet size is 64. it's 
> necessary because core might be slower than the USB speed i.e., 
> core might not have processed the 1st 64 bytes while the next 
> 64bytes arrive. instead of NAKing the 2nd packet, it might 
> retain(since FIFO depth is larger than max packet size) the 2nd one 
> also by ACKing. similarly with 3rd packet also. now when 4rth 
> packet arrives, core might not have finished processing the 1st 
> packet still.

befor 4th OUT transact. EP's FIFO has 64 bytes free to accept max size
(64) packet.

> that's why core might want to take a precautionary 
> measure at this point of time by NAKing. 
> 
> hope u have understood the probable functionality of the core. 


> 
> from the user point of view, u can't do anything if above is the 
> case except that u have to change the core logic according to ur 
> requirements. 


> 
> ...Vikas Rao. 
> 
> >>> Ilja_Alekssev@m...  01/16/03 06:19PM >>> 
> i can't understud this phenomen: 
> 
> my configuration of EndPoint: 
> EP1 -IN Bulk MaxPacket size - 64 
> size of EP1 FIFO 256 byte 
> EP2 -OUT Bulk MaxPacket size - 64 
> size of EP2 FIFO 256 byte 
> 
> when i write OUT in EP2 3 packet with PID sequence DATA0-1-0 core 
> say 
> me with 
> ACK handshake. and all 3 packet (total 64*3 bytes) fit in EP2 FIFO 
> correctly. 
> after that in EP2 FIFO is 64 bytes free space. 
> and when i write OUT to EP2 packet with PID DATA1 (size of packet: 
> 64 
> byte) core 
> say me NAK! But all last 64 byte (from last packet) in EP2 FIFO fit 
> correctly. 
> in write-time(EP2_WE is Hi) of last byte in Last packet EP2_Full is 
> Rise__/--- 
> 
> If i make 3 time write 64 bytes and 1 time 63 byte, core say me 4 
> time 
> ACK and 
> 64*3+63 bytes fit in EP2 FIFO. 
> 
> resume: 
> 256 byte sucessfuly writed to EP2 FIFO but USB core say me NAK to 
> last 
> transaction !  is this right? 
> 
--
To unsubscribe from usb mailing list please visit http://www.opencores.org/mailinglists.shtml