====== Presentation ======

!!//Note: If you got here via a search engine that you'll probably want to check the front page of this section of my site: [[:project]]//!!

So, I've got to present my work eh? That should prove fun. Let's start at the beginning; I'm going to present my project to pry marks from my assessors, so it seems logical to workout what they want and give it to them

:!: I doubt it'll be useful to anyone, but I finished my presentation and you can download it if you like:

{{project:game_boy_usb_interface_and_application.ppt|Game Boy USB Interface & Application.ppt}}

====== Notes ======
Date with destiny: Thursday 3<sup>rd</sup> March 2005 @ 14:20, in CS101

===== Assesment Criteria =====
  * **Technical content:**
    * **Innovative analysis and design.**
      * Parsing descriptors to overcome PIC issues and improve readability and remove duplicated code
    * **Methods and solutions employed.**
      * Test Rig: PIC, PDIUSBD12, (Dumb) Terminal, Logic Probe
      * Incremental appraoch to develeopment (see what the host requests, implement it, repeat)
    * **Quality of examples used to demonstrate results.**
      * MeerMouse HID because it requires no drivers and gives instant feedback to the developer
      * Joystick HID because mice are locked by the system, joysticks also offer clear feedback to the user via Control Panel's Game Controllers, but because the device is not locked a test application can read and write to it.
    * **Overall level of technical achievement.**
      * Meets project specification exactly (driver-less, bi-directional data transfers)
      * Device fails in a compliant manner when issued a request it does not understand.
    * **Conclusions and suggestions for further work.**
      * Limitations of produce: not suitable for transferring large amounts of data (bulk transfers), cannot send/recieve reports larger than the endpoints buffer (16 bytes for Control transfers (i.e. Host->Device) and 64 bytes for interrupt transfers (i.e. Device->Host))
  * **Project management:**
    * **Well conceived project.**
      * Clear objective (Driver-less, easy to setup/use, communication between PC and GBA)
      * Achievable & Verifyable (Can data be sent in either direction? Are special drivers needed? Would a user requre instructions to use the device?)
      * Builds on knowledge & experience gained during degree course (COA, SystemsDesign, compiler design)
    * **Unforseen problems well detected and overcome.**
      * D12 Set_Address ordering is not as expected, and this misconception can break the USB spec's 2ms timelimit
      * D12 RESET_N / CS_N marlarky ("test mode"?)
    * **Progress consistent with project specification.**
      * Suprisingly so
    * **All necessary research, analysis and design work completed.**
      * Implemented and working, with certain limitations.
  * **Communication Skills:**
    * **Care and preparation of visual aids.**
    * **Quality of oral delivery.**
    * **Effective use of time and appropriate length.**
    * **Effective response to questions.**

===== Slide topics =====

The presentation is 25min, including demonstration, so I ought to spend ~20min doing the oral presentation, and ~5 doing the demonstration as there isn't an awful lot to demonstrate. Q&A time also needs to be in there, but I feel that demonstration / Q&A are almost certainly the same thing.

Aim for 15 slides
!! Have report descriptor example available for questioning

  - Introduction
    * Say what I am going to say (presentation outline)
  - My Project is...
    * To enable a Game Boy Advance to have PDA-like features, such as synchronisation (i.e. connectivity is key)
    * To create PC <-> GBA connectivity that is
      * Widely compatable with current PCs
        * Serial / Parallel often not available.
        * USB is widely accepted and if more ports are needed a hub can be added
      * Easy-to-setup (No drivers) & Easy-to-use (No manual application configuration)
    * To create a proof-of-concept application pair to demonstrate the above (display recieved / send raw data)
    * USB was chosen as the interface, and became the core focus of the project.
  - USB Overview
    * "A Fresh Start" --- USB was designed to be new, and is not 'backwards compatable' with anything it replaces.
    * Benefits for Users
      * Automatic configuration, Hot pluggable, Bus powered
      * 3 bus speeds: high (480 Mbits/s), full (12 Mbit/s) and low (1.5Mbit/s) [signalling speeds, not data throughput]
      * Max throughput: 53 MB/s (high) 1.2 MB/s (full) and 800 kB/s (low)
    * Benefits for Developers
      * Flexibility:
        * 4 Transfer types (control, interrupt, bulk and isochronus) + 3 speeds
        * No specific functions for signals, unlike the PC parallel port with it's status and control lines having line-printer specific purposes
        * Classes of device, such as scanner / printer meaning that developers don't have to reinvent them, also allows composite devices which should allow future multi-purpose developments to use USB (Philip's FunCam of the Department has webcam + microphone and is a composite device)
      * Operating System Support (low level, and sometimes all levels, USB support in most operating systems --- i.e. all OSs support enumeration of a USB device, and some support specific classes, like Human Interface Device (HID) class)
    * Peripherals are microcontrolled and, depending on choice of USB interfacing chip, require varying levels of firmware development and USB protocol implementation
    * Problems with USB
      * Lack of support for legacy operating systems 
      * Distance limits (designed as a desktop bus, 5m max)
      * No peer-to-peer
  - USB Layers
    * User-mode program talks to OS device drivers.
    * Device drivers use 'pipes' to transfer data back and forth between it's self and a specific interface of the USB device. (NB use of interface)
    * Potentially bidirectional pipes are made up of uni-directional endpoints, termed from the point of view of the host. Hence OUT is host-to-device, and IN is device-to-host
    * USB devices can have multiple interfaces. For instance a telephone will have an audio-class interface, and a human interface device (HID)-class interface for the buttons.
    * All USB devices have a bidirectional control pipe, which is made up of Endpoint 0 and Endpoint 1. Typically a device will have a seperate interface for normal use which has a larger buffer than the control endpoints.
    * When devices are connected to a host, a conversation takes place where the host learns about the device and loads drivers as appropriate before passing control and communication handles to the driver. This is called enumeration.
    * {Learning by doing software model diagram}
    * The USB protocol, like many others, uses acknowledgement tokens (ACKs), but perhaps more unusually also has NotAcknowledge (NAKs), Stalls and NotYets (NYETS) (Ack as expected, NAK = understood but will not comply, Stall = does not understand, cannot deal with request presently, NYET = too busy. NB Errors do //not// use NAKs, they simply do not return a token and the sender will retry 3 times after set time-outs)
  - GBA
    * The Nintendo Game Boy Advance is a popular portable games console which uses cartridge-based memory to store games.
    * Some details:
      * 32bit ARM7TDMI CPU running on RISC architecture at 16.78Mhz
      * 96 KB of video memory, 32KB of internal RAM and 256KB of externals RAM
      * 2.9 inch TFT colour LCD screen, 240x160 max resolution
      * No operating system
    * Has a multi-purpose communications port, supporting:
      * Normal mode
      * Multi-player mode
      * JoyBus mode
      * General Purpose mode
      * UART mode
    * Normal, Multi-player and JoyBus modes are propriety Nintendo protocols implemented in hardware and are intended for interfacing with other Nintendo products.
    * General purpose mode allows any of the GBA's 4 I/O pins to be used as either input or ouput in an arbitary fashion, much like the PC Parallel port.
    * UART mode allows RS232 serial communications at TTL voltages. It is handled by hardware circuits which can generate interrupts on sending / receiving data. The hardware circuits make full use of the Clear-To-Send and Request-To-Send lines, which was impressive.
    * Large hobbyist community on the web, providing sample code, emulators suitable for developers, compilers, libraries and even one which sports its own IDE!
    * For this project I chose to use the HAM IDE, as it has an accessible and intuitive library which aids fast prototyping. There is a free and a commercial version, in the free version a "Made with HAM" banner is displayed at the beginning of any code execution.
    * Programming a dumb-terminal like application for the GBA which prints recieved characters to the screen, and sends keypresses was suprisingly easy to accomplish, thanks to online tutorials/examples.
  - Microcontroller
    * PIC Microcontrollers are programmable chips with I/O, which the department have facilities for and experience with, so this was considered first.
      * Equipment already in place to program PIC chips
      * IDE for programming PICs using C, instead of assembly as is usual
      * Code examples (including in-house examples) from which to learn quickly
      * Spare programming hardware so I could compile / write-to-chip at home outside of lab-hours
    * The PIC16F877 was recommended by the technicians as the chip to use, because it has:
      * Plenty of I/O pins (33)
      * Likely sufficient Flash ROM memory (112,000 bytes)
      * Likely sufficient RAM available (368 bytes of general-purpose registers)
    * Limitations of the PIC16F877
      * Memory is segmented, both in the ROM and RAM
        * RAM segmentation was almost invisible while developing as the CCS compiler managed RAM usage.
        * ROM segmentation, however, was an issue as certain functions of the firmware grew large and wouldn't fit, these needed to be broken up.
  - D12 (retrospect EZ-USB etc)
    * It is common to have the low-level protocol of USB handled by a dedicated chip which interfaces with a microcontroller. There were quite a few chips to choose from, but ultimately it came down to what was available in small quantites with suitable source code and schematics of example implementations. 
    * I discovered a USB implementation done using a PIC16F877 & Philips Semiconductor PDIUSBD11 USB chip, complete with schematic and sourcecode, in BeyondLogic.org's "USB in a Nutshell" tutorial --- a technical reference and tool site run by Craig Peacock (Techinical Officer of the School of Informatics & Engineering, Flinders University, Australia)
    * Also found a detailed example by a member of Intel titled "USB: Leanring by Doing" using the same USB chip.
    * Both articles were very positive about the PDIUDBS11. Futher investigation only supported this impression, not much relevant detail about implementing other USB chips was available.
    * However, the PDIUSBD11 was disconinuted, and had been replaced by the PDIUSBD12. The main difference being how they comunicate with a microcontroller: the D11 used an I<sup>2</sup>C serial interface, while the D12 uses an 8-bit parallel bus.
    * The D12 has a few nice features which distinguish it above other USB chips:
      * SoftConnect(TM) technology. USB host's detect the presence of a peripheral by the presence of a 1.5 kOhm pull-up resistor on one of the two data lines (which line depends on the speed of the device), the D12 has this feature built in, but software programmable --- the microcontroller can signal the D12 to advertise it's presence to the host, and the D12 connects the pull-up resistor and USB communication starts.
      * GoodLink(TM) indicator controls an LED to show the status of the USB chip. Blinking indicates traffic, and a lit state shows everything is configured and working.
    * These features gave the impression of a well thought out and polished product, with ease-of-development in mind, and utlimately helped make the decision to base my project on it.
    * The D12 takes care of recieving data and performing re-transmission for errors and similar, generating interrupt when it has successfully recieved/transmitted a packet, or (if so enabled) when an error occurs.
  - Test rig (hardware photo) / Approach
    * Connected to a Dumb Terminal / PC equivalent to read debugging statements
    * DIP switches read on PIC startup and set debugging verbosity level
    * Power switch provides a convenient manner to simulate disconnect / reconnect while restarting both PIC and D12 (pushing the button breaks the circuit). Switch was quite tall and had short pins, so it often fell out of the board, hence it was mounted to a wide base.
    * MAX3232 does voltage level conversion from TTL to +/- 12 V.
    * PIC LED serves to show PIC is working (lit) and eventually also changes status upon recieving UART data from the GBA
    * Due to many unknowns a very incremental appraoch was used, seeing what unhandled request windows issues, and then implementing it, repeating.
  - Enumeration
    * User plugs a device into a USB port, hub provides power to the port.
    * The hub detects the device. The hub does //not// transmit data yet, but reports the event to the host.
    * The host learns of the new device.
    * The hub detects whether a device is low of full speed. (Hub has 15kOhm pull downs on both data lines (termed D+ & D-), the device has a 1.5kOhm pull up on D+ for full speed, and D- for low).
    * The hub resets the device by setting both D+ and D- to logic low for at least 10ms. Normally D+ and D- have opposite logic levels.
    * The hub establishes a signal path between the device and the bus. The device is in the ''Default state'' (so it's address is 0x00), can draw 100mA of power from the bus and is ready to recieve communications over endpoint 0.
    * The host sends a Get_Descriptor request to learn the maximum packet size of the default pipe, which is described in the eighth byte of the requested descriptor. Get_Descriptor requests specify how much of the descriptor they want; Windows request 64bytes at first, and after recieving the first packet, issues a bus reset to the device. This is not required by the USB Spec.
    * The host assigns an address via the Set_Address request.
    * The host learns about the devices abilities. The host sends another Get_Descriptor to the new address requesting the device descriptor, and this time reads the whole thing. The device descriptor specifies the maximum packet size for Endpoint 0, the number of configurations it supports and similar. The host continues to learn about the device by requesting the one or more configuration descriptors.
    * The host assignes and loads a device driver
    * The host's device driver selects a configuration
    * The device is now ready for use and available to user-mode applications on the host, enumeration is complete.
  - Descriptors & Requests
    * Descriptors are data structures that enable the host to learn about a device.
      * Eg: Device descriptor contains:
        * USB specification release number
        * Class code (HID, Mass Storage, Printer etc)
        * Subclass code
        * Protocol code (currently only used for mouse / keyboard in legacy application, such as Windows Safe Mode)
        * Maximum packet size for control out endpoint
        * VendorID
        * ProductID
        * Device release number
        * Index of string descriptor for the manufacturer
        * Index of string descriptor for the product
        * Index of string descriptor containing the serial number
        * Number of configurations supported
      * Other standard descriptors: Configuration(s), Class, Interface(s), Endpoint(s)
    * The USB Specification defines 11 standard requests, not all of which have to be implemented. Unimplemented requests should stall the endpoint.
      * The minimum set required to successfully enumerate with Windows XP are:
        * Get_Descriptor
        * Set_Address
        * Set_Configuration
  - HID Class / Report descriptors
    * Needed to get the PC side talking to the hardware, examples pointed towards the "HID" class.
    * "HID" is an acronym for Human Interface Device (class), and was one of the first USB classes to be supported under Windows.
    * HIDs are intended, but not limited, to interacting with people. 
    * Major abilities of HIDs:
      * Data exchanged in structured in 'reports', the structure of which can be defined in a HID-compliant manner in the report descriptor.
      * Each transaction can carry a small to moderate amount of data. 8 bytes per transaction for low speed, 64 for full and 1024 for high. Long reports can use multiple transactions
      * Devices can send data any time, devices are polled periodically by the host (c.f. a USB keyboard)
      * Maximum speed of transfers is limited, the host can only guarentee maximum latency between polls. Max throughput is 800 B/s for low-speed, 64 kB/s for full, and 24.576 MB/s for high.
      * //Rate// of transfer is not guarenteed, maximum latency is just that.
    * Defining report structure is complex and quite involved.
    * Having multiple report structures defined is useful as it allows the device to make best use of bandwidth. For instance a mouse can have a complete report structure, containingg x, y, and button-status, and a shorter button-status only report, and can pick which to use as appropriate.
  - Firmware
    * Firmware would be entirely interrupt driven, using the falling edge of the D12 INT_N line connected to the EXT_INT (External Interrupt) pin of the PIC.
    * {Flowchart}
  - Project problems of note
    * PIC Limitations (ROM segments, limited RAM, out of ROM errors (too many debugging statements))
    * Debug statements and how they affect timings - developement machine (laptop) was more forgiving than others, presumably due to the presence of low-level filtes / sniffers. ~1ms per character of debugging.
    * RESET_N / CS_N issues. Unable to reset D12 via firmware, believed to be due to "test mode".
    * Set address quirk of D12, not in data sheet. This misconception broke compliance with the USB spec's 2ms timelimit for performing the address change. Found out from USB Implementer Forum's webboard.
  - Limitations & Restrictions
    * Due to RAM limitations: (Note that release builds have a much smaller ROM footprint, but near identical RAM footprint)
      * The firmware is unable to recieve multi-transaction reports (i.e. reports larger than the buffer they are being sent to) from the host, due to memory limitations. Code has been written, but no adequate test has been performed. The maximum host-to-device report transaction may contain up to 16 bytes.
      * Similarly, sending of multi-transaction reports has not been adequetly tested. The maximum device-to-host report transaction may contiain up to 64 bytes.
    * The Get_Report HID request currently returns the correct data length, but all the data is null. This is a bug, and is believed to be related to the Set_Report request being issued simultaneously from the host's test application.
    * The device has not been tested on any platforms other than Windows, and only thoroughly tested with Windows XP. Not all standard requests are implemented, but the device does fail in a compliant manner when faced with an invalid/unrecognised request.
    * The device is not suitable for transferring large amounts of data (bulk transfers).
  - Demonstration preamble
    * The project was a success --- the implementation matches the project specification: Driver-less with bidirectional transfers and no user intervention for setup and use.
    * Device fails in a compliant manner. (Demonstratable?)
    * Will demonstrate a HID Mouse and HID Joystick
      * Mouse because it offer instant feedback and was the first to be implemented. Movement / buttons controlled by GBA.
      * Joystick because mouse is locked by the system making it impossible for a PC side application to communicate with it. Joystick report data is equivalent, and feedback can be obtained from Control Panel's "Game Controllers". Again movement / buttons controlled by GBA.
    * Will show debugging data being logged, after explaining a sample log (next slide)
    * Will show data being captured by a user-mode application, written in .NET by Jan Axelson, author of USB Complete, the book I used as reference. (Note I didn't write it, but the application is open source and sufficiently generic)
    * Will show data being sent from host to device, and being displayed on the GBA. 
  - Sample Log
    * Hmmm. Might need to trim one slightly.
  - Summary / Further work
    * Say what I said
    * Further work
      * Further develop and test multi-transaction reports
      * Implement HID-class Set_Idle request, to save bandwidth.
      * Implement multiple report descriptors and handling of different report types.