STM32H5を使ってみる6 -秋月販売記念!SDMMCとFatFsでSDカードを使う-

秋月さんからついにNUCLEO-H563ZIが販売となりました！！！
これで皆様も気軽にSTM32H5をいじることができるでしょう〜！

ちなみにSTM32H5に対応したOpenOCDはねむいさんのぶろぐで公開
しておりますのでどしどしご利用ください！！！！
そうだね宣伝だね！！

あ、それと買った人チップリビジョンちゃんと確認してくださいね…
Zならはずれです…


●STM32H5のSDMMC
そんなわけで今回はSTM32H5のSDMMC機能を利用してFatFsを移植し
SDカードやMMC/eMMCからデータの読み書きを行うところまでを
紹介します。


STM32H5のSDMMCにはSTM32H7と同じくIDMAというGPDMAから独立した
DMAが存在しており、GPDMAと干渉することなく運用が可能です。


また、STM32H5は外部メモリ(FSMC/OCTO-SPI)にしかDキャッシュが
かかわってこないためキャッシュコントロールの面倒さもありません。

●STM32H5では公式にFatFsの移植例がないが…
STM32H5以降はMicrosoft Azure RTOSに入れ込んでおりFatFsではなく
FILEXなるソフトウエアライブラリに置き変わっておりました。

ねむいさんは慣れ親しんだFatFs以外の選択肢はないのでFILEXはガン
無視のザ・シカトで移植に挑みました。


移植についてですがSTM32F7のころから慣れ親しんだいわば"枯れた"
ペリフェラルなのでHALの構造も酷似しているためSTM32H7やSTM32L5の
移植例からI/Oとクロック設定以外はほぼスライド移植で簡単にできて
しまいました！

f_readの結合関数SD_read()はこんな感じです。

DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_OK;

    uint32_t timer = SysTick->VAL + SD_DATATIMEOUT;



    /* first ensure the SDCard is ready for a new operation */

    while((SD_GetCardState() == SD_TRANSFER_BUSY))

    {

		if(timer < SysTick->VAL)

		return RES_NOTRDY;

    }



#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)



	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count ; secNum++){



			if(SD_ReadBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1)!= MSD_OK)

			{

				MSG_PRINTF("Read error on unaligned buffer¥n");

				res = RES_ERROR;

			}



			memcpy(buff+secNum*SECTOR_SIZE, dmabuf, SECTOR_SIZE);

		}

	} else {

		/* Aligned Buffer Address Case (Faster) */

		if(SD_ReadBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Read error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_ReadBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Read error on polling¥n");

		res = RES_ERROR;

	}

#endif

	return res;

}


f_writeの結合関数SD_write()はこんな感じです。
DRESULT SD_write(BYTE lun, const BYTE *buff, DWORD sector, UINT count)

{

	DRESULT res = RES_ERROR;

    uint32_t timer;





#if defined(SD_DMA_MODE) && !defined(SD_POLLING_MODE)

	if((uintptr_t)buff & 0x3)	/* Check 4Byte Alignment */

	{	/* Unaligned Buffer Address Case (Slower) */

		for (unsigned int secNum = 0; secNum < count; secNum++){



			memcpy(dmabuf, buff+(SECTOR_SIZE*secNum), SECTOR_SIZE);



			if(SD_WriteBlocks_DMA((uint32_t*)dmabuf, (uint32_t)(sector+secNum), 1) != MSD_OK)

			{

				MSG_PRINTF("Write error on unaligned buffer¥n");

				res = RES_ERROR;

			}

		}

	} else {

		if(SD_WriteBlocks_DMA((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

		{

			MSG_PRINTF("Write error on DMA¥n");

			res = RES_ERROR;

		}

	}

#else

	if(SD_WriteBlocks((uint32_t*)buff, (uint32_t)sector, count) != MSD_OK)

	{

		MSG_PRINTF("Write error on polling¥n");

		res = RES_ERROR;

	}



#endif



	/* ensure the SDCard is ready for a next operation */

	timer = SysTick->VAL + SD_DATATIMEOUT;

	res = RES_ERROR; /* Timeout */

	/* block until SDIO IP is ready or a timeout occur */

	while(timer > SysTick->VAL)

	{

		if(SD_GetCardState() == SD_TRANSFER_OK)

		{

			res = RES_OK;

			break;

		}

	}



	return res;

}

キャッシュコントロールがないのですっきりですね。
全体的なソースの詳細についてはねむいさんのSTM32H5プロジェクト内の
下記ディレクトリのファイルを参照してください。
./lib/ff/sdmmc_stm32h5.c
./lib/ff/sdmmc_stm32h5.h


●直線リードのパフォーマンスはどんな感じか
STM32H5の最大クロックは250MHz取れるのでSDMMCのクロック周波数も
250/5=50MHzとハイスピードの規格いっぱいの50MHzでぶん回すことが
可能です。

直線の読み出しスピードは19MBytes/Sec出てますね。
こんだけあれば十分でしょう。


ちなみにeMMCでは3.3VでDDRモードに対応しており、STM32H5のSDMMCも
DDRに対応しているのでSDカードを超えた早い読み出しが可能です！！

●SMART取得機能も搭載

ねむいさんはSMARTが取れる産業用/工業用SDカードが大好きですが
STM32H5でももちろんSMARTの取得を可能としてます！
試される際は上記のコードをコメントアウトしてくださいね〜

SMART対応のSDカードについては下記記事もご参照ください！
・DELKIN製SDカード
・TRANSCEND製microSDカード



そんなわけでかなりやっけつ気味にSTM32H5へのSDMMCを使ったFatFs
の移植を紹介しましたがそれらを組み込んだ総合的な成果物は昨年
からすでにおきぱで公開しておりますのでどしどし参考にしてください！

WVGAな解像度で容量性タッチパネルなTFT-LCDモジュールを動かすその2

どこへ行っていたンだッ！カンガルー先輩ッッ！！
俺達は君を待っていたッッッ！！

なんとめでたい･･･いつの間にかトラ技にカンガルー先輩が帰って来てくれて
ましたよぅ！また暴れまわろうＺＥ☆
めでたしめでたし♥


















以下はおまけです。






前回のWVGA液晶の紹介の際にコメント欄で早々にネタバレされてしまい、おまけに
六甲全山縦走路の攻略とかなにやらでサボっていた隙に章さんに先を越されて
しまいましたが480x800をさらに越える480x854という膨大なサイズを持ちつつ容量性
タッチパネルを当たり前のように持つ5inchなTFT-LCDモジュールを4ヶ月くらい
以上前に入手して動作せしめておりますので紹介させていただきます。



前回モジュールとの大きさ比較です。4.3inchでもでかいと感じてましたが5inchの
爆☆発☆的な存在感には到底及びませんね〜♥
TFTのコントローラICはILI9806Gとなります。

ここでいきなりですが前回と同じ注意ですが大解像度の液晶モジュールでは
コントローラIC内のフレームバッファ用RAM容量の節約のために本来必要な量の
半分に削られているHalf-RAMモデルのコントローラICが存在します。

大きい解像度だとマイコンとの接続もSPIとかFSMC等のi8080スタイルのMCUバスに
よる接続よりもRGBインターフェースで繋げたほうが効率が良くなるため、少し
でもコストを下げるためにこのような品種が存在しているかとおもわれます。

ちなみにHalf-RAMモデルのコントローラは偶数アドレスしか指定できず、奇数
アドレスを指定しても無効になるので意図した座標にドットを上手く打つことが
出来ず表示がぼろぼろに崩れます(偶数アドレスだけを指定する使いかたならOk)。

ですから私にとっては私のいつものとはものすごく相性が悪く、単なる地雷に
ほかなりませんのでHalf-RAMモデルのコントローラICが乗ったTFT-LCDの購入は
極力避けております。
以下に私がうっかり購入してウボァーした品種を列挙します。

D51E5TA7601
->これは320x480のHVGAなTFT-LCDで中華通販で良く見かけるのでご注意ください。
OTM8012A
->これはWVGAなTFT-LCDコントローラではポピュラーなOTM8009AのHalf-RAM版
　です。OTM8009Aとくらべてあまり遭遇しないので多分大丈夫でしょう。
ILI9806H
ｰ>これは前出のILI9806Gとものすごく間違えやすいですからご注意ください！
　これも中華通販で良く出回っています。うっかり買ってしまうとｱｳﾂです！


話を戻しましょう。動かし方は初期化の呪文を唱えた後は有名なILI9341たちと同じ
ようにMIPI DisplayCommandSetに倣って0x2A,0x2Bでレクタングルを指定したら
0x2Cでデータを送信するというお決まりのパターンです。

そしてこのモジュールではIMxが外に出ていてデータビット幅とかも変更可能です。
ここまで解像度でかくなるとSTM32F4のFSMCでもきついはずなのでなるべく
デフォルトの16bit幅で使うようにしましょ。



もはや説明不要のFatFsとSDカードの動作試験も兼ねたいつもの。



480x854もの広大なサイズなのでいないさんの表示もらくらくです。
前回と比べて54ドット分ちょっと足先が長めに見えているのが分かると思います。
これだけでかい画面を十分に光らせるためバックライト用のLEDの電力消費が著しく、
モジュール全体で常に100mA以上喰うので3.3Vの電源供給は十分に行ってください。


さらに液晶自身の発色もかなり良くなっていてご覧のとおりいないさんの美しい
肌が青映りせず鮮やかに表示されています♥
有機ELとはなんだったのか…




液晶そのものの話はこの辺にしてお次はタッチパネル部分のお話です。
このモジュールは抵抗膜式タッチパネルと容量性タッチパネルの両方が選べます。
もちろんねむいさんは容量製タッチパネルのモデルを購入しましたが前回の物とは
かなり勝手が違い苦戦しました。このモジュールに使用されているCTPコントローラ
ICはFocaltech社のFT5336GQQという相互容量方式の品種です。

そう、こいつはSTM32F746G-Discoveryに乗っていた奴と同じなのです！あのときは
STマイクロ提供のBSPに頼りっぱなしでした。尤も前回でSPLでI2C接続のCTPコント
ローラを叩くためのルーチンをこさえて居たのでこれも問題ないだろうと思って
いたらなんと画面に触った時だけ変化があるINT出力の挙動がまったく違っていて
入力がまったく受け付けられていない状態となっていやがりました。


↑画面をタッチした時のINT出力波形(前回モジュール)

↑画面をタッチした時のINT出力波形(今回モジュール)

しかも今回のは内部でIOVDDが1.8Vにされているのか1.8Vしか出ていません！
(ていうか3.3Vでプルアップしてるのに1.8Vとか出力ODじゃ無いのかYO!)

一応STM32の+3.3V動作時のハイレベルのスレッショルドは切っているので電位の
問題ではなく処理の問題だと判断し、100mSec単位のポーリングで行っていたINT
の処理を割り込みに変えたりあーだこーだやっていましたが思ったように
座標データをとることがなんでか出来ませんでした。

結局100mSec単位のポーリングでSTM32の外部割込みのフラグを見てデータを取り
込むことで従来どおりの操作感覚を取り戻すことが出来ました。
EXTIだけ有効にしてNVICの設定は行わず割り込みベクタそのものに飛ばさないのが
ミソです。毎回割り込み処理に飛ばしているとタッチパネルに触ってる間ずっと
割り込みが発生することになり他の処理がまったく出来なくなっちゃいますので。
ねむいさんのいつもののtouch_if_basis.cやtouch_if.cを見ていただいたら私の
あがきの跡が分かるかと思います。

あとねむいさんが想定したY軸の座標が上下さかさまだったのでこれも前回
モジュールにあわせるようにしています。もしかして気付いてた方もいたかと
思いますが6月の終りにはすでにコードに仕込んでおりました。

ちなみにFT5336GQQのデバイスIDは0x51だそうです。


5inchは良い。心が洗われるね。

こんなわけで6月の終りくらいに購入したモジュールをいまさら紹介するハメに
なってしまいましたがSTM32のFSMCで賄うことが出来る中では実寸や解像度的に
今度こそ！
これが最強最後のTFT-LCDモジュールである！と言う事が出来ると思います！！
たぶん来年あたりも同じこと言ってるかも知れませんがー！

STM32F4版Nucleo(Nucleo F401RE)を使ってドットマトリクスI2C液晶を動かす


買ってしまった…
でもこのぶろぐの運営上F4版Nucleoは避けては通れないので新しい時代
(mbed全盛)の幕開けには必然であったと思うのですよ！

STマイクロからリリースされたNucleo一族はmbedが利用できるという売り文句の
他に価格が異常なくらい安いという点も注目を集めていますね。これについては
いろんな方がいろんな考察をしておりますが、ねむいさん的にはこれは中華製
ぱちもん基板の駆逐も目的としてるんじゃないかなとにらんでます。STM32って
中国大陸の方の中華圏では日本市場とは比べ物にならないほど大人気なんです。
それにあやかり安かろう悪かろうのとんでもないブツがあふれてますのでST自ら
超安価に基板をばらまいて巨大な中華市場をさらにコントロールしようという
思惑が考えられます。

視点を日本に戻すと日本ではハードウエアレベルを隠ぺいした抽象化を強化した
プログラミングがArduinoや前途のmbedを中心に大流行していますので日本に
おいてもこの基板を用いたことによりSTM32の利用者も急激に増加していく
ことになると思います。
で、ねむいさんってmbedとか使ってないから全然関係ないじゃんとか突っ込まれ
そうなのですが別に便乗とかそういう意味合いでは全くなく単にSTM32F401
シリーズを使ってみたかっただけです！！！！




ｹﾞﾌﾝｹﾞﾌﾌﾝ…というわけでSTM32F401シリーズは従来のF4シリーズの廉価版に
位置付けられていて下記の機能が削られています。
・CCM(Core-Coupled Memory=密結合メモリ)
・DMA転送用SRAM領域
・BackupSRAM領域(バックアップ"レジスタ"は健在)
・クロックがF40x系の半分(MAX84MHz)
・PB11(Vcapになった/一部パッケージのみ使用可能)
・FSMC
・ETHERNET
・その他ペリフェラル色々

引っ掛かりやすいのはPB11でしょうか。GPIOでPB11を使用している場合に
F401系に載せ替えるような時は注意が必要です。


STM32F401系のメモリ構成は大雑把にするとこのような感じになります。
画像はF4版Nucleoに乗っているSTM32F401RET6のものです。ごくごく一般の
ARMマイコンと変わらなくなってますので特に小難しいことは必要ないです。



てわけで実践です！緑色のLEDが点滅します。
(注：右上は某ｸﾚｲｼﾞｰｻｲｺﾚｽﾞではなく見滝原中学校の制服を着たいないさんです)
先ずはLチカ!mbedだとハードを越えてほぼ同じコードでLチカせしめることが出来ます
がねむいさんの環境も同じくmain.cはほぼコピペで同じようなことが可能です！！！
水面を優雅に泳ぐ白鳥も水面下ではせわしなく足を動かしているのと同じく抽象化さ
れたコードの下では頑張って下駄履かせてきた人たちの汗と涙が詰まっていることを
少しでもおもいだしてくれれるとうれしいでｓ


そういうことはどうでもいいのでさっさと先に進みます。お次は前回と同じI2Cデバイス
です。こちらもいつものの奴で汎用化したシンプルなI2Cライブラリを作りこんでいて
そのまま転用出来るようにしてあるのではっきり言って前回のF0系より楽勝でした。

所でこのi2c液晶、私が使い方公開しましたがaitendoさんで全く数が減ってません…
規模の大きいマイコンで使う限りでは圧倒的に使い勝手が良いのですが…
消費電流もST7032iとかに比べて少ないのでお勧めです★
大事なことなので前回に引き続き二度言いました。



というわけで今回動作させたF4版NucleoのLED点滅とI2Cデバイスのサンプルはおきぱに
公開しております。一旦ベースをこさえてしまえばあとはどんどん作りこんでいけるので
オフラインコンパイラフリークな方にも安心してNucleoを利用できると思います。

また忘れるところでした、私のOpenOCDのバイナリは今回のF4版Nucleoに
すでに対応してますのでどしどしご利用ください。

STM32F4シリーズを使ってみる11 - STM32F429I-Discovery発動編 -

ぇー…前回のSTM32の記事の最後で新しいコードスニペットと称するどことなく
卑猥な名称のふれこみで発表されたSTM32CubeMXとそのF4シリーズのサポートを
行うCubeF4という新たなファームウエアライブラリに触れましたが…
私も移植を目指して頑張ってたのですが…

私の従来のいつものに当てはめようと思うと改造個所が多岐に及び、さらにコード
サイズとオーバーヘッドも増加してしまったので移植は見送りにして新規に作る
プロジェクトからCubeF4を使用する方針に逃げ変えました。

STM32CubeF4には抽象化がさら進められ、インスタンスという概念が追加され
ています。これがかなりの曲者で従来のF4シリーズで言うDSP_StdPeriph_Driver
ライブラリに相当する"STM32F4xx_HAL_Driver"はすべてこれの
使用を前提としていてさらにサイズが大きい構造体と併用しなければならない
のが分かりました。
これSRAMやFLASHのリソースが膨大にあるF4シリーズだからよいものをF1やF0
にも当てはめるのはかなりヤバいと思います。
私も過度の抽象化は良いとは思っていません。移植性を重視しすぎてせっかくの
マイコンの性能を引き出せないのであれば本末転倒です。

あんまし考えたくないのですが無理くそ全CPUの格差を埋めるべく抽象化を
目指し、そして失敗して結局ライブラリのバージョンが多岐に分かれて
しまったLPCOpenと同じ道を歩んでいる感じがします。
おそらくCube系のライブラリに遷移していくあたって大混乱が起こると
思いますね。無理にCubeへの遷移を煽る中途半端に発言力が持ってる人が
湧くのは容易に予測されます。学生さんなんかは自分のボスの"せんせい"
にまたCubeライブラリの使い方をwikiにまとめさせられると思います。
そういうこと言ってくる人らには"こんなことしてること自体が時間の無駄。
したけりゃ自分でやれ！"とはっきりNOを突き付けるべきです。
とはいえ私のぶろぐを見られている方は私よりも技術力がはるかに上の方
ばっかなのでそもそもこんなとこ見てない私が注意しなくても各自しっかり
対処出来することができるでしょうからぐだぐだ言いましたがやっぱし
私の杞憂かな〜と思います。




さて、前置きが長くなってしまいましたが以前から触れてきた
STM32F429I-DiscoveryのTFT-LCDをSPIではなくRGBインターフェースで
動かすことに成功しました。
前回は低速なSPIインターフェースでお茶を濁していました。
しかしSTM32F429シリーズにTFT-LCDに特化したグラフィックコント
ローラ(LTDC)とグラフィックに特化したDMAである(Chrom-ART Accelerator)
が搭載されているのでこれらの機能を使っていつものの再現を目指し
ようやく完成したわけです。

●STM32F429Iにあるグラフィック機能
私が説明するよりもこちらのPDFを見たら一目瞭然です。
LTDCに関してはフレームバッファとして確保したメモリアドレスにRGBの
データを書き込むだけで色の表示が可能です。また、STM32F429系では
SDRAMがサポートされているので容量を喰う画像データでも余裕で
取り扱うことができます。

Chrom-ART Acceleratorに関しては別名DMA2Dと称されていて文字通り
2Dグラフィック特化型DMAです。しかもデータ形式を変換してメモリ間
転送したり単一データを指定して転送する(レクタングルフィルに効果を
発揮)ことができます。

STM32F429I-Discoveryでは上記二つの機能を体験可能です。同ボードに
搭載されたTFTLCDの解像度は工作物ではメジャーな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 :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義)


次にRGBデータcolourを書き込みます。


*(volatile uint16_t*)(lcd_c_buf_ptr) = colour;

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		= 0x0F;

	DMA2D_InitStruct.DMA2D_OutputMemoryAdd	= (uint32_t)lcd_f_buf_ptr;  

	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 :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :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_ptr;

	DMA2D_InitStruct.DMA2D_OutputOffset		= 1;

	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 :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
p :転送したい画像データのポインタ

と、従来のDMAと同じ感覚で使用が可能です。もっと汎用なDMA2Dの使用法は
同じくlcdc_if_basis.cをご参照ください。DMA2DはLTDCと組み合わせると
強力なレイヤー機能が使えるようになるでしょうね。
私のサンプルでは全く使いこなせてませんがー！


という訳でそれを踏まえたいつものをビルドして書き込み、
動作させたものが上の画像です。
静止画では違いが分からないと思いますが以前の8-bitSPIのみで動かしてた
ものとは描画速度がダンチですよ♥


惜しむらくはSTM32F429I-Discoveryに使用されているTFT-LCDが発色にちょっと
劣る点です。2014年現在では超高視野角液晶はすでにホビイストでも容易に
入手可能なのでそれに慣れた私にとってはあと一歩がほしいところと感じました
(多分最新の奴搭載したら値段跳ね上がるでしょうけど)。




●いつものFatFs+TFTLCD表示サンプルの細かい整備など

LTDC+DMA2Dに対応したついでに長らく放置していた全部載せSTM32F427IIT6基板の
プログラムも見直して安定化を図りました。いまさら気付いたのですが、新しい
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領域にあたる)を一旦ゼロクリアしてから
表示を行うようにしてバグを潰しております。

以前は変なゴミデータが表示されていましたが…、

修正後はこんな感じにすっきりです★

いろいろ試す20…という名の今年の反省会

今年もいろいろありましたが私としてはやってることはほとんど変わらず
山走りとかに行ったりLチカを極めるべく研究したりOpenOCDのエンバグ
とかです。

特にステップアップらしき事をしたのは今まで利用だけしていたOpenOCDの
プロジェクトに対してパッチを提出する形で能動的に参加したことでしょうか。
言葉の壁はもちろんありますが何度もこなしていくうちにある程度分かって
きますので皆様もオワコンとか言わずにどんどん参加してほしいと思います。



●マイコン向けの最強最後のTFT-LCDをゲッツか

i8080バスで接続できるもので現時点でほぼ最強かと思われるモジュールを手に入れ
ました。320x480(HVGA)・ILI9486L・超広野角・3.8inch・抵抗膜式タッチパネル
付と至れり尽くせりでSTM32F4系のFSMCで接続するには最適です。
これ以上のピクセルサイズになるとRGBやMIPI-DSIのほうが速度的に有利になるので
やはり"マイコン"で使用するのなら320x480が上限と感じます。

以前の主力だった3.45inchの奴(コントローラIC:R61581/B0)と比較してみました。
一回り大きいのがわかると思います。


●GCC ARM Embedded in Launchpadがアップデート
読んで字のごとくですがクリスマス前に合わせて更新というなかなかニクいアップ
デートです。今回からGCC4.8.x系になりました。また今回の目玉は新しいコンパイラ
オプションの"-mslow-flash-data"の追加です。これはどういうものかというとリテ
ラルロードを極力movtに変えてバスの競合を避けパフォーマンスのアップを図ると
いわれるものです。ARM本家のこちらとこちらもご参照のこと。


"-mslow-flash-data"のありなしで吐かれたアセンブラリストの比較をしました。
使用したプログラムはSTM32F4のいつものです。赤でハイライトしてる部分がその違い
ですがLDRで行っていたリテラルロードがmovtに置き換わってるのがわかります。
LDR命令の場合、最短3クロックサイクルかかりバスの競合があるとさらに5クロック
サイクル以上掛かることになります。movtに置き換えた場合はサイズは増加しますが
2クロックサイクル固定です。

次に実際のパフォーマンスを比較してみました。libjpegとlibpngのデコード速度の
実時間を計測して比較しました。表示に使ったのLCDはもちろん最初の項で紹介した
これです！
また表示に使用した画像は320x480サイズにしさらにpngとjpegに変換を行った
いないさんのおぱn…いないさんのｲﾗｽﾂをサンプルとして計測結果をuSec単位で
こんな感じで表示しｔ


…ｹﾞﾌﾝｹﾞﾌﾌﾝ
さて実際の結果ですが、せっかくなのでfreddiechopinさんとこのBleeding-Edgeツール
チェインや役立たずに堕ちたSourceryCodebenchも(←今回の比較のためにわざわざ
登録してインストールしためっちゃめんどくさいF**K!)交えコンパイラオプションも
いろいろ変えて各コンパイラ性能比較も兼ねて行いました。

↓とりあえず各条件の計測時間の羅列です
　(※-mfloat-abi=softの時はlibjpegのDCT_FLOATは無効にしていますのでバイナリ
　　　サイズが全般的に下がっております。)



libjpeg/libpng rendering speed compare

uses inai-san's oketsu-pantsu gazou.

PNG  : INA~1.png 96128kByte

JPEG : INA~1.jpg 40491kByte



LAUNCHPAD

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]



@@L1111

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16 -mslow-flash-data

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 496760	      0	 496760	  79478	main.hex

***libjpeg

182341uSec

***libpng

168305uSec



@@L2222

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 489144	      0	 489144	  776b8	main.hex

***libjpeg

181903uSec

***libpng

168485uSec



@@L2222 (nano-lib)

(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 470620	      0	 470620	  72e5c	main.hex

***libjpeg

194318uSec

***libpng

234706uSec



@@L3333

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16 -mslow-flash-data

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 496752	      0	 496752	  79470	main.hex

***libjpeg

182345uSec

***libpng

168311uSec



@@L4444

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 489136	      0	 489136	  776b0	main.hex

***libjpeg

181925uSec

***libpng

168588uSec



@@L5555

(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 496152	      0	 496152	  79218	main.hex

***libjpeg

186999uSec

***libpng

168740uSec



@@L6666

(Using newlib) -Ofast -mfloat-abi=soft

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 488592	      0	 488592	  77490	main.hex

***libjpeg

187095uSec

***libpng

168490uSec















BLEEDING-EDGE

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-130810) 4.7.4 20130613 (prerelease)



@@B1111

(Using newlib) -Ofast -mfloat-abi=hard  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 555460	      0	 555460	  879c4	main.hex

***libjpeg

183801uSec

***libpng

170161uSec



@@B2222

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 555436	      0	 555436	  879ac	main.hex

***libjpeg

183797uSec

***libpng

170156uSec



@@B3333

(Using newlib) -Ofast -mfloat-abi=soft

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 553492	      0	 553492	  87214	main.hex

***libjpeg

187582uSec

***libpng

170098uSec













SOURCERY CODEBENCH

arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.11-24) 4.8.1

@@S1111

(Using newlib) -Ofast -mfloat-abi=softfp  -mfpu=fpv4-sp-d16

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 504568	      0	 504568	  7b2f8	main.hex

***libjpeg

184072uSec

***libpng

203915uSec



@@L2222

(Using newlib) -Ofast -msoft-float

=== Total Binary Size ===

   text	   data	    bss	    dec	    hex	filename

      0	 504040	      0	 504040	  879c4	main.hex

***libjpeg

186811uSec

***libpng

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を利用する意味が全くなく
なりました。
皆様も早急にLaunchpadに乗り換えられることをお勧めいたします。

すぐにだっ！



●よくいただく質問に対する回答とか
というわけで今年のぶろぐもこれでお開きですが、毎年恒例の尺が余ったので
メールや虹裏でいただいた変な質問にぶろぐ上で返信をさせていただきます。


Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:長き戦いよ、さらば！
　ていうかちゃんとぐぐりなさいよー！

Q:USB3.0でLibUSBが(ry
A:こちらをご覧ください。
　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バイナリは配布されておらず
A:ここが見えないのですかここが！！

Q:(企業のメールアカウントで)***なのですが****を希望しますor早く修正してくだ
　さい。以上。(←回答納期をつけてくる場合も…#)
A:今年に入ってなぜか急にたくさんいただくようになりましたが……企業内で開発を
　行われる場合は有償のサポートが付いたツールを使用されるほうがいいと思います。
　もしくはgpl.txtを1000000000000回音読して"利用者が全責任を負う"っていうこと
　を体で理解してください。ちなみに私の副業先ではARMはIARで開発しております。

Q:ルネサA:帰れや！

Q:ギンギンに勃○してるのですが
A:ﾔﾀﾞﾓｳ///

Q:ギンギンに○起してるのですが
A:ﾔﾀﾞﾓｳ///
　これデザインしたの私と同性の方でしょうか…？
　本来のとは逆向きに付いてますし///

Q:ねむいさんで検索すると候補に入院と出てきます。これは何ですか？

A:これは重篤なサジェスト汚染ですね〜！
　当職が入院したとかいう体だけ(非性的な意味で)が取り柄のねむいさんのあいでん
　てぃてぃを否定する検索が多数行われているのは絶対に許さないよれません！！
　力を。

Q:ねむいさんのぶろぐに右端にあるブラウザベンチマークというリンクをクリック
　したら突然大量の画像が貼られるページにいどうして動作が重たくなり、ブラウザ
　がクラッシュしてしまいました！！！１！！ファ*クユー!!!
A:びぃぶろ君が悪いんですけぉ！１！！ねむいさんは悪くないんですけぉ！１！！１

Q:ねむいさんはさんざモロはあかんといっときながらブログでモロを進めていたのは
　どういうことなの？虹裏メイドだからって何か許された特別な人間だと思ってるの？
A:わかりましたから落ち着いてください。かつて存在した虹裏novという場所があった
　のですが話はそこにさかのぼります。そこでは魅力的ないやらしい口元をした紳士
　画像を赤と黄色を交互に放射状にした…いわばマケドニア国旗のような非常に目立
　ちやすい注目をひく画像に加工したものをスレッドの頭画像とし、おもに紳士に関
　する話題やコラージュを中心としたスレッドの進行体系をとっておりました。
　しかし、実写のコラージュを用いたスレッド信仰であったためふたば☆ちゃんねる
　のｸﾝﾆﾘﾝｻﾝにとって二次元裏のポリシーに反する目の上のタンコブだったのです。
　紳士画像のスレッドの住人はそれには構いなしにナイフみたいに尖っては触る者皆
　すべてに不許を貫いておりｸﾝﾆﾘﾝｻﾝに対する反逆とも呼べる行為を続けていました。
　そしてある日ついに、ついに虹裏novはｸﾝﾆの怒りによってなんと板ごと御取り潰し
　に遭うという悲劇的な結末を迎えました。しかし紳士画像のスレッド住人はそれで
　息絶えたわけではありません。住人達はもといたimg,may,jun,decにとしあきとして、
　｢｣として溶け込みつつもマジスタンスとして2014年になろうとする今現在も続く許
　されざるビューティフル・ウォーを繰り広げているのでございます。
　現在では、前途の紳士画像を二次元裏@ふたばに貼付するという行為はｸﾝﾆに対する
　反逆の証として児童ポルノ画像の貼り付けよりも重篤な一発アウト(スレッド削除・
　アクセス禁止措置)が取られるようになっております。safetyに紳士を語るためには
　紳士を構成する目元といやらしい口元を隠す黒塗りを施した"加工済紳士画像"の
　貼付けにて進行を行わざるを得ないのですがそういった処理前の未加工な紳士画像
　がモロ画像もしくは縮めてモロと呼ばれ、爆発性の危険物として扱われています。
　しかしながらそういったモロが貼られない状況が紳士スレッド内で続くと突然日清
　チキンラーメンのパッケージをはじめ鶏肉を主体とした調理済の料理画像が貼られ、
　あたかも"(モロを貼れない)お前はチキンだ！チキン野郎だ！"と言わんばかりの
　挑発を受けることになります。挙句の果てには手描きを用いチキンとかはたまた妙に
　ウイットに富んだ発音でティキンとかいうモロにストレートな心温まる発言を行ッ
　てくれやがります。ですがあなたたちは紳士です！そのような挑発には決して乗っ
　てはいけません！奴らはあなたの正義感を巧みに利用してモロを貼らせるように仕
　向けているだけです！！１！もし挑発に負けて大人の男怒らせるなよオメーラと言
　わんばかりに未加工の紳士画像を張り付けてしまったらゲーム・セットです。たち
　どころに大勢のアンパイアが現れつぎつぎにアウトの判定を下され、ポケットモン
　スターのアチャモにも｢あちゃ〜…もろ」と吐き捨てられ、仲間であったはずのスレ
　ッド住人にdelを叩き込まれてとどめにｸﾝﾆﾘﾝｻﾝになーとアク禁を喰らうでしょう！

Q:東海自然歩道の静岡バイパイコースについて質問です。
　玉露の里にかかる橋のマークはなかなかイカス植物ですね？
A:し…しらない…
　気のせいでしょうﾊﾊ

Q:東海自然歩道の静岡バイパイコースについて質問です。
　休暇村富士の玄関で栽培されてる葉っぱはなかなかイカス植物ですね？
A:し…しらない…
　き、気のせいでしょうﾊﾊ






…
ー…そろそろ大掃除しますか…

それではみなさま、よいお年を〜

STM32F4シリーズを使ってみる9 - STM32F429I-Discovery準備編 -

STM32F429I-Discovery(製品名:STM32F429I-DISCO)、ようやく一般市場でも入手
しやすくなってきましたね。twitterのタイムライン見てると既に手に入れられた方、
使用されている方々の写真もびしばし上がってます。

私の方はというと…少数の方は更新に気づいていたとは思いますが、東海自然歩道へと
向かう前日の11/29にすでに既存のSTM32F4向けFatFs実装例に対応ボードの
一つとして基本部分を組み入れたソースコードを公開しております。
尤も429I-DiscoveryからはぢめてF4シリーズに触る奇特な人もいるかもしれないので
これがどういう物で何ができるか今一度軽く解説をさせていただきます。
※注意※
　こことここを見て私のプロジェクトをビルド・デバッグ出来る環境拵えてることが
　前提です！"意味が分からない"という方はご縁がなかったということで…


私のFatFs実装例(通称いつもの)は、ChaNさんのFatFsを中心に各マイコンの極めて
基本的な機能を網羅しています。STM32F4においては下に述べる機能を抑えています。
STM32F429I-Discoveryでも勿論使用しております。

　1.GPIO操作
　　->LED点滅・SW入力
　2.UART
　　->割り込みを使用したバッファリングされた送受信・stdioのリダイレクト
　3.液晶モジュール
　　->MCUバスインターフェース(i8080,SPI,I2C)で駆動できる表示素子の操作
　　　STM32F429I-DiscoveryはRGBインターフェースを使わずともSPI単体でも画像
　　　データを送ることができます(遅いですが)。
　4.FatFsのローレベル部の実装
　　->SPIやSDIO等とMMC/SDカードとのインターフェース。STM32F429I-Discovery
　　　ではSPI4を使用しSPI互換モードでSD/MMCを動作させております。
　　　
　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専用のプロジェクトとして公開する予定です。


おまけ

1年以上前に購入した699元全部載せSTM32F407基板もSTM32F427IIT6に
換装してパワーアップさせました。
実はずーーーーっとF427系のチップが出るの待っていたのです！

こっちはこっちでF407系の資産生かしてなおかつ強化する方向で遊んでいきます。

PARTYHARD!(見えづらいですが左上)

もいっこおまけ

STM32F42xxx&STM32F43xxx系をJTAGから見た場合バウンダリスキャンのTAPIDが
40x系と違うものになってるのでOpenOCDで書き込もうとするとコけます。
この修正はgerritに投げてますのでOpenCOD0.9.0あたりで反映されるはずです。

STM32F4シリーズを使ってみる8 - STM32F429I-Discovery接触編 -


ﾃﾞﾝ！

ﾃﾞﾃﾞﾝ！
…ッツついに来ましたよ…！最強に強まったSTM32F4が…！
後ろに見えるSTM32F437IIT6も後日に…



STM32F429I-Discoveryは現時点のSTMマイコンの中で最強種のSTM32F429とそれが
サポートする64MbitのSDRAMとRGBインターフェースが利用できるTFT-LCDまで
搭載されたまさにねむいさんのために作られたようなボードです！
※正式名称は「STM32F429I-DISCO」だそうです。


STM32F429/439シリーズはRGBインターフェースのTFT-LCDドライバとSDRAMを
サポートするFMC(FSMCからSが取れた)を持ち、最高クロック180MHzで動作する
Cortex-M4Fのコアを持つマイコンです。


ついにSDRAMが…♥もうヒープサイズ気にしなくていいんじゃあんちゃん
ちなみにTFT-LCDドライバのフレームバッファ用にも使われるそうです。


とりあえず電源を入れてみるとSTLink/V2が認識してemWinと呼ばれる小洒落たGUIが
走ります。凄いもんだ…基板上に実装されたTFT-LCDの解像度は240x320です。
タッチするといろいろメニューが選択できます。本来はUSBメモリ等の記憶媒体を
挿しておくようになってるみたいですね。


今は168MHzで動いてるらしいです。



…で、
一通りデモプログラムを確認したのであとはおなじみOpenOCDで内蔵フラッシュメモリ
のバックアップをとり(2MBあるので5分くらいかかりましたよ！) 前もって予習して
いたLEDチカチカプログラムを書き込んで一発動作を確認♥
おきぱのSTM32F4向けサンプルの定義をほんの少し変えるだけで事は済みました…。

お次は目玉のTFT-LCDです。ねむいさんはこっちももちろん予習済です。
STM32F42x/43x系ではUSB用SRAMの容量拡張のほかSPIやI2C等の基本となる
ペリフェラルも数が大幅に増えていて更なる柔軟な回路構成が可能となって
います。


それではここらへんでいつものを…このTFT-LCDのコントローラICは定番の
ILI9341なのでRGBインターフェースへの応用も楽勝ですね♥
今回表示したのはねむいさんの頂き物のｲﾗｽ…ｲﾗｽﾄじゃなくて3D絵です。
あ○たご、抜錨しま〜す♪ぐふふ♥
↑ねむいさんが何のキャラのコスしてるのか最近分かったです…鈍い…
↑ねむいさんて艦これ(ブラウザゲー)やらないの？とよく本職してる時に尋ねら
　れますが、6年前からずっとゴルロア続けてますし今もっともアツいブラゲに
　嵌ってる(作業的な意味で)のでさすがに他のにまで手を出す余裕がないです…。

なお、びぃぶろ君に確実に怒られると思われるえろすな個所はトリミング済みなので
安心してご鑑賞ください。

20131114追：

タッチパネルコントローラはi2cのSTMPE811です。
こちらも予習済なのですんなりいけました！


というわけで今回はSTM32F429I-Discoveryのファーストタッチをご報告させて
いただきました。基本的な部分は初期のSTM32F4とほとんど一緒なので、
F4Discoveryからの移植はそこまで難しくないと感じました。
まずはFatFsとChaNさんのファイラーを完全に移植させます。12月上旬には
私のおきぱに新しいラインアップが追加されると思います。

いろいろ試す19

あっという間に(仕事上の)夏が終わってしまいました･･･日記上は更新
してないので夏ばてしてた様に見えるでしょうけどもじつは更なる跳躍の
ために私なりにいろいろやっていたのですよぅ！
とくに東海自然歩道関連もトレーニングを重ねて猛暑の中で難所をクリア
してきたのでこちらも近いうちにじっくりと･･･


●夏休みの工作☆LPC4088

さて、円高の頃に買い込んでいた基板やチップの中で最後の大物で
残っていたLPC4088に着手をはぢめました。

基板はLPC1788ですがLPC4088はほぼピンコンパチなのでそのまま乗っけ
られます。生基板なので仕事や家事終わったあとに大量の部品をちまちま
ちまちま付け続けお盆休み明けにようやくFatFsまで動作を確認しました。

LPC1788のときと同様に大容量のSDRAM乗っけてます。STM32系と違って
heapやstackとしてがんがん使ってもコケないのがすばらしい！
(STM32F1系のFSMCはerrataとしてFSMC上のSRAMをheapやstackに使うな
ととうとう明記されてしまいました!!!11!!F***K!!!!)

LPC4088はLPC1788には存在しないSPIFIインターフェースを持ちます。
しかし･･･
困ったことにLPC1788系と互換性を保った結果LPC4300系と違いSSPポートの
互換性がなくOpenOCDから書けないことが判明orzOpenOCDはSPIFIではなく
ポート互換のSSPで書いてたんですよね〜
･･･ドライバの対応はnuvotonドライバの時よりしんどそうだったので
早々にあきらめ外付けのコネクタを設けてFlashROMを使って書き込みする
作戦に変更しました。SPIFIは容量を喰うFONTXファイルの置き場に
使用していきます。

あと付けてないのはLCDインターフェースですがこれは私がいつも使ってる
MCUバスではなくRGBでつなげるタイプのものを必要とするのでそれに合う
液晶の調達から手を付ける予定です。




●Kinetis K20/K10シリーズを触る
わざわざ独立の記事にするほどでもない超小ネタなのでここでさらっと
紹介します。少し前にFRDM-K20なるボードが販売されましたがこの
シリーズの一番小規模のチップであるMK20DX32VLF5とMK10DX32VLF5を
ちょっと触りました。写真は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の書き込み確認のために単品購入したチップです。
EnergyMicroというメーカのチップでしたが現在はSiliconLabs社に吸収されています。

Gecko(ヤモリ)のマークがチップ上に付けられたイカすデザインでCortex系の
マイコンでは超低消費電力方面に力を込めたラインナップとなっています。

ねむいさんがチラッと触った限りではCMSISライブラリがSTM32ばりに充実
していてCMSISにどっぷりつかったねむいさんの流儀に非常に組み込みやすく
最初の取っ掛かりのLチカ作成が最速の30分で完成しました(逆に一番難儀
したのはあちこちにファイルが点在してて把握しづらく挙句の果てにKeilの
サンプル中にしかCMSISヘッダファイルが無い品種もあるKinetis･･･
てか公式のサイトでリンク切れはまずいですよぅ)。

書き込みデバッグももちろんすんなり完了ですごい相性よかったので
メインのSTM32からちょっと浮気しちゃいそうです･･うそですよぅうふふふ




というわけでOpenOCDのバイナリには上記3品種の書き込みcfgファイルを
追加してます。パッチも前回から不備が見つかったものをさらに改修して
ますので私と同じ環境をお持ちの方は試してみてくださいね〜







･･･すっかりOpenOCDありきのマイコンいじりになってしまいましたが、
実務ではルネさｓ


(日記はここで途切れている)

いろいろ試す17

試"す"というか試"した"結果のご報告の方が多いかも…


●STM32F437シリーズの予習
2013年4月中旬現在はまだチップ単体は手に入る時期ではないのですが
去年買って放置していた超格安全部入りボードを使用して来たるSTM32F437シリーズの
予習をしていました。
ただこれに付属しているTFT-LCDモジュールのタッチパネルドライバICが定番の
ADS7843ではなく、I2C接続のSTMPE811というI/Oエキスパンダと温度計も一体化
された妙に"いんてりじぇんす"なICだったのでそれの対応に非常に苦労しました。

↑画像は春になり発情期を迎えたいないさn
とりあえずいつものが動かせられるようになったので同じ基板を購入した人たちは
無改造で追試できると思います(TFTLCDのドライバはILI932xを選択の事)。
I2Cバスエラー対策はまだ実装していませんので、フン詰まりになったら電源を
いったん落とした後再投入して対処してください。(やっけつ)
また今回はタッチパネルの処理の上位層も少し見直して無駄な記述をしていた
箇所や分かりづらい箇所を廃しております。たとえば、

キャリブレーション画面で青の■をしっかり押せたら…

黄色の■になる！…もちろんこれだけではありませんが細かいところも修正してます。


せっかくなので全体的にソースコードも見直してコメント等をできるだけ随所に
挿入して、プログラムの流れもつかみやすくなるよう努めるようにしました。
本来は書いた本人がプログラムの動作に関する詳しいドキュメントを書くべきなの
ですがこちらのかたが非常に分かりやすい解説をして下さっており、ねむいさんも
いつも参考にさせてもらっていま…あれ？

今回の修正はおきぱにあるSTM32F1,F2,L系のものを始め他社のARMマイコンのFatFs
移植例にも順次反映していきます。

●STM32F4で外部SRAMを使う
ねむいさん非常におまぬけなミスをずっと放置しておりました。
STM32F4向けのいつもののプログラム中でターゲットボードに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円(20130411現在)
まで回復してますが海外のパーツ・基板漁りはひとまずお休みして買いためたブツを
消化して逝きましょう先ずはNxPのCortex-M系最高峰のLPC4357のボードです！
(2013年01月中旬当初は国際送料込みでなんと13000円台で購入できていた超格安な代物でした。)


以前LPC4330というLPC4300系の基板をいじっておりましたがあっちはプログラムを
格納するフラッシュ領域が全くなく、スズメの涙ほどの内蔵SRAMか低速な
SPIFI-SPIROMから実行せざるを得ない非常に使いづらい代物でした。
しかしこいつは違います！204MHz動作でフラッシュも1MB内蔵なので使い勝手が
改善されて(ると思い)ます！…しかし…

…
4.3inchLCD基板の接合部でみてはならないものが目に入ってしまいました…
…なんだこの隙間は…これのせいでベースの基板もひん曲がってるし…
(後日このヘッダピンを半田槽で外し新しいものにまっすぐ付け直しました)


通電すると動作確認用のサンプルプログラムが起動します。またOpenOCD用の
cfgを作っていませんがLPC4300系のフラッシュ書き込みルーチンもまだ
レビュー段階なので先ずはそこから基礎を固めて試してみましょうか…！
(逆さになった何かを無視しつつ)。


●OpenOCDをさらに使いやすく
年明けくらいからでしょうか、ねむいさんが提供しているOpenOCDバイナリを
STLink/V2から使用する際にドライバをLibUSBからではなくSTMicro提供の
純正ドライバを使うように変更できないだろうか？というご要望をちらほら
いただくようになりました。

まさかとおもってSTMicro純正のドライバをよく調べてみると、Windows向け
ドライバとしてWinUSBが使用されているのがわかりました。
また去年行ったFT2232系FTDIデバイスのMPSSE対応の際にWinUSB(LibUSB-1.0)用の
ビルドができるようになっていたのですが、STLink/V2に関してはVersaloonと
同じくLibUSB0.1系を使用するようにビルドオプションを指定したままになって
いたので純正ドライバは使用できない状態でした。

今となってはWinUSB(LibUSB-1.0)を使用しない道理は存在しないのでSTLink/V2の
ドライバとしてWinUSBを使用するようにビルドオプションを変えて純正ドライバを
そのまま利用できるようになったバイナリを現在は提供しております。
ST-LinkUtilityなどの純正ツールとOpenOCDがドライバの差し替えなしに利用
できるようになったのでぐっと便利になっております。
そのかわり従来のLibUSB0.1系から使用できなくなりますのでご注意ください。
↑一応変更当時はトップにでかでかと告知してたので皆さん移行済みかと思います

追：
ドライバの扱いについてちょっとまとめます。
LibUSB-1.0：WindowsにおいてはWinUSBのラッパーとして働きます。
　　　　　　ですのでLibUSB-1.0のAPIを使いたい場合インストールするドライバは
　　　　　　WinUSBとなります。WinUSBのKMDFを使用しています。
LibUSB-0.1：WindowsにおいてはLibUSB-Win32と呼ばれ、LibUSB0.1(libusb0)の
　　　　　　APIはWDMを使用しています。
LibUSBK ：WinUSBのエミュレーションとして働きますが、WinUSBでサポート
　　　　　　してないアイソクロナス転送も使用可能です。
　　　　　　また、libusb0のAPIとも互換性があるのでLibUSBKをインストール
　　　　　　しておくと1.0系と0.1系APIを使うアプリがどちらもドライバの
　　　　　　入れ替え無しに使用可能となります。




さらにFT2232系デバイスの方もZadigでインストールする際にLibUSBKを選択
することによりWinUSBを使うOpenOCDやLibUSB0.1系を使うUrJTAG/FlashROM
などの便利ツールがドライバの入れ替えなしにシームレスに利用できるようになり、
低いコストと簡単な手順で強力なデバッグ環境をそろえることが可能となって
おります♥


●aitendoさんのanux
>ANUX続けるのやめまーす(←peep.usでページを保存しました)
こ ん な こ っ た ろ う と お も っ た で す よ ぅ ！ ！
そうだねチャイナリスクです…せめて全回路図くらいPDFでくだち…

STM32F4シリーズを使ってみる3 -FatFsと下部レイヤ(SDIO・MMC)ドライバたちの実装-


来たぞー！
…って来たのはもう2週間以上前ですけど…
144PinのSTM32F4も手に入ったのでSTM32F2の時と同じく中華生基板に組んで
みました。STM32F2とF4はほとんど同じです。特にコードは上位互換があるので
回路を完全に合わせるとF2のコードがそのまま使用できちゃったりします。
まあでもさっさとCortex-M4F用にしてしまった方が良いでしょう。



↑ということでいつものChan氏のプログラムを走らせて
　みました。

特筆すべきはF2系では何とか動くものの安定していなかった48MHz動作の
SDIOがF4系では非常に安定してることで、SDカードとさらに大容量/高速な
データのやり取りができるようになっています。ただし高速なクロックに耐え
うるSDカードの選択は必須で、Class10のカードを必ず選んでください。
最近出回ってるUHS-1の奴は逆に駄目なものもありましたので幾つか購入して
試してみてください。あと当たり前のことですが、配線の引き回しももの
すごく重要なので注意してください。
↑でたらめ書いてました。SDカードの仕様上通常モード(NomalSpeed)は
　25MHzが上限値でSTM32F2/F4ではUSBとの共用を考えると24MHzが現実的に
　安定して動かせられるクロック上限となります。
　お詫びして訂正しましま。

んでもって前回さらっとお見せしたSTM32F4 Discoveryの方のいつものですが、
ちゃんとした実装にあたり、周辺にぶら下がってる回路の影響でどのように
構成すべきか悩みました。なぜならば…
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が策定される前に販売されたATP製4GBClass6の
microSDです。



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と中華生基板のビルドを切り替える
ことができます。その他細かい部分のノウハウは口で説明するよりソース見て
もらった方が分かると思います。
だから誰か早くSTM32F4Discoverymp3プレーヤー作ってくだち！！
20121220追:
STM32F4Discovery用でMP3再生機能追加しました！



あ、お伝え忘れてました。今回の公開に当たってSTM32F2系とSTM32F107、そして
最近この検索ワードでアクセスが急増中のSTM32VLDiscovery向けのFatFs+液晶表示
プログラムも大幅に更新しておきました。
んでもってOpenOCD用Flash書き込みCFG群もSTM32F4xx用を追加しておきましたよぅ

STM32F4シリーズを使ってみる2 -STM32F4のメモリ構成を理解し基礎を作る-

20111201追：
最近複数の方からメールでご指摘いただきましたが、私はこのwikiとは関係ありません。
私の今回の記事からいくつかの文章を丸々コピペしていますが、私が後日誤りに
気付いて修正した内容が修正されずそのままになっていますので信用しないよう
注意してください。
20111201追：



今回は前回述べたとおり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の読み書き先としてこの領域を使用できません！
(20111026追：実際に試しましたがHardFaultになったりDMAが完了
しなかったりで、やはりDMA用のメモリとして使用できませんでした）
また、128kByte分の汎用SRAMもSTM32F4のコアクロックと同様の168MHzで
アクセスできるので俗に言うTCM(Tightly-Coupled Memory)としての速度的
優位差もほとんどないでしょう。



以上の点を踏まえて、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からこの
オプションが利用可能)が、無償で利用できるSourceryCodebenchLite版にある
標準関数等のライブラリはsoft-floatでビルドされているため、標準関数を
絡めるとリンク時に引数渡しの不整合がおきてエラーになります。
これを回避するためにはCodebenchLite版のビルド済ライブラリを使わない設定
(-nostdlibオプションを付ける)を付与し、同じ機能を持つライブラリを一から
"-mfloat-abi=hard"でビルドしなおさなければなりません。
というわけでいちいちビルドするのめどいので以後は"-mfloat-abi=softfp"で。
20131226追:
GNU Tools for ARM Embedded Processorsなら"-mfloat-abi=hard"が
使用可能です！！


これでFPUの命令を含むプログラムがビルドできるようになりましためでたし
めでたし･･･と言いたい と こ ろ だ が ！
ここも嵌ると思うので記しておきます。Cortex-M4Fの仕様によるとFPUは浮動
小数点命令が行われる前に(つまり起動時)に有効にしてやらないといけません。
STM32F4xxのサンプルではsystem_stm32f4xx.cのSystemInit()の最初で実行
されているものもありますが、テンプレートからsystem_stm32f4xx.cを生成
するとこの記述が欠けているのでほとんどの場合は自分で追加しないと
いけません。

☝のような感じでFPUの有効化を行ってください。



20120410変更：
実際にコンパイルオプションを変えて浮動小数点演算の箇所のアセンブラ
リストを比較してみました。Launchpad提供のGNUToolchainを使用しています。

●-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をつなげていつものをこしらえる
ところまで進みました。STM32F4 Discoveryの回路構成の都合で、SDIOとFSMCが
使用できないのでSDカードもTFTLCDもSPI接続です。
はやくこいこいSTM32F407ZGT6!

あ、そうそう、Chan氏のTJpegDecも組み込ませてもらってます。

STM32F2シリーズを使ってみる3

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で動かすことになるのですが
…それでも十分早いですね。



おきばにはすでに上記で紹介したSTM32F207ZGT6向けのプログラムを
公開しています。これはPowerAVR製の紅牛(もとはSTM32F103ZET6)という
ボードの回路互換となっています。
ねむいさんSTM32F2向けに備えてかなり前にtaobaoで部品未実装の基板
"だけ"超安価で購入していました。てわけでホントに最低限のことしか
できないのですがF2を試すに当たってはこっちの方が幾分都合がよいのです。

ここからどんどん付け足していきます

またmakeファイル内の定義の書き換えによって以前使っていたSTM32F207VGT6
向けにも対応できます。
STM32F207VGT6の方はこちらの(STM32F103VET6)ボードの
回路互換です。両者に共通するのはFSMCのピンが引き出されていて出来合いの
LCDボードが直結できるという点に尽きます
(☝TFT-LCDマニアな人には超重要なファクター)。
まぁデータシートで1xx系とのピンの処理方法の違いとかとか
詳しく解説されていますんで・・・・、
日頃ねむいさんのぶろぐ読んでる人なら簡単に乗せ換え可能でしょう。

あと開発環境のtipsとして、前回も説明しましたがCodeSourceryG++等の
ポピュラーなGCC開発環境はそのまま使用できます。Cortex-M3対応なら
何でもよいでしょう。問題は書き込み環境ですが…20110619現在はシステム
メモリ上のブートローダから使用できるフリーのツールがまだ整わず、
よってJTAG/SWDからしか書き込む方法がありません。幸いOpenOCDの0.5.x系と
VersaloonはすでにSTM32F2系のフラッシュの書き込みに対応しています。
私もフラッシュ書き込み用のOpenOCDコンフィグを公開していますのでJTAGな
いしはSWDでつなげられるアダプタ持ってる人は開発に際して問題はないです。

最後に、次回予定のLPC2388関連の記事で詳しく解説しますが、64bit版
Windows7環境下のビルドにもmakefileの設定で対応できるようにしてあります。
副業先のポジションとPC環境がガラッと変わったのでねむいさんも必要に
迫られてというのもあったりしてます。
ねむいさんとうとう従業員Bから晴れてエンジニアにじょぶちぇんぢ！
(やってること相変わらず雑用だが)






おまけ：
aitendoさんからついにあの扱いやすいSPI液晶が販売されましたね。
以前私が説明した奴です。これ使ったシールドとかも海外ではもうすでに販売されて
ますが、TFT-LCD Shieldを開発した時の生基板を利用して無理やり乗っけてみました！

次はこれで行こう。

そしてaitendoさんからはもう一つQCIFサイズのタッチパッドつきの液晶が発売されま
した。これ確かtaobaoで捨て値で売られてて私も10枚くらいまとめて買って動かして
(飽きて放置)してました。これ8/16bit選択できるのは良いのですが、ピン間隔が0.7mm
なので手配線ではきつい人がいるかもしれないですね。専用の変換ボード出るの待った
方が良いと思います。どちらかというと…、

こっちとか

こっちとか

こっち
の方がピン間広いし8bit固定で小難しいこと考えなくて良くてよいと思います。
思いますよぅ！！(重文)


↑AS021350DをXMEGAで動かしてみたところ。
実はATXMEGA128A1にもchanさんのFilerを日本語対応して移植に成功してます。
しかしXMEGAはFatFsを結局DMA化できないまま白旗降ってクローズします…。
20230701追:
DMA化してSRAMも外付けしましたよう！！！！！！！！！１！！！

STM32F2シリーズを使ってみる2

てなわけで前回の記事からはや一ヶ月、手探り状態でいろいろ進めているうちに
ST公式でやっとこF-2デバイス用のペリフェラルライブラリが出たり

BeableBoardXM購入合戦に勝利したもののまったく火入れしてなかったり

ALTERAのFPGA評価ボード買ったり

ステーション型はんだごて購入したり

USB接続型PCオシロスコープPicoscope3206Aを破格値でゲッツしたり
探訪も笠置まで進んでたりそうこうしてるうちに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な動画も余裕で再生できたので相当
"ぱわふりゃーなので余裕"なの確認できました。
やっけつだけど一番乗りだからどっかにアップしたいな〜


とりあえず次の一手としてはオリジナルなファイラーの実装に着手しつつ
先日がた老氏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さんもこういうの見習ったらｲｲﾅｰ
･･･絶対ありえないですが…

STM32F207はぢめました


ﾂｲﾆｷﾀﾖｰ
去年くらいに発表されて以来トンと音沙汰なかったですけどES品ですがやっっと
一般ユーザの手にもわたり始めましたSTM32 F-2シリーズ。
従来の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…。そして国内のホビーユーザーでF2のデバイス動かした
人間としては今度こそねむいさんが初めての人ですね！一番乗り！
次はSDIOに進みたいところですが、上で述べたとおりライブラリが無い状態
なので手探りで進むことになりそうです。まぁ10x系のものを参考にしたら
何とかなるでしょう。
実はここまで動かすレベルになるのにかなり手間かかった…
何せ資料が全くない…。


おまけ

2xx系はまだまだですが、512kByte以上のフラッシュ容量をもつ10x系の
STM32マイコンはすでにdigikeyやmouserで購入可能です。ねむいさんも
速効ひとつ購入してしまった。1年くらい前にtaobaoでSTM32用の格安の
空基板買っといたのがやっとこ日の目を見れましたのでこっちにさっそく
装着。単にフラッシュ容量が増えただけなので従来のライブラリが
そのまま転用できて動作の確認が非常にラクです♥


お約束カワウソ。

STM32 Primer2をBARE-METALで使ってみる4 -FSMCとLCD-

もうすっかり使いこなせて当然…なはずのカラーグラフィックLCDのつもりでしたが結構
苦戦しました…。STM32Primer2ではLCDの結線はSTM32のFSMCを使用したバス接続
となっていて、CircleOSもこれを利用してLCDの操作を行っています。LCDモジュールの
コントローラICはST7732。以前のTFTモジュールやi2c液晶なんかとおなじメーカの奴です。

ST7735の時と同じ風にやったら楽勝だろうと考えていたらモジュール内部で完結して
いるICのモード設定ピンの関係に気づくまでどうしても表示がうまくいかなくて
うｎうｎ唸っていました。コントローラICが同じもしくは同等品であっても
モジュール全体でみると初期化・制御の仕方とか微妙に違うってことを
思い知りました(いまさらか)。

上記のことさえ注意しておけば後は特に気にすることなくすんなりと一枚絵の表示まで
こぎつけました。128x160フルに使って表示できます。

※性的描写があるので小さく表示
un
↑ごめん…またいなちゃんなんだ…もう許してもらおうとも思ってはいない
　…でもやめられない♥

今回はWindowsで普通に作成できる24bitのビットマップをそのままC言語ヘッダ
ファイルに変換して直接読み込んでいます(内部で16bitに変換してます)。
FatFsが次に控えているのでそれを意識しています。

後気づいたことを一つ…
CircleOSのフォーラム見ていると拡張コネクタから出ているi2cやcanがFSMCからの干渉
でうまく動かないなどのことが議論されています。回路図見た感じではFSMCのバスは外
には手軽に出せないし現状LCD専用状態だしで、あんましFSMC使うメリットが見当たら
ないように気がしますが私の検証用のプログラムはCircleOSのを真似てFSMC使っています。


un

STM32Primer2をBARE-METALで使ってみる3 -ADCによる電源監視とUART2-

前回はSystickタイマを利用したスイッチ入力で電源の制御を行いました。しかし
電源を付けっぱなしにしているとどんどん電力が消費され、ついには3.5Vを切って
しまいます。（リチウムイオン電池の詳細な特性については他の専門に解説されて
いる方たちにうっちゃる(うｎ？)として、）実際3.5V以下になると急速に電圧が低
下していってしまうという特性があるので3.5Vできっちり止めなければなりません。

STM32Primer2はリチウムイオン電池の電圧低下をハードウエアで監視する機構がな
いのでSTM32に内蔵されたADCを利用してソフト的に監視し、3.5V以下になったら強
制的にシャットダウンする必要があります。今回はCircleOSのDMAを利用したADCと
過去の自分のコードを利用して電源監視ルーチンを作りました。

電源監視ルーチンはCircleOSで行っている方法とほぼ一緒で、1Secごとに移動平均
化されたVbatの値が3500(3500mV)になりさらにそれが15秒間連続した時にSHUTDOUN
信号を出してFETスイッチをOFFにするというものです。

そしてこの機構が実際に機能しているかどうかを確認するためにモニタリングする
必要がありますが、この検証には背面の拡張コネクタから出ているUART2を利用し
ました。このUART2のルーチンも自分の過去の(ry)でprintfにリダイレクトさせるよ
うにしています。

以前107系等で組んでいた時はUART-Txだけは割り込みを使用せず、ポーリングで回し
ていました。今回UART-Txも割り込み方式に変えています。それで初めて気づいた
のですがprintf等使用時に高速にバッファに転写すると早すぎて割り込み処理が
間に合わず、文字列が反転した状態で出てきてしまいましたので少し細工を行い安
定して文字列を送信できるようにしました。

un
↑大活躍の極小USB-Serial変換(画像右上)。

以上の条件下(72MHz駆動,LCDバックライトは未制御のため全点灯)でUART2から文字
列を排出した状態で電源電圧低下を感知して自動で切れるまでモニタリングを行い
ました

un
上図の結果のとおり、満充電4.1Vから徐々に電圧が落ちて行って3.5Vに差し掛かっ
たところでFETスイッチが切れています。また3.6V付近から電圧の落ち込みが急速に
早くなっているのが分かりますね。自働強制シャットダウンまで約4時間まるまる
かかりましたがCPUは最高速度,LCDのバックライトも未制御の最大輝度ですのかな
り電流喰っている状態です。この二つを制御できたらさらに持つでしょうね。

次回はFSMCを使ったLCDの制御に入ります。
FSMCは全く使用したことがないので少々手こずりそうです。

Go to top of page