RTThread IOコンポーネントGPIO

本文は主にGPIOの実現を理解する

drv_gpio.cファイルの大まかな分析

drv_gpio.cファイルの大まかな分析
menuconfigグラフィック構成では、components->Device Drivers->using generic GPIO device driversにオンが表示されます.このファイルは、一般的なGPIO構成にかかわらず、周辺機器の多重構成を含まない.まずpin[]の声明を見て、ここでIO口を抽象的に番号にします.私たちが使っているのはこの数字で、iicコンポーネントを使うと2つのピンの番号を入力する必要があります.この番号はこの数字を指して、GET_を使うことができます.PIN(H,10)はピン番号を素早く取得する.
マッピングテーブルを中断するのは何も言うことはありません.続けてみるとstm 32の一連が見つかりますpin_xxx関数これらのpin関数は

const static struct rt_pin_ops _stm32_pin_ops = 
{
	stm32_pin_mode,
	stm32_pin_write,
	stm32_pin_read,
	stm32_pin_attach_irq,
    stm32_pin_dettach_irq,
    stm32_pin_irq_enable,
}

個人的にはここを組み合わせてopsインタフェースを使います.裸機から来た私は以前void xxxxを書くと予想していました.band(device_t x, void (*punc)(…));このような形態では、この方法と比較して、チップを交換して直接対応する下地を変更すればよい.しかも全部constです.RAMを占有しない.この方法はRTThreadでよく見られる構造である.では、上が下で、下が抽象的なものであることを理解する必要があります.呼び出しを明らかにするにはopsを直接素早く調べ、注目に値しないものを省略することができます.
対応する自筆モジュールも抽象化できます.例えば私は足を1つ作って、関節を2つ持っています.各ジョイントにモーターとセンサーを1つずつつけます.では、足のモジュールを独立してコンパイルするには、関節のapiを抽象的に制御し、関節は足の抽象を完成しなければならないと同時に、モータとセンサのapiを抽象的に制御しなければならない.モーターはいろいろありますが、foc、ステッピングなど、センサーはもっとあります.これらの部分は同様にシャットダウンの抽象化を完了し,また対応する共通点を統合して抽象化を継続する.モータとセンサの下層が実際のモータとセンサに対応している場合は,RTThreadのこのような書き方を参考にして達成できる.
これで次々と分割されたが、それでも問題は多い.例えば、インタフェースがどのように設計されているか、最も簡単なインタフェースに基づいて設計されているのか、それとも全面的に設計されているのか.どのように戦略モデルを実現するか、結局モジュール化設計は戦略モデルを実現できないのがもったいない.例えば、ネットワークは有線ネットワークを使用することができ、wefiを使用することができる.特定のアプリケーション・レイヤは、新しいインスタンスを再作成するのではなく、スイッチング・プロトコル・スタックを実行するだけで目的を達成します.
ファイルrt_を見続けますdevice_pin_registerはopsを登録しました.そしてこの関数を見ると、多くのインタフェースが割り当てられたRT_NULL、ここでは直接インタフェースだと思って合理的に実現しなければならないが、今から見れば汎用化されず、使わないものは直接空にすることができる.例えばセンサの私たちはinitとreadインタフェースだけを設計することができます.これは迅速な開発に便利です.
あとは中関係のものです.各割り込みでrt_が呼び出されましたinterrupt_enterとrt_interrupt_leave.
今回はRTThreadのdrvを大まかに把握しましたgpioの作成方法といくつかの設計規則.次に、いくつかのファイルを分析して、頼りになるかどうかを見てみましょう.