実践記事

HOME
実践記事
Raspberry Pi
ラズペリーパイのGPIO応答速度を測定(Python & CUI イベントコールバック編)

2021年5月26日 / 最終更新日時 : 2024年4月24日 neocodemura Raspberry Pi

ラズペリーパイのGPIO応答速度を測定(Python & CUI イベントコールバック編)

前回のラズベリーパイのGPIO応答速度を測定(Python & GUI編)でGPIO応答速度を測定するとCUI & ポーリング式と比べると50倍くらい遅くなっていました。

遅くなる原因がGUIによるものなのかイベントコールバックによるものなのかを判別するためにCUI版のイベントコールバック式のコードで試してみました。

コードは以下のとおりです。

import RPi.GPIO as GPIO
import time

ledOut = 17
swIn = 18

def gpio_event_callback(swIn):
  if GPIO.input(swIn) == False:
    GPIO.output(ledOut, False)
  else:
    GPIO.output(ledOut, True)

GPIO.setmode(GPIO.BCM)
GPIO.setup(swIn, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(ledOut, GPIO.OUT)
GPIO.output(ledOut, False)

GPIO.add_event_detect(swIn, GPIO.BOTH)
GPIO.add_event_callback(swIn, gpio_event_callback)

try:
  while True:
    time.sleep(1e-3)

except KeyboardInterrupt:
  GPIO.cleanup()

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

import RPi.GPIO as GPIO

import time

ledOut = 17

swIn = 18

def gpio_event_callback(swIn):

if GPIO.input(swIn) == False:

GPIO.output(ledOut, False)

else:

GPIO.output(ledOut, True)

GPIO.setmode(GPIO.BCM)

GPIO.setup(swIn, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

GPIO.setup(ledOut, GPIO.OUT)

GPIO.output(ledOut, False)

GPIO.add_event_detect(swIn, GPIO.BOTH)

GPIO.add_event_callback(swIn, gpio_event_callback)

try:

while True:

time.sleep(1e-3)

except KeyboardInterrupt:

GPIO.cleanup()

配線はラズベリーパイのGPIO応答速度を測定(Python編)と同じでnucleoの青いプッシュボタンを押すとPC10(nucleo)→GPIO18(raspberry pi)→GPIO17(raspberry pi)と信号が伝搬していきます。

以前のラズベリーパイのGPIO応答速度を測定(Python編)ではポーリングでGPIO18(swIn)をモニターしてそれをそのままGPIO17(ledOut)に反映していましたが、swInを両エッジイベント(GPIO.BOTH)に登録してコールバック関数gpio_event_callbackでledOutに反映するようにしています。

またラズベリーパイのGPIO応答速度を測定(Python編)ではGPIO23にLowを入れると終了(とgpioクリア)していましたが、今度はCtrl+Cで終了するようにしています。

結果が以下のとおりです。

10回平均で約193usecです。GUI版の約半分くらいです。

GUI関連のイベント待ち処理が約219usec(=412usec – 193usec)くらい、GPIOイベント待ち関連が約185usec(=193usec – 7.6usec)くらいなのでしょうか。

イベント処理関連のオーバーヘッドが結構大きいのかも知れません。

ちなみにtime.sleep(1e-3)は1msec sleepの意味ですが、ここを1(=1sec)、1e-6(=1usec)にすると小さい値ほど小さくなる傾向はあるようですがさほど大差ありませんでした。

time.sleep	GPIO反応時間(10回平均)
1e-6	約160usec
1e-3	約193usec
1	約231usec

またちょっと本題から外れますがtime.sleepの実力はどの程度かを知るために実時間を計測するために以下のコードを書いて測定してみました。

import RPi.GPIO as GPIO
import time

ledOut = 17
swIn = 18

GPIO.setmode(GPIO.BCM)
GPIO.setup(swIn, GPIO.OUT)
GPIO.setup(ledOut, GPIO.OUT)
GPIO.output(swIn, False)
GPIO.output(ledOut, False)

a = input('ready?')
GPIO.output(swIn, True)
time.sleep(1e-3)
GPIO.output(ledOut, True)
a = input('finish?')
GPIO.cleanup()

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

import RPi.GPIO as GPIO

import time

ledOut = 17

swIn = 18

GPIO.setmode(GPIO.BCM)

GPIO.setup(swIn, GPIO.OUT)

GPIO.setup(ledOut, GPIO.OUT)

GPIO.output(swIn, False)

GPIO.output(ledOut, False)

a = input('ready?')

GPIO.output(swIn, True)

time.sleep(1e-3)

GPIO.output(ledOut, True)

a = input('finish?')

GPIO.cleanup()

ledOut、swInは名前をそのまま使っていますが、PC10(nucleo)からの接続は外して、swInからHighを出力してtime.sleep後にledOutにHighを出力してその時間差をnucleoで測定しています。

途中、input文で動作を止めているのは一気にこのコードを走らせるとGPIOが不定のときのnucleo測定ファームウェアがインプットキャプチャー割り込みを拾ってしまうので、これを防ぐためいったん’ready?’まで走らせてからnucleo測定ファームウェアを走らせて、’finish?’で結果を読み取るためです。

結果は以下のとおりです。