Characterizing GPIO input pins - Raspberry Pi Forums

i realize may opening pandora box here, amount of users (not on forum) report "issues" , difficulties related gpio input pins, wanted start characterize them better.

although i've been avid user of pi number of years now, , have used gpio pins extensively in designs , tinkering, i'm still learning , discovering things didn't know.

based on 2 recent post users again reported problems using gpio input pins, decided spend more time characterizing them, , use information write detailed how-to. sounds overkill when you're using button input, have google bit, , you'll see there numerous issues people have can't arms around.

here 2 posts several of collectively worked on:
viewtopic.php?f=28&t=131440
viewtopic.php?f=32&t=133111

before diving intricacies , start offer solutions , workarounds, first need know , share more electrical specifications of input pins. unfortunately, there seems no electrical specifications broadcom, chip supplier, or foundation.

means we're largely on our own, , need figure out as can actual measurements , other empirical observations. need facts, not fiction or beliefs, nor opinions , hearsay. please!

pretty agreed upon inputs have pull_up/pull_down resistor somewhere around 50-70k. know input level should no higher 3.3volt (3v3). know, through measurements, there seems clamping diode input ground, limiting input voltage maximum of -0.3 -0.6v. there seems no clamping diode 3v3 supply, clamping input voltage maximum of on 5.6v, has been proven actual measurements. however, prudent limit input levels 3v3.

threshold levels? when 0 0 , 1 one? broadcom designers have followed jedec standard 3v3 devices (lvttl & lvcmos), recommends maximum , minimum levels. how designers implemented largely unknown , me.

jesd8c.01 jedec interface standard 3.3v devices states that:

inputs:
vih = 2.0v (everything >= logical "1")
vil = 0.8v (everything <= logical "0")
outputs:
voh = 2.4v (a "1" => )
vol = 0.4v (a "0" <= )

simple measurement, using pot-meter between 3v3 , ground, , wiper attached input pin, can determine when system switches 0 1, , back, , 1 0, , back.
measured rising voltage level change state @ 1.3v, , again @ 1.1v. hysteresis of 0.2v falling voltage level went 1 0 @ 1.1v , 1 @ 1.3v. values +/- 50mv due accuracy of simple (and not calibrated standard) measurement , tools, must pretty close.

logic level detection inputs
state changes & threshold levels
rising voltage level or edge:
- 0 1 : 1.3v
- 1 0 : 1.1v

falling voltage level or edge:
- 1 0 : 1.3v
- 0 1 : 1.1v

hysteresis : 200mv

here copy of code used, can check out yourself.

code: select all

#!/usr/bin/env python2.7  # topic: detecting input threshold levels # # file : input_test.py  import rpi.gpio gpio time import sleep  gpio.setmode(gpio.bcm)  potmeter = 23 # gpio-23, pin 16 gpio.setup(potmeter, gpio.in)   try:     print "starting"     while true:         print gpio.input(potmeter)  except keyboardinterrupt:     pass finally:     print "\nrelease our used channel(s)"     gpio.cleanup([potmeter])  def main():     pass  if __name__ == '__main__':     main()

why important? well, if want design method eliminate switch bounce, need know cut-off levels are.

there have been many reports difficulties gpio.add_event_detect , callback method. fair, there @ least 1 anomaly in gpio code falling edges, , miss-understood feature, of bouncetime. we'll not there yet, lets go basics again.

when use logical input read, chances never detect strange. when use interrupts edges, chances larger see unexpected events.

many users have reported "mis-firings" or multiple hits when used add_event_detection. topic of 2 posts above. we're getting little closer problems, lets first determine exact voltage levels when bcm2835 determines go 0 1 , 1 0.

measured myself, input threshold rising edge 1.3v. gert van loo in post on forum mentions bcm2835 changes state @ 1.3v, matches. however, when more detailed measurements on add_event_detection, there more it.

let's take step @ time learn more.
here little script used test latency time between button press , start of the, call interrupt service routine (isr), otherwise known "my_callback" routine.

code: select all

#!/usr/bin/env python2.7  # latency test gpio input & add_event_detect(ion)  import rpi.gpio gpio time import sleep  gpio.setmode(gpio.bcm)  trigger = 24 # used send timing reference signals scope gpio.setup(trigger, gpio.out) button = 23 gpio.setup(button, gpio.in, pull_up_down=gpio.pud_up) # input button  def my_callback(channel):     gpio.output(trigger, gpio.high) # signal we're entering     sleep(0.0001) # 100usec     gpio.output(trigger, gpio.low) # signal we're leaving     return  gpio.add_event_detect(button, gpio.rising, callback=my_callback) #gpio.add_event_detect(button, gpio.both, callback=my_callback, bouncetime=1) # bouncetime specified in milliseconds  print "raspberry pi model b rev.", gpio.rpi_info['p1_revision'] print "gpio version = ", gpio.version print "waiting button press"  try:     while true:         pass except keyboardinterrupt:     pass finally:     print "\nrelease used pin(s)"     gpio.cleanup([trigger, button])

code pretty straight forward. setup event detection, , within isr, set output high, have little delay, , set output low again. on digital scope, trigger on button press on 1 channel, , use other channel measure output activity of manipulated output pin.
here screenshot of seems normal , average situation:

isr latency.gif (11.59 kib) viewed 6483 times

vertical scale 500mv/div, , horizontal scale 100usec/div. red trace button, blue trace trigger activity. use no switch de-bounce capacitor.

evident here isr latency (the time event happening - rising edge of level button - until enter isr) around 340 usec in shot. isr duration 320 usec, of sleep takes 100 usec. linux being linux, can expect latency change based on other priority tasks. saw variation of between 300 usec more 10msec. can vary lot.

when hit button enough times , take measurement every time, can see variations above, , expecting. latency varied 300-400usec, occasional (1 out of 50 or so) longer one.

can expect see switch bounce:

switch bounce2.gif (11.63 kib) viewed 6483 times

should no surprise, hang on, happened our 320usec isr duration? went off screen. reason isr got interrupted next edge, , maybe several times. first pulse below threshold level of 1.3v, not have caused trigger, right? turns out bcm2835 can recognize edges in single nano sec range. simple scope cannot register that, pi can, aware.

surprised see :

switch bounce-4.gif (14.21 kib) viewed 6483 times

first isr happened around 480 nsec after rising edge button, no surprise, linux doing housekeeping. total surprise second isr. yes there glitch 300usec after rising edge, still above 1.3v threshold! "should" not have caused trigger, did.

simple scope cannot register whole spike, maybe yours can't either.
now, aware switch bounce glitches can in low nano second region , pi will register that.

more follow...

[edited correctness , more measurement precision]

if scope can't see whole spike why assume input hasn't dropped 0 volts?

raspberrypi