STM32 対 PSoC4 対 AVR – SPI 通信はどれが速い?

前回の記事で、STM32 は実は制御用途には向いていないのでは?という懸念を持ってしまいました。さらに、32 bit ARM コントローラは 8 bit コントローラと比べて制御に向いていますか?という懸念も持ってしまったので、STM32、PSoC4、AVR で同じテストをして応答時間を比べてみました。以下は結果です。

注意:このテストは僕が予定している用途に合わせた条件で行っているので一般的な結果とは違います。条件が変われば結果も変わります。用途が違うと数字が当てはまらなくなるから気を付けてね。

デバイスGPIO
(API)
GPIO
(自前)
SPI clockSPI
1 byte
(API)
SPI
1 byte
(自前)
SPI
18 bytes
(API)
SPI
18 bytes
(自前)
STM32C011F6P61.2 μS150 ns6 MHz23 μs7 μs95 μs52 μs
CY8C4245AX600 ns180 ns6 MHzn/a4.42 μsn/a27 μs
ATMega328n/a150 ns5 MHzn/a2.12 μsn/a52 μs

テストの詳細

デバイス

比較したのは、STM32、PSoC 4、AVR の三種類です。AVR は 8 ビット代表です。手持ちの部品でテストしましたが基本性能は近いところにあるのではないかと思います。PSoC4 は他と比べると良いチップですけれども「良さ」は速さよりも容量に行っているので比較の際に問題にはならない(多分)と考えました。クロック周波数は、32ビットの二種類は 48MHz、AVR は 20MHz です。

GPIO テスト

GPIO ピンの ON/OFF を繰り返す速さを測定しました。条件分岐やジャンプの実行時間が混入しないようにループを使わずベタでコードを書きました。STM32 と PSoC は GPIO 出力の API が用意されているのでそれを使って測定、さらに中身を見て最速と思われる実装でも測定しました。

結果は、PSoC がやや遅いものの自前実装ではどのコントローラも同じような実行速度でした。API は PSoC の方が明らかに速いです。全体的に STM32 の HAL ライブラリはノロノロという印象があります。

SPI への読み書きテスト – 1バイト

SPI に対して 1 バイトの読み書きにかかる時間を測定しました。同期実行で書き込み・読み出しが終わるまでブロックして待ちました。STM32 は HAL の API を使ったものと、HAL の低レベル部分だけ再利用して独自の実装を使ったものを測定しました。PSoC は API では CAN コントローラを制御するユースケースでは正常動作しないので低レベル API を使った自前実装のみ、AVR はそもそも API がないです。Arduino がそうといえばそうかな?でもまあベンダの API じゃないし除外。AVR では SPI クロックを CAN コントローラの限界の 10MHz まで上げることはできますが、システムクロックの 1/2 まで上がっているせいなのか何となく動作が不安定、半分の 5MHz で測定しました。

結果は、AVR が最も速く 2.2 μs、STM32 が最も遅く 7 μs でした。PSoC はちょうどその中間ぐらいです。STM32 の API 版は、AVR と比べると 10倍以上も時間がかかっており、比較の圏外にいる感じがします。

SPI への読み書きテスト – 18 バイト

今考えているコントローラの用途では、マルチバイトの SPI 送受信の速度が一番大事で、このテストが今回では最も重要です。マルチバイトの送受信の手順は以下のようにする必要があり、今回はこの手順にかかった時間を測定しています。

  • SPI CS を Enable にする
  • データを続けて 18 バイト書き読みする
  • SPI CS を Disable にする

結果は、PSoC が明らかに速いです。なぜこんなに違うのかというと、STM32 ではバイトの間に隙間ができてしまいますが、PSoC では連続して送れるため。それに STM32 ではペリフェラルへアクセスするたびに大きな遅延が生じます。

STM32 の通信パタン
PSoC の通信パタン

印象では、PSoC は DMA を使っているようにも感じます(ドキュメントを見ればきっと書いてありますね。まだ確認してません)。STM32 でも DMA はできるのですが、ペリフェラルとのやりとりがもたつくのかこれぐらいの語長ではかえって遅くなってしまいます。

わかったこと

  • この内容のテストでは、実行速度に「圧倒的な差」はなかったので別に好きなデバイスを使えば良いだけかもしれない。どれを選んでも致命的にはならないのではないかな。
  • ただ、STM32 の HAL は計算資源の無駄遣いと感じるほど遅いと思う。のでちょいちょい自分でコードを書かなくてはならず STM32 を制御用途で使い続けるのはけっこう大変かもしれない。
  • PSoC はバランスが良い。ハードウェア(ペリフェラル)との通信もそれなりに速いし API のオーバヘッドもあまり大きくない。苦手なワザがない印象
  • AVR はレジスタへたどり着くのがが楽なのかペリフェラルへのアクセスはめちゃくちゃ速いが、8 bit が災いしてなのかデータをまとめて送るのが苦手な印象。今回は測定していないが演算の時も同じく 8 ビットを超えると速度的に不利になると思う
  • STM32 は他のデバイスと比較するとペリフェラルへのアクセスが苦手な印象。何かと謎の待ちが発生する。

今のところ、Analog3 では PSoC を使うのが慣れているし無難そうと考えています。ただ、今少し高めのチップしか手元にしかないので、廉価版でも同じような性能を出せるのか確認したほうがよさそうです。機能とサイズを削りに削って一個買い 2 ドル前後ぐらいのもので行けそうかな?と思案中です。昔を考えるとこの値段でこの性能ってまじで夢みたいなんですけれどもね。

STM32 は安価でありプロセッサは速い(はず)ので、工夫して使い道を見つけたいです。信号処理的な用途向けかな?ただ HAL の印象は悪く、あまり使いたくはないです。しかしレジスタの設定など自分で組んだりしたらとんでもない手間でプロジェクトの方向性がくるってしまいます。やっぱり AI の力を借りことになるのかな?余談ですけれども今後「ソフトウェアライブラリ」というのは淘汰が始まるのかもなー、とかおぼろげに考えてます。「なんでもできる」でかいライブラリをメンテするより(これをやるのはめっちゃ大変な割に使う人みんな少しずつ不満になるはず) AI の信頼性を高めて用途に合わせたコードを都度書いてもらった方がよさそう、みたいな感じで

Comments

No comments yet. Why don’t you start the discussion?

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください