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)I(((x)>>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) | (((x) >> 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