Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

SPI struct implements both SpiBus and SpiDevice

オープン
  • 何か問題がありますか？
#99 コメント 1 件 リアクション 3 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
linux, rust
領域
embedded-iot, operating-systems

調査の方向性

現在の Spidev ラッパーと、SpiBus および SpiDevice に対する embedded-hal の実装を、issue #87 の議論と併せて確認することから始めます。チップセレクトとバス共有について提案されている動作を含め、ラッパーを SpidevBus と SpidevDevice に分割することを評価してください。API の分離とそのドキュメントが、意図されたカーネルおよびバスマルチプレクシングのセマンティクスに明確に一致すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Currently our Spidev wrapper struct implements both SpiBus and SpiDevice from embedded-hal. I think this is likely to lead to some confusion, especially since the SpiBus methods will still actually be using a shared SPI bus, toggling CS, and multiplexing with any other spidev devices on the same bus.

We discussed this a bit in #87 and while the main problem there is resolved by the new embedded-hal design, I think the split suggested is still worth considering. The proposal is to have two wrapper structs, SpidevBus and SpidevDevice perhaps, where:

  • SpidevBus implements just the SpiBus trait
    • we configure spidev to not drive the associated CS pin
    • we explain in the documentation that when this struct is used, it must be the only active spidev device on that bus
    • we encourage users to give it a CS pin that is not connected to anything, since whatever pin is assigned to it in the device tree can't be re-used as GPIO (and therefore can't be used as a CS)
    • this struct can then be used with any of the bus-multiplexing crates (like embedded-hal-bus) to generate lots of SpiDevice objects, using generic GPIO for CS control, or used when dedicated bus access is required (eg to generate smart LED waveforms)
    • we are basically lying to the kernel about it being a single device, because there's no way to request exclusive bus access with spidev
  • SpidevDevice implements just the SpiDevice trait
    • it's already a perfect fit for SpiDevice, the kernel handles sharing and CS for us, even with other programs
    • it will work just as users expect
    • but their device tree has to be set up to create the device and use the right CS

I'm happy to implement this as a PR if it sounds good to people, but it'd be great to get some feedback first or any suggestions on how it might be better done, especially if there's any clever spidev-related tricks that might be useful.

主要言語
Rust
スター
323
フォーク
60
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rust-embedded/linux-embedded-hal のほかの issue

rust-embedded/linux-embedded-hal の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。