ZipIt Peeks & Pokes

From eLinux.org
Jump to: navigation, search

Unofficial Zipit "Peeks & Pokes"

Version 1.2 - June 10, 2005

Contributors:

 "Ken McGuire" <kenm@paonia.com> ("cynfab")
 "matt_westervelt" <mattw@seattlewireless.net> ("mattw")
 "Adam Tilghman" <agt@mib.org> ("atilghma")

Updates/Corrections/Additions:

  Please send them to Adam Tilghman <agt@mib.org>.

Message board, files, links to chipset data sheets:

  http://groups.yahoo.com/group/zipitwireless
Cirrus ep7312 (Main CPU) General-purpose I/O (GPIO) pins:

Port A:  All   = input      [ keyboard row inputs ]

Port B:  Bit 0 = unused        [ unaccessable ]
             1 = output     [ green LED ]
             2 = input      [ battery charging ]
             3 = input      [ lid-closed switch status & tied to R115; also tied to Port A interrupt ]
             4 = input        [ hpdet from audio jack & WM8751L 23 ]
             5 = unused     [ goes to a via on the back of the board ]   
             6 = i/o        [ i2c SDA ]
             7 = i/o        [ i2c SCK ]

Port D:      0 = output     [ yellow/orange LED ]
             1 = output     [ drives gate of "CR5" a 2N7002 fet part of contrast control ]
             2 = output     [ drives gate of "CR6" a 2N7002 fet part of contrast control ]
             3 = output     [ drives gate of "CR8" a 2N7002 fet part of contrast control ]
             4 = output?    [ cynfab: Set & cleared by the Zipit audiodrv.o code; not sure what it does, unaccessable.]
             5 = output     [ enable/disable LCD ]
             6 = reserved   [ used for SDRAM interface ]
             7 = reserved   [ used for SDRAM interface ]

Port E:      0 = tied low   [ ==> boot ROM is 16-bits wide ]
             1 = tied high  [ ==> boot ROM is 16-bits wide ]

DSR:         [ unused and unaccessable ]
DCD:         [ unused and accessable on bottom of board ]
CTS:         [ unused and unaccessable ]

---
Zipit I2C bus:

   Device 0x1b  =  wm8751l DAC (handles audio output)
                [ cynfab has written a working driver for this chip ]

   Device 0x55  =  LPC915 microcontroller (?? handles battery charging, power mgmt, more? ??)

          Register 0x01 = ???  (writing to 0x02 loads a value into this reg.)

          Register 0x02 = READ: battery charge state?  (per cynfab)
        [ atilghma: by averaging the last 20 values
          I get a consistent reading which seems
          to approximate battery charge level.
                  Reading this register may directly sample the voltage
                  across the battery via the LPC915's ADC comparator.]

                          WRITE: writing to this location seems to load
                            a related value into Register 0x01,

          Register 0x04 = ??? (value seems to fluctuate)

          Register 0x81 = READs or WRITEs: Power down the system immediately

          Register 0x84 = READs or WRITEs: Reboot the system after ~1 sec. delay

 The LPC915 has the following connections:

Pin 2   P0.0  input   from R102 & CR12  P/O Reset ckt
Pin 1   P0.1  ?       from R116 & R114  P/O Audio Jack extra pins
Pin 14  P0.2  input   from voltage divider across battery
Pin 13  P0.3  input   from R112 & CR12  P/O Reset ckt
Pin 12  P0.4  ?       from C52 & U3 (k6) wireless chip
Pin 11  P0.5  NC

Pin 9   P1.0  ?       from CPU nEint
Pin 8   P1.1  ?       from CPU Wakeup
Pin 7   P1.2  i/o     i2c SCL
Pin 6   P1.3  i/o     i2c SDA
Pin 5   P1.4  ?       from CPU nPOR
Pin 3   P1.5  NC

Pin 4   VSS   GND
Pin 10  VDD   +V


-- end --

LCD framebuffer

> Straight to the point: > When accessing the framebuffer memory, how many bits is the IO?

Each pixel is 4 bits. The 320x240 pixel screen is 38400 bytes (320x240/2) - 160 bytes per row. For speed, I recommend accessing them 4 pixels at a time (32 bits written to framebuffer memory). The CPU can address memory in 8, 16 or 32 bit sizes. The framebuffer is regular memory (either SRAM or the SDRAM). Writing a 4 bit value" == reading the old byte from framebuffer memory, masking out the nibble you want to replace, "OR" in the new nibble, and writing the updated byte back to the frame buffer

The 4 bits for each pixel is an index into the hardware color palette. The standard Linux palette is non-linear (used to make the Tux penguin look good)

If you run "lcdpal 0" it will set the hardware color palette to a linear palette

That way a 4 bit value of 0 will be dark (~= black), and a 4 bit value of 15 will be brightest (~=white).

If you don't want to use 'lcdpal' you can set the register yourself:

PALLSW = 0x89ABCDEF;
PALMSW = 0x01234567;