This section is for the USB-side of the project. The focus of this project has changed to writing a firmware to control the PDIUSBD12 USB physical-layer IC I chose to use.

(If you've arrived here from another site, you may wish to view Final Year Project which puts this page into context)

Use the Index button at the bottom-right of each page for a complete list

Each page contains a link to download a .HEX file which contains the compiled binary firmware, please check the pins used in the source code for each example, as it is likely that the pinning of my circuit changed over time.

• Code¹⁾
  1. Hello World! — Some quick code that blinks an LED and prints “Hello World!” via RS232.
  2. GoodLink(TM) code — Minimum code needed to make the D12's GoodLink LED pin go active
  3. Enumerated — Minimum code needed to (partially) enumerate on Windows XP Pro SP2
  4. Enumerated2 — All descriptors included and the “Out of RAM” problem solved by using ROM-stored constants (which unfortunately meant repeating blocks of code)
  5. HID-Mouse — Enumerates as a mouse and moves according to characters sent from a GBA, or by a predetermined amount. This versions sports a totally new approach to handling descriptors, which is both much more compact in code, and more readable.
  6. Joystick — Enumerates as a joystick with 3 buttons, and accepts Set_Report (2 bytes) which appears as hex on the GBA screen.

I was trying to decipher report descriptors I'd nabbed from various USB devices of mine, and found the (6-bit, 2-bit) way of doing things quite tricky. I used the following table to go from my nabber report descriptor (Report) to the hex I needed to enter into the HID Descriptor Tool (HEX).

Report  Hex     Report  Hex     Report  Hex     Report  Hex 
--------------------------------------------------------------  
00-03   00      40-43   10      80-83   20      C0-C3   30
04-07   01      44-47   11      84-87   21      C4-C7   31
08-0B   02      48-4B   12      88-8B   22      C8-CB   32
0C-0F   03      4C-4F   13      8C-8F   23      CC-CF   33
                                                            
10-13   04      50-53   14      90-93   24      D0-D3   34
14-17   05      54-57   15      94-97   25      D4-D7   35
18-1B   06      58-5B   16      98-9B   26      D8-DB   36
1C-1F   07      5C-5F   17      9C-9F   27      DC-DF   37
                                                            
20-23   08      60-63   18      A0-A3   28      E0-E3   38
24-27   09      64-67   19      A4-A7   29      E4-E7   39
28-2B   0A      68-6B   1A      A8-AB   2A      E8-EB   3A
2C-2F   0B      6C-6F   1B      AC-AF   2B      EC-EF   3B
                                                            
30-33   0C      70-73   1C      B0-B3   2C      F0-F3   3C
34-37   0D      74-77   1D      B4-B7   2D      F4-F7   3D
38-3B   0E      78-7B   1E      B8-BB   2E      F8-FB   3E
3C-3F   0F      7C-7F   1F      BC-BF   2F      FC-FF   3F

Building on the analysis made below, I drew up a schematic of my final design as used in my project. See my project report when that is put online (won't be before July 2005, when I graduate) and will be linked to from Final Year Project.

circuit_diagram.swf

Above is a Macromedia ShockWave Flash version of my diagram — with luck this ought to mean you can right-click and zoom-in or pan the diagram as needed. You may also download a copy: circuit_diagram.swf

The upper chip is the PIC16F877, the lower one the PDIUSBD12, the right one is a MAX3232 level convertor used to connect the PIC to a dumb-terminal via the DB9 serial-port connector. The switches in the top-left are used to set the debugging level in binary (0-7) and to select whether to use the GBA to generate report data (mouse movement etc) or to make it up randomly.

Be sure to check out the HID-Mouse and HID-Joystick examples linked to at the top of the page to see how this is used.

After looking at the example from Philips' on how to interface the PDIUSBD12 with a HITACHI H8S 2357, I noticed that their example schematic (found on page 2 ) indicates that the VOUT3.3 is grounded by two capacitors in parallel (one 0.1u and the other 1u). This strikes me as an odd thing to do.

The datasheet for the PDIUSBD12 has this to say about VOUT3.3 (pin 27):

3.3 V regulated output. To operate the IC at 3.3 V, supply a 3.3 V to both VCC and VOUT3.3 pins.

This supports my understanding of this pin's purpose (to conveniently supply power from the USB cable to devices which require 3.3V), but does not help with the parallel capacitors query. It is likely that this is some sort of standard practice of which I am unaware due to my limited experience with such things. A quick chat with Barry confirmed my suspicions that these capacitors exist to smooth the power supply. Furthermore Barry feels I ought to account for such things in my own project, and has provided me with the capacitors used in this example schematic.

The D12 datasheet specifies that the D+ and D- pins interface with the USB cable via 'termination resistors'. Again this concept is not familiar to me, and I gather from the HITACHI example that two 18 Ohm resistors placed in serial between the pin and wire are what is intended. There also exist two 1MOhm resistors which ground the D+ and D- wires, it is more likely that these are the terminating resistors, in which case the purpose of the 18Ohm resistors is a little unclear.

After consulting with the university technicians it seems that terminations resistors are not required for my project unless I plan to use very high data rates (which I do not), I do not fully understand the reasoning for this, but it has something to do with stabalising the signals. I will not consider this further unless there is good cause to do so.

It seems that EOT_N (pin 19) ought to be connected to the VBUS of the USB cable, as this is how the D12 does VBUS sensing. The schematic shows a seperately powered setup, while I intend to use a USB-powered setup - hence I must be careful about how EOT_N is connected - the schematic shows that EOT_N should be connected to VBUS at a point between 4.7 kOhm (VBUS side) and a 1 MOhm (GND side).

Again, two capacitors in parallel are used - this time between VCC and the various pins it supplies with power. Perhaps this is being used for power-smoothing?

The write and read strobes for the D12 are on seperate pins - and care must be taken to ensure these pins never contradict each other.

There is a chip-select pin (CS_N, pin 11) which presumably is for enabling the data bus pins of the D12 in a multi-chip common-bus environment. In this instance the 877 has sufficient data ports to negate the need for such an approach, and so we must tie the pin low to ensure the chip is always selected.

RESET_N (pin 20) and DMACK_N (pin 18) should be tied high to ensure the chip does not reset while powerd, and DMA acknowledgement is unnecessary as there is currently no intention to use it.

ALE (pin 10) is the 'Address Latch Enable', and is intended for common-bus arrangments, it should be tied low in our case to disable it.

A0 should be connected to one of the general I/O pins of the PIC16F877, and is used to latch a command (directed to the D12). When this pin is high, the data bus is latched and interpreted as a command for the D12, when the pin is low, the databus is used for data to be passed through the D12. Presumably this compliments the normal method of clocked input. This brings rise to the issue how to start and stop sending data via the USB bus.

When the D12 powers-up the default clock setting is 4MHz and appears to be generated by an internal clock of some sort, which is apparently not very accurate (I do not recall reading a specific figure, however).

There is a note in the D12 datasheet which says

There is no protection against writing or reading over a buffer's boundary or against writing into an OUT buffer or reading from an IN buffer. Any of these actions could cause an incorrect operation.

Clearly this is an important remark to keep in mind when setting up the circuits and doing the initial debugging.

Another remark says that when a setup packet is recieved (from the host) the microcontroller must explicity acknowledge it before the validate_buffer and clear_buffer commands are re-enabled. This acknowledge setup command must be sent to both the IN *and* the OUT endpoints. This last bit was not obvious to me.

Curiously some of the timings in Table 17 can be negative, according to the footnote. This is somewhat odd, and as a matter of curiosity I will look into this a bit more.

After a couple of seperate discussions, with Roger and Rod, it seems that this footnote refers to transitions which are linked to other transitions and are intended to occur syncronously. However, when this footnote occurs it states that a transition may be slightly early compared to its counter-part.

Hence the databus of the PDIUSBD12 is connected to port D of the PIC16f877