文件列表:

FX2 GPIF Long transfers\build.bat (1986, 2011-06-02)
FX2 GPIF Long transfers\dscr.a51 (8956, 2011-06-02)
FX2 GPIF Long transfers\DSCR.LST (21013, 2011-06-02)
FX2 GPIF Long transfers\DSCR.OBJ (1139, 2011-06-02)
FX2 GPIF Long transfers\fw.c (13499, 2011-06-02)
FX2 GPIF Long transfers\FW.LST (72231, 2011-06-02)
FX2 GPIF Long transfers\FW.OBJ (6823, 2011-06-02)
FX2 GPIF Long transfers\FX2 GPIFLONGXFR Build ENV.pif (967, 2011-06-02)
FX2 GPIF Long transfers\gpif.c (27924, 2011-06-02)
FX2 GPIF Long transfers\gpif.LST (53332, 2011-06-02)
FX2 GPIF Long transfers\gpif.OBJ (1572, 2011-06-02)
FX2 GPIF Long transfers\gpif.__i (74, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr (29781, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.c (28550, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.hex (11196, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.lnp (203, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.LST (129552, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.M51 (117685, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.OBJ (15710, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.Opt (1579, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.plg (192, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.Uv2 (2150, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr.__i (81, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr_Opt.Bak (1119, 2011-06-02)
FX2 GPIF Long transfers\gpiflongxfr_Uv2.Bak (1985, 2011-06-02)
FX2 GPIF Long transfers (0, 2011-06-04)

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 *** IN - this will put the FIFOs in AUTOOUT mode 08). Issue 0xD0 VendReq *** IN - this reads GPIFTCB3, GPIFTCB2, GPIFTCB1, GPIFTCB0 registers 09). Issue 0xD1 VendReq *** IN - this writes 0xFFFFFFFF to the above registers (4G transfers) 10). Issue 0xD2 VendReq *** 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...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：