当前位置:高等教育资讯网  >  中国高校课件下载中心  >  大学文库  >  浏览文档

《ARM嵌入式系统软件开发实例》教学资源(讲稿)第十讲 PDIUSBD12 固件编程指南

资源类别:文库,文档格式:PDF,文档页数:22,文件大小:98.15KB,团购合买
Firmware Programming guide for PDIUSBD12 This is a legal agreement between you(either an individual or an entity and Philips Semiconductors. By accepting this product, you indicate your agreement to the disclaimer
点击下载完整版文档(PDF)

G PHILIPS Philips semiconductors Interconnectivity 23 September 1998 Firmware Programming Guide for PDIUSBD12 Version 1.0 Philips Semiconductors- Asia Product Innovation Centre Visithttp:/www.flexiusb.com

Philips Semiconductors Interconnectivity _______________________________________________________________________________________________ Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 23 September 1998 Firmware Programming Guide for PDIUSBD12 Version 1.0

Interconnectivity Page 2 of 22 Firmware Programming guide for PDIUSBD12 This is a legal agreement between you(either an individual or an entity and Philips Semiconductors. By accepting this product, you indicate your agreement to the disclaimer specified as follows DISCLAIMER PRODUCT IS DEEMED ACCEPTED BY RECIPIENT. THE PRODUCT IS PROVIDED "AS IS WITHOUT WARRANTY OF ANY KIND. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW. PHILIPS SEMICONDUCTORS FURTHER DISCLAIMS ALL WARRANTIES. INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANT ABILITY. FITNESS FOR A PARTICULAR PURPOSE. AND NONINFRINGEMENT. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE OF THE PRODUCT AND DOCUMENTATION REMAINS WITH THE RECIPIENT TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW IN NO EVENT SHALL PHILIPS SEMICONDUCTORS OR ITS SUPPLIERS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL, DIRECT, INDIRECT. SPECIAL. PUNITIVE. OR OTHER DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS. BUSINESS INTERRUPTION. LOSS OF BUSINESS INFORMATION. OR OTHER PECUNIARY LOSS) ARISING OUT OF THIS AGREEMENT OR THE USE OF OR INABILITY TO USE THE PRODUCT. EVEN IF PHILIPS SEMICONDUCTORS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES Philips Semiconductors-Asia Product Innovation Centre

Interconnectivity Page 2 of 22 Firmware Programming Guide for PDIUSBD12 _______________________________________________________________________________________________ Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com This is a legal agreement between you (either an individual or an entity) and Philips Semiconductors. By accepting this product, you indicate your agreement to the disclaimer specified as follows: DISCLAIMER PRODUCT IS DEEMED ACCEPTED BY RECIPIENT. THE PRODUCT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, PHILIPS SEMICONDUCTORS FURTHER DISCLAIMS ALL WARRANTIES, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANT ABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE OF THE PRODUCT AND DOCUMENTATION REMAINS WITH THE RECIPIENT. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL PHILIPS SEMICONDUCTORS OR ITS SUPPLIERS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL, DIRECT, INDIRECT, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS) ARISING OUT OF THIS AGREEMENT OR THE USE OF OR INABILITY TO USE THE PRODUCT, EVEN IF PHILIPS SEMICONDUCTORS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES

Interconnectivity Page 3 of 22 Firmware Programming guide for PDIUSBD12 Table of contents 1 INTRODUCTION 2 ARCHITECTURE 2. 1 FIRMWARE STRUCTURE 1. Hardware Abstraction Layer- EPPHAL C 2.1.2 PDIUSBD/2 Command Interface-DI2CIC 2.1.3 Interrupt Service Routine-ISRC 2.1.4 Main Loop- MAINLOOP C 455555666 2.1.5 Protocol Laver-CHAP 9.C. PROTODMA C. 2.2 PORTING THE FIRMWARE TO OTHER CPU PLATFORM 2.3 USING THE FIRMWARE IN POLLING MODE 3 HARDWARE ABSTRACTION LAYER 4 PDIUSBD12 COMMAND INTERFACE 5 INTERRUPT SERVICE ROUTINE 667789 5.1 BUS RESET AND SUSPEND CHANGE 5.2 CONTROL ENDPOINT HANDLER 5.3 GENERIC ENDPOINT HANDLER 5. 4 MAIN ENDPOINT HANDLER 5.5 EOT HANDLER o3334 6 MAIN LOOP 7 CHAPTER 9 PROTOCOL 7.1 CLEAR FEATURE REQUEST 7.2 GET STATUS REQUEST. 7.3 SET ADDRESS REQUEST 16 4 GET CONFIG REQUEST 7.5 GET DESCRIPTOR REQUEST 7.6 SET CONFIG REQUEST 7.7 GET/SET INTERFACE REQUEST 18 7.8 SET FEATURE REQUEST 8 DMA SUPPORT 8.1 INTRODUCTION TO PROTOCOL BASED DMA OPERATION 8.2 DEVICES DMA STATES 8.3 DMA CONFIGURATION REGISTER 8.4 SETUP DMA REQUEST 8.5 HOST SIDE PROGRAMMING CONSIDERATIONS Philips Semiconductors- Asia Product Innovation Centre

Interconnectivity Page 3 of 22 Firmware Programming Guide for PDIUSBD12 _______________________________________________________________________________________________ Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com Table of Contents 1 INTRODUCTION........................................................................................................................................... 4 2 ARCHITECTURE.......................................................................................................................................... 5 2.1 FIRMWARE STRUCTURE ............................................................................................................................... 5 2.1.1 Hardware Abstraction Layer - EPPHAL.C ........................................................................................... 5 2.1.2 PDIUSBD12 Command Interface - D12CI.C........................................................................................ 5 2.1.3 Interrupt Service Routine - ISR.C ......................................................................................................... 5 2.1.4 Main Loop - MAINLOOP.C ................................................................................................................. 6 2.1.5 Protocol Layer - CHAP_9.C, PROTODMA.C....................................................................................... 6 2.2 PORTING THE FIRMWARE TO OTHER CPU PLATFORM ................................................................................... 6 2.3 USING THE FIRMWARE IN POLLING MODE .................................................................................................... 6 3 HARDWARE ABSTRACTION LAYER ....................................................................................................... 7 4 PDIUSBD12 COMMAND INTERFACE........................................................................................................ 7 5 INTERRUPT SERVICE ROUTINE .............................................................................................................. 8 5.1 BUS RESET AND SUSPEND CHANGE.............................................................................................................. 9 5.2 CONTROL ENDPOINT HANDLER.................................................................................................................. 10 5.3 GENERIC ENDPOINT HANDLER................................................................................................................... 13 5.4 MAIN ENDPOINT HANDLER........................................................................................................................ 13 5.5 EOT HANDLER ......................................................................................................................................... 13 6 MAIN LOOP................................................................................................................................................. 14 7 CHAPTER 9 PROTOCOL........................................................................................................................... 15 7.1 CLEAR FEATURE REQUEST ........................................................................................................................ 15 7.2 GET STATUS REQUEST............................................................................................................................... 16 7.3 SET ADDRESS REQUEST............................................................................................................................. 16 7.4 GET CONFIG REQUEST............................................................................................................................... 17 7.5 GET DESCRIPTOR REQUEST ....................................................................................................................... 17 7.6 SET CONFIG REQUEST ............................................................................................................................... 18 7.7 GET/SET INTERFACE REQUEST................................................................................................................... 18 7.8 SET FEATURE REQUEST ............................................................................................................................. 19 8 DMA SUPPORT............................................................................................................................................ 20 8.1 INTRODUCTION TO PROTOCOL BASED DMA OPERATION ............................................................................ 20 8.2 DEVICE'S DMA STATES............................................................................................................................. 20 8.3 DMA CONFIGURATION REGISTER.............................................................................................................. 21 8.4 SETUP DMA REQUEST .............................................................................................................................. 21 8.5 HOST SIDE PROGRAMMING CONSIDERATIONS............................................................................................. 22

Interconnectivity Page 4 of 22 Firmware Programming guide for PDIUSBD12 1 Introduction PDIUSBD12 is a high-speed USB interface device with parallel bus and local DMA transfer capability. The objective of the recommended firmware design is to enable PDIUSBD 12 to achieve the fastest transfer rate over USB Peripheral devices such as the printer, scanner, external mass storage, and digital camera can use PDIUSBD12 in transferring data over USB. The CPUs in these devices are very busy in handling many tasks like device control and data and image processing. The firmware of PDIUSBD 12 is designed to be fully interrupt-driven While CPU is doing its foreground task, the USB transfer is being handled in the background. This assures best transfer rate and better software structure and also simplifies programming and debugging The data exchange between the background ISR (Interrupt Service Routine) and the foreground Main Loop is achieved by event flags and data buffers. For example, the PDIUSBD12 Main bulk out endpoint can use a circular data buffer. When PDIUSBD12 receives a data packet from USB, an interrupt request is generated to the CPU and the CPU will service ISR immediately. Inside the ISR, the firmware moves the data packet to the ircular buffer from pdiusbd12 's internal buffer and then clears the pdiusbd i2's internal buffer to enable PDIUSBD12 to receive new packet. The CPU can continue its current foreground task until completion, e.g printing current page. Then it returns to the main loop, checks the circular buffers for new data, and starts another foreground task RXRP, Read Pointer maintained by main loop Main loop in foreground ISR in background Circular data buffer RXWP, Write Pointer maintained by ISr With this structure, the Main Loop does not care whether the data source is from USB, serial port, or parallel port. The Main Loop only checks the circular buffer for new data to be processed. This concept is very important. Thus, the Main Loop program can target on data processing and the ISr can do the job of data transfer at the fastest speed possible Similarly, the control endpoint uses the same concept in data packet handling. The ISR receives and stores control transfers in data buffers and sets the corresponding flag registers. The main loop will dispatch the request to protocol handling routines. Since all the standard device, class, and vendor requests are processed in protocol handling routines, ISR can maintain its efficiency. Also, when new request is added, only modification at the protocol level is needed llips Semiconductors-Asia Product Innovation Centre Visithttp://www.fler

Interconnectivity Page 4 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 1. Introduction PDIUSBD12 is a high-speed USB interface device with parallel bus and local DMA transfer capability. The objective of the recommended firmware design is to enable PDIUSBD12 to achieve the fastest transfer rate over USB. Peripheral devices such as the printer, scanner, external mass storage, and digital camera can use PDIUSBD12 in transferring data over USB. The CPUs in these devices are very busy in handling many tasks like device control and data and image processing. The firmware of PDIUSBD12 is designed to be fully interrupt-driven. While CPU is doing its foreground task, the USB transfer is being handled in the background. This assures best transfer rate and better software structure and also simplifies programming and debugging. The data exchange between the background ISR (Interrupt Service Routine) and the foreground Main Loop is achieved by event flags and data buffers. For example, the PDIUSBD12 Main bulk out endpoint can use a circular data buffer. When PDIUSBD12 receives a data packet from USB, an interrupt request is generated to the CPU and the CPU will service ISR immediately. Inside the ISR, the firmware moves the data packet to the circular buffer from PDIUSBD12's internal buffer and then clears the PDIUSBD12's internal buffer to enable PDIUSBD12 to receive new packet. The CPU can continue its current foreground task until completion, e.g. printing current page. Then it returns to the main loop, checks the circular buffers for new data, and starts another foreground task. With this structure, the Main Loop does not care whether the data source is from USB, serial port, or parallel port. The Main Loop only checks the circular buffer for new data to be processed. This concept is very important. Thus, the Main Loop program can target on data processing and the ISR can do the job of data transfer at the fastest speed possible. Similarly, the control endpoint uses the same concept in data packet handling. The ISR receives and stores control transfers in data buffers and sets the corresponding flag registers. The main loop will dispatch the request to protocol handling routines. Since all the standard device, class, and vendor requests are processed in protocol handling routines, ISR can maintain its efficiency. Also, when new request is added, only modification at the protocol level is needed. ISR in background Main loop in foreground RXWP, Write Pointer maintained by ISR RXRP, Read Pointer maintained by main loop Circular data buffer

Interconnectivity Page 5 of 22 Firmware Programming guide for PDIUSBD12 2. Architecture 2.1 Firmware Structure The firmware for the evaluation board consists of 6 building blocks. They are as folle ED. Process USB Bus Event. etc. MAINLOOP. C ndard Request Vendor request PROTODMA.C Interrupt Service Routine ISR. C Hardware Abstraction Layer EPPHAL C 2.1.1 Hardware Abstraction Layer -EPPHALC This is the lowest layer code in the firmware, which performs hardware dependent I/O access to PDIUSBD12 as well as Evaluation Board hardware. When porting the firmware to other CPU platforms, this part of code al ways needs modifications or additions 2.1.2 PDIUSBD12 Command Interface-D12CL C To further simplify programming with PDIUSBD 12, the firmware defines a set of command interfaces, which encapsulate all the functions used to access PDIUSBD12 2.1.3 Interrupt service Routine-ISR C This part of the code handles interrupt generated by PDIUSBD12. It retrieves data from PDIUSBD12's internal FIFO to CPU memory, and set up proper event flags to inform Main Loop program for processing llips Semiconductors-Asia Product Innovation Centre Visithttp://www.flexi

Interconnectivity Page 5 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 2. Architecture 2.1 Firmware Structure The firmware for the evaluation board consists of 6 building blocks. They are as follows: 2.1.1 Hardware Abstraction Layer - EPPHAL.C This is the lowest layer code in the firmware, which performs hardware dependent I/O access to PDIUSBD12, as well as Evaluation Board hardware. When porting the firmware to other CPU platforms, this part of code always needs modifications or additions. 2.1.2 PDIUSBD12 Command Interface - D12CI.C To further simplify programming with PDIUSBD12, the firmware defines a set of command interfaces, which encapsulate all the functions used to access PDIUSBD12. 2.1.3 Interrupt Service Routine - ISR.C This part of the code handles interrupt generated by PDIUSBD12. It retrieves data from PDIUSBD12's internal FIFO to CPU memory, and set up proper event flags to inform Main Loop program for processing. Hardware Abstraction Layer EPPHAL.C PDIUSBD12 Command Interface D12CI.C Main Loop: Dispatch USB Request, Read Test Keys, Control LED, Process USB Bus Event, etc. MAINLOOP.C Interrupt Service Routine ISR.C Standard Request CHAP_9.C Vendor Request PROTODMA.C

Interconnectivity Page 6 of 22 Firmware Programming guide for PDIUSBD12 2.1.4 Main Loop -MAINLOOPC he Main Loop checks the event flags and passes to appropriate subroutine for furthe It al contains the code for human interface, such as LED and key scan 2.1.5 Protocol Layer-CHAP_ 9.C, PROTODMAC The Protocol layer handles standard USB device requests, as well as specific vendor requests such as DMa and TWAIN 2.2 Porting the firmware to other cPU Platform Below table shows the modifications on building blocks need to be done. There are two levels of porting. First is Chapter 9 only, which is only make the firmware to pass enumeration by supporting standard USB requests. The second level is full product development, this will involve product specific firmware code hapter 9 Only EPPHAL. C Port to hardware specific Port to hardware specif DI2CI.C No change CHAP.C Product specific USB descriptors I PROTODMA C No change. I Add vendor request Add product specific processing on Generic and MAINLOOP. C Depends on the CPU and system Add product specific Main Loop processing ports, timer and interrupt initialization need to be rewritten There are CPU and compiler dependent pre-definitions in MAINLOOP. H: #define SWAP(x)(((x)&OxFF)>8)&OxFF)) #define SWAP(x)(x) #endif #define idata Note the"SWAP"is necessary for micro-controllers, which are big endian format, such as 8031. The"code"and idata"is only necessary when using 8031 and Keil C compiler 2.3 Using the Firmware in Polling Mode It's very easy to use the firmware in polling mode. Inside the Main Loop, add following code: Normally Isr is initiated by hardware. In polling mode, the Main Loop detects interrupt pin's state, and invokes ISR if necessary Visithttp://www.fler

Interconnectivity Page 6 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 2.1.4 Main Loop - MAINLOOP.C The Main Loop checks the event flags and passes to appropriate subroutine for further processing. It also contains the code for human interface, such as LED and key scan. 2.1.5 Protocol Layer - CHAP_9.C, PROTODMA.C The Protocol layer handles standard USB device requests, as well as specific vendor requests such as DMA and TWAIN. 2.2 Porting the Firmware to Other CPU Platform Below table shows the modifications on building blocks need to be done. There are two levels of porting. First is Chapter 9 only, which is only make the firmware to pass enumeration by supporting standard USB requests. The second level is full product development, this will involve product specific firmware code. File Name Chapter 9 Only Product Level EPPHAL.C Port to hardware specific. Port to hardware specific. D12CI.C No change. No change. CHAP_9.C No change. Product specific USB descriptors. PROTODMA.C No change. Add vendor request supports if necessary. ISR.C No change. Add product specific processing on Generic and Main endpoints. MAINLOOP.C Depends on the CPU and system, ports, timer and interrupt initialization need to be rewritten. Add product specific Main Loop processing. There are CPU and compiler dependent pre-definitions in MAINLOOP.H: #ifdef __C51__ #define SWAP(x) ((((x) & 0xFF) > 8) & 0xFF)) #else #define SWAP(x) (x) #define code #define idata #endif Note the "SWAP" is necessary for micro-controllers, which are big endian format, such as 8031. The "code" and "idata" is only necessary when using 8031 and Keil C compiler. 2.3 Using the Firmware in Polling Mode It's very easy to use the firmware in polling mode. Inside the Main Loop, add following code: if(interrupt_pin_low) fn_usb_isr(); Normally ISR is initiated by hardware. In polling mode, the Main Loop detects interrupt pin's state, and invokes ISR if necessary

Interconnectivity Page 7 of 22 Firmware Programming guide for PDIUSBD12 3. Hardware Abstraction Layer This layer contains the lowest layer functions that need to be changed on different CPU platforms rt(PIO_ REQUEST pio) All 1/O access to PDIUSBD12 should be implemented by the first two functions above(outport and inport) As for the last function, it is meant for implementing the"EPP DMA"function. The latter is for setting the EPP page address and CPLD counter. This type of implementation can allow the system to be platform independent, which means that the application s architecture can be used for platform other than 8051 or the PC For USB EPP evaluation board, the dma start functions calls the 2 function below, which are not necessary to be implemented in target application rogram cpld(unsigned shor unsigned char bCor 4. PDIUSBD12 Command Interface The following functions are defined as PDIUSBD12 command interface to simplify device programming. They are simple implementations of the PDIUSBD12 command set, which is defined in the data sheet id D12 SetAddressEnable(unsigned char bAddress, unsigned char bEnable) ned char eNable) void D12 SetMode(unsigned char cOnfig, unsigned char bClkDiv) oid D12 SetDMA(unsigned char bOde) unsigned char D12 SelectEndpoint(un unsigned char D12 ReadLastTransaction Status(unsigned char bEndp) oid D12 SetEndpointstatus(unsigned char bEndp, unsigned char sTalled) unsigned short D12 ReadCurrent Frame Number(void) unsigned char D12 Re nt(unsigned char endp, unsigned char*buf, unsigned char len ed char D12 Writ pint(unsigned char endp, unsigned char*buf, unsigned char len); oid D12 Acknowledge nt(unsigned char endp) llips Semiconductors-Asia Product Innovation Centre Visithttp://www.fler

Interconnectivity Page 7 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 3. Hardware Abstraction Layer This layer contains the lowest layer functions that need to be changed on different CPU platforms. void outportb(unsigned char port, unsigned char val); void inportb(unsigned char port); void dma_start(PIO_REQUEST pio) All I/O access to PDIUSBD12 should be implemented by the first two functions above (outportb and inportb). As for the last function, it is meant for implementing the "EPP DMA" function. The latter is for setting the EPP page address and CPLD counter. This type of implementation can allow the system to be platform independent, which means that the application's architecture can be used for platform other than 8051 or the PC. For USB_EPP evaluation board, the dma_start() functions calls the 2 function below, which are not necessary to be implemented in target application. void eppAwrite(unsigned char A_data); void program_cpld(unsigned short uSize, unsigned char bCommand); 4. PDIUSBD12 Command Interface The following functions are defined as PDIUSBD12 command interface to simplify device programming. They are simple implementations of the PDIUSBD12 command set, which is defined in the data sheet. void D12_SetAddressEnable(unsigned char bAddress, unsigned char bEnable); void D12_SetEndpointEnable(unsigned char bEnable); void D12_SetMode(unsigned char bConfig, unsigned char bClkDiv); void D12_SetDMA(unsigned char bMode); unsigned short D12_ReadInterruptRegister(void); unsigned char D12_SelectEndpoint(unsigned char bEndp); unsigned char D12_ReadLastTransactionStatus(unsigned char bEndp); void D12_SetEndpointStatus(unsigned char bEndp, unsigned char bStalled); void D12_SendResume(void); unsigned short D12_ReadCurrentFrameNumber(void); unsigned char D12_ReadEndpoint(unsigned char endp, unsigned char * buf, unsigned char len); unsigned char D12_WriteEndpoint(unsigned char endp, unsigned char * buf, unsigned char len); void D12_AcknowledgeEndpoint(unsigned char endp);

Interconnectivity Page 8 of 22 Firmware Programming guide for PDIUSBD12 5. Interrupt service Routine The PDIUSBD12 firmware is fully interrupt driven. The flow of ISR is straightforward and this is shown below Read D12 Interrupt Register Reset ldle Set Bus Reset Flag k+Yes Yes-+DMA EOT handler Subroutine >Y+cmRN性e Y→_ Generic RX handler Subroutin Yes-+Generic TX handler Subrou Yes-p Main tx handle Of ISR At the entrance of ISr, the firmware uses D12 ReadInterrupt Register to decide the source of interrupt and then to dispatch it to the appropriate subroutines for processing Visithttp://www.flexi

Interconnectivity Page 8 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 5. Interrupt Service Routine The PDIUSBD12 firmware is fully interrupt driven. The flow of ISR is straightforward and this is shown below. At the entrance of ISR, the firmware uses D12_ReadInterruptRegister() to decide the source of interrupt and then to dispatch it to the appropriate subroutines for processing. ISR ISR Entry Read D12 Interrupt Register Reset Idle Timer Bus Reset? Suspend Change? DMA EOT? Control In Done? Control Out Done? Generic In Done? Generic Out Done? Main In Done? Main Out Done? Send EOI to Interrupt Controller End of ISR No No No No No No No No No Set Bus Reset Flag Yes Set Suspend Changed Flag DMA EOT handler Subroutine Control RX handler Subroutine Control TX handler Subroutine Generic RX handler Subroutine Generic TX handler Subroutine Main RX handler Subroutine Main TX handler Subroutine Yes Yes Yes Yes Yes Yes Yes Yes

Interconnectivity Page 9 of 22 Firmware Programming guide for PDIUSBD12 The isr communicates with the foreground Main Loop through event flags"EPPFLAGS"and data buffers "CONTROL XFER" typedef union_ epr struct ned char nsigned cha unsigned char remote wakeup 1 unsigned char in is unsigned char control state 2: unsigned char ep1 rxdone 1 char setup dm unsigned char dma state 2: signed short value: typedef struct device_ request signed short wvalue signed short wIndex, unsigned short lEngth 1DEVICE_ REQUEST: DEVICE REQUEST Device Request unsigned short lEngth unsigned char’pDaa unsigned char data Buffer[MAX CONTROLDATA SIZE the data. The isR will only inform Main Loop that data is ready for processing when it has collected egg n The task splitting between Main Loop and ISR is that ISr collects data from D12 and Main Loop will proces data. For example, in the case of setup packet with ouT data phase, the ISR will store both setup packet and oUT data to buffer"CONTROL XFER"before it signals"setup packet"flag to Main Loop. This will reduce unnecessary Main Loop servicing time and also simply Main Loop programming 5.1 Bus Reset and Suspend Change Bus reset and suspend does not require special processing within ISR. ISR either sets the bus reset flag or spends the bit in EPPFLAGS and exit. llips Semiconductors-Asia Product Innovation Centre Visithttp://www.fler

Interconnectivity Page 9 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com The ISR communicates with the foreground Main Loop through event flags "EPPFLAGS" and data buffers "CONTROL_XFER". typedef union _epp_flags { struct _flags { unsigned char timer : 1; unsigned char bus_reset : 1; unsigned char suspend : 1; unsigned char setup_packet : 1; unsigned char remote_wakeup : 1; unsigned char in_isr : 1; unsigned char control_state : 2; unsigned char configuration : 1; unsigned char verbose : 1; unsigned char ep1_rxdone : 1; unsigned char setup_dma : 1; unsigned char dma_state : 2; } bits; unsigned short value; } EPPFLAGS; typedef struct _device_request { unsigned char bmRequestType; unsigned char bRequest; unsigned short wValue; unsigned short wIndex; unsigned short wLength; } DEVICE_REQUEST; typedef struct _control_xfer { DEVICE_REQUEST DeviceRequest; unsigned short wLength; unsigned short wCount; unsigned char * pData; unsigned char dataBuffer[MAX_CONTROLDATA_SIZE]; } CONTROL_XFER; The task splitting between Main Loop and ISR is that ISR collects data from D12 and Main Loop will process the data. The ISR will only inform Main Loop that data is ready for processing when it has collected enough data. For example, in the case of setup packet with OUT data phase, the ISR will store both setup packet and OUT data to buffer "CONTROL_XFER" before it signals "setup_packet" flag to Main Loop. This will reduce unnecessary Main Loop servicing time and also simply Main Loop programming. 5.1 Bus Reset and Suspend Change Bus reset and suspend does not require special processing within ISR. ISR either sets the bus_reset flag or suspends the bit in EPPFLAGS and exit

Interconnectivity Page 10 of 22 Firmware Programming guide for PDIUSBD12 5.2 Control Endpoint Handler Control Write DLE RECEIVE Control transfer always begins with the SETUP stage and then followed later by an optional DATA stage. It then ends with the status stage. the diagram below shows the various states of transitions on the Control endpoints. The firmware uses these 3 states to handle Control transfer correctly Visithttp://www.fler

Interconnectivity Page 10 of 22 Firmware Programming Guide for PDIUSBD12 Philips Semiconductors - Asia Product Innovation Centre Visit http://www.flexiusb.com 5.2 Control Endpoint Handler Control transfer always begins with the SETUP stage and then followed later by an optional DATA stage. It then ends with the STATUS stage. The diagram below shows the various states of transitions on the Control endpoints. The firmware uses these 3 states to handle Control transfer correctly. TRANSMIT IDLE RECEIVE No-data Control return Status Control Write Status Control Read Status INs OUTs

点击下载完整版文档(PDF)VIP每日下载上限内不扣除下载券和下载次数;
按次数下载不扣除下载券;
24小时内重复下载只扣除一次;
顺序:VIP每日次数-->可用次数-->下载券;
共22页,试读已结束,阅读完整版请下载
相关文档

关于我们|帮助中心|下载说明|相关软件|意见反馈|联系我们

Copyright © 2008-现在 cucdc.com 高等教育资讯网 版权所有