Jump to content

GPIO Troubles


paul alting

Recommended Posts

Hello all,

Firstly, a huge thank you to Igor and team for Armbian, I love it and appreciate you for the effort and time you have dedicated to this amazing project, thank you.

I have used Armbian on Cubieboard II for a number of years now, running my main server with QuadlogSCADA for my off-grid renewable system at my home.

 

Now, I have had an Olimex LIME-2 eMMC4GB board sitting idle for a while on the corner of my desk and over the past few weeks have been inspired to do some programming with it.

So, on this LIME2 board, I have the latest nightly builds, installed to eMMC, all working fine so far.

Then, I though to connect a standard 20x4 character LCD to this board using I2C, by setting in armbian-config the overlay for I2C1.

I wrote some C code to output data to this display over I2C at address 0x3f and, again, all works wonderfully well, great.

 

Next, I thought, as part of my development toward a larger project, I want to be able to work with discrete GPIO pins, and this is where I have hit a solid rock wall.

I have read all the documentation, over and over many times.

I have looked at much to do with Armbian on Github in relation to using GPIO for A20 devices, both with legacy kernel and mainline.

I have read so much, but have not found the answer that enables me to progress, so, I write this post.

 

Again, I use an Olimex LIME-2 with 4GB of eMMC.

I have, in armbian-config, set it to use the nightly builds, as well as installed the kernel headers.

I have read this post: Armbain add overlay can not fine headers (solved)

I have read this post from March 2018 to do with GPIO problems by user 24Lines: A20-LIME2 can not use GPIO on PG port

From that post, if I try to test with PC23, by the following command to export:

echo 87 > /sys/class/gpio/export

I get the following (using sudo of course)

-bash: /sys/class/gpio/export: No such file or directory

Then, maybe I need to play around with overlays, so, I try.

I pick up a simple overlay from zandor-blood-stained github, the GPIO-button.dts file, from: gpio-button.dts

I thought, yes, I could use this as the overlay mentions GPIO by polling or by interrupt and it looks fairly simple in principle to use.

So, I copy this file across to my home location on the LIME board and then, following the documentation on compiling dts to dtc I give the command:

armbian-add-overlay gpio-button.dts

To which I get the following:

Error: dtc does not support compiling overlays

I check the version of dtc and it tells me it is DTC 1.4.2

 

So, my question is, do I specifically need to provide an overlay to use gpio as simple bit based I/O in Armbian ?

If yes, then where did I miss the correct instruction on how to do this ?

 

Also, I have looked at the C++ code for A20 GPIO which is based on gpio_lib at Olimex site: A20-GPIO

It throws an exception on the first Init() function, so, is this code applicable to mainline kernel and if so, how can it then be used ?

 

If not, then can I still use gpio_lib in some way, I guess after setting up in some way to use GPIO ?

 

Igor, I am really grateful for your time and have just watched your video at BalCCon2K17 conference presentation, very good :)

 

I have uploaded the board config as of right now, after all updates : armbianmonitor config

I hope you or Zandor or Thomas or others may be able to help me in getting GPIO working so I may use it in my C/C++ applications.

 

From the little island down under under - Paul Alting van Geusau (aka Von Baron)

Link to comment
Share on other sites

Hello Martinayotte,

Thank you for your response.

Yes, when I grep /boot/config-* for CONFIG_GPIO_SYSFS, it returns with Yes.

 

The other thing, I understand that using /sys/class/ will be or is deprecated and that using /dev/gpio* is the method to use.

I have /dev/gpiochip0 and /dev/gpiochip1 listed.

 

I was just reading through Larry's thread on Armbian IO Proposal, and noticed you had some posts there as well.

But, there is no pin definition for any Olimex boards and wonder why not ?

Would it be possible to include the pin mappings for other boards supported by Armbian such as those from Olimex ?

I intend to buy more Olimex boards as from the Armbian list of supported boards, I think Olimex suits my needs quite well.

I am looking to use these in industrial sites for low level automation.

Also for renewable energy systems as a central control system.

 

Santé

Paul :)

Link to comment
Share on other sites

19 minutes ago, paul alting said:

Yes, when I grep /boot/config-* for CONFIG_GPIO_SYSFS, it returns with Yes.

In this case, I don't understand why you've got "file not found" ...

20 minutes ago, paul alting said:

But, there is no pin definition for any Olimex boards and wonder why not ?

Header pins mapping is a tedious job since there are so many boards around with different pinouts.

Personnally, I never use that, I'm always use the SoC pinout directly since they are common with all board using the same SoC and even near parents, like PD14 is always pin 110 on every Allwinner SoC.

I've some Olimex too, and I'm using this python library https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/Python/pyA20 , it can also be used directly in C/C++ by linking their gpio*.c files.

 

Link to comment
Share on other sites

Yes, I am at a loss also.

 

I have looked at pyA20 and wasn't sure how well it would link to what I wish to do in C/C++, and having a preference to doing it all with standard C/C++ code and libraries.

I have just installed to the LIME 2 board the libgpiod library as it appears from my reading to support the new character based devices for gpio.

From: Libgpiod

For further ideas I also looked over: https://github.com/sgjava/userspaceio

Again, many thanks for your assistance.

Link to comment
Share on other sites

50 minutes ago, paul alting said:

I was just reading through Larry's thread on Armbian IO Proposal, and noticed you had some posts there as well.

But, there is no pin definition for any Olimex boards and wonder why not ?

The pin mappings in my ArmbianIO project exist because I own those boards. I just don't happen to own any Olimex boards. You're welcome to make a pin mapping table for your board(s) and do a pull request on Github. I'm happy to add contributions to the project. As Martin says, the AllWinner GPIO pins are numbered in a fixed pattern, so it's easy to create a pin mapping table from the schematic for your board.

Link to comment
Share on other sites

Okay, I could try using gpio_lib from pyA20, but is that based on the old method and not the newer method to access GPIO ?

I could also look at how to make up a pin mapping for ArmbianIO.

I use Eclipse on Debian 'testing' on Intel and cross compile for ARM using Linaro 7.3.1 toolchain.

 

Getting the I2C working was a bit of work, but not as much as for simple I/O.

I wonder how I will go with SPI or CAN later on :)

 

Many thanks and any other help is really appreciated.

 

Link to comment
Share on other sites

1 hour ago, paul alting said:

but is that based on the old method

Netiher old method or newer one, it is doing direct access to gpio registers using /dev/mem.

1 hour ago, paul alting said:

will go with SPI or CAN

Probably the same way about linking spi_lib.c from pyA20, but I've never done this one ...

Link to comment
Share on other sites

Oh well, that sounds reasonable then, I will look more into using this and see how it works with what I am trying to do.
One thing though, the Armbian documentation is quite well laid out and explained, though in this area of GPIO it does appear to lack the clarity I am seeking.

But that clarity is coming from your answers as I get to work this out.

 

I am looking forward to making good use of Armbian and to also provide some financial donation from any paid projects I have from it.

Also, I would like to present some of my developments, maybe as a 'how to' for others.

 

I will still like to find why I am not able to get the board to compile a dts using armbian-add-overlay ?

I will keep the thread updated as I proceed.

 

Link to comment
Share on other sites

Coming back to post my findings and to seek some further advice.

 

Martin, I took a look at pyA20 and was able to compile just the appropriate sections to include into my C application.

Looking at the code for pyA20, it accesses the GPIO via /dev/mem, going directly to the registers, which is sort of nice for speed I guess.

But the problem is that it needs to be done as root, meaning that my application then needs to run as root, which I prefer not to do.

I was not able to chown /dev/mem to enable to run non-root.

Also, using this code from pyA20 may also be problematic for me in the longer term, if I wish to be able to use other boards other than A20.

 

So, then coming back to using a driver based approach, by using libgpiod as mentioned in my previous post.

Libgpiod allows GPIO access via /dev/gpiochipx and has bindings for C++ as well as Python, with the underlying library in C.

I was able to use this to read a GPIO pin, PC23 on my Olimex LIME 2 board fine.

Again, as root, but also after chown of /dev/gpiochip0 to group gpio and making me as user member of gpio group.

I guess I would also be able to make that persistent as a uDev rule as well.

 

I am having some difficulty in getting GPIO output to function with this library, and am not sure why yet, both using the C++ bindings and by direct C function call.

 

So, coming back to something in my initial post, about Device Tree, which I am struggling to understand completely the syntax of.

If I were to make a dts overlay for some GPIOs to describe their functionality, my questions are:

Will I then be able to access the GPIO function say for example as /dev/mygpio ?

If so, what advantage is there to having GPIO devices in the device tree ?

 

And still, I would like to resolve the dts compiler on my board as detailed in my first post will not run ?

 

Many questions I know, but I am sure there may be many others who have or will strike similar problems to me.

I appreciate any who may be able to help me proceed further with this.

Link to comment
Share on other sites

11 hours ago, paul alting said:

And still, I would like to resolve the dts compiler on my board as detailed in my first post will not run ?

You can also manually install dtc compiler using those sources : https://github.com/pantoniou/dtc.git

After doing git clone, you will need to switch the branch by issuing "git checkout dt-overlays5"

 

Link to comment
Share on other sites

I have the dtc installed as part of Armbian, as mentioned version:

Spoiler

dtc -v

Version: DTC 1.4.2

I am guessing armbian-add-overlay is a wrapper around dtc, yes ?

 

So, when I try a simple example, again the file I pointed to in my first post, from zandor-blood-stained, the little gpio-button.dts, I have the following results:

With armbian add overlay:

Spoiler

$ armbian-add-overlay gpio-button.dts

Error: dtc does not support compiling overlays

 

With dtc:

Spoiler

$ dtc gpio-button.dts

Error: gpio-button.dts:2.2-8 syntax error
FATAL ERROR: Unable to parse input tree

 

So, my thinking is, that if armbian-add-overlay is a wrapper around dtc, then it is not pulling back the error codes correctly.

Or, if armbian-add-overlay is in itself a device tree compiler, then it would seem to have a problem, as does the native dct.

 

Is there something incorrect with this file from Zandor, has something changed in the way the compiler parses the file that makes this file now out of date and unusable ?

I wonder if someone could try on their Armbian board with the latest mainline nightly could try this simple test for me ?

 

Like I mentioned, I do not really know much about the structure of the device tree, and in particular, with armbian and the use of the available I/O.

I guess I should have made separate posts, one for the dtc problems I am having and another for the GPIO problems.

Many thanks - Paul

Link to comment
Share on other sites

13 hours ago, paul alting said:

Error: dtc does not support compiling overlays

This is because the DTC compiler present in /usr/bin/dtc isn't the good one, it doesn't support symbols since there is no "-@" option.

Replace it with the one found in /usr/src/linux-headers-4.18.5-sunxi/scripts/dtc/ ...

Link to comment
Share on other sites

As mentioned, in armbian-config I set to nightly as well as installed kernel headers, but armbian-config does not confirm kernel headers were installed.

Looking /usr/src it is empty, so no dtc there.

Why is that ?

 

If the device tree compiler was not so good, and the Armbian documentation details how to do dtc overlays, then I would have thought there would be many more people having difficulty with compiling and seeking solutions here on the forum.

Also, why has not the device tree compiler then not updated to one that does work ?

Link to comment
Share on other sites

7 hours ago, paul alting said:

Looking /usr/src it is empty, so no dtc there.

@Igor, since I'm not familiar with armbian-config, do you know why /usr/src is still empy ?

Also, do you think we can add a post-install script in this package to copy /usr/src/linux-headers-4.18.5-sunxi/scripts/dtc/dtc into /usr/bin to have good version in the path ?

 

Link to comment
Share on other sites

1 hour ago, martinayotte said:

ince I'm not familiar with armbian-config, do you know why /usr/src is still empy ?

Also, do you think we can add a post-install script in this package to copy /usr/src/linux-headers-4.18.5-sunxi/scripts/dtc/dtc into /usr/bin to have good version in the path ?

 

Currently, headers install is broken in some stable builds. Packages are not there for a reason - I don't want to update stable repository after enough testings. Since testing reports show that most of the things work ... with one known exception which needs to be fixed (MiQi) ... I'll run the major update as soon as I am back in the office. ATM I have limited time to deal with possible/expected problems. 

Workaround to get headers is switching to the nightly build (preferable with armbian-config), which is mostly already at the "next stable" level. DEV kernels, which we are talking about here, are ofc yet another exception. They are still under development and nightly versions might be broken ... or not.

 

If you are already switched to the nightly and it is not possible to install headers, then this an unknown bug for me.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines