steveryan
Help opening/closing GPIO pin after nerves crashes
Hello,
I’m getting started developing with Nerves and Circuits.GPIO.
When my program starts I’m calling a function like below, to open GPIO pin 26 for output:
@output_pin Application.compile_env(:Program, :output_pin, 26)
def setup_gpio() do
{:ok, output_pin} = GPIO.open(@output_pin, :output)
end
This has so far worked fine, but when testing something, I crashed the program, and now when I go to re-run it I get the following error:
(MatchError) no match of right hand side value: {:error, :already_open}
Which I take to mean, since the program crashed, it didn’t clean up GPIO pin connection, so it’s still left open. My question is, how do I now do anything with that pin. I have tried closing it, but since I do not have access to the handle I can’t get it to close. (e.g. GPIO.close("GPIO26") gives me an error.
Is there any way, short of unplugging the raspberry pi and plugging it back in that I can either get the handle of this GPIO connection so I can write to it, OR close the connection, so that I can reopen it and capture the handle?
Most Liked
fhunleth
@jjcarstens A few people have had similar problems when Circuits.GPIO started requiring that there only be one reference per GPIO at a time. I think that Circuits.GPIO will need to be more helpful since it is turning out to affect more people than expected.
In case it’s helps, the happy path for using Circuits.GPIO is to wrap a GPIO or set of GPIOs in a GenServer. The GPIO reference returned by Circuits.GPIO.open/3 should only exist in that GenServer’s state. I.e., don’t return it. (This is what @jjcarstens and @lawik said, but it seemed good to repeat.) When the GenServer crashes, Erlang’s garbage collector will clean up the GPIO reference and that will free up the GPIO to be used when the Supervisor starts it up again. Adding a call to Circuits.GPIO.close/1 in the terminate callback like @lawik says seems nice. Erlang’s garbage collector is normally amazingly quick at cleaning dead processes up should terminate not get called.
The current unhappy path for working with GPIOs is to create an API that returns raw references. This seems like a completely reasonable thing to do, but once the GPIO references get stored in a couple processes, Erlang’s GC will probably think the GPIO is alive when it’s really not.
If the code isn’t performance critical, try using Circuits.GPIO.write_one/3 and Circuits.GPIO.read_one/2 to avoid processes owning references completely. This might be a quick fix.
I filed an issue on Circuits.GPIO since it should be possible to do something without rebooting.
lawik
I have dealt with this at times by implementing the terminate callback (a GenServer owned the reference) and making sure it tidies up before it dies.
I would assume restarting the BEAM would help..
jjcarstens
Do you have reproducible code? Typically closed process reference is cleaned up by Circuits. The fact you’re getting that error tells me you may not be opening the GPIO from the same process(es) that crashes, you may be inadvertently trying to open it multiple times on process boot, or a potential bug in Circuits. But I’ll need a little bit more code example to be helpful in figuring that out 
Popular in Questions
Other popular topics
Latest Nerves Threads
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"