mestora70
Posts: 11
Joined: Wed Aug 15, 2012 10:46 pm

Wiring Pi in C performance question for Gordon (or anyone)

Fri Aug 17, 2012 5:25 am

I've seen a few sites discussion turn HIGH and LOW times for GPIO using Wiring Pi from C but I have not seen anything about the time it takes to switch between read and write or pull-up and pull-down. Do you know the performance?

Mike

User avatar
joan
Posts: 14849
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 8:08 am

The code has delays of circa 20 microseconds to let the hardware settle after mode changes. That suggests circa 50,000 transitions per second max.

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 12:15 pm

Batteries not included, Some assembly required.

User avatar
joan
Posts: 14849
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 1:00 pm

DexOS wrote:Have you not read this: http://www.raspberrypi.org/phpBB3/viewt ... 44&t=10170
Does it address the question? I thought the post you link was about high/low transistions on pins set to outputs.

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 3:37 pm

joan wrote:
DexOS wrote:Have you not read this: http://www.raspberrypi.org/phpBB3/viewt ... 44&t=10170
Does it address the question? I thought the post you link was about high/low transistions on pins set to outputs.
That's calling the kettle black, has there is no "mode changes" between read/write.
Batteries not included, Some assembly required.

sonite
Posts: 14
Joined: Fri Aug 17, 2012 3:31 pm

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 3:42 pm

Sorry for asking another question related to Wiring Pi here!

when I've started for example test1 by: sudo ./test1
The program continues even when I close the terminal.... how do I quit the program?

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 3:57 pm

joan wrote:The code has delays of circa 20 microseconds to let the hardware settle after mode changes. That suggests circa 50,000 transitions per second max.
Which code?

wiringPi certianly doesn't and tests I've performed indicate that it can do approx. 20million digitalWrites a second - marginally more if you run it in native GPIO mode (using wiringPiSetupGpio()) as there is one-less lookup to do to do the pin to hardware bit translations.


The big issue is that you really can't control jitter at those speeds and things that will get in your way is stuff like the GPU accessing the video memory, something doing the boring task of dram refresh and of-course Linux itself.

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 4:05 pm

[email protected] wrote:
joan wrote:The code has delays of circa 20 microseconds to let the hardware settle after mode changes. That suggests circa 50,000 transitions per second max.
Which code?

wiringPi certianly doesn't and tests I've performed indicate that it can do approx. 20million digitalWrites a second - marginally more if you run it in native GPIO mode (using wiringPiSetupGpio()) as there is one-less lookup to do to do the pin to hardware bit translations.


The big issue is that you really can't control jitter at those speeds and things that will get in your way is stuff like the GPU accessing the video memory, something doing the boring task of dram refresh and of-course Linux itself.

-Gordon
Realising I now may have answered the wrong question, I'll try again!

Switching a pin from input to output or vice versa is a read/modify/write operation, so at best it would go at half the rate we could change an output pin.

Switching the pull-up or pull-down's on or off takes longer - it takes 300 cycles - whatever they are, and that's where I've got 2 delays of 10uS in the code. I'm guessing there is some internal shift-register to clock the internal plumbing through to the pins and this takes a finite amount of time to action.

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
joan
Posts: 14849
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 4:15 pm

So what is your answer to the question posed by the topic starter?

I see we've cross posted. The 20 microsecond delay in PUD accounts for my answer of a maximum of 50K per sec. The pin mode change code (input/output/pwm) also calls the PUD 20 microsecond delay code.

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 4:41 pm

joan wrote:So what is your answer to the question posed by the topic starter?

I see we've cross posted. The 20 microsecond delay in PUD accounts for my answer of a maximum of 50K per sec. The pin mode change code (input/output/pwm) also calls the PUD 20 microsecond delay code.
You were right - I just answered the wrong thing - I skimmed the original post, read yours, got hold of the wrong end of teh stick which is why I posted the 2nd one...

So in summary - setting/resetting output bits - about 20million/sec. (write a reg)
Changing from in to out or vice versa - probably no faster than half that. (read a reg, clear/set bits, write it back again)
Changing from pull up to pull down or vice versa - much slower due to the delays required by the chip - you set a value in one register, wait 150 cycles, poke a bit in another register, wait another 150 cycles, then write zeros to both registers. I'm using 10uS to represent 150 cycles, but I really ought to find out what that is. In Dom/Gerts original code, it's simply a count to 100 (so don't optimise that code!)

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 9:19 pm

sonite wrote:Sorry for asking another question related to Wiring Pi here!

when I've started for example test1 by: sudo ./test1
The program continues even when I close the terminal.... how do I quit the program?
Type Control-C

Although I'm surprised it carries on after you close the terminal though!

-Gordon
--
Gordons projects: https://projects.drogon.net/

mestora70
Posts: 11
Joined: Wed Aug 15, 2012 10:46 pm

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 11:27 pm

Thanks Gordon and others.

DexOS, not only have I researched that thread, my question about read/write state switching was partially inspired by that (as was my decision to use only C for shift register bit banging). I then asked about pull up/down as well to be complete.

I'm looking into high speed shift register I/O applications. This site has a pin saving idea: http://robots.freehostia.com/Software/S ... ister.html The author is using just 2 pins to clock and read/write from/to both the input and output shift registers. The data GPIO pin goes to the input of the output shift registers and the output of the input shift registers. There is a 10k resistor in series with the later so that when the GPIO is an output (low impedance) it overwhelms the shift register output but can still read the shift register when it is an input (high impedance). The cycle goes set input, read bit 1 in, set output, write bit 1 out, shift, set input, read bit 2 in, set output, write bit 2 out, shift, etc. I am trying to get an idea of how fast this is (is it really worth sharing the pin)?

I don't want to get to far into hardware since it was a C performance question in the C forum--just explaining what I am looking for and why.

Mike

mestora70
Posts: 11
Joined: Wed Aug 15, 2012 10:46 pm

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 11:31 pm

joan wrote:The pin mode change code (input/output/pwm) also calls the PUD 20 microsecond delay code.
If this is true, than what I was thinking of doing (to save a pin) is not worth it.

Mike

sonite
Posts: 14
Joined: Fri Aug 17, 2012 3:31 pm

Re: Wiring Pi in C performance question for Gordon (or anyon

Fri Aug 17, 2012 11:56 pm

By just closing the xterminal the program continues.. I don't have the leds, I used an oscilloscope and looked at the pins (GPIO0 toggled between high and low).

User avatar
joan
Posts: 14849
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Wiring Pi in C performance question for Gordon (or anyon

Sat Aug 18, 2012 8:13 am

It is currently true that the pin mode change from input to output calls the PUD logic. The call may not be needed.

Some benchmarks.

Code: Select all

$ cat b1.c
#include <stdio.h>
#include <wiringPi.h>

#define TIMES 100000000
#define PIN 23
main()
{
   int c;

   if (wiringPiSetupGpio()) exit(1);

   printf("begin OUTPUT pin HIGH to LOW %d times\n", TIMES);

   pinMode(PIN, OUTPUT);
   for (c=0; c<TIMES; c++)
   {
      digitalWrite(PIN, HIGH);
      digitalWrite(PIN, LOW);
   }
}
$ cat b2.c
#include <stdio.h>
#include <wiringPi.h>

#define TIMES 50000
#define PIN 23
main()
{
   int c;

   if (wiringPiSetupGpio()) exit(1);

   printf("begin pin INPUT to OUTPUT %d times\n", TIMES);

   for (c=0; c<TIMES; c++)
   {
      pinMode(PIN, INPUT);
      pinMode(PIN, OUTPUT);
   }
}
$ cat b3.c
#include <stdio.h>
#include <wiringPi.h>

#define TIMES 50000
#define PIN 23
main()
{
   int c;

   if (wiringPiSetupGpio()) exit(1);

   printf("begin OUTPUT pin PUD OFF to PUD UP %d times\n", TIMES);

   pinMode(PIN, OUTPUT);
   for (c=0; c<TIMES; c++)
   {
      pullUpDnControl(PIN, PUD_OFF);
      pullUpDnControl(PIN, PUD_UP);
   }
}
$ time sudo ./b1
begin OUTPUT pin HIGH to LOW 100000000 times

real 0m15.495s
user 0m15.360s
sys 0m0.040s


$ time sudo ./b2
begin pin INPUT to OUTPUT 50000 times

real 0m18.682s
user 0m0.140s
sys 0m6.250s


$ time sudo ./b3
begin OUTPUT pin PUD OFF to PUD UP 50000 times

real 0m18.577s
user 0m0.090s
sys 0m6.200s

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Wiring Pi in C performance question for Gordon (or anyon

Sat Aug 18, 2012 8:20 am

joan wrote:It is currently true that the pin mode change from input to output calls the PUD logic. The call may not be needed.
Your right - it may not be needed and in-fact I've taken it out of the current version I'm working on too, however it's important to note that the pull up/down's are rememberd between power cycles, so I guess the time taken is actually clocking it into some non-volatile memory inside the chip... However I've no idea what the kernel initialisation code does with them at boot time...

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
joan
Posts: 14849
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Wiring Pi in C performance question for Gordon (or anyon

Sat Aug 18, 2012 8:45 am

[email protected] wrote:[... in-fact I've taken it out of the current version I'm working ...
Frankly when I saw the call I thought it was a sort of mental note to yourself to remember that pin mode changes removed the internal resistor pull ups/downs.

I've commented out the call and rerun the change pin from input to output mode benchmark with a different loop count.
time sudo ./b2
begin pin INPUT to OUTPUT 100000000 times

real 0m37.271s
user 0m36.990s
sys 0m0.070s

User avatar
jojopi
Posts: 3194
Joined: Tue Oct 11, 2011 8:38 pm

Re: Wiring Pi in C performance question for Gordon (or anyon

Sat Aug 18, 2012 10:46 am

[email protected] wrote:Type Control-C
Although I'm surprised it carries on after you close the terminal though!
Because the sudo job is running as a different user, the shell is not permitted to signal it when the terminal closes. (If any sudo jobs are suspended, however, bash will continue them!) The user checks are not performed for keyboard signals such as ^C, because these are sent by the kernel.

Return to “C/C++”