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.flerInterconnectivity 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