This shows you the differences between two versions of the page.
— |
project:usb [2007/05/15 23:23] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== USB ====== | ||
+ | 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 [[: | ||
+ | |||
+ | ===== Quick links ===== | ||
+ | //Use the '' | ||
+ | |||
+ | Each page contains a link to download a '' | ||
+ | |||
+ | * Code((Note " | ||
+ | - [[project: | ||
+ | - [[project: | ||
+ | - [[project: | ||
+ | - [[project: | ||
+ | - [[project: | ||
+ | - [[project: | ||
+ | |||
+ | ===== HID Reverse Engineering Lookup Table ===== | ||
+ | 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 | ||
+ | -------------------------------------------------------------- | ||
+ | 00-03 | ||
+ | 04-07 | ||
+ | 08-0B | ||
+ | 0C-0F | ||
+ | | ||
+ | 10-13 | ||
+ | 14-17 | ||
+ | 18-1B | ||
+ | 1C-1F | ||
+ | | ||
+ | 20-23 | ||
+ | 24-27 | ||
+ | 28-2B | ||
+ | 2C-2F | ||
+ | | ||
+ | 30-33 | ||
+ | 34-37 | ||
+ | 38-3B | ||
+ | 3C-3F | ||
+ | </ | ||
+ | |||
+ | ===== Master Schematic (PDIUSBD12 & PIC16F877) ===== | ||
+ | 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 [[: | ||
+ | |||
+ | {{ 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: [[/ | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ===== Example PDIUSBD12 / H8S 2357 Implementation Analysis ===== | ||
+ | After looking at the example from Philips' | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | 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' | ||
+ | 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, | ||
+ | |||
+ | ===== Wiring ===== | ||
+ | {{project: | ||
+ | |||
+ | |||
+ | ^ Pin # ^ Name ^ Connect to ^ | ||
+ | | 1 | Data 0 | RD0 (#19) | | ||
+ | | 2 | Data 1 | RD1 (#20) | | ||
+ | | 3 | Data 2 | RD2 (#21) | | ||
+ | | 4 | Data 3 | RD3 (#22) | | ||
+ | | 5 | GND | Board GND | | ||
+ | | 6 | Data 4 | RD4 (#27) | | ||
+ | | 7 | Data 5 | RD5 (#28) | | ||
+ | | 8 | Data 6 | RD6 (#29) | | ||
+ | | 9 | Data 7 | RD7 (#30) | | ||
+ | | 10 | AL_E | Board GND | | ||
+ | | 11 | CS_N | Board GND | | ||
+ | | 12 | SUSPEND| RB4 (#37) | | ||
+ | | 13 | CLKOUT | n/a | | ||
+ | | 14 | INT_N | RB0 (#33) | | ||
+ | | 15 | RD_N | RB1 (#34) | | ||
+ | | 16 | WR_N | RB2 (#35) | | ||
+ | | 17 | DMREQ | n/a | | ||
+ | | 18 | DMACK_N| Board V< | ||
+ | | 19 | EOT_N | USB V< | ||
+ | | 20 | RESET_N| Board V< | ||
+ | | 21 | GL_N | Green LED | | ||
+ | | 22 | XTAL1 | 6Mhz crystal | | ||
+ | | 23 | XTAL2 | 6Mhz crystal | | ||
+ | | 24 | V< | ||
+ | | 25 | D- | USB D- | | ||
+ | | 26 | D+ | USB D+ | | ||
+ | | 27 | VOUT3.3| n/a | | ||
+ | | 28 | A0((When this pin is high the data bus is latched and interpreted as a command for the D12, used as a databus otherwise)) | RB6 (#39) | | ||
+ | |||
+ | Hence the databus of the PDIUSBD12 is connected to port D of the PIC16f877 |