This directory contains 8051 firmware for the Cypress Semiconductor EZ-USB FX2 
chip.

The purpose of this code is to demonstrate how the cpu can "dynamic OUT 
...automaticity" in EZUSB FX2 GPIF applications.

What does that mean?
  By setting REVCTL.1=1 (DYN_OUT) the cpu can dynamically switch between "AUTO"
  ...and "MANUAL" mode, perhaps to edit an OUT packet, without having to do 
  ...a FIFORESET.
  
  NOTE: 
    - the cpu can't source an OUT packet in "AUTO" mode...
      - in AUTO mode the cpu is out of the data path...
    - the core doesn't notify the cpu of zero length OUT packets (in either mode)...
      - typ. this is handled "out-of-band" over endp0 or endp1...
  
Chapter 10 of the EZUSB FX2 TRM explains the General Programmable Interface (GPIF)...

This example configures FX2 as follows:
01).  EP2 512 4x BULK OUT - 8-bit async MANUAL mode
02).  EP6 512 4x BULK IN - 8-bit async MANUAL mode

.....from "the user":
01).  Initially strap:
      - RDY0 to GND
      - RDY1 to VCC (through a 10k ohm resistor)
02).  Setup Logic Analyzer (similar to *.TIF files)
03).  Download "dynout_m.hex"
04).  Issue "Get String"
05).  Issue "Get Pipes"
06).  Issue "Get Conf"
07).  Issue "Get Dev"
08).  Trigger Logic Analyzer on CTL1 going low
09).  Issue 0xC0 VendReg 64 IN
10).  BulkTrans EP2 OUT 512 data (or more if you wish)
11).  Examine Logic Analyzer output      
      - should look similar to "SRCO_M01.TIF"
      - LED0 should flash briefly...
12).  Trigger Logic Analyzer on CTL1 going low
13).  Issue 0xC3 VendReg 64 IN
      - LED1 should turn on...
14).  BulkTrans EP2 OUT 512 data (or more if you wish)
15).  Examine Logic Analyzer output      
      - should look similar to "SRCO_M01.TIF"
      - LED1 should stay on...
16).  Trigger Logic Analyzer on CTL1 going low
17).  Issue 0xC4 VendReg 64 IN
18).  BulkTrans EP2 OUT 512 data (or more if you wish)
19).  Examine Logic Analyzer output      
      - should look similar to "SRCO_M01.TIF"
      - LED1 should turn off...
      - LED0 should flash briefly...
      
NOTE: this example highlights OUT data transfers... 


The "dynout_m.hex" file loads into internal memory.
...issue "build -i" at the command prompt...

This example is for illustrative purpose(s)... You'll need a Logic Analyzer tied
to the DK 2x10 protoboard expansion headers (mapped for HP Logic Analyzer Pods)...

Explaining this implementation...
=================================

Both RDY0 and RDY1 are active low signals:

RDY0=1 when peripheral "not empty"
RDY0=0 when peripheral "empty"

RDY1=1 when peripheral "not full"
RDY1=0 when peripheral "full"

Both CTL0 and CTL1 are active low signals:

CTL0=1 when P_RD deasserted
CTL0=0 when P_RD asserted

CTL1=1 when P_WR deasserted
CTL1=0 when P_WR asserted


The FIFOWr waveform descriptor has been implemented as follows:
S0: Examine RDY0 status for "not empty"
      if empty
        transition to S6
      else
        transition to S1
S1: Assert P_RD for 3 ifclk cycles
S2: Sample current byte on PORTB into interface FIFO, advance fifo ptr
    Assert P_RD for 1 ifclk cycle
S3: Assert P_RD for 1 ifclk cycle
    Transition to IDLE (S7)
S6: Deassert P_RD
    Signal cpu of "empty" condition (see GPIFWF_ISR in dynout_m.c)
    Wait until cpu issues GPIFABORT
S7: IDLE        
    Deassert all CTLx        


The FIFORd waveform descriptor has been implemented as follows:
S0: Examine RDY1 status for "not full"
      if full
        transition to S0 (wait for "not full" condition)
      else
        transition to S1
S1: Assert P_WR for 3 ifclk cycles
    Drive current byte in interface FIFO on PORTB
S2: Advance fifo pointer
    Deassert P_WR for 1 ifclk cycle
S3: Deassert P_WR for 1 ifclk cycle
    Transition to IDLE (S7)
S7: IDLE
    Deassert all CTLx        
    
    
Single Read and Single Write waveform descriptor have been implemented but are
not used in this example.

The "#ifdef TESTING_GPIF" in "gpif.c" is there because this example is frameworks
based ("fw.c" supplies function main();) and none of the "canned" gpif functions
are being used in this implementation...
    

The firmware in "dynout_m.c" handles USB data as follows:

To handle OUT data ->

if endp "not empty"
  commit pkt. to peripheral domain
  
if gpif idle
  if interface fifo "not empty"
    if peripheral "not full"
      trigger gpif FIFOWr
      
      
To handle IN data ->

if gpif idle
  if peripheral "not empty"
    if interface fifo "not full"
      trigger gpif FIFORd
      wait for transaction to complete
      commit pkt. to host domain