Well, I've come up with a kludge for the moment. I'm accessing it directly in userland using devmem2 and the following script:
Code:
#!/bin/sh
clear
# setup SPI MODE -
# Master, fixed peripheral select, Chip selects directly connected
# Mode fault detection disabled, local loopback disabled
# Select peripheral 3 (Chip select 2 active)
# Delay between chip selects = 0/MCK
iotest 0xfffc8004 w 0x30011 > /dev/null
# Setup SPI chip select register 2
# CPOL = 0 : Inactive clock is low
# NCPHA = 1 : Data changed on leading edge, captured on following
# CSAAT = 1 : Chip select does not rise after transaction
# BITS = 0x8 : 16 bits per transfer
# SCBR = 0xFF : Baudrate = MCK/255 = 100MHz/256 = 390.6kHz
# DLYBS = 0x0A : Delay from CS to first clock = 10/MCK = 100nS
# DLYBCT = 0x00 : Delay between consecutive transfers = (32 * 0)/MCK = 0
iotest 0xfffc8038 w 0x000aFF8a > /dev/null
while true
do
# Get X & Y info
echo -e "\033[1;1H"
iotest 0xfffc800c w 0x0094 > /dev/null
iotest 0xfffc8008 w > /dev/null
iotest 0xfffc800c w 0x00D4 > /dev/null
iotest 0xfffc8008 w
iotest 0xfffc800c w 0x0000 > /dev/null
iotest 0xfffc8008 w
done
iotest is devmem2.
The first two writes setup the SPI (which may mess up any other SPI devices used in system drivers, such as the dataflash).
At the beginning of each loop I go to the screen origin so the values appear in the same spot on the screen each loop.
I'm using 16 bit transfers. The touchscreen chip essentially has a 3 byte cycle for each conversion - 1 byte to setup the conversion, and two bytes to read the conversion out. During the last byte the next conversion may be setup. Since I need to do two conversions (x and y) then I have 5 bytes to transfer - remember that second conversion's first byte can overlap the first conversion's last byte. I do three 16 bit transfers, with the first byte all 0, giving me a total of 5 useful bytes:
The first transfer does nothing for 8 bits, then sets up the first conversion.
The second transfer clocks the results out and at the end sets up the second conversion.
The third transfer clocks the results of the second transfer out.
By offsetting this by 8 bits the full X value is found in the second 16 bit result, and the full Y value is found in the third 16 bit result. If I wanted results continuously, I could also start another X conversion in the third transfer and loop around:
Code:
iotest 0xfffc800c w 0x0094 > /dev/null #Start x
iotest 0xfffc8008 w > /dev/null
:loop
iotest 0xfffc800c w 0x00D4 > /dev/null #Start Y
iotest 0xfffc8008 w #X result
iotest 0xfffc800c w 0x0094 > /dev/null #Start X
iotest 0xfffc8008 w #Y result
goto loop
In this case I just want it to be simple. The script loops forever (CTRL-C to exit) displaying the output of the converter in the bottom 2 bytes of the returned data:
Code:
/dev/mem opened.
Memory mapped at address 0x40006000.
Value at address 0xFFFC8008 (0x40006008): 0xB0E28
/dev/mem opened.
Memory mapped at address 0x40006000.
Value at address 0xFFFC8008 (0x40006008): 0xB09C0
The above is the result with the stylus in the upper left hand corner of the screen. The top nibble B indicates that all four chip selects except NCS2 are high - the touchscreen chip select is low (active).
So the result is 0x0E28 and 0x09C0 for X, Y respectively.
Code:
/dev/mem opened.
Memory mapped at address 0x40006000.
Value at address 0xFFFC8008 (0x40006008): 0xB3B18
/dev/mem opened.
Memory mapped at address 0x40006000.
Value at address 0xFFFC8008 (0x40006008): 0xB4238
This was near the middle of the screen, 0x3B18 and 0x4238
Code:
/dev/mem opened.
Memory mapped at address 0x40006000.
Value at address 0xFFFC8008 (0x40006008): 0xB6E28
/dev/mem opened.
Memory mapped at address 0x40006000.
Value at address 0xFFFC8008 (0x40006008): 0xB75F0
This was near the bottom right of the screen, with the result 0x6E28, 0x75F0.
The result is only 12 bits, and is shifted left 3 bits, so the top bit and the lowest three bits are always 0.
As I'm under pressure to just get this out, I'm going to be creating a userspace demo program that uses this. Later I expect I'll fiddle with drivers to get the various patched drivers working.
Also, the pen detect is bit 2 at address 0xFFFFF83C (port C read) as long as it's set as input (on bootup in my configuration it is)
So "devmem2 0xFFFFF83C w" will return whether the pen is down or not in bit 2. If the pen is not down, the conversion results are undefined - do not depend on the conversion without checking the pen status.
-Adam
Forum
