Re: Confused as to what is going on with libgpiod v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bart,

Thank you for responding.

> > Sorry, horribly newbie questions and if I should be asking it
> > somewhere else then please tell me.
>
> Hi Thomas! No, that's perfectly fine.

That's good because I've been watching the traffic and it mostly seems
to be reviews for code that is almost, but not quite, entirely unlike
what I'm interested in. I'm guessing I'm either not looking hard
enough or that it is for the kernel level implementations below the
libgpiod API? - note that I've never had to deal with kernel level
Linux development before, I'm an applications developer IRL.

> > 1. Have there been any releases of libgpiod v2 ? I can't see any tags
> > in the git repo later than v1.6.
>
> Nope, libgpiod v2 is under development and will probably still be so
> for a while.

OK.

Could you explain what gives with something like this then:
https://packages.debian.org/buster/libgpiod2 which advertises itself
as "libgpiod2", but on closer inspection says version 1.2-3, which I
assume is the corresponding version number here:
https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/

Are libgpiod2 and libgpiod v2 referring to different meanings of "2" ?

> > 4. Should I even be trying to use libgpiod v2 yet ?
>
> Probably not, unless you have a good reason to (writing bindings or
> whatever). It's not yet stable and is about to change again soon.

LOL.

Not sure what you mean by "bindings". A friend and I are porting
MMBasic, a *very* niche BASIC interpreter that is usually at home on
microcontrollers, to Linux. The language has an array of inbuilt
commands for controlling digital and analogue pins, SPI, I2C, etc. and
libgpiod seems like the natural match for implementing the former.

A previous (Raspberry Pi specific) attempt by another developer
floundered because (apocryphally) he was trying to treat the Pi as a
microcontroller and programming to too low a level (directly to the
Broadcom API) and finding that it was breaking on every O/S update. We
were hoping to avoid a repeat of this by relying on a higher level
API.

I imagine you are busy, but would you care to offer an opinion as to
whether we should persevere with API v2 (where my friend has had some
success) or roll-back to looking at v1.6.x, assuming that it even
provides everything we need ?

Best wishes,

Tom



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux