Abnormal waveform of Raspberry Pi Linux GPIO driver

Recently, I tested the speed of Raspberry Pi Linux GPIO driver, and observed the square wave output on the oscilloscope. I found that the output waveform is very strange. It only outputs high level in a very short time, and compared with WiringPi ©, the speed is very very slow (although I know it will be slow, I didn’t expect the gap will be so big). I have two questions:

1. The existing Raspberry Pi driver should have some problems in speed, although it can be used normally. Can we further optimize and simplify the code to improve the running efficiency.
2. At the same time, it can be observed that the speed of LibGpiodDriver is not very fast. If there is no logic problem in C# code, can we further improve the execution efficiency of P/Invoke. Of course, I think it should be very difficult to solve this problem.

Test result

Drivers	Language	Library Version	Average Frequency
RaspberryPi3Driver	C#	System.Device.Gpio 1.3.0	363 KHz
SysFsDriver	C#	System.Device.Gpio 1.3.0	1.74 KHz
LibGpiodDriver	C#	System.Device.Gpio 1.3.0 libgpiod 1.2-3	198 KHz
WiringPi	C	e9821ab	17.8 MHz

Test program

C#

int pin = 6;
GpioController controller;

Console.WriteLine("Select GPIO driver: ");
Console.WriteLine("1. SysFsDriver; 2. LibGpiodDriver; 3. RaspberryPi3Driver ");

string key = Console.ReadLine();
switch (key)
{
    case "1":
        controller = new GpioController(PinNumberingScheme.Logical, new SysFsDriver());
        break;
    case "2":
        controller = new GpioController(PinNumberingScheme.Logical, new LibGpiodDriver());
        break;
    case "3":
        controller = new GpioController(PinNumberingScheme.Logical, new RaspberryPi3Driver ());
        break;
    default:
        Console.WriteLine("Exit");
        Environment.Exit(0);
        return;
}

using (controller)
{
    controller.OpenPin(pin, PinMode.Output);
    Console.WriteLine("Press any key to exit.");

    while (!Console.KeyAvailable)
    {
        controller.Write(pin, PinValue.High);
        controller.Write(pin, PinValue.Low);
    }
}

C

#include <wiringPi.h>

int main (void) {
  int pin = 2;
  
  wiringPiSetup();
  pinMode(pin, OUTPUT);

  while(1) {
    digitalWrite(pin, HIGH);
    digitalWrite(pin, LOW);
  }

  return 0;
}

[krwq]

@ZhangGaoxing can you try the same measurements but with while (!Console.KeyAvailable) replaced with while (true)?

wiringPi seems to be LGPL so we can’t look at the sources to see what they use - looking at the speed I’d assume some sort of direct memory access.

I think there are some optimizations we could potentially do in the RPI3Driver:

• https://github.com/dotnet/iot/blob/main/src/System.Device.Gpio/System/Device/Gpio/Drivers/RaspberryPi3LinuxDriver.cs#L498-L501 and similarly in Read
  • this could be special cased when number of pins is less than 32 - in that case there would be couple of divisions less
  • optionally have two protected versions of this method and call different one depending who overrides Write/Read
• if RaspberryPi3LinuxDriver was public and could be used directly (so all driver methods public) then it would be de-virtualized and therefore faster - that would help in optimized scenarios but would not help generic (board/OS independent) code
• https://github.com/dotnet/iot/blob/main/src/System.Device.Gpio/System/Device/Gpio/Drivers/RaspberryPi3LinuxDriver.cs#L57-L63 could be marked with aggressive in-lining - that would also remove a single operation

[raffaeler]

Probably not here, but I often use Benchmark.NET and you would be surprised to see how the optimizer can do a huge difference. I also see apparently small and insignificant changes making a huge difference in benchmarks.