買ってしまった…
でもこのぶろぐの運営上は避けては通れないので新しい時代(mbed全盛)の
幕開けには必然であったと思うのですよ！
STマイクロからリリースされたNucleo一族はmbedが利用できるという売り文句の他に
価格が異常なくらい安いという点も注目を集めていますね。これについてはいろんな
方がいろんな考察をしておりますが、ねむいさん的にはこれは中華製ぱちもん基板の
駆逐も目的としてるんじゃないかなとにらんでます。STM32って中国大陸の方の中華圏
では日本市場とは比べ物にならないほど大人気なんです。それにあやかり安かろう悪か
ろうのとんでもないブツがあふれてますのでST自ら超安価に基板をばらまいて巨大な
中華市場をさらにコントロールしようという思惑が考えられます。
視点を日本に戻すと日本ではハードウエアレベルを隠ぺいした抽象化を強化したプロ
グラミングがArduinoや前途のmbedを中心に大流行していますので日本においてもこの
基板を用いたことによりSTM32の利用者も急激に増加していくことになると思います。
で、ねむいさんってmbedとか使ってないから全然関係ないじゃんとか突っ込まれそう
なのですが別に便乗とかそういう意味合いでは全くなく単にSTM32F401シリーズを使っ
てみたかっただけです！！！！
?????????…というわけでは従来のF4シリーズの廉価版に位置付けら
れていて下記の機能が削られています。
?CCM(Core-Coupled Memory=密結合メモリ)
?DMA転送用SRAM領域
?BackupSRAM領域(バックアップ"レジスタ"は健在)
?クロックがF40x系の半分(MAX84MHz)
?PB11(Vcapになった/一部パッケージのみ使用可能)
?その他ペリフェラル色々
引っ掛かりやすいのはPB11でしょうか。GPIOでPB11を使用している場合にF401系に
載せ替えるような時は注意が必要です。
STM32F401系のメモリ構成は大雑把にするとこのような感じになります。
画像はF4版Nucleoに乗っているSTM32F401RET6のものです。ごくごく一般のARMマイコン
と変わらなくなってますので特に小難しいことは必要ないです。
てわけで実践です！緑色のLEDが点滅します。
(注：右上はではなく見滝原中学校の制服を着たいないさんです)
先ずはLチカ!mbedだとハードを越えてほぼ同じコードでLチカせしめることが出来ます
がねむいさんの環境も同じくmain.cはほぼコピペで同じようなことが可能です！！！
水面を優雅に泳ぐ白鳥も水面下ではせわしなく足を動かしているのと同じく抽象化さ
れたコードの下では頑張って下駄履かせてきた人たちの汗と涙が詰まっていることを
少しでもおもいだしてくれれるとうれしいでｓ
そういうことはどうでもいいのでさっさと先に進みます。お次は前回と同じI2Cデバイス
です。こちらもの奴で汎用化したシンプルなI2Cライブラリを作りこんでいて
そのまま転用出来るようにしてあるのではっきり言って前回のF0系より楽勝でした。
所でこの、私ががaitendoさんで全く数が減ってません…
規模の大きいマイコンで使う限りでは圧倒的に使い勝手が良いのですが…
消費電流もST7032iとかに比べて少ないのでお勧めです★
大事なことなので前回に引き続き二度言いました。
というわけで今回動作させた。一旦ベースをこさえてしまえばあとはどんどん作りこんでいけるので
オフラインコンパイラフリークな方にも安心してNucleoを利用できると思います。
また忘れるところでした、は今回のF4版Nucleoにすでに対応して
ますのでどしどしご利用ください。
ぇー…のSTM32の記事の最後で新しいと称するどことなく卑猥な名称
のふれこみで発表されたとそのF4シリーズのサポートを行うという
新たなファームウエアライブラリに触れましたが…
私も移植を目指して頑張ってたのですが…
私の従来のに当てはめようと思うと改造個所が多岐に及び、さらにコードサイズ
とオーバーヘッドも増加してしまったので移植は見送りにして新規に作るプロジェクトから
CubeF4を使用する方針に逃げ変えました。
STM32CubeF4には抽象化がさら進められ、インスタンスという概念が追加されています。
これがかなりの曲者で従来のF4シリーズで言うDSP_StdPeriph_Driverライブラリに相当
する"STM32F4xx_HAL_Driver"はすべてこれの使用を前提としていてさらにサイズが
大きい構造体と併用しなければならないのが分かりました。これSRAMやFLASHのリソース
が膨大にあるF4シリーズだからよいものをF1/F0にも当てはめるのはかなりヤバいと思います。
私も過度の抽象化は良いとは思っていません。移植性を重視しすぎてせっかくのマイコン
の性能を引き出せないのであれば本末転倒です。
あんまし考えたくないのですが無理くそ全CPUの格差を埋めるべく抽象化を目指し、
そして失敗して結局ライブラリのバージョンが多岐に分かれてしまったLPCOpenと同じ
道を歩んでいる感じがします。
おそらくCube系のライブラリに遷移していくあたって大混乱が起こると思いますね。
無理にCubeへの遷移を煽る中途半端に発言力が持ってる人が湧くのは容易に予測
されます。学生さんなんかは自分のボスの"せんせい"にまたCubeライブラリの使い方を
wikiにまとめさせられると思います。そういうこと言ってくる人らには"こんなことしてる
こと自体が時間の無駄。したけりゃ自分でやれ！"と。
とはいえ私のぶろぐを見られている方は私よりも技術力がはるかに上の方ばっかな
のでそもそもこんなとこ見てない私が注意しなくても各自しっかり対処出来することが
できるでしょうからぐだぐだ言いましたがやっぱし私の杞憂かなと思います。
さて、前置きが長くなってしまいましたが以前から触れてきたSTM32F429I-Discoveryの
TFT-LCDをSPIではなくRGBインターフェースで動かすことに成功しました。
前回は低速なSPIインターフェースでお茶を濁していました。しかしSTM32F429シリーズ
にTFT-LCDに特化したグラフィックコントローラ(LTDC)とグラフィックに特化したDMAである
(Chrom-ART Accelerator)が搭載されているのでこれらの機能を使っていつものの再現
を目指しようやく完成したわけです。
●STM32F429Iにあるグラフィック機能
私が説明するよりもを見たら一目瞭然です。
LTDCに関してはフレームバッファとして確保したメモリアドレスにRGBのデータを書き込む
だけで色の表示が可能です。また、STM32F429系ではSDRAMがサポートされているので
容量を喰う画像データでも余裕で取り扱うことができます。
Chrom-ART Acceleratorに関しては別名DMA2Dと称されていて文字通り2Dグラフィック
特化型DMAです。しかもデータ形式を変換してメモリ間転送したり単一データを指定して
転送する(レクタングルフィルに効果を発揮)ことができます。
STM32F429I-Discoveryでは上記二つの機能を体験可能です。同ボードに搭載されたTFT
LCDの解像度は工作物ではメジャーな240x320となっています。STM32のLTDC単体では
レクタングルを指定して書き込み時にアドレスを自動インクリメントしながら連続で書き
込める機能はない(DMA2Dで解説します)ためアドレス計算は必須です。
具体的にいうとたとえば座標x,yにドットを打ちたい場合は基本的には先ず以下のように
座標を指定します(RGB=565,1ドットあたり2Byteのデータを想定)。
lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(x + (MAX_X*y));
lcd_c_buf_ptr :ドットデータを実際に書き込むメモリのアドレス
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
:TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義)
次にRGBデータcolourを書き込みます。
*(volatile uint16_t*)(lcd_c_buf_ptr) =
lcd_c_buf_ptr +=2;
より具体的な実装はの./lib/display/mcu_depend/src/lcdc_if_basis.cをご覧
下さい。FONTX2等の描画ルーチンは完全にドット単位で行っていますがMCUバスと外部
LCDコントローラとの通信オーバーヘッドがなくなるのでドット単位でも十分に早くなり
ます。また、LTDCは2枚のレイヤーを使用可能でさらにアルファブレンディングの透過
効果も使用可能です。現状では単一のレイヤとしてしか使用していませんがこちらも
学習を重ねてモノにしていきます！
次にもう一つの目玉機能Chrom-ART Accelerator(以下DMA2D)です。私のいつものでは
FillRect系のレクタングル指定塗りつぶしやレクタングル指定の動画データ転送に使用
しています。
基本的には通常のDMAと同じですがグラフィック特化なのでRGBデータを格納するレジ
スタもあります。単一色描画では以下のように設定します。
※RGB565,黒色,全画面(240x320)塗りつぶしの場合
/* configure DMA2D */
DMA2D_DeInit();
DMA2D_InitStruct.DMA2D_Mode
= DMA2D_R2M;
DMA2D_InitStruct.DMA2D_CMode
= DMA2D_RGB565;
DMA2D_InitStruct.DMA2D_OutputGreen
= (0x07E0 & COL_BLACK) >> 5;
DMA2D_InitStruct.DMA2D_OutputBlue
0x001F & COL_BLACK;
DMA2D_InitStruct.DMA2D_OutputRed
= (0xF800 & COL_BLACK) >> 11;
DMA2D_InitStruct.DMA2D_OutputAlpha
DMA2D_InitStruct.DMA2D_OutputMemoryAdd = (uint32_t)lcd_f_buf_
DMA2D_InitStruct.DMA2D_OutputOffset
= (MAX_X - 1));
DMA2D_InitStruct.DMA2D_NumberOfLine
= MAX_X+1;
DMA2D_InitStruct.DMA2D_PixelPerLine
= MAX_Y+1;
DMA2D_Init(&DMA2D_InitStruct);
/* Start Transfer */
DMA2D_StartTransfer();
/* Wait for CTC Flag activation */
while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
:TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
:TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
フォアグラウンドのレイヤーへ画像データを転送したい場合は以下のように。
/* configure DMA2D */
DMA2D_DeInit();
DMA2D_InitStruct.DMA2D_Mode
= DMA2D_M2M;
DMA2D_InitStruct.DMA2D_CMode
= DMA2D_RGB565;
DMA2D_InitStruct.DMA2D_OutputGreen
= 0; /*　M2M系転送の場合は使わない */
DMA2D_InitStruct.DMA2D_OutputBlue
= 0; /*　M2M系転送の場合は使わない */
DMA2D_InitStruct.DMA2D_OutputRed
= 0; /*　M2M系転送の場合は使わない */
DMA2D_InitStruct.DMA2D_OutputMemoryAdd = (uint32_t)lcd_f_buf_
DMA2D_InitStruct.DMA2D_OutputOffset
DMA2D_InitStruct.DMA2D_NumberOfLine
= MAX_X+1;
DMA2D_InitStruct.DMA2D_PixelPerLine
= MAX_Y+1;
DMA2D_Init(&DMA2D_InitStruct);
/* Configure default values for foreground */
DMA2D_FG_StructInit(&DMA2D_FG_InitStruct);
DMA2D_FG_InitStruct.DMA2D_FGMA
= (uint32_t)p;
DMA2D_FGConfig(&DMA2D_FG_InitStruct);
/* Start Transfer */
DMA2D_StartTransfer();
/* Wait for CTC Flag activation */
while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
:TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
:TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
:転送したい画像データのポインタ
と、従来のDMAと同じ感覚で使用が可能です。もっと汎用なDMA2Dの使用法は同じく
lcdc_if_basis.cをご参照ください。DMA2DはLTDCと組み合わせると強力なレイヤー機能が
使えるようになるでしょうね。私のサンプルでは全く使いこなせてませんがー！
という訳でそれを踏まえたをビルドして書き込み、動作させたものが上の画像です。
静止画では違いが分からないと思いますが以前の8-bitSPIのみで動かしてたものとは
描画速度がダンチですよ&
惜しむらくはSTM32F429I-Discoveryに使用されているTFT-LCDが発色にちょっと劣る点
です。2014年現在でははすでにホビイストでも容易に入手可能なので
それに慣れた私にとってはあと一歩がほしいところと感じました(多分最新の奴搭載し
たら値段跳ね上がるでしょうけど)。
●の細かい整備など
LTDC+DMA2Dに対応したついでに長らく放置していたの
プログラムも見直して安定化を図りました。いまさら気付いたのですが、新しいSTM32F4に
存在するFMC(フレキシブル?メモリコントローラ)ではFSMCの設定とは微妙に違っておりました…。
なんとFSMCでは存在しなかった変数が構造体に追加されていてこれを設定してなかった
せいで動作が不安定になっておりましたorzいまさら気付きましたがまだFMC世代の新しい
STM32F4を使用されている方が少ないのか指摘されず助かりましたうふふふふふふふｆ
また、この全部載せ基板はI2Cのコーデックも乗っていて音質は非常に悪いですがmp3や
waveファイルの再生も可能です。私のいつものプログラムではSDIO経由でSDカードのmp3
ファイルなどを読みだして再生します…がしかしビットレートが高いmp3の再生ではSDIOの
データ読みだしにDMAの転送を行うとI2Sの方のサーキュラモードDMA転送と干渉しまくり
あっという間にオーバーフローになってエラーをはいて止まります。
という訳でこれを避けるためにSTM32F4でもFIFOのポーリングでの読み書きに本格的に
対応させることにしました。STマイクロ配布のSTM32F4のデモではポーリングの読み
書きはRead/WriteBlockしか対応しておらず非常に低速度なのですがマルチブロック転送
でもポーリングで読み書きできるように改良しております。ポーリングでもDMAとほぼ
同等の転送速度が得られたので速度に関しては問題なしです。
…という訳でDMAあえてを使用せずポーリングによる読み出しだけで無事ビットレートの
高いmp3ファイルの再生も可能となりましためでたしめでたし！
(helixのフォルダにあるassembly.hのマクロが前回の機能追加で間違っててそもそもmp3
　ファイルが全く再生できなくなっていたのは見逃していただきたい)
●もいっこおまけ
私のでは一部のmp3ファイルを再生したときにアーティスト/曲名情報表示の際に
ゴミデータが表示されてしまっておりましたが、こちらも文字列ストア用のバッファ(私の
プログラムではCCM領域にあたる)を一旦ゼロクリアしてから表示を行うようにしてバグを
潰しております。
以前は変なゴミデータが表示されていましたが…、
修正後はこんな感じにすっきりです★
今年もいろいろありましたが私としてはやってることはほとんど変わらず山走りとかに
行ったりLチカを極めるべく研究したりOpenOCDのエンバグとかです。
特にステップアップらしき事をしたのは今まで利用だけしていたOpenOCDのプロジェクト
に対してパッチを提出する形で能動的に参加したことでしょうか。言葉の壁はもちろん
ありますが何度もこなしていくうちにある程度分かってきますので皆様もオワコンとか
言わずにどんどん参加してほしいと思います。
●マイコン向けの最強最後のTFT-LCDをゲッツか
i8080バスで接続できるもので現時点でほぼ最強かと思われるモジュールを手に入れ
ました。320x480(HVGA)?ILI9486L?超広野角?3.8inch?抵抗膜式タッチパネル付と
至れり尽くせりでSTM32F4系のFSMCで接続するには最適です。
これ以上のピクセルサイズになるとRGBやMIPI-DSIのほうが速度的に有利になるので
やはり"マイコン"で使用するのなら320x480が上限と感じます。
以前の主力だった3.45inchの奴(コントローラIC:R61581/B0)と比較してみました。
一回り大きいのがわかると思います。
●がアップデート
読んで字のごとくですがクリスマス前に合わせて更新というなかなかニクいアップ
デートです。今回からGCC4.8.x系になりました。また今回の目玉は新しいコンパイラ
オプションの"-mslow-flash-data"の追加です。これはどういうものかというとと
いわれるものです。ARM本家のともご参照のこと。
"-mslow-flash-data"のありなしで吐かれたアセンブラリストの比較をしました。
使用したプログラムはです。赤でハイライトしてる部分がその違い
ですがLDRで行っていたリテラルロードがmovtに置き換わってるのがわかります。
LDR命令の場合、最短3クロックサイクルかかりバスの競合があるとさらに5クロック
サイクル以上掛かることになります。movtに置き換えた場合はサイズは増加しますが
2クロックサイクル固定です。
次に実際のパフォーマンスを比較してみました。libjpegとlibpngのデコード速度の
実時間を計測して比較しました。表示に使ったのLCDはもちろん最初の項で紹介した
です！また表示に使用した画像は320x480サイズにしさらにpngとjpegに変換を行った
いないさんのをサンプルとして計測結果をuSec単位でｔ
…?????????
さて実際の結果ですが、せっかくなのでfreddiechopinさんとこのや役立たずに堕ちたSourceryCodebenchも(←今回の比較のためにわざわざ
登録してインストールしためっちゃめんどくさいF**K!)交えコンパイラオプションも
いろいろ変えて各コンパイラ性能比較も兼ねて行いました。
↓とりあえず各条件の計測時間の羅列です
　(※-mfloat-abi=softの時はlibjpegのDCT_FLOATは無効にしていますのでバイナリ
　　　サイズが全般的に下がっております。)
libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
: INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3
(release) [ARM/embedded-4_8-branch revision 205641]
(Using newlib) -Ofast -mfloat-abi=hard
-mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
hex filename
79478 main.hex
***libjpeg
182341uSec
168305uSec
(Using newlib) -Ofast -mfloat-abi=hard
-mfpu=fpv4-sp-d16
=== Total Binary Size ===
hex filename
776b8 main.hex
***libjpeg
181903uSec
168485uSec
@@L2222 (nano-lib)
(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard
-mfpu=fpv4-sp-d16
=== Total Binary Size ===
hex filename
72e5c main.hex
***libjpeg
194318uSec
234706uSec
(Using newlib) -Ofast -mfloat-abi=softfp
-mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
hex filename
79470 main.hex
***libjpeg
182345uSec
168311uSec
(Using newlib) -Ofast -mfloat-abi=softfp
-mfpu=fpv4-sp-d16
=== Total Binary Size ===
hex filename
776b0 main.hex
***libjpeg
181925uSec
168588uSec
(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data
=== Total Binary Size ===
hex filename
79218 main.hex
***libjpeg
186999uSec
168740uSec
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
hex filename
77490 main.hex
***libjpeg
187095uSec
168490uSec
BLEEDING-EDGE
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-.7.4
(prerelease)
(Using newlib) -Ofast -mfloat-abi=hard
-mfpu=fpv4-sp-d16
=== Total Binary Size ===
hex filename
879c4 main.hex
***libjpeg
183801uSec
170161uSec
(Using newlib) -Ofast -mfloat-abi=softfp
-mfpu=fpv4-sp-d16
=== Total Binary Size ===
hex filename
879ac main.hex
***libjpeg
183797uSec
170156uSec
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
hex filename
87214 main.hex
***libjpeg
187582uSec
170098uSec
SOURCERY CODEBENCH
arm-none-eabi-gcc (Sourcery CodeBench Lite ) 4.8.1
(Using newlib) -Ofast -mfloat-abi=softfp
-mfpu=fpv4-sp-d16
=== Total Binary Size ===
hex filename
7b2f8 main.hex
***libjpeg
184072uSec
203915uSec
(Using newlib) -Ofast -msoft-float
=== Total Binary Size ===
hex filename
879c4 main.hex
***libjpeg
186811uSec
203920uSec
かなり条件が入り乱れているので要点をかいつまんで紹介しますと、
まず"-mslow-flash-data"有だと、無しのものより逆にlibjpegのデコード速度が若干
下がるといった結果になりました。libpngはちゃんと速くなったのですが…全体的に
スピードアップすると思っていたのでちょっと微妙な結果です。
はつぶしが聞くように"-mslow-flash-data"オプションは
デフォルトではコメントアウトにしてます。
↑2014年が明けて一週間たったころにようやくlibpngとlibjpegの評価をあべこべに書いて
　たの気づきましたすみませんorzちゃんと修正しました。
　"-mslow-flash-data"オプションを付与するとlibjpegでは逆効果になってしまいます。
またLaunchpad特有のnewlibをシュリンクしたnano-libを使用した場合、全体的なパフォー
マンスが低下することが分かりました。libjpegもlibpngもmallocを使用するので、そこに
パフォーマンスの違いが現れていると思われます。作成するアプリケーションの目的に
応じて使い分けるのがよいでしょう。
次に各コンパイラ比較ですが同条件(-Ofast -mfloat-abi=softfp
-mfpu=fpv4-sp-d16)
の場合、LaunchpadのGCCがサイズの小ささ/速度ともにトップになりました。さらに
Launchpadのは"-mfloat-abi=hard"も選択できる(Sourceryのはsoftしかない)ので、
もはやわざわざ登録してまでSourceryCodebenchを利用する意味が全くなくなりました。
●よくいただく質問に対する回答とか
というわけで今年のぶろぐもこれでお開きですが、毎年恒例の尺が余ったので
メールや虹裏でいただいた変な質問にぶろぐ上で返信をさせていただきます。
Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
　ていうかちゃんとぐぐりなさいよー！
Q:USB3.0でLibUSBが(ry
　USB3.0のホストのほうもファームやドライバの最新化は必須ですよぅ！
Q:いままで問題なく動いてたのに急にOpenOC(ry
A:変なことやらかした人に限って口をそろえたように"問題なく動いていたのに急に
　何ちゃら"は何らかのシンクロニシティなのでしょうか…？？？
Q:(ブラジルポルトガル語と思われるFatFsに関する質問)
A:Sorry,I cannot understand your language,at least in English.
Q:(簡体字中国語と思われるSTM32(←中国で人気のマイコンだそうです)に関する
　　何らかの質問)
A:Sorry,I cannot understand your language,at least in English.
Q:(日本語と思われる文字列だが日本語としてまったく解読不能の何らかの質問)
A:Sorry,I cannot understand your language,at least in English.
Q:ねむいさんとか言うサイトみたけど役立つ情報が全くない上に何が
　言いたいのかよくわからないので
A:私もそう思う。特に今日の前半のとことか。意識他界方がこんなトコ来ちゃ駄目ですよ…
Q:OpenOCDのWindowsバイナリは配布されておらず
Q:(企業のメールアカウントで)***なのですが****を希望しますor早く修正してくだ
　さい。以上。(←回答納期をつけてくる場合も…#)
A:今年に入ってなぜか急にたくさんいただくようになりましたが……企業内で開発を
　行われる場合は有償のサポートが付いたツールを使用されるほうがいいと思います。
　もしくはを0回音読して"利用者が全責任を負う"っていうこと
　を体で理解してください。ちなみに私の副業先ではARMはIARで開発しております。
Q:ルネサA:帰れや！
A:?????///
A:?????///
　これデザインしたの私と同性の方でしょうか…？
　本来のとは逆向きに付いてますし///
Q:ねむいさんで検索すると候補に入院と出てきます。これは何ですか？
A:これは重篤なサジェスト汚染ですね?！
　当職が入院したとかいう体だけ(非性的な意味で)が取り柄のねむいさんのあいでん
　てぃてぃを否定する検索が多数行われているのは絶対に許さないよれません！！
Q:ねむいさんのぶろぐに右端にあるブラウザベンチマークというリンクをクリック
　したら突然大量の画像が貼られるページにいどうして動作が重たくなり、ブラウザ
　がクラッシュしてしまいました！！！１！！ファ*クユー!!!
A:びぃぶろ君が悪いんですけぉ！１！！ねむいさんは悪くないんですけぉ！１！！１
Q:ねむいさんはさんざモロはあかんといっときながらのは
　どういうことなの？虹裏メイドだからって何か許された特別な人間だと思ってるの？
A:わかりましたから落ち着いてください。かつて存在した虹裏novという場所があった
　のですが話はそこにさかのぼります。そこでは魅力的ないやらしい口元をした紳士
　画像を赤と黄色を交互に放射状にした…いわばのような非常に目立
　ちやすい注目をひく画像に加工したものをスレッドの頭画像とし、おもに紳士に関
　する話題やコラージュを中心としたスレッドの進行体系をとっておりました。
　しかし、実写のコラージュを用いたスレッド信仰であったためふたば☆ちゃんねる
　の???????にとって二次元裏のポリシーに反する目の上のタンコブだったのです。
　紳士画像のスレッドの住人はそれには構いなしにナイフみたいに尖っては触る者皆
　すべてに不許を貫いており???????に対する反逆とも呼べる行為を続けていました。
　そしてある日ついに、ついに虹裏novは???の怒りによってなんと板ごと御取り潰し
　に遭うという悲劇的な結末を迎えました。しかし紳士画像のスレッド住人はそれで
　息絶えたわけではありません。住人達はもといたimg,may,jun,decに2014年になろうとする今現在も続く許
　されざるビューティフル?ウォーを繰り広げているのでございます。
　現在では、前途の紳士画像を二次元裏@ふたばに貼付するという行為は???に対する
　反逆の証として児童ポルノ画像の貼り付けよりも重篤な一発アウト(スレッド削除?
　アクセス禁止措置)が取られるようになっております。safetyに紳士を語るためには
　紳士を構成する目元といやらしい口元を隠す黒塗りを施した"加工済紳士画像"の
　貼付けにて進行を行わざるを得ないのですがそういった処理前の未加工な紳士画像
　がモロ画像もしくは縮めてモロと呼ばれ、爆発性の危険物として扱われています。
　しかしながらそういったモロが貼られない状況が紳士スレッド内で続くと突然日清
　チキンラーメンのパッケージをはじめ鶏肉を主体とした調理済の料理画像が貼られ、
　あたかも"(モロを貼れない)お前はチキンだ！チキン野郎だ！"と言わんばかりの
　挑発を受けることになります。挙句の果てには手描きを用いチキンとかはたまた妙に
　ウイットに富んだ発音でティキンとかいうモロにストレートな心温まる発言を行ッ
　てくれやがります。ですがあなたたちは紳士です！そのような挑発には決して乗っ
　てはいけません！奴らはあなたの正義感を巧みに利用してモロを貼らせるように仕
　向けているだけです！！１！もし挑発に負けて大人の男怒らせるなよオメーラと言
　わんばかりに未加工の紳士画像を張り付けてしまったらゲーム?セットです。たち
　どころに大勢のアンパイアが現れつぎつぎにアウトの判定を下され、ポケットモン
　スターのにも?あちゃ?…もろ」と吐き捨てられ、仲間であったはずのスレ
　ッド住人にdelを叩き込まれてとどめに???????になーとアク禁を喰らうでしょう！
Q:東海自然歩道の静岡バイパイコースについて質問です。
　はなかなかですね？
A:し…しらない…
　気のせいでしょう??
Q:東海自然歩道の静岡バイパイコースについて質問です。
　はなかなかですね？
A:し…しらない…
　き、気のせいでしょう??
ー…そろそろ大掃除しますか…
それではみなさま、よいお年を?
STM32F429I-Discovery(製品名:)、ようやく一般市場でも入手
しやすくなってきましたね。twitterのタイムライン見てると既に手に入れられた方、使用
されている方々の写真もびしばし上がってます。
私の方はというと…少数の方は更新に気づいていたとは思いますが、へと
向かう前日の11/29にすでに既存のSTM32F4向けFatFs実装例に対応ボードの一つとし
て基本部分を組み入れたしております。
尤も429I-DiscoveryからはぢめてF4シリーズに触る奇特な人もいるかもしれませんから
これがどういう物で何ができるか今一度軽く解説をさせていただきます。
　とを見て私のプロジェクトをビルド?デバッグ出来る環境拵えてることが
　前提です！"意味が分からない"という方はご縁がなかったということで…
私の(通称いつもの)は、ChaNさんのFatFsを中心に各マイコンの極めて
基本的な機能を網羅しています。STM32F4においては下に述べる機能を抑えています。
STM32F429I-Discoveryでも勿論使用しております。
　1.GPIO操作
　　->LED点滅?SW入力
　　->割り込みを使用したバッファリングされた送受信?stdioのリダイレクト
　3.液晶モジュール
　　->MCUバスインターフェース(i8080,SPI,I2C)で駆動できる表示素子の操作
　　　STM32F429I-DiscoveryはRGBインターフェースを使わずともSPI単体でも画像
　　　データを送ることができます(遅いですが)。
　4.FatFsのローレベル部の実装
　　->SPIやSDIO等とMMC/SDカードとのインターフェース。STM32F429I-Discoveryで
　　　は。
　5.外部RAMの制御
　　->STM32F407系はFSMCでSRAMを、STM32F429I-DiscoveryではFMCでSDRAMを制御
　　　します。
んでもっていつものをSTM32F429I-Discoveryで動かしているところ
DMAの転送に使用される内蔵RAMが圧倒的に増加したので多少転送効率もよくなり、
その分ヒープ領域もたくさん取れるようになったのもうれしいです&
画像はRAM馬鹿食いのgiflibを動かしてるところ
ファイラーの操作はタッチパネルより。STM32F429I-Discvoeryではコントローラに
内蔵のフィルタがあるSTMPE811が使用されているのでキャリブレーションも簡略化
しました。同基板ではVBATがVCC直結で外部にピンが出ておらずバックアップRAMが
機能しないので苦肉の策です…
タッチパネルからのファイラーの操作は上下でファイルポインタ移動、右で選択、
左でキャンセルと手抜ｋ直感的です！
前回述べていた基礎のとっかかりに関しては対応完了です。このプロジェクトではまだ
STM32F429I-Discoveryの機能のすべてを使いこなしてはいません。以下の項目は目下
実装中のSTM32F429にしか使えない機能です。
　1.LCDCを使用したRGBインターフェースによる高速な表示
　　->やっけつで急ごしらえしましたが過去の資産をなんとか生かせるように
　　　作り変えてます…こちらはもうすぐ完了…。
　2.FatFsのファイル読み書き先をSDカードからUSBメモリに
　　->これ結構作業量ががが
　　　こちらに関しては先人の作例も数多くあるので参考にさせてもらってます。
　　　せっかくUSB-OTGがあるのにSDカードばっか使っててもったいないですから自身
　　　の学習がてらに実装がんばります！
そういうわけでSTM32F429I-Discoveryのフル機能を駆使した作例のほうはもう少しお待ち
ください。過去のSTM32F407系の作例と完全に切り離してSTM32F429I-Discovery専用の
プロジェクトとして公開する予定です。
もSTM32F427IIT6に換装してパワー
アップさせました。実はずーーーーっとF427系のチップが出るの待っていたのです！
こっちはこっちでF407系の資産生かしてなおかつ強化する方向で遊んでいきます。
(見えづらいですが左上)
もいっこおまけ
STM32F42xxx&STM32F43xxx系をJTAGから見た場合バウンダリスキャンのTAPIDが
40x系と違うものになってるのでOpenOCDで書き込もうとするとコけます。
OpenCOD0.9.0あたりで反映されるはずです。
…ッツついに来ましたよ…！最強に強まったSTM32F4が…！
後ろに見えるSTM32F437IIT6も後日に…
は現時点のSTMマイコンの中で最強種のとそれが
サポートする64MbitのSDRAMとRGBインターフェースが利用できるTFT-LCDまで搭載
されたまさにねむいさんのために作られたようなボードです！
※正式名称は「STM32F429I-DISCO」だそうです。
はRGBインターフェースのTFT-LCDドライバとSDRAMをサポート
するFMC(FSMCからSが取れた)を持ち、最高クロック180MHzで動作するCortex-M4Fの
コアを持つマイコンです。
ついにSDRAMが…&もうヒープサイズ気にしなくていいんじゃあんちゃん
ちなみにTFT-LCDドライバのフレームバッファ用にも使われるそうです。
とりあえず電源を入れてみるとSTLink/V2が認識してemWinと呼ばれる小洒落たGUIが
走ります。凄いもんだ…基板上に実装されたTFT-LCDの解像度は240x320です。
タッチするといろいろメニューが選択できます。本来はUSBメモリ等の記憶媒体を
挿しておくようになってるみたいですね。
今は168MHzで動いてるらしいです。
一通りデモプログラムを確認したのであとはおなじみで内蔵フラッシュメモリ
のバックアップをとり(2MBあるので5分くらいかかりましたよ！) 前もって予習してい
たLEDチカチカプログラムを書き込んで一発動作を確認&
の定義をほんの少し変えるだけで事は済みました…。
お次は目玉のTFT-LCDです。ねむいさんはこっちももちろん予習済です。STM32F42x/43x系
ではUSB用SRAMの容量拡張のほかSPIやI2C等の基本となるペリフェラルも数が大幅に
増えていて更なる柔軟な回路構成が可能となっています。
それではここらへんでいつものを…このTFT-LCDのコントローラICは定番のILI9341なので
RGBインターフェースへの応用も楽勝ですね&
今回表示したのはねむいさんの頂き物の???…????じゃなくて3D絵です。
あ○ご、抜錨しま?す?ぐふふ&
↑ねむいさんが何のキャラのコスしてるのか最近分かったです…鈍い…
↑ねむいさんて艦これ(ブラウザゲー)やらないの？とよく本職してる時に尋ねら
　れますが、6年前からずっとゴルロア続けてますしに
　嵌ってる(作業的な意味で)のでさすがに他のにまで手を出す余裕がないです…。
なお、びぃぶろ君に確実に怒られると思われるえろすな個所はトリミング済みなので
安心してご鑑賞ください。
タッチパネルコントローラはi2cのです。
こちらもなのですんなりいけました！
というわけで今回はSTM32F429I-Discoveryのファーストタッチをご報告させていた
だきました。基本的な部分は初期のSTM32F4とほとんど一緒なのでF4Discoveryからの
移植はそこまで難しくないと感じました。まずはFatFsとChaNさんのファイラーを完全に
移植させます。12月上旬には私のおきぱに新しいラインアップが追加されると思います。
あっという間に(仕事上の)夏が終わってしまいました???日記上は更新してないので
夏ばてしてた様に見えるでしょうけどもじつは更なる跳躍のために私なりにいろいろ
やっていたのですよぅ！
こちらも近いうちにじっくりと???
●夏休みの工作?LPC4088
さて、円高の頃に買い込んでいた基板やチップの中で最後の大物で残っていた
に着手をはぢめました。
基板はLPC1788ですがLPC4088はほぼピンコンパチなのでそのまま乗っけられます。生
基板なので仕事や家事終わったあとに大量の部品をちまちまちまちま付け続けお盆休み
明けにようやくFatFsまで動作を確認しました。
LPC1788のときと同様に大容量のSDRAM乗っけてます。STM32系と違ってheapや
stackとしてがんがん使ってもコケないのがすばらしい！(STM32系のFSMCはerrataとして
FSMC上のSRAMをheapやstackに使うなととうとう明記されてしまいました)
LPC4088はLPC1788には存在しないSPIFIインターフェースを持ちます。しかし???
困ったことにLPC1788系と互換性を保った結果LPC4300系と違いSSPポートの互換性がなく
OpenOCDから書けないことが判明orzOpenOCDはSPIFIではなくポート互換のSSPで書いて
たんですよね????ドライバの対応はnuvotonドライバの時よりしんどそうだったので早々に
あきらめ外付けのコネクタを設けてを使って書き込みする作戦に変更しました。
SPIFIは容量を喰うFONTXファイルの置き場に使用していきます。
あと付けてないのはLCDインターフェースですがこれは私がいつも使ってるMCUバスでは
なくRGBでつなげるタイプのものを必要とするのでそれに合う液晶の調達から手を付ける
予定です。
●Kinetis K20/K10シリーズを触る
わざわざ独立の記事にするほどでもない超小ネタなのでここでさらっと紹介します。
少し前にFRDM-K20なるボードが販売されましたがこのシリーズの一番小規模のチップで
あるとをちょっと触りました。写真はK10のほうです。
K20はUSBと内蔵3.3Vレギュレータが付いてて本当にこれひとつで完結した基板も作れ
ねむいさんがこれを単品で購入した理由はOpenOCDの書き込み/デバッグ確認のため
だけに過ぎません???が、このチップ特有の機能にちょっとはまってしまいました。
、私はKL25やKL05を触りOpenOCDへの書き込み/デバッグを可能にしてきましたが、
K10/K20もコアがCortex-M4(F無し)違いでKLシリーズと同じように楽勝だろうと高を
くくってました。しかしPOR後のウォッチドッグタイマの挙動が違っていてブート直後に
即効ウォッチドッグの機能を殺しにいかないとせっかく書き込んだのにセキュリティ状態に
突入してしまい、mass-eraseして解除してからGDBからイメージをもう一回ロードしないと
デバッグできない事態になることが判明!
工場出荷時はセキュリティ状態は解除されてるらしいですがこのウォッチドッグリセットの
せいで実質セキュリティ状態になってる為STLink/V2などのMDM-APを直接叩くことが
不可能なデバッガハードウエアでは手詰まりになってしまいます???ぬぎゃー
(これFRDM-K20が国内販売されたらまたねむいさんのとこにプログラムが書けなくなった
　って質問飛んでくるんだろうなぁ????)
●EFM32シリーズもおさわり
同じくOpenOCDの書き込み確認のために単品購入したチップです。という
メーカのチップでしたが現在はSiliconLabs社に吸収されています。
Gecko(ヤモリ)のマークがチップ上に付けられたイカすデザインでCortex系のマイコンでは
超低消費電力方面に力を込めたラインナップとなっています。
ねむいさんがチラッと触った限りではCMSISライブラリがSTM32ばりに充実していてCMSIS
にどっぷりつかったねむいさんの流儀に非常に組み込みやすく最初の取っ掛かりのLチカ
作成が最速の30分で完成しました(逆に一番難儀したのはあちこちにファイルが点在して
て把握しづらく挙句の果てにKeilのサンプル中にしかCMSISヘッダファイルが無い品種も
あるKinetis???てか公式のサイトでリンク切れはまずいですよぅ)。
書き込みデバッグももちろんすんなり完了ですごい相性よかったのでメインのSTM32から
ちょっと浮気しちゃいそうです??うそですよぅうふふふ
というわけでには上記3品種の書き込みcfgファイルを追加してます。
パッチも前回から不備が見つかったものをさらに改修してますので私と同じ環境をお
持ちの方は試してみてくださいね?
???すっかりOpenOCDありきのマイコンいじりになってしまいましたが実務ではルネサ
(日記はここで途切れている)
試"す"というか試"した"結果のご報告の方が多いかも…
●STM32F437シリーズの予習
2013年4月中旬現在はまだチップ単体は手に入る時期ではないのですが去年買って放置
していたを使用して来たるSTM32F437シリーズの予習をしていました。
ただこれに付属しているTFT-LCDモジュールのタッチパネルドライバICが定番のADS7843
ではなく、I2C接続のというI/Oエキスパンダと温度計も一体化された妙に"いん
てりじぇんす"なICだったのでそれの対応に非常に苦労しました…。
↑画像は春になり発情期を迎えたいないさn
とりあえずが動かせられるようになったので同じ基板を購入した人たちは無改造
で追試できると思います(TFTLCDのドライバはILI932xを選択の事)。I2Cバスエラー対策は
まだ実装していませんので、フン詰まりになったら電源をいったん落とした後再投入
して対処してください。(やっけつ)
また今回はタッチパネルの処理の上位層も少し見直して無駄な記述をしていた箇所や
分かりづらい箇所を廃しております。たとえば、
キャリブレーション画面で青の■をしっかり押せたら…
黄色の■になる！…もちろんこれだけではありませんが細かいところも修正してます。
せっかくなので全体的にソースコードも見直してコメント等をできるだけ随所に挿入して、
プログラムの流れもつかみやすくなるよう努めるようにしました。
本来は書いた本人がプログラムの動作に関する詳しいドキュメントを書くべきなの
ですがが非常に分かりやすい解説をして下さっており、ねむいさんもいつも
参考にさせてもらっていま…あれ？
今回の修正はにあるSTM32F1,F2,L系のものを始め他社のARMマイコンのFatFs
移植例にも順次反映していきます。
●STM32F4で外部SRAMを使う
ねむいさん非常におまぬけなミスをずっと放置しておりました。
のプログラム中でターゲットボードにREDBULLを指定した場合は外部SRAMを使用できる
ようにFSMCの設定を行っていたのですが…REDBULL上ではキー入力も同時に有効にして
おりそこのGPIO設定がでたらめだったためFSMCのポートにもそれが波及し外部SRAMへの
特定のアドレスのアクセスで頻繁にHardFaultっておりましたorz
一見まともに動いているように見えたので気づくの遅れましたorzorz
今回のソースコードの見直しではぢめて気づきましたorzorzorz
というわけでそこを修正して大容量のSRAMをmalloc系関数のheap領域として使えるよう
にして、(さすがに内部SRAMと比べると非常に速度が遅いうえにマトリクス化されてい
ないのでスタック領域までは割り当てる気がありません…F4はCCMあるし)これでメモリ
サイズを気にせずに自由自在に使えるようになったー！
…と思いきや、16bitのアラインメントが乱れるようなアクセスが連続で続くとやっぱり
コケます。これはlibjpegで画像をデコードするような時に特に顕著になりこのように途中で
表示がグレーになったストール状態に、虹裏で見られるみたくなってしまいます。
↑libpngとgiflibだとこの現象一切起こらないのですが…調査はいずれまた…
また、FSMCのバスにSRAM以外に入出力容量の大きいブツ(低速でしか動作できない
一昔前のTFTLCD等)がぶら下がっているとやっぱりこけます。オシロでWRの波形を見たら
オーバーシュートしまくりです。なのでTFT-LCDも影響を与えないものをオシロの波形と
にらめっこして選ぶ必要があります。もしくはFSMCに影響を与えないSPI接続のLCDの
選択も考えてください。
ねむいさんが試行した限りでは16bit区切りになるような、たとえばVRAMとして16bitに
パックされたRGB565のデータをスタティックに確保しただけの状況下の使用では問題は
一切発生なかったのでこの先も慎重に確かめてみます。
●LPC4357全部載せ基板
RMBレートが13円のころに買っておいてよかったです&USDも99円(現在)まで
回復してますが海外のパーツ?基板漁りはひとまずお休みして買いためたブツを消化して
逝きましょう先ずはです！
(2013年01月中旬当初は国際送料込みでなんと13000円台で購入できていた超格安な代物でした。)
あっちはプログラムを格納
するフラッシュ領域が全くなく、スズメの涙ほどの内蔵SRAMか低速なSPIFI-SPIROM
から実行せざるを得ない非常に使いづらい代物でした。しかしこいつは違います！204MHz
動作でフラッシュも1MB内蔵なので使い勝手が改善されて(ると思い)ます！…しかし…
4.3inchLCD基板の接合部でみてはならないものが目に入ってしまいました…
…なんだこの隙間は…これのせいでベースの基板もひん曲がってるし…
(後日このヘッダピンを半田槽で外し新しいものにまっすぐ付け直しました)
通電すると動作確認用のサンプルプログラムが起動します。またOpenOCD用のcfgを作
っていませんがLPC4300系のフラッシュ書き込みルーチンもまだレビュー段階なので
先ずはそこから基礎を固めて試してみましょうか(逆さになった何かを無視しつつ)。
●OpenOCDをさらに使いやすく
年明けくらいからでしょうか、をSTLink/V2
から使用する際にドライバをLibUSBからではなくSTMicro提供の純正ドライバを使うように
変更できないだろうか？というご要望をちらほらいただくようになりました。
まさかとおもってをよく調べてみると、Windows向けドライバとして
WinUSBが使用されているのがわかりました。また去年行ったFT2232系FTDIデバイスの
MPSSE対応の際にWinUSB(LibUSB-1.0)用のビルドができるようになっていたのですが、
STLink/V2に関してはVersaloonと同じくLibUSB0.1系を使用するようにビルドオプション
を指定したままになっていたので純正ドライバは使用できない状態でした。
今となってはWinUSB(LibUSB-1.0)を使用しない道理は存在しないのでSTLink/V2のドラ
イバとしてWinUSBを使用するようにビルドオプションを変えて純正ドライバをそのまま利用
できるようになったバイナリを現在は提供しております。
などの純正ツールとOpenOCDがドライバの差し替えなしに利用できるように
なったのでぐっと便利になっております。
そのかわり従来のLibUSB0.1系からは使用できなくなっておりますのでご注意ください。
↑一応変更当時はトップにでかでかと告知してたので皆さん移行済みかと思います
ドライバの扱いについてちょっとまとめます。
LibUSB-1.0：WindowsにおいてはWinUSBのラッパーとして働きます。
　　　　　　ですのでLibUSB-1.0のAPIを使いたい場合インストールするドライバは
　　　　　　WinUSBとなります。WinUSBのを使用しています。
LibUSB-0.1：WindowsにおいてはLibUSB-Win32と呼ばれ、LibUSB0.1(libusb0)の
　　　　　　APIはを使用しています。
：WinUSBのエミュレーションとして働きますが、WinUSBでサポートしてない
　　　　　　アイソクロナス転送も使用可能です。また、libusb0のAPIとも互換性があるので
　　　　　　LibUSBKをインストールしておくと1.0系と0.1系APIを使うアプリがどちらも
　　　　　　ドライバの入れ替え無しに使用可能となります。
さらにFT2232系デバイスの方もZadigでインストールする際にを選択することにより
WinUSBを使うやLibUSB0.1系を使う/FlashROMなどの便利ツールが
ドライバの入れ替えなしにシームレスに利用できるようになり、低いコストと簡単な手順で
強力なデバッグ環境をそろえることが可能となっております&
●aitendoさんのanux
(←peep.usでページを保存しました)
こ ん な こ っ た ろ う と お も っ た で す よ ぅ ！ ！
そうだねチャイナリスクです…せめて全回路図くらいPDFでくだち…
来たぞー！
…って来たのはもう2週間以上前ですけど…
144PinのSTM32F4も手に入ったのでSTM32F2の時と同じく中華生基板に組んでみました。
STM32F2とF4はほとんど同じです。特にコードは上位互換があるので回路を完全に合わ
せるとF2のコードがそのまま使用できちゃったりします。まあでもさっさと
にしてしまった方が良いでしょう。
↑ということでいつものChan氏のプログラムを走らせてみました。
特筆すべきはF2系では何とか動くものの安定していなかった48MHz動作のSDIOが
F4系では非常に安定してることで、SDカードとさらに大容量/高速なデータのやり取りが
できるようになっています。ただし高速なクロックに耐えうるSDカードの選択は必須で、
Class10のカードを必ず選んでください。最近出回ってるUHS-1の奴は逆に駄目なものも
ありましたので幾つか購入して試してみてください。あと当たり前のことですが、配線の
引き回しもものすごく重要なので注意してください。
↑でたらめ書いてました。SDカードの通常モードは25MHzが使用上の上限値で
　STM32F2/F4ではUSBとの共用を考えると24MHzが実際に安定して動かせられる
　クロック上限となります。お詫びして訂正します。
んでもってさらっとお見せしたの方のいつものですが、ちゃんとした
実装にあたり、周辺にぶら下がってる回路の影響でどのように構成すべきか悩みました。
なぜならば…
SDIO : SDIO_CLKがCS43L22のSDINとかぶってるから使えない
FSMC : 肝心のnRDがCS43L22のResetに、nWRがUSBの過電流検出に被ってて(ry
　　　　その他諸々のペリフェラルが被ってて(ry
SPI3 : CS43L22がI2S3として使ってて(ryついでにI2C1も
SPI2 : MP45DT02がI2S2とし(ry
SPI1 : LIS302DLがSPI1(ry
まぢでひっぺがしたろかと思いましたが先に書いた通りSTM32F407ZGTが手に入った
のでSTM32+SDIO+FATFS+FSMCの構成はこっちに実装してDiscoveryの方は既存のペリフェラル
と何とか共存する道を選んでみました。
てわけで妥協したのが以下のSTM32+MMC+FATFS+SPI-LCDのプラン…。
SDカード　: SPI1(LIS302DL(SPI通信)と共用)
TFT液晶　: SPI2(MP45DT02(I2S通信)と排他)
　　　　　　※STM32F4DiscoveryではSPITFT液晶のみ対応
その他　 : CS43L22は丸々残す！
　　　　　　UARTはUART2(TX:PA2 RX:PA3)
SDカードとSPITFT液晶はもちろんDMA化してあります。
TFT液晶がシリアルしか使えない上にMOSIがI2Sの入力とかぶってしまうのでMP45DT02
とは排他になっていますが、必要な人はGPIOによるソフトSPI(超遅いですが)で逃げても
よいと思います。私のLCD表示ドライバは潰しが効くようにかなり柔軟にデバイス依存の
部分を作り込んであります。またSTM32F1系ではペリフェラルはひとかたまり単位でしか
リマップできない構成でしたが、F2系以降はピン単位で柔軟なリマップができるように
なったのでみなさんもデータシートとにらめっこして工夫してみてください。
とりあえずSTM32F4 Discovery上でこの構成でハード改造を行わずに音楽再生はかろう
じてできるでしょうか。音再生関係の作り込みはこれからなのでがんばってみます！
てわけでいつものコードでSDカードの読み出し速度比較を行ってみました。
使用したカードはClass10が策定される前に販売されたです。
STM32F4Discovery上で組んだFatFsは先に書いた通りの構成ですが、SPI1は42MHz
まで叩きだせるので読み出し速度もめっちゃ速いです！(注：SDカードは選びます)
音楽再生程度ならもう十分な早さですね&今回の実装に際してMMCのSTM32用
ドライバも移植性をかなり高めた作りにしてみました(もちろんDMA化も)!
ちなみにDMA化に際する注意事項ですが、前回も言及していますが、CCM領域をDMAの
読み書き先として利用することは一切できません！STM32F4系でCCM領域を高速な
スタック領域として使用する前提でF2系から移植を考えた場合、既存のプログラムがauto変数
をDMAの読み書き先として定義されていると特定困難な不具合に悩まされる可能性があ
りますのでよく吟味してください。
お次は中華生基板(STM32F407ZGT6)で組んだSDIOの読み出しスピードです。
上にも書いていますが、F2系ではコケまくって全く安定してなかった48MHzのクロック
でも安定してアクセスができるようになり、20MByte/Sec以上のすさまじいスピードで
読み出しが可能になりました&ちなみにこの基板上ではFSMCもDMA化してます！
バグ出しもほとんど終わり、最低限のドキュメントもそろいましたのでSTM32F4 Discovery
と中華基板対応のを公開します。makeファイル内の定義でSTM32F4Discoveryと
中華生基板のビルドを切り替えることができます。その他細かい部分のノウハウは口で説明す
るよりソース見てもらった方が分かると思います。だから誰か早くSTM32F4Discovery
mp3プレーヤー作ってくだち！！
あ、お伝え忘れてました。今回の公開に当たってと、そして
最近この検索ワードでアクセスが急増中の向けのFatFs+液晶表示プロ
グラムも大幅に更新しておきました
んでもってもSTM32F4xx用を追加しておきましたよぅ
つい最近複数の方からメールでご指摘いただきましたが、私はとは関係ありません。
私の今回の記事からいくつかの文章をコピペしているようですが、私が後日誤りに
気付いて修正した内容は修正されずにそのままになっているようなので注意してください。
今回は前回述べたとおり192kByteに増強された内蔵SRAMをどのように使うかを決定し、
お約束の標準関数の使用やFPUを用いた浮動小数点の計算をSTM32F4 Discovery
上で実践してみます。
STM32F4系は192kByteのSRAMを持っていますが、実際は112kByte,16kByte,64kByte
の3ブロックに分かれています。後で図示しますが、112kByte分はAHBバスマトリクスに
接続された汎用SRAMで,16kByte分は同じくAHBバスマトリクスに接続されているものの
112kByte分のSRAMと同時に読み書きができるように(主にEtherNetMAC&USB-OTG(HS)
用に特化されているようです)なっています。アドレスは連続しているのでEthernetや
USB-OTG(HS)を使うつもりがない人は128kByte分まるまる汎用SRAMとして使用する
ことが出来ます。
その他細かい制約があるので各自データシートやマニュアルを参照のこと(丸投げ！)。
もうひとつの64kByte分はCore-Coupled Memory(CCM)と呼ばれ、Cortex-M4Fのコアに直
接接続されています。このSRAM領域はAHBバスマトリクス上にはなく、マニュアルを読
む限りではDMAの読み書き先としてこの領域を使用できないようです。
(追：実際に試しましたがHardFaultになったりDMAが完了しなかったりで、
　　　　　　　やはりDMA用のメモリとして使用できませんでした）
また、128kByte分の汎用SRAMもSTM32F4のコアクロックと同様の168MHzでアクセスできる
ので俗に言うとしての速度的優位差もほとんどないでしょう。
以上の点を踏まえて、STM32F4系でつぶしが利くようにねむいさんはSRAMの構成を下図
のようにしてみました。
64kByteもある広大なスタック領域を君はどうつかうのか！？
注：CCM領域はDMAできません！！大事なことだから２度言います！！
この構想をリンカスクリプトに落とすと下図のような感じです。
この下にも長-く各セクションの定義が続きますが省略。
この構成で前回のTFT-LCDの表示テストも改めてクリア?またprintf系の標準関数も
UARTにリターゲットして動作を確認しました。
次にFPUを使って浮動小数点の演算のテストに取り掛かりました。
Cortex-M4Fは単精度の浮動小数点ユニットを持っています。GCCコンパイラからこの機能
を使うためには浮動小数点命令に落とし込むようにフラグを与えてあげないといけません。
具体的にどういうフラグを与えるかについては
氏の情報を元にでは以下の箇所の変更で浮動小数点命令に切り替わりました。
-msoft-float("-mfloat-abi=soft"と同じ意味)
-mfloat-abi=softfp
-mfpu=fpv4-sp-d16
-mfpu=fpv4-sp-d16は必須です。これが無いと倍精度の命令を使ってしまい、実行
したとたんにHardFaultになってしまいます。
ちなみに-mfloat-abi=※※※※　の意味はそれぞれ以下のように表されます。
-mfloat-abi=soft　　：浮動小数点の演算に整数命令のみで構成された浮動小数
　　　　　　　　　　　　　　　点演算ライブラリ(soft-float)を使う。
-mfloat-abi=softfp　：浮動小数点の演算に浮動小数点演算命令を使うが、floatを
　　　　　　　　　　　　　　　引数にする関数の呼び出し規約はsoft-floatと同じく汎用
　　　　　　　　　　　　　　　レジスタを使って値を渡す(ソフトウエア?リンケージ)。
-mfloat-abi=hard　　：浮動小数点の演算に浮動小数点演算命令を使い、floatを
　　　　　　　　　　　　　　　引数にする関数は浮動小数点レジスタを使って値を渡す。
酔漢氏のページでは"-mfloat-abi=hard"となっていました(GCC4.5.xからこのオプショ
ンが利用可能)が、にある標準関数等のラ
イブラリはsoft-floatでビルドされているため、標準関数を絡めるとリンク時に引数渡し
の不整合がおきてエラーになります。これを回避するためにはCodebenchLite版のビルド済
ライブラリを使わない設定(-nostdlibオプションを付ける)を付与し、同じ機能を持つライブ
ラリを一から"-mfloat-abi=hard"でビルドしなおさなければなりません。
というわけでいちいちビルドするのめどいので以後は"-mfloat-abi=softfp"で。
なら"-mfloat-abi=hard"が使用可能です！！
これでFPUの命令を含むプログラムがビルドできるようになりましためでたしめでたし
???と言いたい と こ ろ だ が ！
ここも嵌ると思うので記しておきます。Cortex-M4Fの仕様によるとFPUは浮動小数点命令
が行われる前に(つまり起動時)に
STM32F4xxのサンプルではsystem_stm32f4xx.cのSystemInit()の最初で実行されている
ものもありますが、テンプレートからsystem_stm32f4xx.cを生成するとこの記述が欠け
ているのでほとんどの場合は自分で追加しないといけません。
実際にコンパイルオプションを変えて浮動小数点演算の箇所のアセンブラリストを
比較してみました。を使用しています。
●-mfloat-abi=soft
FPUを一切使用しない場合です。FPUのレジスタは一切使用されず、また浮動小数点
演算ルーチンが呼ばれています。
●-mfloat-abi=softfp -mfpu=fpv4-sp-d16
FPUを使用する場合(SoftFP)です。関数の値は汎用レジスタで渡されています。
●-mfloat-abi=hard -mfpu=fpv4-sp-d16
FPUを使用する場合(HardFP)です。関数の値もFPUレジスタで渡されています。
printf関数は暗黙の型変換によってfloat値を渡してもdouble型に強制変換されます。
単精度のFPUしかもたないSTM32F4ではdouble型に変換するための__aeabi_f2dルーチンが
必ず挿入されます。
ってわけでこれでほぼ完全にCortex-M4Fとして開発を行う下地が整いました！
現在はSDカードとSPI接続のTFT-LCDとUARTをつなげていつものをこしらえるところまで
進みました。の回路構成の都合で、SDIOとFSMCが使用できない
のでSDカードもTFTLCDもSPI接続です。はやくこいこいSTM32F407ZGT6!
あ、そうそう、Chan氏のも組み込ませてもらってます。
4月から本当に少しずつ使い始めたSTM32F207ですが、公式の方もやっとこ資料が出そ
ろってきてだいぶ扱い方が理解できるようになってきました。
とりあえず一つの通過点ということでいつものchan氏のLPC2388向けのFatFs+OLED表
示プログラムの移植をしました(ほとんど原形とどめてませんが…)。いろいろやってきた
中でjpegデコーダ乗せたり(デコードが1.8倍速くなってる!)FONTX2の使い方覚えたりで
今回はM+フォント(FONTX2)を使いFilerの日本語表示を可能にしてみました。
↑やっとここまでこれた…
なんと当のchan氏も6/11更新のLPC2368向けFatFsサンプルでFilerの日本語化をされていた
ようで今度はこちらを元にしておりぢなるなFilerの構想を練っていきたいと思います。
そうそう、気になるFatFsの読み取り速度ですが、SDIOが出せる最高速度の48MHzまで
クロックを引き上げた場合、最大21MB/Secを叩き出すことができました！
↑てかいつも比較に使ってるATP製のmicroSDカードもすごい…class6なのに。
しかし、48MHz動作は8bitモードしか保証していない(rm0033.pdfより)のでsdカードで
使うときは実際は24MHzで動かすことになるのですが…それでも十分早いですね。
おきばにはすでに上記で紹介したを公開しています。
これはというボードの回路互換となっています。
ねむいさんSTM32F2向けに備えてかなり前にtaobaoで部品未実装の基板"だけ"超安価で
購入していました。てわけでホントに最低限のことしかできないのですがF2を試すに当た
ってはこっちの方が幾分都合がよいのです。
ここからどんどん付け足していきます
またmakeファイル内の定義の書き換えによって以前使っていたSTM32F207VGT6向けにも
対応できます。STM32F207VGT6の方はの回路互換です。
両者に共通するのはFSMCのピンが引き出されていて出来合いのLCDボードが直結できる
という点に尽きます(←TFT-LCDマニアな人には超重要なファクター)。
まぁで1xx系とのピンの処理方法の違いとかとか詳しく解説されていますん
で日頃ねむいさんのぶろぐ読んでる人なら簡単に乗せ換え可能でしょう。
あと開発環境のtipsとして、前回も説明しましたがCodeSourceryG++等のポピュラーな
GCC開発環境はそのまま使用できます。Cortex-M3対応なら何でもよいでしょう。
問題は書き込み環境ですが…現在はシステムメモリ上のブートローダから使用で
きるフリーのツールがまだ整わず、よってJTAG/SWDからしか書き込む方法がありません。
幸いOpenOCDの0.5.x系とVersaloonはすでにSTM32F2系のフラッシュの書き込みに対応し
ています。私もフラッシュ書き込み用のを公開していますのでJTAGな
いしはSWDでつなげられるアダプタ持ってる人は開発に際して問題はないです。
最後に、次回予定のLPC2388関連の記事で詳しく解説しますが、64bit版Windows7環境下
のビルドにもmakefileの設定で対応できるようにしてあります。副業先のポジションと
PC環境がガラッと変わったのでねむいさんも必要に迫られてというのもあったりしてます。
ねむいさんとうとうすっぴんの従業員Bから晴れてエンジニアにじょぶちぇんぢ！
(やってること相変わらず雑用だが)
aitendoさんからついにあのが販売されましたね。
です。これ使ったシールドとかも海外ではもうすでに販売されてい
ますが、を開発した時の生基板を利用して無理やり乗っけてみました！
次はこれで行こう。
そしてaitendoさんからはもう一つが発売されま
した。これ確かtaobaoで捨て値で売られてて私も10枚くらいまとめて買って動かして
(飽きて放置)してました。これ8/16bit選択できるのは良いのですが、ピン間隔が0.7mm
なので手配線ではきつい人がいるかもしれないですね。専用の変換ボード出るの待った
方が良いと思います。どちらかというととかとかの方がピン間広
いし8bit固定で小難しいこと考えなくて良くてよいと思います。思いますよぅ！！(重文)
↑AS021350DをXMEGAで動かしてみたところ。
実はATXMEGA128A1にもchanさんのFilerを日本語対応して移植に成功してます。
しかしXMEGAはFatFsを結局DMA化できないまま白旗降ってクローズします…。
てなわけで前回の記事からはや一ヶ月、手探り状態でいろいろ進めているうちにST公
式でやっとこが出たりの購入
合戦に勝利したもののまったく火入れしてなかったりを購(ryたり今後を見越
してや購入したりそうこうしてるうちにSTM32F2シリーズもようになってたりする昨今、いかがお過ごしでしょうか？
震災を境に身の回りの状況が一変してしまいましたが、ねむいさんはいないさんをひ
ざに乗せてくんかくんかしつつできることから着々と取り組んでいく所存でございます。
勘違いや無知無学が祟って時間を食ってしまいましたが、STM32F207VGT6でSDIOと
Chan氏謹製のFatFsを連結させて安定動作できるまでになりました。SDIOはもちろん
DMAを使って高速に転送可能です&以前のSTM32F103VET6のものと同じ条件でRead
の速度を比べると若干の向上が得られました！
SDカードだとSDIOは25MHzまでしか出なかったり(MAX48MHz)カード自身の転送速度
もボトルネックになってるとは思いますが、小規模のマイコンでもこんだけ早かったら御
の字ですよね?。
さらに前回ちょろっと紹介しましたが480x272pixelの4.3inchTFT-LCDのドライバも組
み込んで"いつもの"をやってみました。こちらもFSMC使った高速転送です！
ねむいさんへたれだからSSD1963っていうコントローラつきの液晶モジュール基板使っ
てますが???。
↑タッチパネル入力にももちろん対応。
↑再びぽぽぽーん
STM32F2になってフラッシュも1MByteまで増えたことだし、フォントも扱えるように
なって機は熟したからそろそろ私もChan氏のファイラーは卒業しておりぢなるなファ
イラーを作ろうかな、と。
んでもってSDIOとFSMCの高速な転送を利用して動画再生も試みました。Chan氏のLPC2388
向けの動作再生ルーチンをチューンアップしないでまんま利用してもQVGAサイズで29.97fps
な動画も余裕で再生できたので相当"ぱわふりゃーなので余裕"なの確認できました。やっけ
つだけど一番乗りだからどっかにアップしたいな?
???と思ってるてるうちにどこかの誰かが私と同じようにSTM32F2シリーズのMCUを使った
らしい作例で扱ってる動画の内容とかアップロード先が虹裏
メイド的に一発アウトなヤバい代物なのは置いといて動画が暗くて荒くて何をしたいのか
分からないとかもういい加減にしろって感じだよ(棒読みで)
とりあえず次の一手としてはオリジナルなファイラーの実装に着手しつつ先日がた老氏
FreeRTOSがらみの質問をもらった機会にご無沙汰だったRTOSのおべんきょもふたたび
進めていくつもりです(BeagleBoard-xMとDE0-Nanoから目を逸らしながら)。
て言うかこっからが本題です！！！！
LatticeのispVMがいつの間にかFT2232デバイスに対応していた件
いままでsvfとかUrJTAGとか使って手間のかかる方法しかできなかったのが嘘のよう
です！もうこれでLPTポート無くてもいいです！
↑ふつーに認識
↑そしてふつーに書き込み
JTAGkey2Cloneで使うためにはJTAGのOEを常時イネーブルにしておく必要があります。
※ispVMに対応するようにスルーモードをつけて回路図差し替えときます。
もちろん外付けSPI-ROMにも書き込むことができます&ispVMは多種のSPI-ROMに
対応しているわけですが???つまりこれはLatticeのデバイスがJTAGで繋がってれば
USB接続のSPI-ROMライタが安価にかつ確実に構築できるというものすごいことで
まさに神対応なわけなのです！！これでマザボのBIOSいくらすっ飛ばして怖くない！
xilinxさんやalteraさんもこういうの見習ったら???????絶対ありえないですが…
去年くらいに発表されて以来トンと音沙汰なかったですけどES品ですがやっっと一般
ユーザの手にもわたり始めましたシリーズ。
従来のSTM32と違う部分は最大動作周波数が120MHzまで増加したのとメモリ保護ユ
ニットがついたのとフラッシュアクセラレータが(やっと)強化されて120MHzまでノーウエ
イトで動作可能となったのとその他諸々のペリフェラル機能が追加された点しょうか。
ライバルに相当するLPC1769も似たような機能をすでに備えているのでいまさら目新し
ものではなくなってしまいましたがー…。あ、そうそうフラッシュ容量も1MBまで増加
してます。低速な外付けのメモリとか用意しないでも結構でかいサイズのフォントもぶ
ち込めるのがうれしいです。
てわけでさっそく使用してみましたが、STM32F107VCT6とは一部ピンの定義が違います。
そこだけ注意してのmigration guideを参考に配線を変更しました。
使用したボードは元はSTM32F103VET6が乗っかっていたebayで格安で購入した基板です。
STM32F207からはFSMCが使えるので(←これ重要!)あえてこのボードを選びました。
次に開発環境ですが、もちろん従来から使ってきたCodesourceryG++を使用します。
しかしまだSTマイクロの公式サイトではF-2デバイス用のペリフェラルライブラリなんぞは
用意されていない(10x系とはレジスタ定義は全く違う)のでKEILのサンプルに含まれてい
るF-2用のbeta版に当たるV0.01と記された定義ファイルのみと上記のごく簡単なサンプル
コードを頼りに手探りで進めていきました。
ちなみにフラッシュの書き込みもF-2デバイスは手順が違うようでOpenOCDではSTM32F1xx
系とは別に用意されていました。後述しますがOpenOCDはSTM32F103xF/G系の512kByte
以上のフラッシュを持つ種への書き込みも対応しています…これはありがたい。
書き込み時はこんな感じです。
ぽぽぽぽーんと動かしてみたところです。480x272も一瞬だわ…流石120MHzとFSMC…。
そして国内のホビーユーザーでF-2のデバイス動かした人間としては今度こそねむい
さんが初めての人ですね！一番乗り！
次はSDIOに進みたいところですが、上で述べたとおりライブラリが無い状態なので手
探りで進むことになりそうです。まぁ10x系のものを参考にしたら何とかなるでしょう。
実はここまで動かすレベルになるのにかなり手間かかった…何せ資料が全くない…。
2xx系はまだまだですが、512kByte以上のフラッシュ容量をもつ10x系のSTM32マイコンは
すでにdigikeyやmouserで購入可能です。ねむいさんも速効ひとつ購入してしまった。
1年くらい前にtaobaoでSTM32用の格安の空基板買っといたのがやっとこ日の目を見れま
したのでこっちにさっそく装着。単にフラッシュ容量が増えただけなので従来のライブ
ラリがそのまま転用できて動作の確認が非常にラクです&
お約束カワウソ。
もうすっかり使いこなせて当然…なはずのカラーグラフィックLCDのつもりでしたが結構
苦戦しました…。STM32Primer2ではLCDの結線はSTM32のFSMCを使用したバス接続
となっていて、CircleOSもこれを利用してLCDの操作を行っています。LCDモジュールの
コントローラICはST7732。以前のTFTモジュールやi2c液晶なんかとおなじメーカの奴です。
ST7735の時と同じ風にやったら楽勝だろうと考えていたらモジュール内部で完結して
いるICのモード設定ピンの関係に気づくまでどうしても表示がうまくいかなくてうｎうｎ唸って
いました。コントローラICが同じもしくは同等品であってもモジュール全体でみると初期化?
制御の仕方とか微妙に違うってことを思い知りました(いまさらか)。
上記のことさえ注意しておけば後は特に気にすることなくすんなりと一枚絵の表示まで
こぎつけました。128x160フルに使って表示できます。
※性的描写があるので小さく表示
↑ごめん…またいなちゃんなんだ…もう許してもらおうとも思ってはいない
　…でもやめられない&
今回はWindowsで普通に作成できる24bitのビットマップをそのままC言語ヘッダファイル
に変換して直接読み込んでいます(内部で16bitに変換してます)。FatFsが次に控えて
いるのでそれを意識しています。
後気づいたことを一つ…
見ていると拡張コネクタから出ているi2cやcanがFSMCからの干渉
でうまく動かないなどのことが議論されています。回路図見た感じではFSMCのバスは外
には手軽に出せないし現状LCD専用状態だしで、あんましFSMC使うメリットが見当たら
ないように気がしますが私の検証用のプログラムはCircleOSのを真似てFSMC使っています。
はSystickタイマを利用したスイッチ入力で電源の制御を行いました。しかし
電源を付けっぱなしにしているとどんどん電力が消費され、ついには3.5Vを切って
しまいます。（については他の専門に解説されて
いる方たちにうっちゃる(うｎ？)として、）実際3.5V以下になると急速に電圧が低
下していってしまうという特性があるので3.5Vできっちり止めなければなりません。
STM32Primer2はリチウムイオン電池の電圧低下をハードウエアで監視する機構がな
いのでSTM32に内蔵されたADCを利用してソフト的に監視し、3.5V以下になったら強
制的にシャットダウンする必要があります。今回はCircleOSのDMAを利用したADCと
過去の自分のコードを利用して電源監視ルーチンを作りました。
電源監視ルーチンはCircleOSで行っている方法とほぼ一緒で、1Secごとに移動平均
化されたVbatの値がmV)になりさらにそれが15秒間連続した時にSHUTDOUN
信号を出してFETスイッチをOFFにするというものです。
そしてこの機構が実際に機能しているかどうかを確認するためにモニタリングする
必要がありますが、この検証には背面の拡張コネクタから出ているUART2を利用し
ました。このUART2のルーチンも自分の過去の(ry)でprintfにリダイレクトさせるよ
うにしています。
以前107系等で組んでいた時はUART-Txだけは割り込みを使用せず、ポーリングで回し
ていました。今回UART-Txも割り込み方式に変えています。それで初めて気づいた
のですがprintf等使用時に高速にバッファに転写すると早すぎて割り込み処理が
間に合わず、文字列が反転した状態で出てきてしまいましたので少し細工を行い安
定して文字列を送信できるようにしました。
↑大活躍の極小USB-Serial変換(画像右上)。
以上の条件下(72MHz駆動,LCDバックライトは未制御のため全点灯)でUART2から文字
列を排出した状態で電源電圧低下を感知して自動で切れるまでモニタリングを行い
上図の結果のとおり、満充電4.1Vから徐々に電圧が落ちて行って3.5Vに差し掛かっ
たところでFETスイッチが切れています。また3.6V付近から電圧の落ち込みが急速に
早くなっているのが分かりますね。自働強制シャットダウンまで約4時間まるまる
かかりましたがCPUは最高速度,LCDのバックライトも未制御の最大輝度ですのかな
り電流喰っている状態です。この二つを制御できたらさらに持つでしょうね。
次回はFSMCを使ったLCDの制御に入ります。
FSMCは全く使用したことがないので少々手こずりそうです。
August 2015
SunMonTueWedThuFriSat
9101112131415
16171819202122
23242526272829
連絡?質問は↑のリンクに
STM32F7を使ってみる4 -CPUキャッシュとDMAを考慮する-=>
STM32F7を使ってみる4 -CPUキャッシュとDMAを考慮する-=>
STM32F7を使ってみる4 -CPUキャッシュとDMAを考慮する-=>
STM32F7はぢめました=>
STM32F7はぢめました=>
LPC1114を使ってみる3=>
STM32F4シリーズを使ってみる13 - FatFsとSDカード再考その2(SDIO基本編) -=>
LPC1114を使ってみる3=>
STM32F4シリーズを使ってみる13 - FatFsとSDカード再考その2(SDIO基本編) -=>
STM32F4シリーズを使ってみる13 - FatFsとSDカード再考その2(SDIO基本編) -=>}