Why is the Tinker Board GPIO ports so slow?

[promate]

On the Tinker Board , I have tested a simple GPIO application using preinstalled wiringPi C library. I also ran the same application on Raspberry Pi using preinstalled wiringPi C library, but I noticed that the Tinkerboard GPIO speed is very slow. I wonder why this is the case. I would appreciate, if someone share opinion about it. I've added the C program and attached  oscilloscope screen-display for GPIO port speed for both Tinker Board and Raspberry Pi.

 I tested Tinker Board with  2018-02-22-tinker-board-linaro-stretch-alip-v2.0.5  image. GPIO speed is about 158 Khz
 I tested  Raspberry PI 3 Model B with  2018-03-13-raspbian-stretch image. GPIO speed is about 1.92 Mhz

#include <stdio.h>
#include <wiringPi.h>

#define LED     0

int main (void)
        {
        printf ("TB blink\n");

        wiringPiSetup ();
        pinMode (LED, OUTPUT);

        for (;
        {
                //printf ("led on\n");
                digitalWrite (LED, HIGH);
                //delay (500);
                //printf ("led off\n");
                digitalWrite (LED, LOW);
                //delay (500);
         }
        return 0;
}

/* #define LED 0 matches with ASUS_GPIO 164! 
 This can be checked with command 'sudo gpio readall'.

To compile the script run the command:
sudo gcc -o blink blink.c -lwiringPi

To run the newly compiled led run the command:
sudo ./blink
 
*/

                   

Edited April 22, 2018 by promate

[chwe]

Attachments are not visible... 

 

1 hour ago, promate said:

On the Tinker Board , I have tested a simple GPIO application using preinstalled wiringPi C library.

to my knowledge, we don't deliver wiringPi with armbian.. So, did you install it or do you use TinkerOS (whitch is no part of Armbian)?

 

From a quick google search, I might be wrong, but tinkers wiringPi has a 'fallback' to sysFS (/sys/class/gpio) and RPis wiringPi is based on gpiomem (writing direct to the SoCs registers). sysFS in known to be slower than gpiomem. 

 

in development branch we do provide a rootless gpiomem access, but at the moment you have to build those images on your own.

https://github.com/armbian/build/pull/907

 

You might build your own image and test wiringPi again and look if this speeds up the process. Just as a side-note, I've only tested if it works, I didn't do any performance tests, simply cause I don't have any oscilloscope to 'benchmark' the speed.  

 

How to build images:

https://docs.armbian.com/Developer-Guide_Build-Preparation/

How to switch to development branch:

Quote

Don't alter it manually and it should work.

1. Git clone as usually

2. I added LIB_TAG to default config

... and it worked for me.

LIB_TAG="development"

 

Edit:

and otherwise, you can test ArmbianIO from @Larry Bank which is also based on sysFS but might be a bit more 'lightweight'.. Not sure, cause I didn't do 'benchmarking' and I don't know if somebody ever tried to get at it's limit.. 

[Larry Bank]

25 minutes ago, chwe said:

 

and otherwise, you can test ArmbianIO from @Larry Bank which is also based on sysFS but might be a bit more 'lightweight'.. Not sure, cause I didn't do 'benchmarking' and I don't know if somebody ever tried to get at it's limit.. 

CHWE's comments look to be correct. If you need super fast toggling of GPIOs, then you need to memory map the I/O ports and write directly to them. My ArmbianIO library and others use the sysfs access which goes through the linux file system (much slower).

[promate]

7 hours ago, chwe said:

You might build your own image and test wiringPi again and look if this speeds up the process. Just as a side-note, I've only tested if it works, I didn't do any performance tests, simply cause I don't have any oscilloscope to 'benchmark' the speed.  

Thanks for your quick response.
I am not a linux user so I can not compile my own kernel. Is there a version of precompiled-kernel that you talked about and that I can download image file  directly?

 

7 hours ago, chwe said:

Attachments are not visible... 

the attached pictures are below.

Raspberry Pi.BMP

Tinker.BMP

[promate]

7 hours ago, Larry Bank said:

7 hours ago, chwe said:

 

and otherwise, you can test ArmbianIO from @Larry Bank which is also based on sysFS but might be a bit more 'lightweight'.. Not sure, cause I didn't do 'benchmarking' and I don't know if somebody ever tried to get at it's limit.. 

CHWE's comments look to be correct. If you need super fast toggling of GPIOs, then you need to memory map the I/O ports and write directly to them. My ArmbianIO library and others use the sysfs access which goes through the linux file system (much slower).

thank you very much for your valuable suggestions, 
Is there any C library (like as wiringPi)  that works as you mentioned?. I want to use it with  2018-02-22-tinker-board-linaro-stretch-alip-v2.0.5  Tinker Board image.

[chwe]

Just now, promate said:

I want to use it with  2018-02-22-tinker-board-linaro-stretch-alip-v2.0.5  Tinker Board image.

then you should look in one of the tinkerboard forums around the web.. This one is specific to Armbian not to some sorts of linaro.  

 

12 minutes ago, promate said:

I am not a linux user so I can not compile my own kernel.

Indeed you can... Virtualbox (on whatever OS you use) --> ubuntu  --> buildscript. We suggest to use a virualbox for the buildscript anyway (maybe performance will be a bit worse compared to a virtualbox on a linux machine). 

 

What might be interesting? Why do you need this speed? May PWM be a solution? 

[promate]

21 minutes ago, chwe said:

What might be interesting? Why do you need this speed? May PWM be a solution? 

I am using a GLCD (320x240 8bit data bus ) on my project with Tinker Board. So, GLCD is running very slowly.

[TonyMac32]

54 minutes ago, promate said:

GLCD (320x240 8bit data bus

What specific model?  It may be that we can include its driver in the Armbian kernel.  Then with an adjustment to the device tree you could use it directly as a system device instead of running a userspace driver (I assume that's how it's working now)

 

[chrisf]

3 hours ago, promate said:

I am using a GLCD (320x240 8bit data bus ) on my project with Tinker Board. So, GLCD is running very slowly.

Have a look and see if it's supported by fbtft

https://github.com/notro/fbtft/wiki/LCD-Modules

You might find the best performance option is a SPI interface, to take advantage of DMA transfers between the frame buffer and the LCD.

[promate]

21 hours ago, TonyMac32 said:

What specific model?  It may be that we can include its driver in the Armbian kernel.  Then with an adjustment to the device tree you could use it directly as a system device instead of running a userspace driver (I assume that's how it's working now)

 

Thank you for your interest and valuable support.
In my project I am using QT5, QtCreator4, GCC Compiler with WiringPI C library. Is it possible to use these tools in Armbian OS?

The GLCD is  WG320240C0-TMI-TZ # (RA8835 based) 

link : https://github.com/delsauce/Adafruit_GFX_RA8835

[chwe]

3 hours ago, promate said:

In my project I am using QT5, QtCreator4, GCC Compiler with WiringPI C library. Is it possible to use these tools in Armbian OS?

I don't see any reason why not.. for gpiomem you need to compile a kernel on your own, cause not implemented in master branch yet. For the rest, you might check what's there and what needs to be installed but both projects are based on stretch (you can also use jessie or ubuntu xenial when it comes to armbian) which should it make easy to use them.

 

You might need to look for a linux not arduino driver for your display or think about changing the display to a SPI based one when possible cause they might be a way easier to handle..