Hello Michael, > -----Original Message----- > From: Michael Welling [mailto:mwelling79@xxxxxxxxx] On Behalf > Of Michael Welling > Sent: Thursday, August 06, 2015 11:08 AM > To: Greg Wilson-Lindberg > Cc: Daniel Baluta; linux-iio@xxxxxxxxxxxxxxx > Subject: Re: BBB IIO ADC access not working > > On Thu, Aug 06, 2015 at 08:42:21AM -0700, Greg Wilson-Lindberg wrote: > > Hello Daniel, > > See my comments in, line > > > > > -----Original Message----- > > > From: Daniel Baluta [mailto:daniel.baluta@xxxxxxxxx] > > > Sent: Thursday, August 06, 2015 12:36 AM > > > To: Greg Wilson-Lindberg > > > Cc: linux-iio@xxxxxxxxxxxxxxx > > > Subject: Re: BBB IIO ADC access not working > > > > > > Hi Greg, > > > > > > On Sat, Aug 1, 2015 at 12:15 AM, Greg Wilson-Lindberg > > > <GWilson@xxxxxxxxxxxx> wrote: > > > > Hi Jonathan, > > > > To recap my current problems, we are using all 3 of the ADC > > > channels that are unused by the BBB for our system. One > channel has > > > an analog mux on it to allow selecting between 2 input pots. The > > > other two channels are hooked up to pressure transducers. > > > > > > What devices and drivers are you exactly using? > > > > The pressure transducers are a MPXV7007GP and a MPXV7002GP. I'm not > > using any driver, just reading that analog input and > processing in my > > application. > > > > > > > > > > > > > I'm processing the channels in a routine that gets called > > > from a timer every 100ms. I enable the IIO buffer to collect data > > > and 100ms later read the samples and turn the buffer off again. I > > > leave the buffer off for 400 ms and then go through the process > > > again. I do this enable, read, disable cycle to allow the touch > > > screen enough time to gather data to properly handle touch screen > > > events. > > > > > > > > With this setup the system will work properly for a few > > > seconds, and then the buffer/adc read process slows down > so that it > > > takes more than 2 seconds to process the two enable, > read, disable > > > cycles in my read state machine. When the slow down happens, the > > > touch screen stops responding, and even mouse presses > stop working, > > > although the mouse pointer did continue to follow mouse movements > > > and the screen continued to update properly. > > > > > > > > Because of the size of the code I've posted it on pastebin: > > > > http://pastebin.com/TDRS1nu7 instead of including it here. > > > > > > > > This is running on a Jessie debian system build from Robert > > > C. Nelson, based on the 3.18 kernel. > > The kernel messages say otherwise: > [ 0.000000] Linux version 3.14.40-ti-r62 > (root@a4-imx6q-wandboard-2gb) (gcc version 4.9.2 (Debian > 4.9.2-10) ) #1 SMP PREEMPT Thu Apr 30 18:28:06 UTC 2015 I guess I got messed up, I had been messaging RCN referring to 3.8/3.14, and I must have put them together. > > Here are a few messages that I noticed that are related to the tsadc: > [ 2.838041] TI-am335x-tsc TI-am335x-tsc: ti,charge-delay > not specified > [ 2.838401] input: ti-tsc as > /devices/ocp.3/44e0d000.tscadc/TI-am335x-tsc/input/input0 > > Something to try is specifying the ti,charge-delay in the appropriate > device tree file. > > IE: > ti,charge-delay = <0xB000>; > > Increasing this delay slows the touchscreen response time but > may help in > this situation. I added the charge-delay, it does make the system last longer before the touch screen locks up, but it does still lock up. The program that I'm testing this from is written in qt, the main GUI loop is still running, even though the touch screen has locked up, so the calls to the IIO lib are still being made, although I don't know if I'm getting back the same data as the last time it worked, or I'm not getting back any data at all. I tested it with the sampling set to twice a second, and the touch screen locked up more quickly than when set to only sample once a second. Regards, Greg > > > > > I hope that you or someone else on the list can help me > > > understand what is going on. > > > > > > Could you provide your dmesg output and also cat /proc/interrupts. > > > > Because of the length I've posted the dmesg to: > http://pastebin.com/v8kSbSAw > > There aren't any new messages at the end of the dmesg > output after the > > touch screen lockup. > > > > cat /proc/interrupts: > > CPU0 > > 23: 0 INTC 7 tps65217 > > 28: 7149 INTC 12 edma > > 30: 155 INTC 14 edma_error > > 32: 35030 INTC 16 TI-am335x-tsc, TI-am335x-adc > > 33: 348 INTC 17 47400000.dma-controller > > 34: 0 INTC 18 musb-hdrc.0.auto > > 35: 203 INTC 19 musb-hdrc.1.auto > > 36: 0 INTC 20 4a300000.pruss > > 37: 0 INTC 21 4a300000.pruss > > 38: 0 INTC 22 4a300000.pruss > > 39: 0 INTC 23 4a300000.pruss > > 40: 0 INTC 24 4a300000.pruss > > 41: 0 INTC 25 4a300000.pruss > > 42: 0 INTC 26 4a300000.pruss > > 43: 0 INTC 27 4a300000.pruss > > 44: 1790 INTC 28 mmc1 > > 46: 0 INTC 30 4819c000.i2c > > 52: 3600215 INTC 36 tilcdc > > 56: 0 INTC 40 4a100000.ethernet > > 57: 1750286 INTC 41 4a100000.ethernet > > 58: 1114 INTC 42 4a100000.ethernet > > 59: 0 INTC 43 4a100000.ethernet > > 80: 21331 INTC 64 mmc0 > > 84: 11923739 INTC 68 gp_timer > > 86: 4399997 INTC 70 44e0b000.i2c > > 88: 453 INTC 72 serial > > 90: 951 INTC 74 serial > > 91: 0 INTC 75 rtc0 > > 92: 0 INTC 76 rtc0 > > 93: 0 INTC 77 wkup_m3 > > 94: 1 INTC 78 wkup_m3_txev > > 125: 0 INTC 109 53100000.sham > > 127: 0 INTC 111 48310000.rng > > 150: 0 44e07000.gpio 6 mmc0 > > IPI0: 0 CPU wakeup interrupts > > IPI1: 0 Timer broadcast interrupts > > IPI2: 0 Rescheduling interrupts > > IPI3: 0 Function call interrupts > > IPI4: 0 Single function call interrupts > > IPI5: 0 CPU stop interrupts > > IPI6: 0 IRQ work interrupts > > IPI7: 0 completion interrupts > > Err: 0 > > > > Please let me know if there is any thing else that I can provide. > > Regards, > > Greg > > > > > > > > thanks, > > > Daniel. > > > -- > > To unsubscribe from this list: send the line "unsubscribe > linux-iio" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
