STM32F7を使ってみる2 -STM32CubeF7移植への道-

STM32F7シリーズは今年から量産開始した新しいマイコンです。つまり昔から
STM32を昔から弄ってる人にとってはおなじみだったStandard Peripheral Library
(=SPL)のF7版なぞ影も形もなく、STM32CubeF7ライブラリ通称HALライブラリ
しか存在いたしません！

ChaNさんクラスの実力がある人ならリファレンスマニュアルからレジスタ構成を
引っ張ってきて自前のペリフェラルライブラリこさえるのでしょうけどねむいさんに
そんな力があるはずもなくなすすべもなくSTマイクロのエコシステムの一部に
とりこまれてしま…ぅ･･･


まだまだだぁ！！！

幸いにもCubeF7ライブラリの中にはSW4STM32(System Workbench for STM32)
なるEclipseベースのフリーのIDEがあり、コンパイラはGCCを使用していますので
これを分析することによって私のコマンドライン&makeの環境移植へのとっかかり
を見つけることが出来ました。
ところでなんでEclipse使ってるのに全身から血を吹き出して死なないのかこの
嘘吐きめと突っ込みたいでしょうが私はメーカーお仕着せの各種設定完了済の
Eclipseのカスタム版IDEでは無傷です。あくまで死ぬのは未設定の素のEclipseで
攻撃された時だけです。あといないさんがスカートをたくし上げて下着を見せてるイラストを
見せられただけでも死ぬので絶対に見せないでください
絶対にですよぅ！！！！






それはおいといてSTM32F7-Discoveryを使ってF7版のいつものの構築に移ります。
昨年の時点でNucleo系の板はSPLからHALライブラリに引っ越ししておりました。
しかしあくまでUARTやI2Cと言った基本のライブラリを動かす程度に留まって
いたのですが今回はSDRAMやFatFsなどを動かすところまで行きます。


STM32F7になってメモリ構成がF4よりもはるかに複雑になりましたが基本は
全く変わっていません。恐れずにF4と同じようにプランを練っていきました。

TCMのうちユーザーが触ることができるDTCMはF4ではできなかったDMAができる
ようになったので細かいことは気にせずスタック/Auto変数領域に割り振る
ことができます。CubeF7のExampleではDTCMの初めからメインSRAMの終わりまで
をまるまる一本の巨大SRAMとして使っていますので細かいこと気にするなと
言うことなのでしょう。実際DTCM〜SRAM2までリニアに繋がってますし。
↑実はこれが伏線だった…


そんなわけでいつものGCCのビルド環境のひな形が出来ました

先ずは基本の"き"LED点滅とUARTから。
LEDはF7-Disacovery上ではArduinoUNOライクなコネクタピンのSCKに
相当するPI1です。

なお、昨年くらいのCubeF4のアップデートで気づいたのですがGPIOのビット
単位でセット/リセットが可能なレジスタSBRR/BRRと言うのが昔はおなじみ
だったと思いますがそれが廃止され32bitのSBRRのみとなってやがります###
ビット単位でI/Oをやり取りする際にこれは超不便且つビットアクセスのための
新しくできたHALライブラリのオーバヘッドがでかすぎるので旧来のGPIOの
構造体を作って昔と同じように16bit幅のSBRR/BRRレジスタをアクセス
できるようにしました。

UARTはSTLink/V2-1のVCP入出力が繋がるUSART1ポートのPA9(TX)、そして
GPIOB7(RX)です。RXピンはおなじみのPA10じゃないのでご注意を！

と言うわけでこの2つはF4版NUCELOを参考にF7用にあてはめるだけでOKでした。


もちろんprintf関数などのnewlibの関数群との結合も余裕です★



ここでちょっと注意ですがSTLink/V2-1でVCPを使う際に特定のUSB3.0
ホストに差すとSTLink/V2-1側から送信するUARTの信号が正常に出力
されない場合があることを発見しました。
その特定のUSBホストと言うのはFL1100なのですが上記の画像のように
めちゃくちゃな信号が出力されてSTM32F7側と正常に通信ができません。
もしUSB3.0ポートで上手くいかない場合はUSB2.0ポートに差し直して
試してみてください。


お次はSDRAMです、F7-Discoveryには128MbitのSDRAMが搭載されています。
こちらもBSPの初期化コードを参考にねむいさんの環境に嵌めて行って危なげなく
動作せしめることが出来ました。このボードにおいてはSDRAMBank1に配置されて
いて0xC0000000が開始アドレスとなっています。

STM32F7でFMCを使ってSDRAMを使用する場合、F7側はデータバスが16bit分
しかないので32bitの変数のアクセスはAHBバスで16*2bitに分割転送されます。
そんなわけでこのボード上では上位16bit分のデータバスを男らしくバッサリ
捨てており容量は128MBitありますが実質64MBit分しか使えませんorz
また、Example曰く実装されたSDRAMが安定動作するシステムクロックの
上限は200MHz、その時のSDRAMCLKの上限は100MHzになるので、
(↑根拠としてSTM32F7のデータシートに下記の記述がありました。
　For 3.0 V≤ VDD≤ 3.6 V, maximum FMC_SDCLK = 100 MHz at CL=20 pF (on FMC_SDCLK).)
単純計算で100MHz*16=1600MBps
が理論値となります。なんかちょっともったいない使い方ですね…。

前回の記事でたけさんと言う方からリクエスト貰いましたのでSDRAMのR/W
性能を測定してみました。4MByte分(下述)を16bit変数単位で読み書きした値です。
D/I-Cacheは有効にしていますが妙に数値が低いのは私のコーディングが悪い
せいでしょうか･･･


最後にFatFsです。CubeF7謹製のFatFsのローレベルドライバはやたら凝っていて
USB-OTGのUSB-MSCの接続も想定したつくりになっています。FatFSで必須な
関数群はFATFS_LinkDriverなる関数で結合する仕組みとなっています。
今回からはSTのスタイルに倣ってそれを積極的に使うようにしました。
といっても私のプロジェクト向けにほんの少しの変更をしただけですが。


まだTFT-LCDのドライブまでは進めてないのでUARTからのコマンドでFatFsの
動作を確認しました。F7-DiscoveryではSDIO改めSDMMCインターフェースが
出ていてSDカードからのデータを高速にやり取りできます。


いつものごとく読み出し速度を調べてみました。CubeF7のExampleではSDMMCの
クロックは潰しの効くNomalMode(25MHz以下)に抑えられているのでF4の25MHzと
さほど変わりませんね。


CubeF7のライブラリを調べているとDMAは全く使用してないFIFOポーリングで
読み書きを行っていることが分かりましたがHALライブラリにはDMAを使用する
関数も用意されていてほんの少しの改修でDMA化できるので試してみました

が…！



なん…だと…！？


つづく！

Go to top of page