Recommended
More Related Content
What's hot
Similar to 20211002 stm32 cube halとtoppes
Similar to 20211002 stm32 cube halとtoppes (20)
Recently uploaded
Recently uploaded (9)
20211002 stm32 cube halとtoppes
- 3. 自己紹介 堀江誠一 2001,2~ TOPPERS/JSP for Blackfin https://ja.osdn.net/projects/toppersjsp4bf/ 2010~ TOPPERS/ASP for LPC https://ja.osdn.net/projects/toppersasp4lpc/ 2016~ Unzen Audio Framework https://os.mbed.com/users/shorie/notebook/unzen_audio_framework/ 2017~ Murasaki Class Library https://github.com/suikan4github/murasaki 2021~ Kaiten-Yaki Linux Full Disk Encryption Installer https://github.com/suikan4github/kaiten-yaki
- 5. TOPPERS/JSP for Blackfin 技術的興味から2001年頃よりTOPPERS/JSPのカーネルの研究を始め る 2004年にTOPPERS/JSP for Blackfinが実機で動き始める その後、Analog Devices 純正ツールからGCCに移植、Source Forgeに 公開
- 6. やりたかったこと もともとDSPの上でオーディオ処理をする際、割り込みハンドラの中 で信号処理をするのが嫌だった 「RTOSがあればもっと『きれい』に書けるのに」 RTOSの原理なら高校生のころから知っていた uITRONのオープン実装としてTOPPERSプロジェクトがあることを知る オーディオ信号処理 2002年：2191空挺団「MCMを使う」（割り込み駆動） http://bfin.sakura.ne.jp/oldsite/2191/program/mcm/mcm_01.shtml 2011年：まんがで読むTalkthrough https://www.pixiv.net/artworks/17722404
- 7. SDRをDSPで書けば面白そう もともとラジオ少年なんだし 書く以上はきれいに作りたい 綺麗じゃなくてもいいならSDRを作ったことはある 「オーディオ信号処理で学ぶDSP」 インターフェース誌2007年1月号より連載 https://www.cqpub.co.jp/interface/contents/2008/JA/200802.htm
- 8. TOPPERS/JSP for Blackfinの挫折 動作したはいいが、ペリフェラルの操作が面倒 ペリフェラルをClassに包んで遮蔽すればいいのでは？ RTOSを積んだのだからC++でさらに生産性をあげたい Classの中に同期や通信を遮蔽すれば、アプリケーション記述が楽になる ２つの障壁 CRTをTOPPERS/JSP用に書いたので、C++用に移行するときに躓いた JSPには動的リソース生成機能がないため、Classの中にセマフォの生成・削 除を遮蔽できなかった。 結局、あまり『きれい』な実装にならない その後フェードアウト
- 9. マイコンによる信号処理
- 10. マイコンの性能が上がってきたのでSDRをき れいに作ることができる気がしてきた マイコンによるSDR実装者は複数いた 2010年か11年のMTMで中本伸一氏がデモ 2015年のインターフェース誌に高橋知宏氏による特集 海外でも多くの実験が行われており、特別に珍しい技術ではなくなっ ている マイコンでも「きれい」に実装できる気がしてきた
- 11. TOPPERS/ASP for LPC (2010~) TOPPERS/ASPをNXPのLPCマイコンに 実装 CORTEX/M3,M4F ユニバーサル基板にLPC1788 ExperssoとCODECを積んで実験 TOPPERS/JSPとCodeRed IDEのマネー ジド・プロジェクトの食い合わせが悪 い CMSISはARMがいうほどよくなかった フェードアウト
- 12. 雲仙フレームワーク (2016~) mbedの手軽さが面白かったので、 オーディオ・フレームワークを実装 してみた 割り込みベース シンセサイザーを実装 macaroomがライブで使用した やはりアプリケーションはきれいに 書けない そもそもmbedがRTOSではないので
- 13. 紫ライブラリ(2017~)
- 14. 今度こそきれいに書きたい 当初「箸にも棒にもかからない」と思っていたSTM32 CubeHALが、ま あまあ使えそうに思えた。 CubeMXがミドルウェアまでコード生成してくれる FreeRTOS STM32独自のHAL これらの初期化コード この上に乗っかればうまくいくのでは
- 15. 紫の設計指針 アプリケーションが使用するすべ てのIO HAL関数をクラスでくるむ。 IO関数はすべて同期IO。 I2CやSPIのような複数のタスクが 呼びうる関数は、クラス内部で排 他処理する。 排他や同期に必要なセマフォはク ラス内部で生成・削除する。 ASSERT/SYSLOGの提供 STM32 MCU CubeHAL FREERTOS Murasaki Application
- 16. クラス化の恩恵 遮蔽 セマフォなどの資源の生成・削除・使用がすべて遮蔽される 特にセマフォの初期状態に気を使わなくてよい 入力補完機能の活用 関数のスコープが細かくなるので、IDEの入力補完を活用できる メソッド関数の引数を強く型付けすることで、入力補完を活用できる TDDが容易に I2CやSPIはすべて抽象的な型から派生している。したがって、同じ型から派 生するスタブ・クラスを容易に作ることが出来る。
- 17. 可能な限り広く対応する 信号処理だけでなく、ほかの用 途にも使いたい コンソールパネル処理など なるべく多くのSTM32に広く対応 することで柔軟性を維持する CORTEX-M0, M0+ CORTEX-M3, M4F CORTEX-M7
- 19. TOPPERS/ASPの良いところ APIの直交性(ITRON4) APIの仕様の厳密さ(ITRON4) パラメタ・バリデーションがしっかりしている Syslog完備 仕様も実装も考え抜かれている
- 20. 他のエコシステムとの不整合 マネージド・ビルドなシステムとのすり合わせが面倒 TOPPERSとして一つの世界を作っていて、手軽に組み込むことが出来なかっ た 利用者の教育は手厚かったが、実装者の教育が手薄だった。 そのため、他のエコシステムへの合わせこみの知見が蓄積されなかった印 象 Syslogが完備していた一方で、そのためにシリアルポート実装がカー ネル実装とべったりくっついていた CRTと割り込みハンドラを独自に作ることが前提になっていた。その ため、CPUメーカーのコードジェネレータと相性が悪い。
- 22. 一度動き出せば生産性は高い FREERTOSを使うとTOPPERS/ASPの良さが身に染みる 最初からSyslogがあるのでデバッグが容易 紫はSyslogの構築が終わるまでデバッグが大変だった コンテキスト識別APIがある FREERTOSにはなかった！（今はある模様） つまりFREERTOS内部ではコンテキストのバリデーションを行っていなかった 一方で、FREERTOSもタスク・コンテキストと非タスク・コンテキストでは使えるAPIに差が ある FREERTOSでは独自実装せざるを得なかった ISRがITRON独自なので、ISRから出るときに必ずタスク・スイッチが必要かど うかチェックしてくれる FREERTOSはISR出口で明示的に専用APIを呼ぶ必要がある
- 23. CubeHALに関する所感
- 24. CubeHALの良いところ STM32 HALの機能をかなりの割合でカバーしている おおむね統一された設計指針 シリーズ間(F09x, F4xx, F7xx, H7xx, G4xx,L07x,… )の互換性 ポーリング、割り込み、DMA転送によるIOがそろっている Assertionによるパラメータ検証
- 25. CubeHALの問題点 機能カバレージが不十分 UART RXのタイムアウトを扱う方法がない シリーズ間APIの不統一 GPIO割り込みコールバック名の相違 設計指針の甘さ シリーズごとにインクルードファイル名が異 なる 不明瞭なドキュメント I2C通信APIの不明瞭さ 特に初期化の方法がわからない ペリフェラルの詳細を知っていなければ使 えない パラメータが型付けされていない 膨大なMACROの中から適切な名前を選ば なければならない 設計者の組み込みへの無理解 I2CでNAK中断した際のリカバリができない GPIO割り込み入力のマスクができない(!!) 品質の低さ パラメータ検証の不徹底 バグのレグレッション テストカバレッジの低さ 報告されたバグへの対応の遅さ コミュニティの雰囲気が悪い 罵詈雑言やマウントが幅を利かせている STM担当者によるレスポンスは遅い GitHubにレポジトリがあるのに、バグ報告 は雰囲気の悪いコミュニティにすることを強 いられる
- 27. 紫によるCubeHAL利用 紫をCubeHALで使うには以下の設定が必要になる main.cにInitPlatform()呼び出しを差し込む main.cにExecPlatform()呼び出しを差し込む 以上の関数プロトタイプを読み込むために、インクルードファイルをmain.cに挿入する HALのASSERTIONを紫で取り扱えるようcustomAssertFailed()呼び出しを差し込む Startup/startup_stm32*.sのDefault_Handlerに、CustomDefaultHandlerへの呼び出しを差し 込む Src/stm32*_it.cにCustomeDefaultHandler()への呼び出しを差し込む 以上の関数プロトタイプを読み込むために、murasaki_platform.hppをインクルードさせる シリーズごとに異なるヘッダファイル名を吸収するために、統合ヘッダファイル murasaki_include_stub.hを作る 実アプリでCubeHALを使おうとすると、このくらい手がかかる。 Lチカならもっと簡単
- 28. 設定スクリプト 前述の設定を毎回手作業で行うことは非現実的なので、紫プロジェ クトはinstallスクリプトを提供している 名前が良くない。 setupスクリプトの方が良かった。 225行のシェルスクリプト 二重セットアップ回避機能付き https://github.com/suikan4github/murasaki/blob/master/install
- 31. TOPPERS/ASPにCubeHALを埋め込む TOPPERS/ASPのディレクトリ構造 の中に、CubeHALをコピーする CubeMXに生成させたコードを、 手作業でTOPPERS/ASPのスレッ ドにコピーする 初期化 割り込みハンドラ スクラッチで初期化コードを書く ことは推奨しない どうせユーザーがついていけなく なる TOPPERS/ASP CRT TOPPERS/ASP ISR CubeHAL Application TOPPERS/ASP
- 32. 利点 TOPPERS/ASPをそのまま使える 欠点 CubeMXに生成させたコードを、 手作業でTOPPERS/ASPのスレッ ドにコピーする 初期化 割り込みハンドラ ピン配置やペリフェラルを修正 するたびに、手作業のコピーが 必要になる TOPPERS/ASPにCubeHALを埋め込む方法の 得失
- 33. CubeHAL/CubeMXにTOPPERS/ASPを埋め込 む CubeMXが生成したディレクトリ の中にTOPPERS/ASPを埋め込む。 TOPPES/ASPカーネルは、main() からkernel_start()を呼ぶ。 CubeMXが生成するISRを使うた め、割り込みの出入口処理がで きなくなる。 CubeMX CRT CubeMX ISR CubeHAL Application TOPPERS/ASP
- 34. 通常のASPカーネル dispatchは関数として呼ばれる。 割り込みハンドラは出入口処理 を持つ 改造案 dispatchは割り込みとして処理 する 割り込みの入口処理はしない 割り込みの出口処理はdspatch の遅延割り込み呼び出しに変 更する 以上はARMの技術文書に示さ れている方法 FREERTOSもこの方式 ASPカーネルの改造案
- 35. 利点 CubeMXが生成するCRTとISRを そのまま使える。 ISRはTOPPERS/ASPコンフィギュ レーターの管理外になるので、 コンフィギュレーションの回数が 減る 動的生成を使えば、タスクやセ マフォの増減もコンフィギュレー ション不要になる 欠点 TOPPERS/ASPカーネルを書き換 えることが必要になる。 カーネル・コンフィギュレーション を変えるたびに、TOPPERS/ASP をコピーする必要がある main()の然るべき場所から kernel_start()を呼ぶ必要がある ISRの然るべき場所から出口処 理を呼ぶ必要がある 改造案の得失
- 36. CubeMX生成コードの取り扱い CubeMXはユーザー・コードを保 存する機能を持つ コード再生成時も変更されない main()関数の赤枠の内側に start_kernel();を書けば、保存され る。
- 38. 終わりに
- 39. FREERTOSがあるのにTOPPERSを使う意義 は？ FREERTOSの利点 CubeMXのコンフィギュレータに一体化されている気安がある FRERTOSの欠点 FREERTOSは実装が雑なので、手懐けるまでに時間がかかる。 設計が緻密さに欠けるので、不安が残る。 産業用途にはSAFERTOSが推奨されていたりする。
- 40. TOPPERS/ASPの難しさ 少なくとも10年前は、「TOPPERS/ASPは世界のエコシステムから外れ ている」という認識に欠けていた よそ様のエコシステムに挟み込むことをよく考えていないOS。 手を加えればよそ様のエコシステムに組み込めるが、TOPPERS/ASPの良さ が少しづつ失われる。 ビルド済みライブラリとヘッダー・ファイルををプロジェクトにポンと放 り込んで使えるようになれば、心理障壁は下がると思う。
- 41. おわり