On Tue, Jan 3, 2017 at 3:47 PM, Jan <spljaa@xxxxxxxxx> wrote: > Hi, > It was standard package that provides RPi.GPIO for python. > I think I checked versions both from dnf and pip. What was that package's name? I'm not sure off hand which packages are packaged in Fedora TBH (there's well over 18K source packages). > I do understand that to debug my configuration I would need to collect > more data. > > My question was more about current user's experiences. Does interaction > with GPIO is expected to work. > Which is needed step before jumping into problem solving. If GPIO is > not expected to work yet, then debugging case is pointless. I'm not aware of any reason it shouldn't. I don't have direct access to a working RPi ATM but the lsgpio tool (built in the 4.9 kernel-tools package) gave me a list of GPIOs the last time I tested it, I've not had time to dig deeper although it's on my todo list. > I wanted also to use some Adafruit libs latter for DHT22 sensor. > It failed to compile as its detection of device is based on > /proc/cpuinfo. Well that's just a terrible library by the sounds of it. > Right now I put back Raspbian, as GPIO part there just works. > > And I do not understand the device tree concept. It is not something I > have noticed before on desktop or server. That's why I might miss some > quite obvious step. Well on x86 it's not standard, on ARM, Power and other platforms it is. It's a means of defining the layout of hardware on some platforms that don't have an x86 style BIOS. > Regards > Jan > W dniu 03.01.2017, wto o godzinie 07∶11 +0000, użytkownik Peter > Robinson napisał: >> On Tue, Dec 6, 2016 at 8:08 AM, Jan <spljaa@xxxxxxxxx> wrote: >> > Hi, >> > I've problems with using GPIO from python. It just throws some >> > memory >> > error and dumps. I'm not familiar with C/dumps and so on, so I did >> > not >> > yet start to try to get details of it. >> > >> > One thing I noticed is different content of /proc/cpuinfo between >> > Raspbian and Fedora 25. >> > Thus my interpretation is that if Fedora reports a bit different >> > hardware then some calls to some methods might fail. >> > Am I missing some step that should be done after install? >> > >> > It could be some mutation of FAQ: about support for HATs. >> > But I would love clear statement, which would point that it just >> > does >> > not work out-of-the-box and there is/isn't way to manually fix it >> > for >> > someone who is not C/kernel developer. >> > As for me support for HATs and support to set GPIO pin 18 to HIGH >> > state >> > are slightly different things. But maybe they have same root cause. >> >> I've not had time to test GPIO, what python libraries are you using >> to >> access it? Basically some more details would be useful. _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
