Research Providing MRAA as common GPIO Library as a Replacement for WiringPi

[p-i-u.de]

As WiringPi was never meant to support other boards nor does the author like to support other boards and it is officially depreciated now (http://wiringpi.com/wiringpi-deprecated/). 

I want to ask why not put some efforts into libmraa https://github.com/intel-iot-devkit/mraa and put it into the Armbian repository.

 

I have already a fork which fixes Rock Pi 4 on recent mainline 5.3 kernels with updated debian build scripts here: https://github.com/bootsy52/mraa, so debian packages could be simple built using dpgk-buildpackage.

 

Why I think it is a good idea to supply libmraa with the Armbian repository

 

1. Supporting multiple boards is a desired goal of the project
2. Supporting a board is really easy, for Rock Pi for example this is just the files src/arm/rockpi4.c include/arm/rockpi4.h and an entry in src/arm/arm.c, that's it
3. Instead of multiple forks of wiringPi and different sources of different versions (or even different gpio implementations) just have one common implementation for all boards
4. with wiringPi you need additional bridges if you want to code in other languages like Java or Python for example, with MRAA you have out of the box bindings for Python, Java, Javascript, C/C++ and NodeJS support

 

What do you think? @Igor

 

[Igor]

23 minutes ago, p-i-u.de said:

What do you think?

 

Idea is good, but if you expect that I / we will do anything about this, forget. We have zero budget for any R&D. It is already extremely difficult and expensive only to maintain the core, important things / basic support.

[p-i-u.de]

4 minutes ago, Igor said:

 

Idea is good, but if you expect that I / we will do anything about this, forget. We have zero budget for any R&D. It is already extremely difficult and expensive only to maintain the core, important things / basic support.

What do you mean by R&D? Resources and Development? Note: the Github Repo is mine, which means I have done the modifications. Only problem though I'm not a C Coder and could need some help by an experienced C developer here and there

[p-i-u.de]

I also plan to add Tinkerboard Support as I got this board, too. However I know what you mean by time constraints which is also a very limiting factor for me.

What would you think are the most important boards to add? OrangePi, Odroid?

[Tido]

1 hour ago, p-i-u.de said:

As WiringPi was never meant to support other boards

I don't know what tickles your interest, but is it worth to add a 4th or does it make sense to improve the ones already here ?

 

Within armbian you find following User-Supported options for GPIO and more:
ArmbianIO (sysFS) or
UserSpaceIO (libgpiod),
pyGPIO accesses 'pins' directly through /dev/mem

 ArmbianIO API
https://forum.armbian.com/topic/5655-armbianio-api-proposal/

 

 User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces
https://forum.armbian.com/topic/6523-user-space-io-is-python-3-and-java-8-bindings-for-user-space-gpio-spi-i2c-pwm-and-serial-interfaces/

 

 pyGPIO - A 'more general' python GPIO library based on pyA20
https://forum.armbian.com/topic/5662-pygpio-a-more-general-python-gpio-library/

 

[p-i-u.de]

2 hours ago, Tido said:

I don't know what tickles your interest, but is it worth to add a 4th or does it make sense to improve the ones already here ?

 

 

 

Mainly, because I wasn't aware of them plus second I also want to access the gpio without being root and I develop in Java so need some native JNI library. Leaving just User Space IO where I'll have a look at.

Actually the MRAA Library developed by Intel first exists since 2015 so it was there before the alternatives, the question should have been why did the others re-invent the wheel :-)

[sgjava]

https://github.com/sgjava/userspaceio already does this, but using the latest userspace libraries. I took a peek at mraa and the gpio source uses sysfs which is deprecated. See https://blog.adafruit.com/2018/11/26/sysfs-is-dead-long-live-libgpiod-libgpiod-for-linux-circuitpython/ No need to bake this into Armbian in my opinion. Also, I can install Userspace IO on other Linux distributions besides Armbian, so I'm not limited to a distribution.

 

This whole idea of mapping pins the same seems kind of silly to me since a lot of my SBCs have a variable number of GPIO pins, some have multiple I2C, some have multi purpose pins, etc. This is something that should be done a layer above the actual APIs and is trivial to implement (using a pin map or table).

 

There's no wheel reinvention going on here. I started Userspace IO over 2 years ago and it still remains the only true cross SBC API (there is no need to detect board type). Basically if your kernel is > 4.8 and supports devices mapped to userspace then it should work. mraa has limited ARM support (Pi is the only ARM SBC supported that I have out of 10 different SBCs).

 

As far as non-root access see https://github.com/sgjava/userspaceio#non-root-access

 

I'd love to just install Linux and have everything working, but that's not reality now. I'm not dissing mraa, but it's not something I'd use personally.

 

[atul]

On 11/27/2019 at 6:13 PM, Tido said:

I don't know what tickles your interest, but is it worth to add a 4th or does it make sense to improve the ones already here ?

 

Within armbian you find following User-Supported options for GPIO and more:
ArmbianIO (sysFS) or
UserSpaceIO (libgpiod),
pyGPIO accesses 'pins' directly through /dev/mem

 

 ArmbianIO API
https://forum.armbian.com/topic/5655-armbianio-api-proposal/

 

 User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces
https://forum.armbian.com/topic/6523-user-space-io-is-python-3-and-java-8-bindings-for-user-space-gpio-spi-i2c-pwm-and-serial-interfaces/

 

 pyGPIO - A 'more general' python GPIO library based on pyA20
https://forum.armbian.com/topic/5662-pygpio-a-more-general-python-gpio-library/

 

 

Thanks a lot for complete info on GPIO . Was searching for a cpl of days. :)

 

regards