From: thaGod <th...@gm...> - 2007-10-31 22:55:52
|
Ok, more or less I have it working. When I run ts_calibrate I don't see any of the crosshairs or anything... I assume this has to do with some kink in my TSLIB env variables or fb0 setup.. not my biggest concern atm. I'm puting together a basic directfb test application that places a sprite where I touch on the screen. I'm just familiarizing myself with the directfb API, so it's not quite in working order. I do get the tsc2003 listed as my linux_input device and a thread is launched properly upon directfb application launch. It might be worth mentioning the exact steps for getting things up and running. mkdir /dev/input mknod /dev/input/event0 c 13 64 mknod /dev/input/event1 c 13 65 export TSLIB_TSDEVICE=/dev/input/event0 export TSLIB_CONFFILE=/etc/ts.conf modprobe evdev modprobe i2c-pxa modprobe tsc2003 Like I said.. with this setup I still just get a blank screen when I run ts_calibrate, but I do get some values shown.. I can't tell if everything is working right... I'll know soon enough. BTW the modprobing could be made easier by adding the dependencies to the end of the tsc2003 module in modules.dep. Just add a colon and then list separated by spaces the full paths to each dependency module. Erick -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13520430 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bill G. <bg...@bi...> - 2007-11-01 20:00:52
|
thaGod wrote: > This is my dmesg.. there's somethin goofy going on. Anyone ran into this > before? > Have you tested your i2c interface with any other chips? Makes me wonder if you're missing a pullup resistor somewhere... b.g. -- Bill Gatliff bg...@bi... |
From: thaGod <th...@gm...> - 2007-11-01 20:41:02
|
I haven't tried any other devices. This should be easy enough to scope... I think I can get to the SDA and SDL pins on the chip while everything is up and running. Erick Bill Gatliff wrote: > > thaGod wrote: >> This is my dmesg.. there's somethin goofy going on. Anyone ran into this >> before? >> > > Have you tested your i2c interface with any other chips? Makes me > wonder if you're missing a pullup resistor somewhere... > > > b.g. > > -- > Bill Gatliff > bg...@bi... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13536998 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Gordon K. <go...@gu...> - 2007-11-02 17:28:05
|
Hmmm. 1) SDA and SCL are pulled up through 4K7 to 3.3V on the verdex. 2) nPENIRQ is pulled up through 75K to 3.3V on the console-LCD but unused by the gumstix. Gordon > So far.. not good for gumstix. There are no pullups on SDA or SCL. > Additionally there is no 50k pullup on penirq. !!! <insert expletives here> > > With 1.5Ks on the clock and data lines and 50k on the penirq.. I'm still > getting the same errors. I'm going through the datasheet more carefully now > that I know my hardware can't be trusted. More to follow... > > Erick > > > thaGod wrote: > >> I haven't tried any other devices. This should be easy enough to scope... >> I think I can get to the SDA and SDL pins on the chip while everything is >> up and running. >> >> Erick >> >> >> Bill Gatliff wrote: >> >>> thaGod wrote: >>> >>>> This is my dmesg.. there's somethin goofy going on. Anyone ran into this >>>> before? >>>> >>>> >>> Have you tested your i2c interface with any other chips? Makes me >>> wonder if you're missing a pullup resistor somewhere... >>> >>> >>> b.g. >>> >>> -- >>> Bill Gatliff >>> bg...@bi... >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >>> >> > > |
From: thaGod <th...@gm...> - 2007-11-02 18:03:19
|
SDA and SCL have no voltage on them without the pullups that I added. Apparently the pullups on the Verdex (assuming they actually do exist) aren't connected.. same goes for the 75K pullup on the consoleLCD... I see no voltage on pin 9 of the tsc2003 either (without my own pullup). Is it possible that we're dealing with different board/schematic revisions? I got this verdex+console a little over a month ago.. and I think I waited 3 weeks before that... so roughly 2 months ago. Erick Gordon Kruberg wrote: > > Hmmm. > > 1) SDA and SCL are pulled up through 4K7 to 3.3V on the verdex. > 2) nPENIRQ is pulled up through 75K to 3.3V on the console-LCD but > unused by the gumstix. > > Gordon > >> So far.. not good for gumstix. There are no pullups on SDA or SCL. >> Additionally there is no 50k pullup on penirq. !!! <insert expletives >> here> >> >> With 1.5Ks on the clock and data lines and 50k on the penirq.. I'm still >> getting the same errors. I'm going through the datasheet more carefully >> now >> that I know my hardware can't be trusted. More to follow... >> >> Erick >> >> >> thaGod wrote: >> >>> I haven't tried any other devices. This should be easy enough to >>> scope... >>> I think I can get to the SDA and SDL pins on the chip while everything >>> is >>> up and running. >>> >>> Erick >>> >>> >>> Bill Gatliff wrote: >>> >>>> thaGod wrote: >>>> >>>>> This is my dmesg.. there's somethin goofy going on. Anyone ran into >>>>> this >>>>> before? >>>>> >>>>> >>>> Have you tested your i2c interface with any other chips? Makes me >>>> wonder if you're missing a pullup resistor somewhere... >>>> >>>> >>>> b.g. >>>> >>>> -- >>>> Bill Gatliff >>>> bg...@bi... >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Splunk Inc. >>>> Still grepping through log files to find problems? Stop. >>>> Now Search log events and configuration files using AJAX and a browser. >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>>> >>> >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13552992 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-11-02 21:28:31
|
Thanks for everyone's help.. especially Bill and Nick. I appreciate it, but this issue will have to remain unresolved for someone else. I'm switching to a different touchscreen and our own code. I can have my own expansion board designed and in house by the time I get my applications written, so that's what I'm going to do. Erick thaGod wrote: > > SDA and SCL have no voltage on them without the pullups that I added. > Apparently the pullups on the Verdex (assuming they actually do exist) > aren't connected.. same goes for the 75K pullup on the consoleLCD... I see > no voltage on pin 9 of the tsc2003 either (without my own pullup). > > Is it possible that we're dealing with different board/schematic > revisions? I got this verdex+console a little over a month ago.. and I > think I waited 3 weeks before that... so roughly 2 months ago. > > Erick > > > Gordon Kruberg wrote: >> >> Hmmm. >> >> 1) SDA and SCL are pulled up through 4K7 to 3.3V on the verdex. >> 2) nPENIRQ is pulled up through 75K to 3.3V on the console-LCD but >> unused by the gumstix. >> >> Gordon >> >>> So far.. not good for gumstix. There are no pullups on SDA or SCL. >>> Additionally there is no 50k pullup on penirq. !!! <insert expletives >>> here> >>> >>> With 1.5Ks on the clock and data lines and 50k on the penirq.. I'm still >>> getting the same errors. I'm going through the datasheet more carefully >>> now >>> that I know my hardware can't be trusted. More to follow... >>> >>> Erick >>> >>> >>> thaGod wrote: >>> >>>> I haven't tried any other devices. This should be easy enough to >>>> scope... >>>> I think I can get to the SDA and SDL pins on the chip while everything >>>> is >>>> up and running. >>>> >>>> Erick >>>> >>>> >>>> Bill Gatliff wrote: >>>> >>>>> thaGod wrote: >>>>> >>>>>> This is my dmesg.. there's somethin goofy going on. Anyone ran into >>>>>> this >>>>>> before? >>>>>> >>>>>> >>>>> Have you tested your i2c interface with any other chips? Makes me >>>>> wonder if you're missing a pullup resistor somewhere... >>>>> >>>>> >>>>> b.g. >>>>> >>>>> -- >>>>> Bill Gatliff >>>>> bg...@bi... >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Splunk Inc. >>>>> Still grepping through log files to find problems? Stop. >>>>> Now Search log events and configuration files using AJAX and a >>>>> browser. >>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>>>> >>>> >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13556592 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Craig H. <cr...@gu...> - 2007-10-22 22:54:21
|
On Oct 22, 2007, at 3:33 PM, thaGod wrote: > I'm really beginning to wonder why this LCD/touchscreen combo was > chosen by > gumstix. It seems like it would have made more sense to go with a > 24bit LCD > and a touchscreen controller that is already supported in the > kernel. It may > just be easier to lay out a new expansion board with a UCB1400 and > reroute > the LCD signals to make use of a different TFT. The panel *is* a 24-bit panel. Only 18 bits are brought out on the 60-pin connector from the gumstix though. We do have a new board using the UCB1400 (working name audiostix III), but it'll have audio jacks and other bits on it too, and will be more expensive than the console board(s). The part cost just on the UCB1400 vs TSC2003 by themselves is pretty significant. I have used Dave Hylands' I2C read/write program to talk to the TSC on the console-lcd-vx before, so I know it can be made to work... C |
From: Philip B. <ph...@ba...> - 2007-10-23 10:57:32
Attachments:
smime.p7s
|
Craig Hughes wrote: > I have used Dave Hylands' I2C read/write program to talk to the TSC > on the console-lcd-vx before, so I know it can be made to work... What is the I2C address of the TSC? Philip |
From: Craig H. <cr...@gu...> - 2007-10-23 16:35:07
|
From the datasheet: "The first five bits (MSBs) of the slave address are factory preset to 10010. The next two bits of the address byte are the device select bits: A1 and A0. Input pins (A1-A0) on the TSC2003 determine these two bits of the device address for a particular TSC2003." On the console-lcd-vx, A1 and A0 are both pulled down, so the address is 0b1001000 or 0x48 -- remember though that those are the first 7 bits, and the 8th bit is the "read/write" bit: 1 for read, 0 for write. So if you access 0x90 you can write to the device, 0x91 to read from the device. See page 16 of the datasheet <http://www.ti.com/lit/gpn/tsc2003> for details on the commands you can send and the data you can read back. Section 3 of this appnote <http://www.ti.com/litv/pdf/slaa359> might also be helpful. C On Oct 23, 2007, at 3:56 AM, Philip Balister wrote: > Craig Hughes wrote: >> I have used Dave Hylands' I2C read/write program to talk to the >> TSC on the console-lcd-vx before, so I know it can be made to >> work... > > What is the I2C address of the TSC? > > Philip > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: thaGod <th...@gm...> - 2007-10-29 14:00:24
|
Bill, That would be great. I'm going to try and get my footing today so we can have an intelligent dialogue about your code =) thanks, Erick Bill Gatliff wrote: > > thaGod wrote: >> Philip, >> >> Yep, that is the same code. I've recently moved past my LCD color >> problems >> and I'm ready to tackle this touchscreen driver. Did you compile this >> into >> your kernel, or as a module.. ? I think I did try dropping this in the >> kernel source and editing the K files to add it to the menuconfig. If I >> remember right it had errors? I didn't take the time then to address >> them. >> >> Just a couple more questions.. should be easy. Did you use tslib as well? >> and were you using any kind of window manager or directfb or qtopia or >> something? Just kinda trying to get an idea of the path you've already >> explored. >> >> > > I'd be happy to help you get that code running on the latest kernels. I > wrote it back in the 2.6.12 days, and a lot of the APIs have changed > since then... and I just haven't had time to keep up! > > > Regards, > > > b.g. > > -- > Bill Gatliff > bg...@bi... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13467889 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-29 17:49:50
|
Ok, I've got it worked in where I want it and I've started working on getting it to compile. The first hurdle appears to be some changes in i2c.h: ============================================================= drivers/i2c/chips/tsc2003.c:19: error: 'I2C_CLIENT_ISA_END' undeclared here (not in a function) drivers/i2c/chips/tsc2003.c:21: error: 'normal_i2c_range' undeclared here (not in a function) drivers/i2c/chips/tsc2003.c:21: error: initializer element is not constant drivers/i2c/chips/tsc2003.c:21: error: (near initialization for 'addr_data.normal_i2c_range') drivers/i2c/chips/tsc2003.c:21: error: 'normal_isa_range' undeclared here (not in a function) drivers/i2c/chips/tsc2003.c:21: error: initializer element is not constant drivers/i2c/chips/tsc2003.c:21: error: (near initialization for 'addr_data.normal_isa_range') drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': drivers/i2c/chips/tsc2003.c:334: warning: passing argument 2 of 'request_irq' from incompatible pointer type drivers/i2c/chips/tsc2003.c:337: warning: implicit declaration of function 'set_irq_type' drivers/i2c/chips/tsc2003.c:337: error: 'IRQ_TYPE_EDGE_FALLING' undeclared (first use in this function) drivers/i2c/chips/tsc2003.c:337: error: (Each undeclared identifier is reported only once drivers/i2c/chips/tsc2003.c:337: error: for each function it appears in.) drivers/i2c/chips/tsc2003.c: In function 'tsc2003_probe': drivers/i2c/chips/tsc2003.c:471: warning: implicit declaration of function 'to_platform_device' drivers/i2c/chips/tsc2003.c:471: warning: initialization makes pointer from integer without a cast drivers/i2c/chips/tsc2003.c:472: warning: implicit declaration of function 'platform_get_irq' drivers/i2c/chips/tsc2003.c: In function 'tsc2003_driver_register': drivers/i2c/chips/tsc2003.c:503: error: 'platform_bus_type' undeclared (first use in this function) drivers/i2c/chips/tsc2003.c:503: warning: assignment from incompatible pointer type drivers/i2c/chips/tsc2003.c:511: warning: implicit declaration of function 'init_input_dev' drivers/i2c/chips/tsc2003.c:522: warning: passing argument 2 of 'driver_find' from incompatible pointer type drivers/i2c/chips/tsc2003.c: At top level: drivers/i2c/chips/tsc2003.c:552: error: unknown field 'owner' specified in initializer drivers/i2c/chips/tsc2003.c:552: warning: initialization makes integer from pointer without a cast drivers/i2c/chips/tsc2003.c:553: error: unknown field 'name' specified in initializer drivers/i2c/chips/tsc2003.c:553: warning: initialization makes integer from pointer without a cast drivers/i2c/chips/tsc2003.c:554: error: unknown field 'flags' specified in initializer drivers/i2c/chips/tsc2003.c:554: error: 'I2C_DF_NOTIFY' undeclared here (not in a function) drivers/i2c/chips/tsc2003.c:554: error: initializer element is not constant drivers/i2c/chips/tsc2003.c:554: error: (near initialization for 'tsc2003_driver.attach_adapter') ================================================================ I'm comparing the old version of i2c.h (which I believe is the one you have used) with the latest version and it seems to have changed fairly significantly. I doubt I can get away with replacing the new with the old, but I will try it just to rule it out. I'll do this first and then get to work on tracing all the changes and getting things updated. Also, I think the use of linux/config.h is depreciated? I simply added a symlink to autoconf.h. i2c-sensors.h was not included in the 2.6.21 kernel that gumstix is using. That's as far as I've gotten. Erick Bill Gatliff wrote: > > thaGod wrote: >> Bill, >> >> That would be great. I'm going to try and get my footing today so we can >> have an intelligent dialogue about your code =) >> > > Great! > > In retrospect, I think I kinda over-engineered the thing in a few spots, > but the chip has so much stuff on it that I was using at the time... And > there are a few errata, too. The details of all seem to escape me at the > moment. > > In general, the way it works is that when the device is in use, there's > a worker thread that looks at the ADCs whenever the pen is down, and > feeds the results to an input device (which is later handled by TSLIB). > The worker thread tries to scan the glass semi-periodically, rather than > on each PENIRQ, because the latter is incredibly noisy as you might > expect. > > Basically, the kernel thread is a state machine that, on the first pen > interrupt, starts sampling the glass periodically until the pen > interrupts have "gone away". I use timeouts and completions to help > determine when the pen interrupt is still happening, but don't do the > actually sampling inside of the interrupt handler. > > Also, I noted somewhere that I think there's an initialization race in > tsc2003_idev_open. It didn't seem to come up in 2.6.12, but I think in > later kernels you'll get an OOPS because I set up the interrupt handler > before the completion for the penirq is initialized. > > > Questions, comments welcome. > > > b.g. > > -- > Bill Gatliff > bg...@bi... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13473067 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-10-29 21:22:53
|
Ok.. I got everything to compile with just a few warnings. It doesn't however make it all the way to being installed as a kernel module. This is the line causing the problem and it seems to be another i2c.h reference that has since changed. init_input_dev(&data->idev); It appears as though people are doing it this way now: data->idev = input_allocate_device(); but when I do it this way I get a new error... drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of 'request_irq' from incompatible pointer type drivers/i2c/chips/tsc2003.c: In function 'tsc2003_driver_register': drivers/i2c/chips/tsc2003.c:514: error: incompatible types in assignment drivers/i2c/chips/tsc2003.c: In function 'tsc2003_i2c_attach_adapter': drivers/i2c/chips/tsc2003.c:538: warning: implicit declaration of function 'i2c_detect' the init_input_dev fail only happens at the modpost stage of the kernel build. I don't quite understand this problem, but it has been a long day. I'm thinking tomorrow sounds like a better time to tackle this =) Erick -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13477308 Sent from the Gumstix mailing list archive at Nabble.com. |
From: nchen <nc...@cs...> - 2007-10-29 23:49:43
|
I've been hacking at this as well. I actually have a semi-working TSC2003 driver (i.e. sort of works with the tslib test programs and also works in Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it builds on gumstix build 1432 (2.6.20 kernel?). I've noticed some strange behavior when running ts_test in that it reports spurious coordinates (cursor seems to jump to a position off screen intermittently). I don't know if this is from my changes or if this was happening originally. In any case, I think it might be a starting point for a more stable and bug free version. I can post a copy if you think it will be helpful. Nick thaGod wrote: > > I've started working on this problem... I'm at home now so I don't have my > code in front of me. I think I changed the input_dev idev declaration to > input_dev * idev and that seemed to break me into the rest of the errors > I'll need to get it reworked. > > All-in-all though this hasn't been too painful. Philip have you already > done all this? This seems to be required stuff in order to compile this > driver. Maybe you'll have some insight into getting this compiled > initially. > > thanks, > Erick > > > Bill Gatliff wrote: >> >> thaGod wrote: >>> drivers/i2c/chips/tsc2003.c: In function 'tsc2003_idev_open': >>> drivers/i2c/chips/tsc2003.c:336: warning: passing argument 2 of >>> 'request_irq' from incompatible pointer type >>> >> >> Interrupt handlers have a different signature now. >> >> >> b.g. >> >> -- >> Bill Gatliff >> bg...@bi... >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13479346 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Bill G. <bg...@bi...> - 2007-10-30 02:03:55
|
nchen wrote: > I've been hacking at this as well. I actually have a semi-working TSC2003 > driver (i.e. sort of works with the tslib test programs and also works in > Qtopia using tslib). I modified Bill Gatliff's 2.6.12 code so that it builds > on gumstix build 1432 (2.6.20 kernel?). > > I've noticed some strange behavior when running ts_test in that it reports > spurious coordinates (cursor seems to jump to a position off screen > intermittently). I don't know if this is from my changes or if this was > happening originally. > It worked smoothly on my test systems here. Note that the hardware can be hard to get right, because the touch screen is basically a giant antenna--- things will be noisy without filtering on the lines. Check the datasheets for the TSC2003 for recommendations, IIRC. One source of noise for me early on was interrupting ADC reads to perform other ADC reads--- software bug. The converters in the TSC2003 are pretty fussy. On top of that, if you don't sequence the reads right then you end up injecting additional noise from the switching circuits into the measurements. But I think that problem yields consistently bad measurements, not intermittent ones. b.g. -- Bill Gatliff bg...@bi... |
From: Craig H. <cr...@gu...> - 2007-10-31 00:05:41
|
On Oct 30, 2007, at 2:06 PM, thaGod wrote: > I guess I'm missing something here as I try to make use of the > driver. I've > modprobed the tsc2003 driver and exported my TSLIB_TSDEVICE > variable to > /dev/input/event0, and I've set up ts.conf for module_raw input. I > guess my > problem is with my mknod step. Maybe I just can't seem to pick the > right > major/minor combo or something. The only way I can get ts_* > programs to do > anything besides give me a ts_open: device not found error is to mknod > /dev/input/event0 p as a pipe, but then the test apps just hang. > Any ideas? In these udev times, if you ever find yourself running "mknod", you've probably got something mis-configured, or forgot to load a module or something. You should basically never have to create device nodes yourself, unless you're doing something *really* exotic. C |
From: Bill G. <bg...@bi...> - 2007-10-31 03:13:48
|
Craig Hughes wrote: > You should basically never have to create device nodes yourself, unless you're doing something *really* exotic. > ... like, say, not running udev? :) b.g. -- Bill Gatliff bg...@bi... |
From: thaGod <th...@gm...> - 2007-10-31 03:07:30
|
Hrmm... I'd have to agree, but Nick seems to be using this driver in conjunction with tslib. I know the module doesn't spawn a dev node upon loading, so is this something I should look at adding? It does compile just fine. I have little doubt that this driver is actually doing what it is supposed to do... I just can't seem to get tslib to make meaningful contact with it. I just don't understand the code yet :/ I haven't had the pleasure of a touchscreen project before this one. Erick Craig Hughes wrote: > > On Oct 30, 2007, at 2:06 PM, thaGod wrote: > >> I guess I'm missing something here as I try to make use of the >> driver. I've >> modprobed the tsc2003 driver and exported my TSLIB_TSDEVICE >> variable to >> /dev/input/event0, and I've set up ts.conf for module_raw input. I >> guess my >> problem is with my mknod step. Maybe I just can't seem to pick the >> right >> major/minor combo or something. The only way I can get ts_* >> programs to do >> anything besides give me a ts_open: device not found error is to mknod >> /dev/input/event0 p as a pipe, but then the test apps just hang. >> Any ideas? > > In these udev times, if you ever find yourself running "mknod", > you've probably got something mis-configured, or forgot to load a > module or something. You should basically never have to create > device nodes yourself, unless you're doing something *really* exotic. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13502162 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-11-01 19:58:51
|
This is my dmesg.. there's somethin goofy going on. Anyone ran into this before? i2c /dev entries driver I2C: i2c-0: PXA I2C adapter I2C: i2c-1: PXA I2C adapter tsc2003 i2c touch screen controller Bill Gatliff <bgat at billgatliff.com Nicholas Chen <nchen at cs.umd.edu> tsc2003_i2c_detect: probing address 0x48 tsc2003_driver_register: irq 48 input: tsc2003 as /class/input/input0 tsc2003 - registering input device tsc2003_i2c_detect: device address 0x48 attached. i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000007e0 ISR: 00000002 i2c: log: [00000446:000007e0] i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000007e0 ISR: 00000002 i2c: log: [00000446:000007e0] i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000007e0 ISR: 00000002 i2c: log: [00000446:000007e0] tsc2003 i2c touch screen controller Bill Gatliff <bgat at billgatliff.com Nicholas Chen <nchen at cs.umd.edu> tsc2003_i2c_detect: probing address 0x48 i2c: error: timeout i2c: msg_num: 1 msg_idx: 0 msg_ptr: 1 i2c: ICR: 000017ee ISR: 00000005 i2c: log: [00000045:000017e8] [00000085:000017ee] i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c: error: exhausted retries i2c: msg_num: 1 msg_idx: 0 msg_ptr: 1 i2c: ICR: 000017ee ISR: 00000005 i2c: log: [00000045:000017e8] [00000085:000017ee] i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c: error: exhausted retries i2c: msg_num: 1 msg_idx: 0 msg_ptr: 1 i2c: ICR: 000017ee ISR: 00000005 i2c: log: [00000045:000017e8] [00000085:000017ee] i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c_adapter i2c-1: i2c_pxa: timeout waiting for bus free i2c: error: exhausted retries i2c: msg_num: 1 msg_idx: 0 msg_ptr: 1 i2c: ICR: 000017ee ISR: 00000005 i2c: log: [00000045:000017e8] [00000085:000017ee] Erick -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13536277 Sent from the Gumstix mailing list archive at Nabble.com. |
From: thaGod <th...@gm...> - 2007-11-02 16:58:57
|
So far.. not good for gumstix. There are no pullups on SDA or SCL. Additionally there is no 50k pullup on penirq. !!! <insert expletives here> With 1.5Ks on the clock and data lines and 50k on the penirq.. I'm still getting the same errors. I'm going through the datasheet more carefully now that I know my hardware can't be trusted. More to follow... Erick thaGod wrote: > > I haven't tried any other devices. This should be easy enough to scope... > I think I can get to the SDA and SDL pins on the chip while everything is > up and running. > > Erick > > > Bill Gatliff wrote: >> >> thaGod wrote: >>> This is my dmesg.. there's somethin goofy going on. Anyone ran into this >>> before? >>> >> >> Have you tested your i2c interface with any other chips? Makes me >> wonder if you're missing a pullup resistor somewhere... >> >> >> b.g. >> >> -- >> Bill Gatliff >> bg...@bi... >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/TI-TSC2003-touchscreen-controller-%28supplied-with-Gumstix-Samsung-display%29-tf4666655.html#a13551450 Sent from the Gumstix mailing list archive at Nabble.com. |