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.