How long is 'CGPIOPin::SetMode(..,)' supposed to take? #438

pottendo · 2024-03-02T16:21:34Z

pottendo
Mar 2, 2024

Hi,
in my application timing is critical. It uses all 4 cores of the used PIs (4 and 5) - but there's little dependencies between the functions on the different cores. I.e. the main code (below) is fairly independent from some web-server (on another core) and the UI (again on another core).

Consider the following code

	PIGPIO_CLOCK = 17,
	PIGPIO_DATA = 18,	

	static CGPIOPin IO_CLK;
	static CGPIOPin IO_DAT;
[...]
	IO_CLK.AssignPin(PIGPIO_CLOCK); IO_CLK.SetMode(GPIOModeInput, true);
	IO_DAT.AssignPin(PIGPIO_DATA); IO_DAT.SetMode(GPIOModeInput, true);
[...]
static unsigned ctb, cta;
[...]
		ctb = CTimer::GetClockTicks();
		if (DataSetToOut)
			IO_DAT.SetMode(GPIOModeOutput, true);
		else 
			IO_DAT.SetMode(GPIOModeInput, true);
		if (ClockSetToOut) 
			IO_CLK.SetMode(GPIOModeOutput, true);
		else 
			IO_CLK.SetMode(GPIOModeInput, true);
		{	
			unsigned delta;
			if ((delta = (CTimer::GetClockTicks() - ctb)) > 1)
				DEBUG_LOG("%s: delta = %d", __FUNCTION__, delta);
		}		
[...]

As you can see, the 2 GPIOPins, depending on some state variables (DataSetToOut and ClockSetToOut), are set either to Input- or Output-mode.

When I run this on a Pi4 (@1500Mhz) my app failed due to timings. So I put the measurement around and found that these two SetMode() calls take 2 microseconds.

When I run this on a Pi5 (@2400Mhz) this takes even 6 to 7 microseconds.

Is this reasonable? Is my measurement correct?

The alternative code works only on the Pi4:

		unsigned outputs = 0;
		if (DataSetToOut) outputs |= (1 << ((PIGPIO_DATA - 10) * 3));
		if (ClockSetToOut) outputs |= (1 << ((PIGPIO_CLOCK - 10) * 3));

                // myOutsGPFSEL1 hold the current I/O state and 
                // PI_OUTPUT_MASK_GPFSEL1 sets the exact 2 pins to 0 before the new state is logical or'ed: 
		unsigned nValue = (myOutsGPFSEL1 & PI_OUTPUT_MASK_GPFSEL1) | outputs;
		write32(ARM_GPIO_GPFSEL1, nValue);

With this code (on the Pi4) the time is <= 1 microsecond.
As this code won't work anymore on the Pi5 due to its changed IO HW, my application won't run on the Pi5.

I must be wrong somehow - I can't believe that the Pi5 is so much slower doing SetMode() on GPIOPins. And even 2 usecs for the Pi4 is unreasonable long...

any feedback is appreciated!

thanks, pottendo

Answered by pottendo

Mar 4, 2024

hi,

here's the update - with enhanced measurement accuracy

now I've enforced maximum freq (which I overlooked above; my app does it though)
interrupts are disabled (found how to do it for all archs)

Pi3:

logger: Circle 46 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 12.2.1
00:00:00.30 timer: SpeedFactor is 3.33
00:00:00.30 : timing of GPIOs on Raspberry Pi 3 Model B+
00:00:00.31 : maxed freq to 1300MHz
00:00:00.31 : Temp 36C (max=85C), dynamic adaption not possible, current freq = 1300MHz (max=1300MHz)
00:00:00.32 : loop 1 -------------------------------------------------
00:00:00.33 : LED on      ,	1000 loops:	018us,	0.017us avg.
00:00:0…

View full answer

pottendo · 2024-03-03T19:17:18Z

pottendo
Mar 3, 2024
Author

Hi,
for easier reproduction, find attached a minimal test-program. Just unpack in sample and it should compile & run as the other samples.
This doesn't use multi-core support, still the measured times are quite high. Too high for my application unfortunately.

logger: Circle 46 started on Raspberry Pi 5 4GB (AArch64)
logger: Revision code is c04170, compiler has been GCC 12.2.1
00:00:00.13 timer: SpeedFactor is 7.69
00:00:00.13 : timing of GPIOs on Raspberry Pi 5
00:00:00.13 : led on: 1usec
00:00:00.64 : led off: 0usec
00:00:01.14 : Setmode output: 8usec
00:00:01.14 : Write: 2usec
00:00:01.64 : Setmode input: 5usec
00:00:01.64 : Read: 1usec

It's also interesting to see that the two subsequent SetMode() calls are significant different in their execution time - as the Read/Write access is.
bye, pottendo
43-IO-Timing.zip

0 replies

rsta2 · 2024-03-04T10:52:43Z

rsta2
Mar 4, 2024
Maintainer

Please set the second parameter of SetMode() to true only in the first initialization and to false in the timed section. This should reduce the taken time. If the parameter is true this method sets the pull mode, which takes some time.

1 reply

pottendo Mar 4, 2024
Author

Hi,
Thanks for the feedback. Will try later today and follow up here.
The read / write access is probably not affected then, correct?
So related to the comparison Pi4 vs. Pi5, would you expect the lower performance of the Pi5 for those functions?
Just curious, for now...
Bye, pottendo

pottendo · 2024-03-04T15:53:40Z

pottendo
Mar 4, 2024
Author

Hi,
as promised here some measurements.

Here's the result for Pi5:

logger: Circle 46 started on Raspberry Pi 5 4GB (AArch64)
logger: Revision code is c04170, compiler has been GCC 12.2.1
00:00:00.13 timer: SpeedFactor is 7.69
00:00:00.13 : timing of GPIOs on Raspberry Pi 5
00:00:00.13 : led on: 1usec
00:00:00.64 : led off: 0usec
00:00:01.14 : Setmode output: 2usec
00:00:01.14 : Write: 2usec
00:00:01.64 : Setmode input: 2usec
00:00:01.64 : Read: 1usec
00:00:02.14 : led on: 0usec
00:00:02.64 : led off: 0usec
00:00:03.14 : Setmode output: 2usec
00:00:03.14 : Write: 2usec
00:00:03.64 : Setmode input: 2usec
00:00:03.64 : Read: 1usec
00:00:04.15 : led on: 0usec
00:00:04.65 : led off: 0usec
00:00:05.15 : Setmode output: 2usec
00:00:05.15 : Write: 3usec
00:00:05.65 : Setmode input: 2usec
00:00:05.65 : Read: 1usec
[...]

One can see that the SetMode is down to 2usecs.
Read and write are still unbalanced.

and here the very same test on a Pi4:

logger: Circle 46 started on Raspberry Pi 4 Model B 4GB (AArch64)
logger: Revision code is c03112, compiler has been GCC 12.2.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.66 : timing of GPIOs on Raspberry Pi 4 Model B
00:00:00.67 : led on: 0usec
00:00:01.17 : led off: 0usec
00:00:01.67 : Setmode output: 1usec
00:00:01.67 : Write: 0usec
00:00:02.17 : Setmode input: 1usec
00:00:02.17 : Read: 0usec
00:00:02.68 : led on: 0usec
00:00:03.18 : led off: 0usec
00:00:03.68 : Setmode output: 1usec
00:00:03.68 : Write: 0usec
00:00:04.18 : Setmode input: 1usec
00:00:04.18 : Read: 0usec
00:00:04.68 : led on: 0usec
00:00:05.18 : led off: 0usec
00:00:05.68 : Setmode output: 1usec
00:00:05.68 : Write: 0usec
00:00:06.18 : Setmode input: 1usec
00:00:06.18 : Read: 1usec
00:00:06.69 : led on: 0usec
00:00:07.19 : led off: 0usec
00:00:07.69 : Setmode output: 1usec
00:00:07.69 : Write: 1usec
00:00:08.19 : Setmode input: 1usec
00:00:08.19 : Read: 1usec

confirmed now that the Pi4 is faster in these operations.

and finally a Pi3 (32 bit) - a bit on steroids, config.txt:

arm_freq=1300
over_voltage=4
sdram_freq=500
sdram_over_voltage=1
force_turbo=1

even faster than the Pi4:

logger: Circle 46 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 12.2.1
00:00:00.30 timer: SpeedFactor is 3.33
00:00:00.30 : timing of GPIOs on Raspberry Pi 3 Model B+
00:00:00.31 : led on: 0usec
00:00:00.81 : led off: 0usec
00:00:01.31 : Setmode output: 0usec
00:00:01.32 : Write: 1usec
00:00:01.82 : Setmode input: 0usec
00:00:01.82 : Read: 0usec
00:00:02.32 : led on: 0usec
00:00:02.82 : led off: 0usec
00:00:03.32 : Setmode output: 0usec
00:00:03.33 : Write: 0usec
00:00:03.83 : Setmode input: 0usec
00:00:03.83 : Read: 1usec
00:00:04.33 : led on: 0usec
00:00:04.83 : led off: 0usec
00:00:05.33 : Setmode output: 0usec
00:00:05.34 : Write: 0usec
00:00:05.84 : Setmode input: 0usec
00:00:05.84 : Read: 0usec
00:00:06.34 : led on: 0usec
00:00:06.84 : led off: 0usec
00:00:07.34 : Setmode output: 0usec
00:00:07.35 : Write: 0usec
00:00:07.85 : Setmode input: 0usec
00:00:07.85 : Read: 0usec
00:00:08.35 : led on: 0usec
00:00:08.85 : led off: 0usec
00:00:09.35 : Setmode output: 0usec
00:00:09.36 : Write: 0usec
00:00:09.86 : Setmode input: 0usec
00:00:09.86 : Read: 0usec

for the sake of completeness, no real difference observed using 64bit on a Pi3, same config.txt:

logger: Circle 46 started on Raspberry Pi 3 Model B+ 1GB (AArch64)
logger: Revision code is a020d3, compiler has been GCC 12.2.1
00:00:00.30 timer: SpeedFactor is 3.33
00:00:00.30 : timing of GPIOs on Raspberry Pi 3 Model B+
00:00:00.31 : led on: 0usec
00:00:00.81 : led off: 0usec
00:00:01.31 : Setmode output: 0usec
00:00:01.32 : Write: 0usec
00:00:01.82 : Setmode input: 0usec
00:00:01.82 : Read: 0usec
00:00:02.32 : led on: 0usec
00:00:02.82 : led off: 0usec
00:00:03.32 : Setmode output: 0usec
00:00:03.33 : Write: 0usec
00:00:03.83 : Setmode input: 0usec
00:00:03.83 : Read: 0usec
00:00:04.33 : led on: 0usec
00:00:04.83 : led off: 0usec
00:00:05.33 : Setmode output: 0usec
00:00:05.34 : Write: 1usec
00:00:05.84 : Setmode input: 0usec
00:00:05.84 : Read: 1usec
00:00:06.34 : led on: 0usec
00:00:06.84 : led off: 0usec
00:00:07.34 : Setmode output: 0usec
00:00:07.35 : Write: 1usec
00:00:07.85 : Setmode input: 0usec
00:00:07.85 : Read: 1usec
00:00:08.35 : led on: 0usec
00:00:08.85 : led off: 0usec
00:00:09.35 : Setmode output: 0usec
00:00:09.36 : Write: 0usec
00:00:09.86 : Setmode input: 0usec

I'll not spend too much time to tweak my application - Pi5 is not the target platform for this anyway - however it's not intuitive for the average user, that GPIO performance on the newest model is significantly lower than on previous models. The target applications for Pi5s are not necessarily the embedded realtime apps - same for Pi4s - they get way to hot anyway! ;-)

Any comments are welcome - you may close this discussion as well.

bye, pottendo

5 replies

rsta2 Mar 4, 2024
Maintainer

Thanks for the results. I guess, the RPi 5 is really a bit slower here than the earlier models, because the GPIO pins are connected to the RP1 southbridge, which is connected via PCIe to the CPU. But I have to note, that the RP1 contains a PIO module, which can be programmed to do fast I/O. Unfortunately the necessary info, to use this, has not been published so far. I also cannot say, how difficult it will be to use this from bare-metal apps.

I want to add something. There is an uncertainty of 1µs in each measurement here, so 1µs can be near to 0. So for a more precise result it is better to run an operation many times in a loop and divide the measured time for all operations by the number of loop runs.

pottendo Mar 4, 2024
Author

...good point on the measurement - I'll extend the tests accordingly.
Though I do think that the performance is closer to 1 usec than lower as my app won't work (on Pi4); tried it already - not even the Pi3 using circle's GPIO... which seems weird; but let's see what the more accurate result will show.
bye, pottendo

rsta2 Mar 4, 2024
Maintainer

You should disable the IRQ, while the measurement is running. Otherwise the timer interrupt may disturb it.

pottendo Mar 4, 2024
Author

hi,

here's the update - with enhanced measurement accuracy

now I've enforced maximum freq (which I overlooked above; my app does it though)
interrupts are disabled (found how to do it for all archs)

Pi3:

logger: Circle 46 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 12.2.1
00:00:00.30 timer: SpeedFactor is 3.33
00:00:00.30 : timing of GPIOs on Raspberry Pi 3 Model B+
00:00:00.31 : maxed freq to 1300MHz
00:00:00.31 : Temp 36C (max=85C), dynamic adaption not possible, current freq = 1300MHz (max=1300MHz)
00:00:00.32 : loop 1 -------------------------------------------------
00:00:00.33 : LED on      ,	1000 loops:	018us,	0.017us avg.
00:00:00.35 : LED off     ,	1000 loops:	018us,	0.017us avg.
00:00:00.38 : SetMode(Out),	1000 loops:	160us,	0.159us avg.
00:00:00.40 : Write()     ,	1000 loops:	014us,	0.014us avg.
00:00:00.43 : SetMode(In) ,	1000 loops:	163us,	0.163us avg.
00:00:00.45 : Read()      ,	1000 loops:	067us,	0.067us avg.
00:00:00.47 : all fns     ,	1000 loops:	458us,	0.458us avg.

Pi4:

logger: Circle 46 started on Raspberry Pi 4 Model B 4GB (AArch64)
logger: Revision code is c03112, compiler has been GCC 12.2.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.66 : timing of GPIOs on Raspberry Pi 4 Model B
00:00:00.67 : maxed freq to 1500MHz
00:00:00.67 : Temp 37C (max=85C), dynamic adaption possible, current freq = 1500MHz (max=1500MHz)
00:00:00.68 : loop 1 -------------------------------------------------
00:00:00.69 : LED on      ,	1000 loops:	016us,	0.016us avg.
00:00:00.71 : LED off     ,	1000 loops:	016us,	0.016us avg.
00:00:00.73 : SetMode(Out),	1000 loops:	310us,	0.310us avg.
00:00:00.76 : Write()     ,	1000 loops:	015us,	0.014us avg.
00:00:00.78 : SetMode(In) ,	1000 loops:	310us,	0.310us avg.
00:00:00.80 : Read()      ,	1000 loops:	016us,	0.016us avg.
00:00:00.82 : all fns     ,	1000 loops:	704us,	0.703us avg.

Pi5:

logger: Circle 46 started on Raspberry Pi 5 4GB (AArch64)
logger: Revision code is c04170, compiler has been GCC 12.2.1
00:00:00.13 timer: SpeedFactor is 7.69
00:00:00.13 : timing of GPIOs on Raspberry Pi 5
00:00:00.14 : maxed freq to 2400MHz
00:00:00.14 : Temp 25C (max=85C), dynamic adaption possible, current freq = 2400MHz (max=2400MHz)
00:00:00.15 : loop 1 -------------------------------------------------
00:00:00.16 : LED on      ,	1000 loops:	1074us,	1.074us avg.
00:00:00.18 : LED off     ,	1000 loops:	1073us,	1.072us avg.
00:00:00.20 : SetMode(Out),	1000 loops:	1418us,	1.417us avg.
00:00:00.23 : Write()     ,	1000 loops:	1142us,	1.141us avg.
00:00:00.25 : SetMode(In) ,	1000 loops:	1419us,	1.419us avg.
00:00:00.28 : Read()      ,	1000 loops:	193us,	0.193us avg.
00:00:00.30 : all fns     ,	1000 loops:	7045us,	7.045us avg.

the Read() in the Pi5 case is a bit strange as way faster than the rest. Maybe there's some caching or compiler optimization cheating me?!

[1] PS: I disabled/enabled IRQs using DisableIRQs() and EnableIRQs()

Answer selected by rsta2

rsta2 Mar 5, 2024
Maintainer

Thanks. Doesn't look that bad on the RPi 3 and 4.

On the RPi 5 an additional register read is done for Write() and two reads and writes for SetMode(). But for an exact explanation of the times one would need to know the PCIe bus protocol, and how it is applied between the BCM2712 and the RP1.

I think the read time is OK. I did a test earlier, with which frequency one can read a GPIO pin from the RP1 and came to about 6 MHz.

pottendo · 2024-03-08T18:55:26Z

pottendo
Mar 8, 2024
Author

Hi,
here now some more tests added and comparison between Pi3, Pi4 and Pi5:

logger: Circle 46 started on Raspberry Pi 3 Model B+ 1GB
logger: Revision code is a020d3, compiler has been GCC 12.2.1
00:00:00.30 timer: SpeedFactor is 3.33
00:00:00.30 kernel: timing of GPIOs on Raspberry Pi 3 Model B+
00:00:00.31 kernel: maxed freq to 1300MHz
00:00:00.31 kernel: Temp 46C (max=85C), dynamic adaption not possible, current freq = 1300MHz (max=1300MHz)
00:00:00.32 kernel: loop 1 -------------------------------------------------
00:00:00.33 kernel: LED on      ,	1000 loops:	017us,	0.017us avg.
00:00:00.36 kernel: LED off     ,	1000 loops:	018us,	0.017us avg.
00:00:00.38 kernel: SetMode(Out),	1000 loops:	160us,	0.159us avg.
00:00:00.40 kernel: Write(H)    ,	1000 loops:	014us,	0.014us avg.
00:00:00.43 kernel: WriteAll(H) ,	1000 loops:	010us,	0.009us avg.
00:00:00.45 kernel: Write(L)    ,	1000 loops:	014us,	0.014us avg.
00:00:00.48 kernel: WriteAll(L) ,	1000 loops:	010us,	0.009us avg.
00:00:00.50 kernel: Invert()    ,	1000 loops:	015us,	0.014us avg.
00:00:00.53 kernel: SetMode(In) ,	1000 loops:	161us,	0.160us avg.
00:00:00.55 kernel: Read()      ,	1000 loops:	067us,	0.067us avg.
00:00:00.58 kernel: ReadAll()   ,	1000 loops:	057us,	0.057us avg.
00:00:00.60 kernel: SetModeAll(Out),	1000 loops:	223us,	0.223us avg.
00:00:00.63 kernel: SetModeAll(In),	1000 loops:	209us,	0.209us avg.
00:00:00.65 kernel: write ARM_GPIO_GPFSEL1 Out,	1000 loops:	007us,	0.007us avg.
00:00:00.68 kernel: write ARM_GPIO_GPFSEL1 In,	1000 loops:	007us,	0.007us avg.
00:00:00.70 kernel: read ARM_GPIO_GPLEV0,	1000 loops:	053us,	0.052us avg.
00:00:00.73 kernel: rv = 0xd006c1ff apirv = 0xd006c1ff

logger: Circle 46 started on Raspberry Pi 4 Model B 4GB (AArch64)
logger: Revision code is c03112, compiler has been GCC 12.2.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.66 kernel: timing of GPIOs on Raspberry Pi 4 Model B
00:00:00.67 kernel: maxed freq to 1500MHz
00:00:00.67 kernel: Temp 25C (max=85C), dynamic adaption possible, current freq = 1500MHz (max=1500MHz)
00:00:00.68 kernel: loop 1 -------------------------------------------------
00:00:00.69 kernel: LED on      ,	1000 loops:	018us,	0.017us avg.
00:00:00.71 kernel: LED off     ,	1000 loops:	018us,	0.017us avg.
00:00:00.74 kernel: SetMode(Out),	1000 loops:	310us,	0.310us avg.
00:00:00.76 kernel: Write(H)    ,	1000 loops:	015us,	0.014us avg.
00:00:00.78 kernel: WriteAll(H) ,	1000 loops:	005us,	0.004us avg.
00:00:00.81 kernel: Write(L)    ,	1000 loops:	015us,	0.014us avg.
00:00:00.83 kernel: WriteAll(L) ,	1000 loops:	005us,	0.004us avg.
00:00:00.85 kernel: Invert()    ,	1000 loops:	017us,	0.017us avg.
00:00:00.87 kernel: SetMode(In) ,	1000 loops:	310us,	0.310us avg.
00:00:00.90 kernel: Read()      ,	1000 loops:	016us,	0.016us avg.
00:00:00.92 kernel: ReadAll()   ,	1000 loops:	011us,	0.010us avg.
00:00:00.94 kernel: SetModeAll(Out),	1000 loops:	316us,	0.316us avg.
00:00:00.97 kernel: SetModeAll(In),	1000 loops:	316us,	0.316us avg.
00:00:00.99 kernel: write ARM_GPIO_GPFSEL1 Out,	1000 loops:	010us,	0.009us avg.
00:00:01.01 kernel: write ARM_GPIO_GPFSEL1 In,	1000 loops:	010us,	0.009us avg.
00:00:01.04 kernel: read ARM_GPIO_GPLEV0,	1000 loops:	011us,	0.010us avg.
00:00:01.06 kernel: rv = 0xd006c1ff apirv = 0xd006c1ff

logger: Circle 46 started on Raspberry Pi 5 4GB (AArch64)
logger: Revision code is c04170, compiler has been GCC 12.2.1
00:00:00.13 timer: SpeedFactor is 7.69
00:00:00.13 kernel: timing of GPIOs on Raspberry Pi 5
00:00:00.14 kernel: maxed freq to 2400MHz
00:00:00.14 kernel: Temp 23C (max=85C), dynamic adaption possible, current freq = 2400MHz (max=2400MHz)
00:00:00.15 kernel: loop 1 -------------------------------------------------
00:00:00.16 kernel: LED on      ,	1000 loops:	1074us,	1.074us avg.
00:00:00.19 kernel: LED off     ,	1000 loops:	1073us,	1.072us avg.
00:00:00.21 kernel: SetMode(Out),	1000 loops:	105us,	0.104us avg.
00:00:00.23 kernel: Write(H)    ,	1000 loops:	103us,	0.103us avg.
00:00:00.25 kernel: WriteAll(H) ,	1000 loops:	102us,	0.101us avg.
00:00:00.28 kernel: Write(L)    ,	1000 loops:	103us,	0.103us avg.
00:00:00.30 kernel: WriteAll(L) ,	1000 loops:	102us,	0.101us avg.
00:00:00.32 kernel: Invert()    ,	1000 loops:	103us,	0.103us avg.
00:00:00.35 kernel: SetMode(In) ,	1000 loops:	105us,	0.104us avg.
00:00:00.37 kernel: Read()      ,	1000 loops:	194us,	0.194us avg.
00:00:00.39 kernel: ReadAll()   ,	1000 loops:	152us,	0.151us avg.
00:00:00.42 kernel: SetModeAll(Out),	1000 loops:	125us,	0.125us avg.
00:00:00.44 kernel: SetModeAll(In),	1000 loops:	125us,	0.125us avg.

To notice: SetModeAll() is behaving well on the Pi5, whereas on the other Pis it's really poor in comparison to the other functions on the same machine. Your latest improvements are significant - now al GPIO funs are faster than Read()!

SetMode on Pi3/4 is very poor in comparison with the direct register access on these machines - maybe I'm doing things wrong here? The difference is huge.

The tests can be found on the develop branch.

bye, pottendo

5 replies

rsta2 Mar 8, 2024
Maintainer

Have a look at section 3.3.1. of this document for latency considerations.

I guess, some of these results would be different, when multiple reads and writes to different registers will be applied. In the end it counts, if it's quick enough to fulfill its purpose in an application.

pottendo Mar 8, 2024
Author

Thanks for the tips - the application I've played around with, is still not happy using the Circle calls vs. the direct write32 calls. Maybe the design could be changed; Hoewever, I think I won't spend too much effort there.
At least my observations already lead to significant improvements by your changes, so Circle again has improved - good work!
thx, pottendo

rsta2 Mar 8, 2024
Maintainer

I also used the direct register access for very time critical things (e.g. in sample/11-gpioclock). The class CGPIOPin has honestly never been designed for that purpose. But yes, especially for the RPi 5 it's quicker now, which is good. A good horse is jumping only as high, as it must. So thanks, because it's a problem, when there is nothing to jump over (i.e. a use case). ;)

pottendo Mar 10, 2024
Author

fyi,

I've used now used some of the new functions and can confirm that my app pottendo-Pi1541 is working on Pi4s. Neither on Pi3's nor on Pi5s the application is running stably as it still misses some cycles (usec granularity).
Pi3 works using the direct access to the registers.

Interesting is, that the observed behavior on the Pi5 is not matching my measurements above; see the code:

		unsigned ctb = Kernel.get_clock_ticks();
		u32 im = 0, om = 0;
		if (AtnaDataSetToOut || DataSetToOut)
			om |= (1 << PIGPIO_DATA);
		else
			im |= (1 << PIGPIO_DATA);
		if (ClockSetToOut)
			om |= (1 << PIGPIO_CLOCK);
		else
			im |= (1 << PIGPIO_CLOCK);
		CGPIOPin::SetModeAll(im, om);
		{	
			unsigned delta;
			if ((delta = (Kernel.get_clock_ticks() - ctb)) > 1)
				DEBUG_LOG("%s: delta = %d", __FUNCTION__, delta);
		}

this shows sometimes delta = 2 on a Pi5.
My measurement shows 0.125usec average for SetModeAll, so significantly far away from 2usecs, so it may be a measurement artifact here.
As this code is running as expected on the Pi4, I suspect that the sum of all (slower) I/O calls (there are some ReadAll()s elsewhere) make the difference for the Pi5.

happy hacking, pottendo

rsta2 Mar 10, 2024
Maintainer

Accessing the GPIO registers directly is absolutely OK for very time critical things. You could try this for the RPi 5 too, but the document, I referenced above, explains, why there are limits on the RPi 5 for GPIO access times.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

How long is 'CGPIOPin::SetMode(..,)' supposed to take? #438

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 4 comments 11 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

How long is 'CGPIOPin::SetMode(..,)' supposed to take? #438

pottendo Mar 2, 2024

Replies: 4 comments · 11 replies

pottendo Mar 3, 2024 Author

rsta2 Mar 4, 2024 Maintainer

pottendo Mar 4, 2024 Author

pottendo Mar 4, 2024 Author

rsta2 Mar 4, 2024 Maintainer

pottendo Mar 4, 2024 Author

rsta2 Mar 4, 2024 Maintainer

pottendo Mar 4, 2024 Author

rsta2 Mar 5, 2024 Maintainer

pottendo Mar 8, 2024 Author

rsta2 Mar 8, 2024 Maintainer

pottendo Mar 8, 2024 Author

rsta2 Mar 8, 2024 Maintainer

pottendo Mar 10, 2024 Author

rsta2 Mar 10, 2024 Maintainer

pottendo
Mar 2, 2024

Replies: 4 comments 11 replies

pottendo
Mar 3, 2024
Author

rsta2
Mar 4, 2024
Maintainer

pottendo Mar 4, 2024
Author

pottendo
Mar 4, 2024
Author

rsta2 Mar 4, 2024
Maintainer

pottendo Mar 4, 2024
Author

rsta2 Mar 4, 2024
Maintainer

pottendo Mar 4, 2024
Author

rsta2 Mar 5, 2024
Maintainer

pottendo
Mar 8, 2024
Author

rsta2 Mar 8, 2024
Maintainer

pottendo Mar 8, 2024
Author

rsta2 Mar 8, 2024
Maintainer

pottendo Mar 10, 2024
Author

rsta2 Mar 10, 2024
Maintainer