Questions on (QuickStart) touchpads
er@ Anyone
Working with the QS (= QuickStart) board, the use of the touchpads appears somewhat touchy. I visualize a touchpad circuitry as simply depicted below my code:
Here's a strange detail. I have a Tektronix 2241A scope with 10 MΩ, 11.8 pF probes. When I probe a J1-n pin (n = 1..8 for P0..P7 I/O) attached to the touch pads, I see a positive pulse on the scope, which decays towards ground in less than 0.5 msec. Using ViewPort, it shows the touchpad I/O at a HI level when not probed by the scope, but a positive pulse, width ~ 300 µsec, and the rest of the time at ground until the next touchpad 'charge' time.
The sense time occurs after a ~ 40 µsec 'charge' pulse (I'm basically using Jonny Mac's scan_pads PUB code.) Why does the scope probe discharge the 'charge' pulse level so quickly?
I was hoping to 'hold' the updating of a LED display until a touch of a touchpad (presently using a waitcnt of ~5 sec). The LCD shows 16 characters of the LCD character ROM, a Space, the beginning and ending character values, separated with a hyphen. That part works great. ViewPort shows the operation properly, but adding a scope probe messes with the 'discharge' time. Makes for rough debugging.
Comment: the 'drawing' was drawn in the Prop IDE, copied out, and pasted into the forum editor. Somehow I got it right this time. Hurrah. But looks bad in the editor view.
Working with the QS (= QuickStart) board, the use of the touchpads appears somewhat touchy. I visualize a touchpad circuitry as simply depicted below my code:
[font=Parallax][size=2] x := 0 repeat repeat y from 1 to 16 chr := x ' send 16 char wr_LCD x += 1 ' waitcnt((MS_001 * 500) +cnt) chr := $20 ' show a Space wr_LCD chr := (x - 1) & $F0 ' display beginning value wr_hex chr := "-" ' use '-' separator wr_LCD chr := x - 1 ' display ending va~ 5 sec wr_hex repeat until scan <> 0 ' loop until a pad is touched scan := scan_pads ' touched pad(s) return non-zero value OUTA[LED7..LED0] := scan scan := 0 ' touched pad(s) return non-zero value waitcnt((MS_001 * 5000) +cnt) ' pause for 5 sec OUTA[RS_LCD]~ chr := $E0 wr_LCD OUTA[RS_LCD]~~ PUB scan_pads : pads DIRA[24]~~ ' use P24 for debugging this PUB in ViewPort DEBUG OUTA[24]~~ ' set pin HI DEBUG OUTA[PAD7..PAD0]~~ ' charge pad/line capacitance DIRA[PAD7..PAD0]~~ ' (set line HI; touch drains line LO) DIRA[PAD7..PAD0]~ ' release lines to input state waitcnt(MS_001 * 10 + cnt) ' give time for'touch' discharge pads := $0000_00FF & !INA[PAD7..PAD0] ' return touched pad(s) value ' DIRA[PAD7..PAD0]~~ ' return lines to output state MAY NOT BE NEEDED OUTA[24]~ ' then LO DEBUG PUB wr_hex n := chr ' save value chr >>= 4 ' get ms nybble fix_hex ' convert to ASCii chr := n & $0F ' get ls nybble fix_hex PUB fix_hex if chr => 10 ' check if greater than 9 (A..F) chr += $37 ' form ASCII 'A'..'F' else chr += $30 ' else, form '0'..'9' wr_LCD {{ J1- pin n (SMD header) │ │ Propeller 1 touchpad 100K │ Rprop ┳──────────╋──────┳──────V? C1? C2? Cprop    }} [/size][/font]
Here's a strange detail. I have a Tektronix 2241A scope with 10 MΩ, 11.8 pF probes. When I probe a J1-n pin (n = 1..8 for P0..P7 I/O) attached to the touch pads, I see a positive pulse on the scope, which decays towards ground in less than 0.5 msec. Using ViewPort, it shows the touchpad I/O at a HI level when not probed by the scope, but a positive pulse, width ~ 300 µsec, and the rest of the time at ground until the next touchpad 'charge' time.
The sense time occurs after a ~ 40 µsec 'charge' pulse (I'm basically using Jonny Mac's scan_pads PUB code.) Why does the scope probe discharge the 'charge' pulse level so quickly?
I was hoping to 'hold' the updating of a LED display until a touch of a touchpad (presently using a waitcnt of ~5 sec). The LCD shows 16 characters of the LCD character ROM, a Space, the beginning and ending character values, separated with a hyphen. That part works great. ViewPort shows the operation properly, but adding a scope probe messes with the 'discharge' time. Makes for rough debugging.
Comment: the 'drawing' was drawn in the Prop IDE, copied out, and pasted into the forum editor. Somehow I got it right this time. Hurrah. But looks bad in the editor view.
Comments
After lots of digging, found a broken wire to the LCD. I know better than to use wire-wrap wire for certain things; but didn't have stranded on hand. Well it worked for about 2 months, then didn't a few days ago. Right in the midst of debugging other problems. Found I also needed to add some delay after strobing data into the LCD. Even Spin was too fast for the LCD to accept initialization before the next values were presented. A few photos to 'show-n-tell. Used 'paper clip' wire to solder onto the LCD mounting frame tangs and into the mezzanine board. Now shouldn't incur more broken wire, as they were strained every time it was moved. Bad leaving the LCD 'cabling' at the mercy of movement, cats, or me.
After finding the LCD loaded down and pulled up the touchpad lines (P0..P7), I rewired to use P16..P23. Blinks the LEDs whenever the LCD is updated. Next to try to get access to those touchpads to have some 'control' of selections. QuickStart is a fun, smaller than a credit card, module to work with.
edit: After some code cleanup, it now allows Jonny Mac's 'scan touchpads' to work for increment/decrement to read out the LCD ROM character set, forwards or backwards 16 values. Nice to have sojme control over the program and displayed results. Since the same 8-bit buss drives the LCD and the LEDs, when data is sent to the LCD the LEDs flash, but that is only for a brief moment when 22 of the 24 digits are updated. I present the scanned touchpad value to be displayed for a short time (1/2 sec) to indicate to the 'operator' which touchpad(s) actually were detected.
Nice to get to this point. Seems each LCD type has a seemingly tough grind to get them working. This LCD has it's built-in contrast setting and comes up full contrast, so isn't like no contrast but is otherwise working but the user can't see any display problem.