I have Jetson.GPIO version 0.1.3. trying code similar to button_interupt.py. input on pin 12 only. (no output led)
Main loop reads pin 12 every second and prints value. This works fine.
GPIO.add_event_detect(12, GPIO.RISING, callback=blink1, bouncetime=10)
only works one time, returning to main ok. Further button pushing does not cause interrupt.
Wiring of pin 27 is as suggested in
Any suggestions?
code and current results in GitHub - jhjames3/python_stuff: learning how to read GPIO pins in Nvidia nano. see button_interrupt.py and notes.txt
Interrupt worked only one time.
hello jjames3,
could you please check this via sysnode, is the GPIO state cannot change after 2nd trial.
also, could you please gather kernel message to check any suspicious failures.
thanks
Iām having the same issue on my Jetson Nano, using pin 21 (GPIO 17). I can read the GPIO state changing in a loop, but if I try to use the add_event_detect, it only activates the callback 1 or 2 times at the start and then does nothing. Really need this function to work so I can use my motor encoders for RPM feedback.
RPM feedback in Python using GPIO state change callbacks is unlikely to work well, because Python has a single global execution lock, is garbage collected using a high-latency connector, and has very high execution overhead compared to statically typechecked statically compiled languages without garbage collection.
Jerry Chang
( I have been traveling so sorry for the delay) I found a suspicious error in the system Log for about the time I ran the python code:
Jun 13 13:10:11 fuseki compiz[26322]: WARN 2019-06-13 13:10:11 unity.glib.dbus.proxy GLibDBusProxy.cpp:487 Calling method āEmitEventā on object path: ā/com/ubuntu/Upstartā fai
led: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.Unity.Test.Upstart was not provided by any .service files
Jun 13 13:10:11 fuseki systemd[25801]: Stopped target A target that, when running, represents the screen being locked.
Jun 13 13:10:11 fuseki systemd[25801]: Stopping Backing Service for the Unity Panel in Lockscreen modeā¦
Jun 13 13:10:12 fuseki systemd[25801]: Stopped Backing Service for the Unity Panel in Lockscreen mode.
Jun 13 13:11:16 fuseki NetworkManager[4011]: [1560445876.7115] connectivity: (l4tbr0) timed out
Jun 13 13:16:16 fuseki NetworkManager[4011]: [1560446176.7363] connectivity: (l4tbr0) timed out
Jun 13 13:17:01 fuseki CRON[27892]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
I do not know how to use suggested āsysnodeā to see if āthe GPIO state cannot change after 2nd trialā. Any pointers or suggestions would be appreciated.
thanks.
Snarky,
That may be true but the demo, with less, worked better than it does for me.
Do you have any suggestions of alternative libraries/language combinations. I did implement similar interface on RasberryPI in Golang. It functionally worked but did not respond consistently. The library did not have an interrupt feature (I think it was polling) and it did not have the debounce ignore times built in as this one does.
Any suggestions would be appreciated.
John
The log message listed in comment 6 arenāt related to the operation of Jetson.GPIO at all.
OK re comment #3: where do I " gather kernel messages to check any suspicious failures"
And again where do I read about āsysnodeā I have googled many sources and find no useful info.
Thanks
John
I doubt there will be any relevant kernel message. However, if there are any, then running ādmesgā will show you those messages.
I think the request to use sysnode was simply a request to read the GPIO input value to validate whether it is actually changing. If so, you can simply use Jetson.GPIOās input() function to validate that the input does read different values over time.
I looked at your sample code. It is both reading the pinās value directly using input(), and setting up a callback for the same pin using add_event_detect(). These two APIs cannot be mixed at the same time on the same pin (with the exception that you should be able to read the input value from within the callback); reading the pinās value using input() clears any event status and hence prevents the callback from triggering. I suspect if you remove the GPIO.input() call from your main loop, the event will fire as you expect.
StephenWarren #11 sounds very good, but it did not work. I started with the example code (button_interrupt.py),again from GitHub - NVIDIA/jetson-gpio: A Python library that enables the use of Jetson's GPIOs. Took out all GPIO.input() calls and just printed different things depending on the state.
Changed to a RISING interupt condition, as this is what my hardware setup did.
Again it worked one time. see code in or_button_interrupt.py in GitHub - jhjames3/python_stuff: learning how to read GPIO pins in Nvidia nano. output in āor_but_int_output.txtā
Note on the 2nd try, it starts with an error: āRuntimeWarning: This channel is already in use,ā¦ā Is this a hint?
I tried or_button_interrupt.py on my Nano and it worked (i.e. printed āBlinkā) 20 times.
What and how exactly are you connecting to pin 11? I have a simple jumper wire with 1 end permanently connected to pin 11, and Iām moving the other end between pin 1 (3.3V) and pin 39 (ground). Maybe the problem is with the external circuit thatās connected to Nanoās input pin?
Yes that worked here too. Thanks, but I do not know why my circuit does not work, When I used your wire method I had to touch wire to pin 11 to ground after a successful interrupt to get it to interrupt again. My circuit had a 1K resister from pin 11 to ground. I connected one side of a switch thru a 100 ohm resister to 3.3v. (this circuit was recommended in the article) It seems to me it would essentially ground pin when the switch was opened as required because the 1k should pull it down to 0v. Maybe there is current from the processor thru the 1k and the voltage on the pin is not low enough. I used the 100ohm as the pull down and It interuppted 2 times.
I will try 10ohm. only worked one time. then I connected pin 11 thru a 100 ohm to the pull down and one side of the switch. I worked only 2 times. What is the recommended circuit for the nano to connect to a pull up signal?
On the Jetson Nano, Pin 11 is wired to the UART. You should probably view this as SFIO, not GPIO. With that in mind, in the default device tree it is configured as a pull down with 100K internal resistor. See this note: [url]https://devtalk.nvidia.com/default/topic/1055269/jetson-nano/gpio-button-seems-to-latch-maybe-wrong-resistor-value-but-unsure-of-cause/post/5355757/#5355757[/url]
The 100 ohm resistor is usually for the case when a programmer (not one of us of course, one of those other, less gifted people) mistakenly configures the pin as output instead of input. That would lead the pin to be connected straight to ground, which would lead to bad things happening.
Kangalow that helped. I am now using pin 31 with only an external 10K pull down resistor. It now interrupts continuously as many times as I wish. I added timing code using the OS and get in the ball park to what my scope shows. My application needs two pins so I will try to find another pin that works. Thanks.
I made a mistake, I am using pin 31. (which is high 100K) and It only works with a 10 ohm resistor pulling down. it also works on pin 29 (also high 100K) 10K will not pull it back down.
I tried pin 33 (low 100K) that works with 10ohm but does not work with 10K or 1 K.
High is pull up, Low is pull down. Iām not sure what your expectations are without a schematic of your circuit of some sort. The wiring for PULLDOWN is different than PULLUP for a switch.
āHigh is pull up, Low is pull down.ā meaning the internal resistors are connected to high and low respectively? Is that correct?
My external pull down resistors are connected to the associated pin to ground. my switch always connects the pin to 3.3v. My python is always interrupting on both edges: eg.
GPIO.add_event_detect(self.pin_1, GPIO.BOTH, callback=self.blink1, bouncetime=10)
So if the internal is high, my pull down resistor pulls the pin low and when the switch pulls high I get an interrupt. Then the switch opens and my pull down brings the pin back down to zero and causeing another interrupt, if it can get the pin low enough (thus the 10ohms).
If the internal is low and I have a pull down, the switch again pulls the pin to high causing an interrupt and upon opening the external and internal pulls it down to cause another interrupt.
Is this logic correct? It does not seem I am wasting a lot of current, but is my logic correct? How should I wire it?
Pull up and Pull Down refer to pulling a signal up to a reference voltage, and pulling down refers to pulling a signal to ground. Each has different wiring because they are on opposite sides of the switch. Thatās why you have been asked for your schematic/wiring diagram.
On the Jetson Nano, like the Raspberry Pi, there are built in Pull up and Pull down resistors which internalize the actual resistor itself. On the Raspberry Pi, the direction (pull up, pull down) are programmable in user space, on the Jetson Nano they are setup in the device tree and not easily accessible at run time. Therefore you need to pick your method and wire the switch accordingly.
As we talked about before, wired and programmed properly you probably donāt need to add an external resistor on a properly selected pin. However, for people who might make a mistake and program the pin as output instead of input ( I believe most programmers have been guilty of this sometime in their career), or select the wrong pull up/pull down, an extra external resistor is added so it doesnāt short out the pin.
Hereās a good explanation of the pull up/pull down concept on the RPI:
From the video, the 10K Ī© R1 resistor is the one that we are talking about as the built-in 100K Ī© resistor of the Jetson. Itās built in to the board, you donāt need to add it externally. The R2 1K Ī© resistor is the protector resistor weāve been talking about. The value is probably a little high for the Jetson, you may have to lower it in application.