naito
2025年8月27日 18時38分
==========
製品型番：Armadillo-900
Debian/ABOSバージョン：ABOS 3.21.3-at.14
カーネルバージョン：5.10.238-at0
その他：ATDE9使用
==========
お世話になっております。
内藤です。
この度は、本来の範疇を超えたご質問を差し上げることとなり、誠に申し訳ございません。
大変恐縮ではございますが、以下の内容についてご教示いただけますと幸いです。
今回、Armadillo-900の開発セットでSPI通信の速度計測を行いました。
マスターのクロックを5MHzまたは10MHzに指定したとき、転送レートが1Mbps以上落ちる結果となりました。
クロックを1～4、8、12MHzに設定した際は、クロックが上がるにつれて転送レートが上がることを確認しております。
スレーブデバイスの性能によって、特定のクロックだけ遅くなる可能性はありますでしょうか？
また、上記の原因として考えられる事項などあれば、ご教授いただければ幸いです。
下記に計測時の環境を記載します。
マスターデバイス：Armadillo-900 開発セット
スレーブデバイス：Raspberry Pi Pico
マスターSPIの設定参考URL：https://armadillo.atmark-techno.com/howto/a900-spi-adc-mcp3204
デバイスツリーで設定した最大クロック数：30MHz
1回の通信データサイズ：256Byte
総通信データサイズ125KByte
また、1回の通信で476Byteより多くデータを送ろうとすると下記エラーが発生しました。
[ 3898.348092] spidev spi10.0: SPI transfer failed: -34 [ 3898.353231] spi_master spi10: failed to transfer one message from queue Error: Unable access to slave
こちらの原因についてもご教授お願い致します。
今回のご質問は特殊なケースに該当するため、明確なご回答が難しい場合があることも十分に理解しております。
そのような状況におきましても、何かご参考となる情報やアドバイスをいただければ幸いです。
以上、よろしくお願いいたします。
コメント
naito
お世話になっております。
内藤です。
丁寧な解説ありがとうございます。
クロックとプロセス間通信による制約があるとのこと、承知しました。
> 今回2つのご質問に対し、それぞれをSPI通信の制約という形で回答いたしましたが、この制約はnaito様のユースケースにとって致命的なものでしょうか?
期待していた通信速度は確認できていますので、致命的なものではございません。
ご回答しづらい質問になるかもしれませんが、Armadillo-900のコンセプト上、
SPIはあまり重要視されていないのか今後も手厚くサポートされるのかお聞きしたく存じます。
SPI自体が新しい通信方式ではないため、高速な通信を実現する場合は別の通信方法を推奨する方針でしょうか。
at_mizo
溝渕です。
ご回答ありがとうございます。
> ご回答しづらい質問になるかもしれませんが、Armadillo-900のコンセプト上、
> SPIはあまり重要視されていないのか今後も手厚くサポートされるのかお聞きしたく存じます。
手厚くサポートを継続していくつもりです。というのも、Armadilloは(ハードウェアやソフトウェアがカスタマイズされる事を前提とした)中間製品である為、製品に固有の制約は残したくないのです。
ただ、前述したプロセス間通信を利用した実装による弊害なのですが、SPIの機能変更を行う場合、以下の作業が必要となり、通常の(Linux device driverだけの修正)よりも時間がかかります。
- M33 firmwareの修正
- A35(Linux)device driver の修正
2つの問題(clockが正確でない/476Byte以上の通信ができない)がありますが、どちらが修正された方が嬉しいでしょうか?
# SPIは同期シリアルなので、clockが正確でなく通信できない事は恐らく無いと思います。そうなると後者でしょうかね?
現状、実現可否や今後の開発スケジュールを確認していない為、修正する(またはできる)事を確約する訳では無い点をご了承ください。
> SPI自体が新しい通信方式ではないため、高速な通信を実現する場合は別の通信方法を推奨する方針でしょうか。
いえ。SPI含めUARTやI2C等もそうですが、高速な通信を必要としない周辺機器も数多く存在するため、上記のような考えはありません。
at_mizo
2025年8月28日 10時30分
溝渕です。
> この度は、本来の範疇を超えたご質問を差し上げることとなり、誠に申し訳ございません。
いえ、Armadillo(正確にはi.MX8ULP)固有の内容です。細かに調査していただき有難うございます。
> マスターのクロックを5MHzまたは10MHzに指定したとき、転送レートが1Mbps以上落ちる結果となりました。
こちら、クロックの作り方による制限です。
まず、SPI clockを作る親clockは、96MHzです。これを2つのdividerを経由してSPI clockを作ります。
1つめのdivierが取る値は、
1, 2, 4, 8, 16, 32, 64, 128
で、
2つめのdiverは、
2,3,4,...
となります。
例えば、1MHzを作る場合は、1つめを"1"、2つめを"94"とする事で、
96MHz / 1 / (94+2) = 1MHz
となりますが、10MHzを作る場合は、
96MHz / 1 / (8+2) = 9.6MHz
と誤差が出てしまいます。これがSPI clockに誤差が出てしまう原因となります。
> また、1回の通信で476Byteより多くデータを送ろうとすると下記エラーが発生しました。
現状の実装では、1度に送受信できるデータの最大長は476Byteです。
これは、lpspiの仕様ではなく、ソフトウェアによる制限です。
Armadillo-900に搭載のSoC(i.MX8ULP)では、Cortex A35が属するドメインと、Cortex M33が属するドメインが存在し、それぞれが制御するcoreを占有します。今回の場合ですと、lpspi1は、M33に接続されています。
LinuxはA35で動作する為、lpspi1を直接制御する事ができません。この為、プロセス間通信を利用して、lpspi1を直接制御しているかのように見せています。
NXP BSPでのプロセス間通信の最大サイズは496Byteです。また、プロセス間通信を行うlpspiドライバが利用するヘッダサイズが20Byteである事から、SPIペイロードの最大サイズは476Byteとなります。
今回2つのご質問に対し、それぞれをSPI通信の制約という形で回答いたしましたが、この制約はnaito様のユースケースにとって致命的なものでしょうか?