Electronica digital

Introducing the USB software interface

Microchip provides a layer of software for the PIC16C745/65 that handles the lowest level interface so your application won’t have to. This provides a simple Put/Get interface for communication. Most of the USB processing takes place in the background through the Interrupt Service Routine. From the application viewpoint, the enumeration process anddata communication takes place without further interaction. However substantial setup is required in the form of generating appropriate descriptors.

Integrating USB into your application

The latest version of the USB interface software is available on Microchip’s website. See http://www.microchip.com/

The interface to the application is packaged in 5 functions: InitUSB,PutEP1, PutEP2, GetEP1 and GetEP2. InitUSB initializes the USB peripheral allowing the host to enumerate the device. Then for normal data communications, the PutEPn functions send data to the host and the GetEPn functions receive data from the host.

There’s also a fair amount of setup work that must be completed. USB depends heavily on the descriptors. These are the software parameters thatare communicated to the host to let it know what the device is, and how to communicate with it. See USB V1.1 spec section 9.5 for more details.

InitUSB enables the USB interrupt so enumeration can begin. The actual enumeration process occurs in the background, driven by the host and interrupt service routine. Macro ConfiguredUSB waits until the device is in the CONFIGURED state. The timerequired to enumerate is completely dependent on the host and bus loading.

Interrupt structure concerns

Processor Resources

Most of the USB processing occurs via the interrupt and thus is invisible to the application. However it still consumes processor resources. These include ROM, RAM, Common RAM, Stack Levels and processor cycles. This section attempts to quantify theimpact on each of these resources, and shows ways to avoid conflicts.

These considerations should be taken into account if you write your own Interrupt Service Routine: Save W, STATUS, FSR and PCLATH which are the file registers that may be corrupted by servicing the USB interrupt.

The file usb_main.asm provides a skeleton ISR which does this for you, and includes tests for each of thepossible ISR bits. This provides a good starting point if you haven’t already written your own.

Stack Levels

The hardware stack on the PIC is only 8 levels deep. So the worst case call between the application and ISR can only be 8 levels. The enumeration process requires 4 levels, so it’s best if the main application holds off on any processing until enumeration is complete.ConfiguredUSB is a macro that waits until the enumeration process is complete for exactly this purpose. This macro does this by testing the lower two bits of USWSTAT (0x197).

ROM

The code required to support the USB interrupt, including the chapter 9 interface calls, but not including the HID interface calls or descriptor tables is about 1kW. The HID specific functions and descriptortables take up additional memory. The location of these parts is not restricted, and the linker script may be edited to control the placement of each part. See the Strings and Descriptors sections in the linker script.

RAM

With the exception of Common RAM discussed below, servicing the USB interrupt requires approximately 40 bytes of RAM in Bank 2. That leaves all the General PurposeRAM in banks zero and one, plus half of Bank 2 available for your application to use.

Common RAM usage

The PIC16C745/765 has 16 bytes of common RAM. These are the last 16 addresses in each bank and all refer to the same 16 bytes of memory without regard to which register bank is currently addressed by the RP0, RP1 and IRP bits.

These are particularly useful when responding to...