前回は概要をさらっただけなので、今回はもう少し中身を見ていこう。
私が持っている、STM32F411REが搭載されてNUCLEO-F411REを使おうかと思ったのだが・・・。
STM32Cube BSP with FreeRTOS for STM32 ARM Cortex-M
STM32CubeMX
なんと、FreeRTOS対応のSTM32Cubeがあるんだと!
「テスト開始!」っていわれて解答用紙を見たら、既に答が書いてあった気分だ。
まあ、移植する作業からやるつもりもなかったし、よしとしよう。
ステップ1は、STのホームページからSTM32Cubeをダウンロードする。
今の最新は、4.16.0だ。
あれ、STM32CubeMXはEclipseのプラグインのようだ。
以前はスタンドアローンだった気がするのだが、記憶違いか。。。
ああ、STM32Cubeは、F1とかF4でまたダウンロード先が分かれているんだ。
私はSTM32CubeF4ということになる。
この辺、ちょっと紛らわしいな。。。
- STSW-STM32095 : Eclipse pluginのSTM32CubeMX(4.16.0)
- STM32CubeMX : スタンドアローンのSTM32CubeMX(4.16.0)
- STM32CubeF4 : STM32F4系のSTM32Cube(1.13.0)
STM32CubeF4を解凍すると、こっちはプロジェクトやらドキュメントやらの一式だった。
STM32CubeMXはインストーラが入っていた。Windows, Linux, Macの全部が入っているようだ。
まずは、STM32CubeMXをインストールする。
ステップ2では、STM32CubeMXを起動する。
"Help > New Libraries Manager"を選択すると、ダイアログが表示させる。
Firmware Packageの一覧が表示されるので、私は「STM32CubeF4 Releases」の一番上(1.13.0)をチェックして"Install Now"。
なんかエラーが出た。
よくわからないので、左下の"From Local..."で、先ほどダウンロードしたSTM32CubeF4のzipファイルを指定する。
そうすると、もごもごやってインストールされる。
ステップ3は、プロジェクトの作成。
CubeMXの画面に戻って、左から"New Project"をクリック。
そうするとダイアログが表示される。
手順ではMCUから順番に選択していくのだが、今回はNUCLEOなのでBoard Selectorタブで選ぶ。
UARTが出てこないけど、そういうのは設定済みでよいのか。
まあ、CubeMXで設定できるだろう。
ステップ4は、ピンの設定。
ステップ5は、周辺の設定。
ステップは8まであるのだが、あとはCubeMXの使い方になっていくので、ここでは省略する。
Pinoutタブの項目には最初からFreeRTOSが入っているので、これをチェックすればうまいことやってくれるのだろう。
プロジェクトの設定をしてからソース生成してもらうのだが、その辺りは自分の環境に合わせよう。
私はGCCでやりたいので、ToolchainをSW4STM32にして、Makefileに変換するスクリプトを作ってくれている方がいるので、それを使うことにした。
変換して出てきたMakefileは、Windowsのコマンドプロンプトではうまくいかなかったが、cygwinでは通った。
Windowsの時に何かコマンドが見つからなかったようなのだが、まあいいや。
これで、ビルドできる環境だけは整った。
ただ、実際に何か動かさないと、ビルドできても動くかどうかわからない。。。
自動生成されたソースはいろいろあるが、ユーザ用はここだろう。
その4つのソースファイルのうち、下2つは初期関係なので省略。
main.cはいろいろ書けるようになっているが、タスクを起動する様子がうかがえるので、StartDefaultTask()にLEDを点滅する処理を書けば、そこまで動いているか確認できそうな雰囲気がある。
/* StartDefaultTask function */
void StartDefaultTask(void const * argument)
{/* USER CODE BEGIN 5 */
/* Infinite loop */
for(;;)
{
osDelay(1);
}
/* USER CODE END 5 */
}
使っているBlogエディタが、プラグインに対応できていないので、ソースコードはそのままだ。
見にくくて済まない。。。
まあ、このソースを見た感じでは、osDelay(1)が1msecか1secかわからないけど待つだけだろう。
コメントでBEGIN~ENDがあるのは、その間にユーザコードを埋め込むようにしておかないと、CubeMXで設定を変更して自動生成し直したときに消えてしまうのだ。
void StartDefaultTask(void const * argument)
{/* USER CODE BEGIN 5 */
/* Infinite loop */
for(;;)
{
HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
osDelay(1);
}
/* USER CODE END 5 */
}
さあ、どうなる?
・・・
・・・・・
NUCLEOをWindows10がMass Storageとして認識しなくなってる。。。
いや、ドライブとしては見えているけど、ファイルシステムが見えていないのかな?
NUCLOEは、たしかFAT12だったと思う。
どうも、Anniversary Updateを行ってから接続できなくなったという情報が多い。
うーん、ST-Link Utilityからだったら焼けるだろうか?
焼けた。
けど、LEDは点灯しっぱなし。
eclipse + GDB OpenOCD Debuggingでやってみる。
たぶんOpenOCDは、ねむいさんスペシャルだったと思う。
一発目は、Config optionsがどーたらこーたらというエラーになった。
たしかに何も設定していない。
こちらを見ながら、-sと-fを指定。
意外なことに、これで動いた。
main()の頭で止まる。
ステップして動く。
おお、動いているじゃないか!
では、StartDefaultTask()にブレークを張ってrun。。。来てるじゃないか!
ステップ実行してLEDは、点灯。
osDelay(1)。
またステップ実行してLEDは、消灯。
動いてるじゃないか!
ということは、osDelay(1)は1msecで、速すぎてわからなかったというだけか。
では、1000くらいにして焼き直すと。。。おお、点滅している!
点滅しているぞ!
こういう「開通おめでたう」みたいなときが、一番楽しいですな。
今回は、STM32F411が搭載されたNUCLEOと、STM32CubeMXを使って、FreeRTOSのタスクが1つ動くテンプレートをそのまま使ってLED点滅をさせるところまで動かせた。
大したことをさせていないからだとは思うが、思ったよりもあっさり動いた。
FreeRTOSが動いたことよりも、CubeMXのソースを使ってeclipse+OpenOCDでデバッグまでできることが確認できたことの方が私としてはよかった。
あまり深入りするつもりはないのだが、さすがにテンプレートそのままでは「動かせた」というのはおこがましいので、せめて自分でタスクをもう1つつくって両方動いてくれることを確認したいところだ。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。