Dotric Pty Ltd - Software

USB Communications Using Microchip PIC

Doug Richards, Dotric Pty Ltd, July 2014.
Revised June 2015

Introduction
Hardware Considerations
Program Start Up
Setup Sequence
Application Data
The PC End
Conclusion

Introduction

All Dotric Station Blue model railway controller modules to date have offered Bluetooth or serial port as the means of communication to the controlling computer. In every case the microcontroller at the device end has been the Microchip 18F4520. The popularity of model railway automation has directed development effort towards the desktop computer. Since desktop computers are no longer sold with operating serial ports, it seems logical to offer a USB alternative to Dotric Station Blue customers.

Conceptually the idea is to replace the 18F4520 chip with the 18F4550 which additionally has a USB interface. Firmware changes should be restricted to those changes necessary for USB communications. The existing firmware is written in Microchip assembler and runs at 40MHz using a 10MHz crystal. The nearest clock speed available with the 18F4550 is 48MHz using a 20MHz crystal.

The largest single serial port message used by Dotric Station Blue is 15 bytes long. A USB HID (Human Interface Device) interface running at full speed therefore seems possible.

My starting point for this project was this good book:

USB Complete Fourth Edition by Jan Axelson

While this book remains my first reference for everything USB, it is a little short on the bits and bytes level information required for assembler coded firmware. The best single example of Microchip assembler source code for a USB HID I have found is the following:

http://www.marcansoft.com/subidos/sdgp.zip

I understand that this source code was based on a similar work produced by Bradley Minch, who is worth a google since he appears in a number of public forums. Also worth a look is the following brief but very informative website:

http://www.usbmadesimple.co.uk/

And of course the Microchip data sheet is essential:

Microchip PIC18F2455/2550/4455/4550 Data Sheet

Hardware Considerations

The USB standard B socket proposed to be used with USB equipped Dotric Station Blue modules is shown below:

The 0V USB line and the earth shield are connected directly to the circuit zero voltage supply rail. The basic rules of USB seem to indicate that circuits should behave like they are powered via the USB cable even when they are not. Dotric Station Blue model railway controls will of course not be powered from the USB cable so the Self Power Only option described in Section 17.6.2 in the Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 186 will be implemented. Here the 5v USB line is connected to a digital input pin on the PIC via a 100K resistor. Within the PIC assembly code I stop execution before my main loop and before any USB process until that digital input pin goes high. On every pass within my main loop I check that digital input pin and call device reset if it goes low.

The capacitor between VDD and circuit zero is routine. I use a 0.22uF tantalum capacitor between VUSB and circuit zero as recommended elsewhere in the datasheet to assist in the regulation of the PIC 3.3V internal power supply.

The proposed full speed data lines in fact run at 12 MBits/sec, so consideration must be given to unwanted capacitance effects and matched terminations. However, the PIC does apparently provide the correct termination internally. So provided the leads from the D+ and D- lines are short, from an electrical point of view at least, data transmission should be trouble free. To provide an indication of what a trouble free connection might look like, I have provided a photograph of my breadboard setup below.

Not especially tidy but the D- and D+ lines are short. Below is an oscilloscope display of the data on those D- and D+ lines.

Again not especially tidy but good enough for trouble free operation.

Program Start Up

I want full speed USB communications which requires a 48MHz USB clock. I want a 48Mhz CPU clock for my application. Referring to Figure 2.1 in the Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 24 my 20MHz crystal oscillator needs to be divided down to 4MHz using the PLLDIV MUX and PLL Prescalar. This will achieve the 48MHz USB clock provided USBDIV is one and the FSEN flag is set in the UCFG register. My 48Mhz CPU clock is achieved by using the CPUDIV MUX to select a by 2 division of the 96MHz PLL output. FOSC3:FOSC0 needs to be set to one. All this is implemented with the following config settings:

CONFIG PLLDIV=5,CPUDIV=OSC1_PLL2,USBDIV=2,FOSC=HSPLL_HS

Referring to the Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 174, there are 32 end points ranging from EP0 to EP31. Each end point has two sets of the registers BDnSTART, BDnCNT, BDnADRL and BDnADRH. In each case one set is for IN messages and the other set is for OUT messages. For the sake of confusion USB terminology is PC centric, so IN refers to messages being sent by the device and OUT refers to messages being received by the device.

BDnSTAT contains the UOWN flag which determines whether you or the microcontroller core "owns" the BDnSTAT, BDnCNT, BDnADRL and BDnADRH registers. BDnSTAT is also used to read and set DATA0/DATA1. DATA0/DATA1 is used to check for the correct sequencing of USB messages. If you are having trouble getting USB communications to work then there is a good chance that the DATA0/DATA1 sequencing is not correct. BDnCNT contains the message length. BDnADL and BDnADRH contain the starting address for the actual USB message either sent or received.

One important sentence on page 174 that I totally missed the first time I read the text is:

Although they can be thought of at Special Function Registers, the Buffer Descriptor Status and Address registers are not hardware mapped ...

Perhaps more to the point, these registers need to implemented by yours truly! Additionally these registers and associated buffers occupy pages 4 and 5 of data memory. Fortunately 18F4550 has an extra two pages of data memory over the 18F4520 I am replacing. Unfortunately I have to move the data that was on pages 4 and 5 to pages 6 and 7. My buffer descriptor status and address register definitions are as follows:

#define BD0OSTAT 0x400
#define BD0OCNT 0x401
#define BD0OADRL 0x402
#define BD0OADRH 0x403
#define BD0ISTAT 0x404
#define BD0ICNT 0x405
#define BD0IADRL 0x406
#define BD0IADRH 0x407
#define BD1OSTAT 0x408
#define BD1OCNT 0x409
#define BD1OADRL 0x40A
#define BD1OADRH 0x40B
#define BD1ISTAT 0x40C
#define BD1ICNT 0x40D
#define BD1IADRL 0x40E
#define BD1IADRH 0x40F

Since they are my registers I can call them whatever I please and have elected to go for the "Hector Martin" convention. The USB setup process always uses endpoint EP0 and I plan to use endpoint EP1 for all my Dotric Station Blue application messages so these are the only end point registers I have bothered to define.

The more relevant USB related parts of my start up sequence are shown below:

WaitForUSBConnection

: bra WaitForUSBConnection
movlw (1 << UPUEN) + (1 << FSEN)
movwf UCFG ; Internal pullup & transceiver on
clrf USTAT
movlw (1 << USBEN)
movwf UCON

SingleEndedZero

: bra SingleEndedZero ; Loop until out of single ended cond
movlw (1 << TRNIE) | (1<< URSTIE)
movwf UIE ; Set up USB Interrupt
movlw (1 << USBIE)
movwf PIE2
movlw ((1 << GIE) + (1 << PEIE)) ; Start interrupts
movwf INTCON
movlw (1 << USBEN) ; Try again
movwf UCON

As described earlier, I loop until the USB 5V line goes high. The UPUEN and FSEN flags are set to provide the correct internal pull up resistor configuration for full speed USB. The USBEN flag is used to enable the USB interface, but then I must wait until the single ended condition ends.

The existing Dotric Station Blue code uses interrupts to detect serial port activity and uses circular buffers to pass data to and from the main program. So to retain this structure, I have set up similar interrupts on USB activity. The TRNIE flag is used to detect transmission activity and the URSTIE flag is used to detect a USB reset. Once these interrupts have been connected up the USB enable is attempted again.

My interrupt routine is shown, in part below:

btfss UIR, URSTIF
: bra NotUSBReset
call USBReset

NotUSBReset

btfss UIR, TRNIF
: bra NotUSBInterrupt

CheckTransaction

movlw B'01111000'
andwf USTAT, w
btfss STATUS, Z
: bra NotEndPointZero
call EndPointZero
bra ClearUSBInterrupt

NotEndPointZero

call EndPointOne

ClearUSBInterrupt

bcf UIR, TRNIF
btfsc UIR, TRNIF ; check FIFO
: bra CheckTransaction

Here I use the URSTIF flag to detect a USB reset and the TRNIF flag to detect USB transmission activity. If there is USB transmission activity I use the USTAT register to separate endpoint zero (EP0) activity from end point 1 (EP1) activity. For my application at least, endpoint zero (EP0) is USB setup stuff and endpoint one (EP1) is Dotric Station Blue model railway stuff.

Of note is the behaviour of the FIFO described in the Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 170. Once the TRNIF flag is cleared it is important to check it in case it has been immediately reset indicating that there is more transmission activity in the queue.

Two fundamental differences between USB and serial port communication are: firstly unlike serial port communications USB is not full duplex, and secondly unlike serial port commmunications, preemptive messages cannot be sent from a device with USB. Even HID devices like keyboards rely on being polled by the PC. So in terms of this interrupt routine, there use to be a specific serial port send interrupt to indicate when the serial port send buffer was empty and more data could be sent. There is no equivalent with USB.

Setup Sequence

Referring to figure 4.1 on page 91 of USB Complete Fourth Edition by Jan Axelson, this complete scenario must occur if the coveted "The device is working properly" message is to appear in Windows Device Manager for your device.

If you don't have the book on hand the sequence is:

Reset
GetDescriptor (Device)
Reset
SetAddress
GetDescriptor (Device)
GetDescriptor (Configuration - short)
GetDescriptor (Configuration - long)
GetDescriptor (String - language id)
GetDescriptor (String - Product)
GetDescriptor (String - language id)
GetDescriptor (String - Product)
GetDescriptor (Device)
GetDescriptor (Configuration - short)
GetDescriptor (Configuration - long)
GetStatus (Device)
SetConfiguration

Reset

Reset detection is in my interrupt routine described above. Basically the URSTIF flag in the UIR register is used to detect a reset. Once detected, your reset routine is an ideal place to intialize all your USB related variables.

In my reset routine I start off by flushing out the FIFO described in the Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 170:

bcf UIR, TRNIF
bcf UIR, TRNIF
bcf UIR, TRNIF
bcf UIR, TRNIF

Then I disable all sixteen endpoints:

movlw 16
lfsr FSR1, UEP0

ClearEP

clrf POSTINC1
decfsz WREG, f
bra ClearEP

Now we actually need to populate those not so special buffer descriptor status and address registers described earlier. I only bother to set up the registers for endpoints EP0 and EP1 because these are the only two end points I intend to use. Firstly, the message byte count in each case is set to the maximum allowable of 64 bytes:

movlb 4
movlw EP0MAXPS
movwf BD0OCNT, 1
movwf BD0ICNT, 1
movwf BD1OCNT, 1
movwf BD1ICNT, 1

Then those address registers need to point to the message buffers on page 5 of data memory:

clrf BD0OADRL, 1
movlw 0x3F
movwf BD0IADRL, 1
movlw 0x7F
movwf BD1OADRL, 1
movlw 0xBF
movwf BD1IADRL, 1
movlw 0x05
movwf BD0OADRH, 1
movwf BD0IADRH, 1
movwf BD1OADRH, 1
movwf BD1IADRH, 1

There is also the not so special status registers. I initially set the UOWN flag for "O" or incoming messages so that the microcontroller core has initial control of incoming messages and clear the UOWN flag for "I" or outgoing messages so that I have initial control of outgoing messages. The DTS flag is initially cleared in all cases so that the DATA0/DATA1 sequence is initialized to DATA0.

movlw (1<<UOWN)|(1<<DTSEN)
movwf BD0OSTAT, 1
movwf BD1OSTAT, 1
movlw (1<<DTSEN)
movwf BD0ISTAT, 1
movwf BD1ISTAT, 1
clrf BSR

Now I need to supply the micrprocessor core with the USB address of my device using the UADDR register. The attached PC will initially give my device the USB address of zero, so the UADDR register should be initially cleared:

clrf UADDR

Clear the USB interrupt register:

clrf UIR

Finally I enable endpoints EP0 and EP1. I want handshaking, incoming messages and outgoing messages on both endpoints, but I only want setup messages to occur on endpoint EP0.

movlw (1 << EPHSHK) | (1 << EPOUTEN)| (1 << EPINEN)
movwf UEP0
movlw (1 << EPHSHK) | (1 << EPCONDIS) | (1 << EPOUTEN)| (1 << EPINEN)
movwf UEP1

EndPoint Zero

Once the reset routine is organised, the rest of the 16 step setup sequence is a case of processing incoming messages and responding as necessary. All setup messages occur on endpoint zero (EP0). While I find the processing of incoming (OUT) messages a little bit idiosyncratic, I find the processing of outgoing (IN) messages to be completely weird. This weirdness I believe, is due to the inability to send preemptive messages. Basically the procedure is to arm the appropriate message buffer and then wait for an IN interrupt from the PC before actually sending the message. A DATA0/DATA1 toggle actually needs to occur between the arming and the sending.

Another unusual feature of this process is the dual functionality of the not so special USB status registers as described in Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 177. In particular:

When the BD and its buffer are owned by the SIE, most of the bits in BDnSTAT take on a different meaning.

Before we start processing messages there is a handy piece of special register structure that may not be immediately apparent. Referring to the Microchip PIC18F2455/2550/4455/4550 Data Sheet on Page 171, if you apply a mask for bits 2 to 6 of USTAT you instantly have the address of the correct BDnSTAT register on page 4 of data memory.

So my interrupt routine described earlier has detected a transaction using the TRNIF flag in UIR and has used USTAT to determine which endpoint the message is on. I then use USTAT again to get the contents of the appropriate BDnSTAT register while it is still owned by the SIE as follows:

movlw 0x04
movwf FSR1H
movf USTAT, w
andlw B'01111100'
movwf FSR1L
movf POSTINC1, w
andlw B'00111100'
movwf Token , 1

Once I have the contents of BDnSTAT, I apply a mask for bits 2 to 5 to its contents and save that to Token. Now Token may have one of the following values:

#define TOKEN_OUT (0x01<<2)
#define TOKEN_ACK (0x02<<2)
#define TOKEN_IN (0x09<<2)
#define TOKEN_SETUP (0x0D<<2)

TOKEN_OUT refers to incoming messages on endpoint EP0 that are not related to the setup sequence. I basically do nothing with this or TOKEN_ACK. TOKEN_IN is important. As mentioned earlier, sending any messages back to the PC is a two step process of arming and then sending went requested to do so. TOKEN_IN is that request to send the message.

Finally there is TOKEN_SETUP which indicates that a setup message has been received from the PC. At this point we know that the received message is in the message buffer referred to by the not so special registers BD0OADRL and BD0OADRH. I have found that I actually only need five variables out of received setup messages and I obtain them as follows:

movff BD0OADRL, FSR1L
movff BD0OADRH, FSR1H
movff POSTINC1, bmRequestType
movff POSTINC1, bRequest
movff POSTINC1, bDscIndexADRL
movff POSTINC1, bDscTypeADRH
movff POSTINC1, UsbLength
movff POSTINC1, UsbLength
movff POSTINC1, UsbLength ;Length of the required response

Firstly a bit of housekeeping:

movlb 4
movlw EP0MAXPS
movwf BD0OCNT, 1
movlw (1 << DTSEN)
movwf BD0ISTAT
clrf BSR

The incoming message count is set to EP0MAXPS - 64 bytes. The DATA0/DATA1 sequence is set to DATA0 for outgoing messages.

So to the first byte in the received message - bmRequestType. It contains the following information:

bits 0 to 5: 00000 = device, 00001 = interface, 00010 = endpoint, 00011 = other
bits 6 to 7: 00 = standard, 01 = class, 10 = vendor

For reasons I don't really understand, the DATA0/DATA1 sequence for incoming messages is set differently for standard and class setup messages:

movlw 0x21

cpfseq bmRequestType, 1

bra SetUp21

movlw (1<<UOWN)|(1<<DTS)|(1<<DTSEN)

bra SetUpReady

SetUp21

movlw (1<<UOWN)|(1<<DTSEN)

SetUpReady

movlb 4
movwf BD0OSTAT, 1
clrf BSR

Following this the setup request is separated out into standard, class and vendor requests. I don't do anything with the vendor requests and while I do have set and get report routines associated with class requests, I am not convinced they actually do anything. I find that all the action occurs with standard requests.

Moving on to the second byte in the received message - bRequest. It may have one of the following values:

#define NO_REQUEST 0xFF
#define USB_REQUEST_GET_STATUS 0
#define USB_REQUEST_CLEAR_FEATURE 1
#define USB_REQUEST_SET_FEATURE 3
#define USB_REQUEST_SET_ADDRESS 5
#define USB_REQUEST_GET_DESCRIPTOR 6
#define USB_REQUEST_SET_DESCRIPTOR 7
#define USB_REQUEST_GET_CONFIGURATION 8
#define USB_REQUEST_SET_CONFIGURATION 9
#define USB_REQUEST_GET_INTERFACE 10
#define USB_REQUEST_SET_INTERFACE 11

Now referring to those vital 16 steps in the setup sequence, the way forward should be clear. It should be even clearer when I point out that the fourth byte in the received message - bDscTypeADRH may have one of the following values:

#define USB_DESCRIPTOR_DEVICE 0x01
#define USB_DESCRIPTOR_CONFIGURATION 0x02
#define USB_DESCRIPTOR_STRING 0x03
#define USB_DESCRIPTOR_INTERFACE 0x04
#define USB_DESCRIPTOR_ENDPOINT 0x05
#define USB_DESCRIPTOR_DEVICE_QUALIFIER 0x06
#define USB_DESCRIPTOR_OTHER_SPEED 0x07
#define USB_DESCRIPTOR_INTERFACE_POWER 0x08
#define USB_DESCRIPTOR_OTG 0x09

In addition if you are setting up a HID device as I am, the fourth byte in the received message - bDscTypeADRH may also have one of the following values:

#define DSC_HID 0x21
#define DSC_RPT 0x22
#define DSC_PHY 0x23

Now referring again to those 16 steps my GetDescriptor - Device response is:

Value	Variable	Description
0x12	bLength	Size of this message in bytes
0x01	USB_DESCRIPTOR_DEVICE	Descriptor Type - Device
0x0111	bcdUSB	USB Specification release number 1.11
00	bDeviceClass	Class is specified in interface descriptor
00	bDeviceSubClass
00	bDeviceProtocol
0x40	bMaxPacketSize	EP0 maximum packet size
0x04D8	idVendor	Microchip vendor id
0x4242	idProduct	any number really - refer to text below
0x0100	bcdDevice	device release number
0x01	iManufacturer	used to reference string in string descriptors
0x02	iProduct	used to reference string in string descriptors
00	iSerialNumber	A zero indicates that there is no serial number
0x01	bNumVConfigurations	Number of configurations

Firstly it should be noted that when sending 16 bits variables, the low bytes are sent first. The idVendor and idProduct values provided here actually appear in the Device Instance Id property string displayed by Device Manager on the connected PC. As shown these values appear directly after the strings "VID_" and "PID_" and importantly provide the means of identifying your device and obtaining a handle for it on the PC.

I originally had 2.0 as the USB specification release number which worked well with Windows 7 but produced requests for information on high speed operation with Windows XP. USB specification 1.11 seems to work well with both platforms. It should also be noted that the iManufacturer and iProduct indices provided here will appear in the GetDescriptor - String set up messages received later in the setup process.

The process of sending this response is a case of loading up the message buffer referred to by the not so special BD0IADRL and BD0IADRH registers and setting BD0ICNT to the message length - 0x12 in this case. I use the following routine to set BD0ISTAT and keep the DATA0/DATA sequence on track:

movlb 4
movf BD0ISTAT, w, 1
xorlw 1 << DTS
andlw 1 << DTS
iorlw (1 << UOWN) | (1 << DTSEN)
movwf BD0ISTAT, 1
clrf BSR
bcf UCON, PKTDIS

Keep in mind that once this process is complete, you will be asked to effectively send the same message again via a TOKEN_IN request. Since my variables bmRequestType, bRequest and bDscTypeADRH haven't changed in the interim, I simply call the same routine again when I get that TOKEN_IN request. And yes toggling DATA0/DATA1 is the right thing to do.

Moving on with the 16 step setup sequence, we get to SetAddress. Now the USB address for my device is saved to special register UADDR. During the reset routine UADDR was set to zero. So up to this point all the setup requests have been sent to USB address zero. Not surprisingly, once the SetAddress request has been successful, all subsequent setup requests will be to the USB address supplied in the SetAddress request.

The third byte in the received message - bDscIndexADRL is in fact the USB address that the PC has allocated to my device. However, the process is not quite a simple matter of saving this value to UADDR because of that following TOKEN_IN request that will also be using USB address zero. So when I receive the SetAddress request I save the provided USB address as a temporary variable:

movff bDscIndexADRL, UsbAddrPend
movlb 4
clrf BD0ICNT, 1
movlw (1<<UOWN)|(1<<DTS)|(1<<DTSEN)
movwf BD0ISTAT, 1
clrf BSR
bcf UCON, PKTDIS

Then when I get that TOKEN_IN request I save the address to UADDR:

ProcessTokenIn

movlw USB_REQUEST_SET_ADDRESS

cpfseq bRequest, 1

bra NotSetAddress

movff UsbAddrPend, UADDR

return

NotSetAddress

movlw USB_REQUEST_GET_DESCRIPTOR

cpfseq bRequest, 1

return

goto UsbRequestGetDescriptor

Moving on in the 16 step setup sequence we get to GetDescriptor - Configuration - short and GetDescriptor - Configuration - long. The required response to GetDescriptor - Configuration - short is the first nine bytes of the required response to GetDescriptor - Configuration - long. Determining which response to send is a case of checking the seventh byte in the received message - UsbLength. If UsbLength is 9 the short response is required. Otherwise respond with a long message such as the one shown:

Value	Variable	Description
0x09	bLength	Size of this message component in bytes
0x02	USB_DESCRIPTOR_CONFIGURATION	Descriptor Type - Configuration
0x0029	wTotalLength	Total length of the long response
0x01	bNumInterfaces	Number of interface in this configuration
0x01	bConfigurationValue	Index of this configuration
0	iConfiguration	Configuration string index
0xC0	bmAttributes	Attributes - in this case self powered only
0x32	bMaxPower	Maximum power consumption (100mA)
0x09	bLength	Size of this message component in bytes
0x04	USB_DESCRIPTOR_INTERFACE	Descriptor Type - Interface
0	bInterfaceNumber	Interface number
0	bAlternateSetting	Alternate setting number
0x02	bNumEndpoints	Number of endpoints in this interface
0x03	bInterfaceClass	Interface class (HID)
0	bInterfaceSubclass	Interface subclass
0	bInterfaceProtocol	Interface protocol
0	iInterface	Interface string index
0x09	bLength	Size of this message component in bytes
0x21	DSC_HID	Descriptor Type - HID
0x0111	bcdHID	HID specification release number
0	bCountryCode	Country code
0x01	bNumDescriptors	Number of subordinate class descriptors
0x22	bDescriptorType (DSC_RPT)	Descriptor type (report)
0x0022	wDescriptorLength	Report descriptor size in bytes
0x07	bLength	Size of this message component in bytes
0x05	USB_DESCRIPTOR_ENDPOINT	Descriptor Type - endpoint
0x01	bEndpointAddress	Endpoint number and direction (1 OUT)
0x03	bmAttributes	Transfer type - interrupt
0x000F	wMaxPacketSize	Maximum packet size
0x0A	bInterval	Polling interval (milliseconds)
0x07	bLength	Size of this message component in bytes
0x05	USB_DESCRIPTOR_ENDPOINT	Descriptor Type - endpoint
0x81	bEndpointAddress	Endpoint number and direction (1 IN)
0x03	bmAttributes	Transfer type - interrupt
0x000F	wMaxPacketSize	Maximum packet size
0x0A	bInterval	Polling interval (milliseconds)

One may observe that this message is structured like 5 descriptor response messages combined into one. In fact, I have structured my code to be able to respond to Get Descriptor types USB_DESCRIPTOR_CONFIGURATION, USB_DESCRIPTOR_INTERFACE, DSC_HID and USB_DESCRIPTOR_ENDPOINT when each is requested separately. However in reality I believe that if wTotalLength is set to the total length of all of these responses in that first short GetDescriptor - Configuration response, then the PC will "swallow the whole lot in one shot" when it requests the long response.

While many of the variables here are merely transcriptions from other code samples, a few variables are noteworthy. The bmAttributes value of 0xC0 indicates a self powered device without remote wakeup. The bNumEndpoints value of 0x02 indicates that this configuration has 2 endpoint descriptors. The bInterfaceClass value of 0x03 indicates that this device is a HID. The wDescriptorLength value of 0x0022 indicates that our response to the GetDescriptor - Report (DSC_RPT) request will be 34 bytes long. The two bEndpointAddress values of 0x01 and 0x81 indicate that both incoming and outgoing application data streams occur on endpoint EP1. The two bInterval values of 0x0A indicate a polling interval of 10ms. Given a proposed message length of 15 bytes, this will give me an effective data rate of 15 bytes per 10ms or 12,000 baud.

A wMaxPacketSize value of 0x000F is used for both the incoming and outgoing application data streams. This seems like a repeat of the information supplied in the Report Descriptor described next, but maybe the information here has more to do with the operation of the interrupts than the report content. I understand that the maximum possible packet size here is 64 bytes. Now if your report size is bigger than this I believe that muliple interrupts will be triggered to fill your report with multiple 64 byte chunks. If this sounds like you it might pay to revisit my earlier comments about the FIFO.

The 34 byte response to the GetDescriptor - Report (DSC_RPT) request just mentioned is as shown:

Code	Value	Description
0x06	0xFFA0	Usage page
0x09	0x01	Usage
0xA1	0x01	Collection
0x09	0x03	Usage
0x15	0	Logical minimum
0x26	0x00FF	Logical maximum
0x75	0x08	Report size
0x95	0x0F	Report count
0x81	0x02	Input
0x09	0x04	Usage
0x15	0	Logical minimum
0x26	0x00FF	Logical maximum
0x75	0x08	Report size
0x95	0x0F	Report count
0x91	0x02	Output
0x0C		End collection

First point to be noted is that the format of this response is quite different to the others. Instead of following a preset format, it has codes immediately followed by values. Once again many of my values simply follow other code samples. However, it should be noted that my response describes one input and one output. Both have a report size of 8 and a report count of 15 indicating that both my incoming and outgoing messages consist of fifteen eight bit bytes.

Noteable for its absence is code 0x85 - Report Id. The Report Id of each endpoint is added to the front of every message sent and received by the connected PC. The Report Id is thus used to associate specific messages with specfic endpoints at the PC end. I have not included Report Id values in my GetDescriptor - Report (DSC_RPT) response because of course, I am using only one endpoint for all my application data. In the absence of a specified Report Id value, the default Report Id value is zero.

Referring back to the 16 step setup sequence, there is the GetDescriptor - String request . Now in my response to the GetDescriptor - Device request I provided the string indices for iManufacturer and iProduct. These indices will appear in turn in the GetDescriptor - String requests in the third byte - bDscIndexADRL. Also appearing in turn will be an index value of zero which is a request for language id. The only language I am supporting at this stage is English which has a language id of 0x0409. My response is therefore:

Value	Variable	Description
0x04	bLength	Size of this message in bytes
0x03	USB_DESCRIPTOR_STRING	Descriptor Type - String
0x0409	wLangId	Language Id

The responses to the iManufacturer and iProduct indices simply consist of the message size, descriptor type (USB_DESCRIPTOR_STRING) and any desired string. These strings must be in 16 bit unicode format, which for English letters consist of ASCII characters in the low bytes and zeroes in the high bytes. Keep in mind that low bytes are sent first. Now I wouldn't spent too much time on this exercise. I have been unable to find my manufacturer string anywhere on my PC. My product string appears in a balloon in the bottom right hand corner of the monitor when my device is first installed, but is thereafter gone forever unless my device fails, in which case the product string seems to become prevalent again.

Last but certainly not least is the SetConfiguration request. Basically this is the "Thunderbirds are go" message. I respond to this one with a zero length message.

Application Data

My basic stategy is have all of my Dotric Station Blue application messages occurring through endpoint EP1. The procedure for processing messages on endpoint EP1 is similar to the one used for endpoint EP0. Namely, my interrupt routine described earlier detects a transaction using the TRNIF flag in UIR and uses USTAT to determine which endpoint the message is on. I then use USTAT again to get the contents of the appropriate BDnSTAT register while it is still owned by the SIE as follows:

EndPointOne

movlw 0x04

movwf FSR1H

movf USTAT, w

andlw B'01111100'

movwf FSR1L

movf POSTINC1, w

andlw B'00111100'

movwf Token , 1

movlw TOKEN_OUT

cpfseq Token

bra NotTokenOut1

call ReceivedInterrupt

return

NotTokenOut1

movlw TOKEN_IN

cpfseq Token

bra NotTokenIn1

call SendInterrupt

return

NotTokenIn1

return

If TOKEN_OUT is detected I call my incoming message routine - ReceivedInterrupt. If TOKEN_IN is detected I call my outgoing message routine - SendInterrupt. As explained earlier, my existing serial port application on PIC 18F4520 uses a circular buffer to pass messages between my communications interrupt routines and my main program.

My USB converted incoming message routine - ReceivedInterrupt is therefore fairly straight forward. I simply load up my circular buffer from the appropriate USB message buffer as shown:

ReceivedInterrupt

movff BD1OADRL, FSR2L
movff BD1OADRH, FSR2H
movff BD1OCNT, RecvCount

ReadNextByte

movff POSTINC2, Byte

.....

Existing application code

.....

decfsz RecvCount

bra ReadNextByte

Once the received data has been retrieved, I reset the message count and toggle DATA0/DATA1 as shown:

movlw EP0MAXPS
movlb 4
movwf BD1OCNT, 1
movf BD1OSTAT, w, 1
xorlw(1<<DTS)
andlw(1<<DTS)
iorlw (1<<UOWN)|(1<<DTSEN)
movwf BD1OSTAT, 1
clrf BSR
bcf UCON, PKTDIS

Sending a message is no more complicated than receiving a message. While the USB interrupts must be set up for receiving messages, there is really no need to service an interrupt for a sent message at all. A simple check of the UOWN bit in BD1ISTAT is all that is needed to ensure that a new message may be set. So I check my circular buffer in my main programming loop and if there is data to send I check the UOWN bit in BD1ISTAT. If UOWN is clear I load the message buffer referred to by the non so special registers BD1IADRL and BD1IADRH and reset the message count and toggle DATA0/DATA1 as shown:

movlb 4

btfss BD1ISTART, UOWN, 1

bra UownGood

clrf BSR

return

UownGood

.....

Existing application code

.....

movlb 4

movlw 0x0F

movwf BD1ICNT, 1

movf BD1ISTAT, w, 1

xorlw(1<<DTS)

andlw(1<<DTS)

iorlw (1<<UOWN)|(1<<DTSEN)

movwf BD1ISTAT, 1

clrf BSR

return

As mentioned nothing is actually done in the send interrupt routine.

SendInterrupt

return

The PC End

I have seen a number of examples of C# code for PCs interfacing with USB devices and find them rather convoluted. I prefer to use CLR C++ to write a dll that interfaces with my C# code. The FastSerialPort dll described in the article Improving the Performance of Serial Ports Using C#: Part 2 may be suitably modified for the purpose.

So starting with the ReceiveMessage routine, reading one byte at a time does not work with USB, instead a whole USB message buffer must be read with one ReadFile command. Recall that I specified a 15 byte message in my GetDescriptor - Report (DSC_RPT) response on the PIC. Recall also that a Report Id is always added to the front of every message. Applying these modifications the ReceiveMessage routine is now in part as shown:

BYTE buffer[16];

if (ReadFile(m_hUSBPort, buffer, 16, &readSize, &osRead) == 0)

{

DWORD error = GetLastError();

if (GetLastError()== ERROR_IO_PENDING)

GetOverlappedResult(m_hUSBPort, &osRead, &readSize, TRUE);

else

break;

}

for(int iii = 0; iii < (int)readSize; iii++)

The SendMessage routine in FastSerialPort doesn't really change at all apart from the need to add the Report Id (zero in this case) to the front of every message. Note that for my application every message must be 16 bytes long including the Report Id.

The OpenPort routine is much simpler with USB. All that is really required is the CreateFile command:

m_hUSBPort = CreateFile(

portName,
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_WRITE | FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED,
NULL);

However portName is no longer a string like "COM1" but rather a string more like "\\?\hid#vid_04d8&pid_4242#6&398d1a5a&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}". Locating this long and rather strange looking string is a case of calling a series of Windows API functions defined in setupapi.h and devpropdef.h.

First you need to populate an instance of HDEVINFO:

HDEVINFO DeviceInfoSet = SetupDiGetClassDevs(&classGuid, NULL, NULL, DIGCF_DEVICEINTERFACE | DIGCF_PRESENT);

The class GUID required here is for the HID class - {4D1E55B2-F16F-11CF-88CB-001111000030}. I actually obtain the required value for classGuid from a C# string as follows:

array^ guidData = guid.ToByteArray();
pin_ptr data = &(guidData[0]);
_GUID classGuid = *(_GUID*)data;

Now it is a case of looping through the list of available HID class devices until you find the one you are looking for:

int memberIndex = 0;
SP_DEVICE_INTERFACE_DATA DeviceInterfaceData;
ZeroMemory(&DeviceInterfaceData, sizeof(SP_DEVICE_INTERFACE_DATA));
DeviceInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);

while( SetupDiEnumDeviceInterfaces(DeviceInfoSet, NULL, &classGuid, memberIndex, &DeviceInterfaceData))
{ DWORD bufferSize = 0; memberIndex++;

For each of the available HID class devices an instance of PSP_DEVICE_INTERFACE_DETAIL_DATA is populated:

if (!SetupDiGetDeviceInterfaceDetail( DeviceInfoSet, &DeviceInterfaceData, NULL, 0, &bufferSize, NULL))

{

DWORD Error = GetLastError();

if (Error != ERROR_INSUFFICIENT_BUFFER)

return false;

}

PSP_DEVICE_INTERFACE_DETAIL_DATA detailBuffer = (PSP_DEVICE_INTERFACE_DETAIL_DATA)(new BYTE[bufferSize]);

detailBuffer->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA);

if (!SetupDiGetDeviceInterfaceDetail(DeviceInfoSet, &DeviceInterfaceData, detailBuffer, bufferSize, NULL, NULL))

{

DWORD Error = GetLastError();
return false;

}

It can be seen that the function SetupDiGetDeviceInterfaceDetail is called twice. The first time is to obtain the buffer size. The long and strange string required by the CreateFile Windows API function in my OpenFile function is the parameter DevicePath in PSP_DEVICE_INTERFACE_DETAIL_DATA. Now I need to determine if I have the DevicePath to the HID device I am actually wanting to connect to. To do that I need the device instance id. The device instance id is obtained using the process shown:

SP_DEVINFO_DATA deviceInfoData;

deviceInfoData.cbSize = sizeof(deviceInfoData);

if (!SetupDiEnumDeviceInfo(DeviceInfoSet, memberIndex, &deviceInfoData))

{

DWORD Error = GetLastError();
return false;

}

WCHAR deviceInstanceId[1024];

if (!SetupDiGetDeviceInstanceId(DeviceInfoSet, &deviceInfoData, deviceInstanceId, sizeof(deviceInstanceId), NULL))

{

DWORD Error = GetLastError();
return false;

}

The device instance id (deviceInstanceId) is another long strange string. What is needed from this string is the vendor id and the product id. These are four digit hex numbers that appear after the substrings "VID_" and "PID_" respectively. They must match the vendor id and product id provide in the response to the GetDescriptor - Device request at the PIC end.

Conclusion

While information is available on programming Microchip PIC devices for USB communication, most of it is targeted at C programmming language solutions. What I have attempted to provide here is a description of a assembly language solution. I have not actually provided a complete source code listing - these are available elsewhere. Hopefully this descriptive article will help others develop a USB solution for their own particular application. To further aid the collective understanding of this topic, Contact Us with any comments.

USB Communications Using Microchip PIC

Contents

Introduction

Hardware Considerations

Program Start Up

Setup Sequence

Reset

EndPoint Zero

Application Data

The PC End

Conclusion