Shop OBEX P1 Docs P2 Docs Learn Events
Questions on (QuickStart) touchpads — Parallax Forums

Questions on (QuickStart) touchpads

HShankoHShanko Posts: 402
edited 2011-09-12 15:03 in Propeller 1
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:
[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)
                 &#9474;
                 &#9474;      Propeller 1
 touchpad  100K  &#9474;        Rprop
    &#9523;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#61629;&#61630;&#9472;&#9472;&#9472;&#9547;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9523;&#9472;&#9472;&#61629;&#61630;&#9472;&#9472;&#9472;&#9472;V?
   &#61612;&#61613;&#61614;C1?       &#61612;&#61613;&#61614;C2? &#61612;&#61613;&#61614;Cprop
    &#61464;            &#61464;      &#61464;
    }}
[/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

  • HShankoHShanko Posts: 402
    edited 2011-09-12 15:03
    @ anyone interested,

    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.
    640 x 480 - 33K
    640 x 480 - 26K
    640 x 480 - 28K
    640 x 480 - 25K
Sign In or Register to comment.