Ultrasimple USB Display Interface Specifications ------------------------------------------------ 06092012 V1.00 K. Horton The aim of this specification is an ultra simple method of getting data from a PC to my standard display controller. It has been designed to be as flexible as possible, yet still be simple and self-aligning. The link between the controller and the PC is an FT2232 in FIFO mode. The FPGA will empty the FT2232's FIFO if bytes are present, and check for packet headers. These headers, if found, then determine what happens. For maximum simplicity, there are just two packet types. Each header is composed of 8 bytes, a 6 byte length field and then the data. packet header: -------------- 44 53 50 5F 43 4F 4E ID The first 7 bytes are the ASCII string "DSP_CON". The last byte contains the packet ID: bits: 7 -> 0 --------- 1010 IIII The first 4 bits are the hex digit "A" and the last 4 is the packet ID. There's only 2 packet IDs defined at the moment: Display Identify ---------------- 44 53 50 5F 43 4F 4E A0 00 00 00 This is the "display identify" packet. Sending this packet will cause the device to reply with its capabilities on the return FIFO board. The first 7 bytes are our packet header, the 8th is the packet type, and the 3 00 bytes are the length (since this packet type has a length of 0) The return packet to the PC has this form: 44 49 53 50 5F 53 45 54 XX XX YY YY BB MM The first 8 bytes are ASCII for "DISP_SET". XX XX is the display's X size in pixels. It is 16 bit, little endian. YY YY is the display's Y size in pixels. It too is 16 bit, little endian. BB is the greyscale depth: Instead of being a straight bit depth, (i.e. 1 = mono, 2 = 4 level greyscale, etc) it is a direct count of brightness levels. This is because some displays only support 3 levels of brightness instead of 2 or 4. Thus, BB is the number of brightness levels minus 1. 00 - 1 level (this is invalid) 01 - 2 levels (monochrome... pixels are either on or off) FF - 256 levels (full 8 bits worth of brightness) MM is the display modes supported: bits: 7 -> 0 --------- FFFF 00CC F: number of frames supported in the frame buffer minus 1 (i.e. 0 = 1 frame only, 0fh = 16 frames) 0: these should always be 0's C: number of display channels: 1 - monochrome (just one colour) 3 - RGB (full colour) NOTE: only 1 and 3 are supported at this time. Display Data ------------ 44 53 50 5F 43 4F 4E A1 LL LL LL RR MM This is the "display data" packet. Sending this packet will perform two functions: First is it will cause the display to show a new frame while another is being loaded, and it will load data into SDRAM. An optional flag can be set to cause the FPGA to emit a packet when the display scan is finished (if full motion is desired with no missing frames this is a way to do it) The first 7 bytes are again our packet header, the 8th is the packet ID, then 3 bytes of length (little endian), followed by the RR and MM bytes, and finally the display data itself. The RR and MM bytes are included in the length count. RR: Frame: bits: 7 -> 0 --------- DDDD LLLL D: displayed frame L: frame to load this packet's data into NOTE: do not specify a frame # greater than the maximum number of frames. MM: Modes: bits: 7 -> 0 --------- 0000 00IW I: send a frame return packet when the frame is finished displaying. NOTE: If this is turned on, the display controller will keep sending frame return packets until it is turned off (i.e. it will not just send one for each display data packet sent by the PC). W: wait for frame to finish displaying before showing the new frame # specified in the RR byte, above. frame return packet format: --------------------------- 44 49 53 50 5F 46 52 4D NN NN The first 8 bytes are ASCII for "DISP_FRM", and the last 2 bytes are a frame number. This frame number is little endian, 16 bits, and is non-resettable and increments each time a frame is shown. This should allow the PC to keep track of which frame has been shown in case the PC software wishes to be able to detect frame dropping or whatever.