readme.txt

本人自己编的usb数据采集固件,对四路信号进行采集

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

The purpose of this code is to demonstrate how to implement long transfers 
...in EZUSB FX2 GPIF applications.

What does that mean?
  When using the GPIF Transfer Count method the cpu can setup a transfer of up
  ...to 4294967296 transactions (either 8 or 16-bit data bus).  The cpu is
  ...still responsible for monitoring and controlling the GPIF... but the data
  ...transfers are handled without cpu interaction (typically...although it is 
  ...possible for the cpu to interact (via REVCTL.0=1 and REVCTL.1=1)
  
  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).  Download "gpiflongxfr.hex"
03).  Issue "Get String"
04).  Issue "Get Pipes"
05).  Issue "Get Conf"
06).  Issue "Get Dev"
07).  Issue 0xC3 VendReq 64 IN
      - this will put the FIFOs in AUTOOUT mode
08).  Issue 0xD0 VendReq 64 IN
      - this reads GPIFTCB3, GPIFTCB2, GPIFTCB1, GPIFTCB0 registers
09).  Issue 0xD1 VendReq 64 IN
      - this writes 0xFFFFFFFF to the above registers (4G transfers)
10).  Issue 0xD2 VendReq 64 IN
      - this launches the GPIF FIFOWr waveform
11).  BulkTrans EP2 OUT 512 data (or more if you wish)
      - note: EZUSB Control Panel v2.3 and above supports 65,535 byte transfers
12).  Repeat step 11 as much as you wish...      

NOTE: at any time you can Issue 0xD0 VendReq to view the live GPIF Transaction Count...

      
NOTE: this example highlights OUT data transfers... 


The "gpiflongxfr.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 gpiflongxfr.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...