Raspberry Pi PicoのPIOやDMAは1クロックごとに処理が可能ですが（125MHzなら秒間1億2500万回）、データをDMAでPIOに送り続ける場合にautopull・PIOからDMAへのDREQ（データリクエスト）・DMAチャンネル間のchain trigger等の使用時でも待ち時間なしにデータ転送され続けるのだろうか、という疑問が湧いたので確認してみました。
環境はWindows 11とVS Code、PlatformIOでearlephilhower版Arduinoコア（Raspberry Pi Pico/RP2040）を使用してます。Raspberry Pi Pico C/C++ SDKでもだいたい同じだと思います、earlephilhower版がC/C++ SDKをベースに作られているので。
- PIOのpullをautopullに任せた場合「TX FIFO→autopullでosrへ→osrからout」で転送待ちは発生するのか
- DMAチャンネル間のchain trigger使用時はそれぞれのDMA転送が切れ目なく続くのか
- その他の転送開始方法も試してみる
- ソースコード
PIOのpullをautopullに任せた場合「TX FIFO→autopullでosrへ→osrからout」で転送待ちは発生するのか
DMAでTX FIFOに毎クロックデータを入れつつ、PIOのステートマシンではpullはautopullに任せて毎クロックoutする、とした場合、autopull待ちが1クロック発生したりするのだろうか、という疑問。
DMAで「0,1,2,3,0･･･」と0から3でループする32bitデータを毎クロックTX FIFOに送り続け、autopullからout pins, 32して毎クロック32bitをGPIOへ出力して結果を確認してみます。
出力結果はこう（タイミング図で表記してます、右方向が時間経過、1マスが1クロック）。
1クロックに1つずつデータが出力されています、autopull待ちなども発生していないようです。
では、DMA転送にchannel_config_set_dreqでDREQ_PIOn_TXnを設定して、TX FIFOが空になった時にPIOからDREQが来てDMA転送するようにした場合に「TX FIFOの空き確認→DREQ→DMA転送」でどこかで待ち時間は発生しないだろうか。
先程のテストにchannel_config_set_dreqを追加して検証。
こちらも待ち時間は発生していないようです。これならPIOのpullするペースが可変でもDMAに転送を任せられそうですね。待ち時間が発生してデータ転送ペースが落ちるという事態にならない。
以上は「32bit outしたらautopull」「毎クロック32bitをout pins」＝「毎クロックautopull」した結果ですが、これを「8bit outしたらautopull」「毎クロック8bitをout pins」＝「毎クロックautopull」という設定に変更して試してみます（最後に載せているソースが当初こっちの設定になっていたため今は32bitに修正してあります）。
DREQ待ち無しの場合は全部1クロックで待ちは発生しませんでしたが、DREQを使った場合はこう。
3の時だけ3クロックになってます、ループする時に遅れるということですかね？ということで0～3のループではなく0～16のループにして確認。
ループ箇所関係なく4回に1回3クロックに増えてました。4回に1回autopullではなく、毎クロックautopullしてるのにこの4回に1回ってなんでしょうね？しかも2クロック増えてる、1クロックではなく。
16bitにしたら32bitと同じ結果、2bitにしたら8bitと同じ結果になりました。32bitの1/4の8bitだから4回に1回というわけでもないらしい。
DMAチャンネル間のchain trigger使用時はそれぞれのDMA転送が切れ目なく続くのか
picoでは1つのDMAチャンネルの転送終了時に別のDMAチャンネルの転送を開始させるという、DMAチャンネルの連鎖(chain trigger)設定が可能です(channel_config_set_chain_to関数)。
この時に転送終了と転送開始の間に転送してない時間が発生してないか、を確認してみます。
2つのDMAチャンネルに「0,1,2,3」の4つのデータを転送するという設定をして（最初のテストと同じく毎クロック32bit autopullする設定）、転送終了時にもう一方のチャンネルの転送を開始する設定をしておきます、ここから片方のDMAチャンネルを転送開始することでDMA転送が終わらず続くようになります。
これで切れ目なく転送できてるかどうか。
あれ、「3」が1クロックで終わらず4クロック続いてますね。PIOが「3」をout pinsした後データが来ないので待機してる時間が3クロックある？
転送しっぱなしではなくDMAがPIOからのDREQを受け付ける場合はどうでしょうか。channel_config_set_dreqでDREQ_PIOn_TXnを設定してみます。
更に「3」の時間が伸びました、6クロック続いています。
てっきり切れ目なく転送が続くのかと思ったんですがそうでもないっぽいです、ステートマシンから毎クロックpullする場合はこのことを考慮した方がいい場合があるかもしれません。
その他の転送開始方法も試してみる
転送終了時再び転送開始したい場合によくある方法として、転送終了時に割り込みが発生するようIRQを設定し割り込みで呼ばれた関数内で転送開始処理をする、というのがあります、そちらも試してみます。
転送するデータはこれまでと同じ設定で、転送終了時の割り込み関数内でDMAのINTSnレジスタ（割り込みステータスレジスタ）のビットをクリアし、dma_channel_transfer_from_buffer_now関数で読み込みアドレスと転送回数を設定して転送を開始する、という条件で試してみます。
すみませんこれ図にする方がむしろわからんっすね。
言葉で説明すると、「3」の状態が44～48クロック続きました。続く長さは固定ではなく変動しっぱなしです。これはデュアルコアの2コア目の場合の結果で、1コア目だと更にバラつきます。
dma_channel_transfer_from_buffer_nowは読み込みアドレスと転送回数をレジスタに代入する関数ですが、代入を転送回数だけにすると4クロック縮んで40～44クロックになりました。
他の手段と比べると40クロック以上ってのは長いですね…まぁCPUはいろいろ仕事がありますし、割り込み終了後の原状復帰のための準備しながら他の処理止めて割り込むので仕方ないのですが…。
RP2040 Datasheetの"2.5.6. Example Use Cases"内の"2.5.6.2. DMA Control Blocks"では、レジスタの更新にCPUを使わずDMAでレジスタ更新＆転送開始するという手法が紹介されています。当ブログのPicoによるNTSCのコンポジット映像信号モノクロ出力でも使用してて、そっちの記事で解説してます。
この方法についてもタイミングを確認してみます。
「3」の状態が8クロック続いています。chain triggerだけの時は4クロックでしたが、それにchannel trigger registerへの書き込み＆転送開始までの時間が加わり更に4クロック増えています。それでもCPUでやるよりは断然早いですね、繰り返しても8クロックからほとんど変化しませんし。
ソースコード
最後に今回のテストのソースコードを。test.pioはPIOASMでtest.pio.hを生成する必要があります。
Arduino開発環境向けに書いたソースでありpicoのC/C++ SDKでは動作確認していません、main.cppをC/C++ SDKで動かす場合は#include <arduino.h>とloop()関数の記述を消してvoid setup()をint main()にする必要があります。
ArduinoでのPIOASMの使用やC/C++ SDKとの違いはこちらのページを参考にしました。
main.cpp
test.pio
