On Tue, Jan 3, 2017 at 3:47 PM, Jan <spljaa(a)gmail.com> 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(a)gmail.com> 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.