TuxScreen on SourceForge TuxScreen CVS search the Wiki
Browsing -> Wiki -> Main -> [TouchScreen]
Google
Topic:
edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki create a new user or login

The Touch Screen bug is no more

[KenRestivo notes: Reading to the end of this page, it looks like this bug still exists and a fix is still being worked on. But, in my experience, this patch works like a champ and this bug is indeed gone. but NOTE! the binary 0.4 kernel in the downloads area does not have the patch. To use a patched kernel, checkout buildroot-tux from cvs with -r kernel2_4_7, and build and use that kernel instead. It works perfectly for me on a tuxscreen that did not work with the binary 0.4 kernel.]

SpaceCoaster with the able assistance of CosmicPenguin and DerekAtkins eliminated all possibilities until only the most obvious remained!

reset the codec

The lines

GPDR |= GPIO_GPIO18;
GPCR = GPIO_GPIO18;
GPSR = GPIO_GPIO18;

added into ucb1200_sa1100.c just before we initialize the MCP does the trick.


The DSTN panel has a TouchScreen interface as well which hooks up through the ucb1200.

Shaggy says there are 4 ways to read the x/y info from the ucb1200 and that Inferno averages them all. The 4 ways of reading the screen are all the combinations of reversing the polarity, and picking which edge to take the reading from. i.e., for reading X, you can:

  • charge left, ground right, read top
  • charge right, ground left, read top
  • charge left, ground right, read bottom
  • charge right, ground left, read bottom

TimRiker didn't know where else to put this. Inferno get's 8 levels of contrast but only 4 levels of brightness on the display.


The TouchScreen works fine under Linux on all systems now. We started tracking serial numbers here before SpaceCoaster found the problem. You can still enter the last 4 digits of the serial number (the last 4 digits of the one that starts with IS2630PCC0) here (in sorted order):

sn#status nick comm board revision mainboard revision
1887Y RussDill
1899Y TimRiker rev E issue 3 rev E issue 3
1939Y ZachH
1989Y NamKyu
1997N DerekMulcahy rev E issue 3
2056Y JohnLaur rev E issue 3 rev E issue 3
2316N GiuseppeOttaviano rev E issue 3
2321Y GiuseppeOttaviano ?
2328Y JordoCrouse
2510Y EricJorgensen
3206Y EricJorgensen
3258N TimRiker rev E issue 3 rev E issue 3
3303N KenRestivo
3363Y CarlWorth
3501Y RussDill
3525N MatthewAllum
3712? RussNelson
3721Y PTD rev E issue 3
4051N ErikAndersen
????Y CarlWorth

JohnLaur notes that this serial number business is not making any sense. Perhaps there is another part number that would better distinguish units with working touchscreens from units without. GiuseppeOttaviano notes that on the comm board there is a revision/issue number that could be related to the problem. In his ts-not-working tuxscreen it's "rev E issue 3". He doesn't know about the working one because he didn't open it :-)). GiuseppeOttaviano adds that the commboard in the photograph in the hardware page seems to be an "issue 1" (I'm not sure because of the low resolution). So different issues of the board DO exist!

RussNelson wonders how to test his TouchScreen.

TimRiker mentions that RussNelson could try MicroWindows.

CarlWorth mentions that RussNelson could also try RunningX.

(10/04) AkulaSJ wonders if getting output from 'cat /dev/ucb1200-ts' when touching the screen counts as 'working'

(10/07) AkulaSJ later finds out that MicroWindows and the touchscreen are working on his box.

TimRiker reloaded Inferno (see ReInferno) on 3258 and Inferno worked with the TouchScreen. He then reloaded Linux and it still did not work with the TouchScreen. We are definitely missing something in the hardware setup. This is a software issue that will be found.

GiuseppeOttaviano was among the many to notice a lockup during init with the kernel that has backlight controls enabled. The lockup occurs while the kernel is trying to turn on the backlight. JordoCrouse notes that we appear to be waiting for an interrupt that never comes. This could explain alot. Is it possible that different boards have different interrupts for stuff like the UCB1200 ADC? JohnLaur wonders if the only machines that lock up with the backlight patch are machines which have non-working (as of yet) touchscreens?

JordoCrouse replies that this is almost certainly the case, since the backlight patch works very well on his tuxscreen with a working touchscreen, while the same kernel locks on GiuseppeOttaviano's device as well as MarkLehrer's device (both with non functioning touchscreens).

DerekMulcahy changes his mind, the touch screen doesn't work AND the backlight patch makes the kernel hang.

PTD wonders if there are any firmware differences (e.g. F!kern1, F!config, etc.)?

DerekAtkins notes that the MainBoard appears to be the key element that differentiates the working from non-working TuxScreen units. I've got two units, one works, one does not. Swapping the CommunicationsBoard or the TouchScreen between the two units does not change the working-ness of the resulting box. This implies that working-ness is based on the MainBoard.

JordoCrouse then points out that this means that the UCB1200 chip is completely absolved from any problems, becuase it resides on the CommunicationsBoard. Further work with SpaceCoaster shows that the CRC bit (read complete) on the processor register Ser4MCSR is not being set, resulting in the backlight hangs. Others have experienced similar hangs while trying to get the UCB1200 register values from /proc/driver/ucb1200/*, so JordoCrouse believes that the bug resides somewhere in the pipe between the UCB1200 and the processor.

Now we just need to figure out what's different between these two main boards and write the software to work around the differences.

SourceForge Content of these pages are owned and copyrighted by the poster. SourceForge