STM32F7を使ってみる18 -CubeF7がv1.7.0になった(ついでにCubeF4も上がった)-

当らないミサイルやGWが日本に迫る中、STマイクロがリリースしている統合ファーム
ウエアパッケージ群のCubeF7
がアップデートしV1.7.0になりました。
ややこしいですがCubeF7中のHALライブラリ本体は1.2.1(CubeF7v1.6.1時)から1.2.2
へとバージョンアップしています。


変更点はCANのライブラリのバグが修正されたことくらいで前回私が指摘していた
幾つかのSDMMC関連ライブラリに関するバグの致命的な部分はそれより前のCubeF7v1.6.1で
修正されていますがまだバグが残ったままとなっています。
でもねむいさんはCubeF7v1.6.1v1.5.0をベースに最新の奴にアジャストしてるので何も影響あり
ませんけどー!!!

ちなみにCubeF4とかの他の品種もアップデートしているようですがHP上で数字だけ
変わっても変更直後はまだ従来の奴だったりする罠がありますのですぐに落とそう
とせず一日ほど待ってからの方がよいです。
ねむいさんは新しモノ好きなのでよくSTマイクロの罠に引っかかるたちです。
この件は昔からフォーラムでたびたび指摘されていますが今に至るまで真剣に対処
されず連携の取れて無さが見て取れるようでちょっと悲しいです。


ちなみに私は現在もDropboxの画像表示できなくなった問題にひたすら対処して
いる段階なのでマイコンその他のアイテムに関する深い解説記事が取れずお預け
状態となっておりますがおきぱのプロジェクトファイルの更新はライブラリの
アップデートとともに月一ペースで更新しておりますのでよろしくお願いします。
今月もちょっと早いですけど5/1版のいつものを更新しました。OpenOCDも新しい
のがマージされたら常に更新掛けてますのでよろしくお願いします。


やる気を保つために次回更新予定のネタを少しお見せします。
OpenOCDのSTM32L0への対応が漸く使い物になるレベルになったので解説を絡めながら
Discovery基板を動かしていく予定です☆

STM32F7を使ってみる17 -とっくの昔ですがCubeF7がv1.6.0になっていた-

前回少しだけ触れましたが、STM32F7向けのHALライブラリCubeF7のバージョンが
v1.5.0(CubeMXの場合v1.5.1)からv1.6.0に上がっておりました。

主な変更点はARMv8系コアのSTM32F7x27x3シリーズのレジスタ定義が追加された
事と、SDMMCドライバの大変更、さらに悲願のマルチメディアカード&eMMCサポート
の追加です。

eMMCのサポートはねむいさんも歓迎すべき事柄なのですがソースコードを読み解くと
その期待は完全に裏切られました☠なぜなら…

1.初期化シーケンスさえしっかり記述したら同一のソースコードで読み書きできる
  はずなのになぜかSDカードとMMCのソースコードがわざわざ分離されている。
  (↑まじふぁっく)

2."1."のおかげでSDカードとMMCが同時に使用できない。
  (↑まじふぁっく)

3.MMCの処理中でMMCv4以降のカードで必須のExtCSDレジスタを取得していないため
  4GB以上のeMMCが全く使用不可能。昨今のeMMCは最低8GBからなので全く無意味。
  (↑まじふぁっく)

4.DMA転送のコードが適当で使い物にならずデフォのポーリング版しかまともに
  動作しない。v1.5.0の時は私が手を加えなくともある程度まともに動いていた。
  (↑まじふぁっく)

5.SD/MMCとも両規格で指定されている電源投入->動作電圧到達後1mSec待ちその
  後74クロック空撃ちする処理が無くたまにイニシャライズすら失敗するカードが
  出る。eMMCは一部カードでbootシーケンスの際に74クロックが必須。
  (↑まじふぁっく)

6.まともなはずのポーリング版でも一見動いてるように見えるけどランダムで
  ReadもWriteもエラー発生するのが判明orz v1.5.0に戻すと全く問題なし。
  (↑馬鹿野郎)

私を含め外人さんたち憤慨していますが最終的にねむいさんのコードで動いたYO!
とのことで胸をなでおろしております。
CubeF7とは関係ないですがこちらの方は歓喜の絶叫を上げております。


ねむいさんはChaN師の「xxの上手な使い方はxxを使わないことである」と言う
格言に倣いCubeF7v1.6.0にv1.5.0のSDカードのドライバ(ややこしいですがHALライ
ブラリ自身のバージョンはv1.2.0)を無理やり移植してやりましたよオラー!

無理糞移植なものでねむいさんの環境以外で使用するには多少コツが要ります。
1."stm32f7xx_hal_conf.h"内の"#define HAL_SD_MODULE_ENABLED"をコメント
  アウトし"#define HAL_MMC_MODULE_ENABLED"を有効にする。

2.ねむいさん謹製の無理糞ドライバ"sdmmc_stm32f7.c"をプロジェクト/makefile
  のビルド対象にする。

3."diskio.c","ff_gen_drv.c"はv1.5.0の物を流用する。

4.内部変数はDTCMからとるようにリンカ/スキャッタファイルを設定しておく。
  (アライメントずれとデータキャッシュ不整合対策です)


"1."で何故本来は不必要なはずの"#define HAL_MMC_MODULE_ENABLED"を有効にして
いるかと言うと、これを有効にしておかないとstm32f7xx_ll_sdmmc.cで必要なロー
レベルの関数がビルドされずエラーになるからですファッ●ク!
ちなみに"#define HAL_MMC_MODULE_ENABLED"と"#define HAL_SD_MODULE_ENABLED"
を両方とも有効にしていると定義がぶつかって
またまたビルドエラーになりますフ●ァック!11!!1

そんなこんなでCubeF7v1.6.0でも安定してFatFsが動作するようになっております。
FatFs0.12cの最新パッチやCMSISv5の最新版ヘッダフィルを適用した4月版のソース
コード
も先行ですがアップしておりますのでどしどしご利用ください。


一方でむぎたさんは私のドライバを既に試されており残念ながら上手く動作できな
かった
とのことですがv1.5.0時代のコードでも大幅にSDMMCのクロック周波数を落と
さないと駄目
とのことでSDMMCの各信号波形そのものが変になってる可能性があります。

いわゆるインピーダンスミスマッチ状態で各信号の波形に相当なリンギングが発生
している事が考えられますのでオシロで波形を確認したのちインピーダンス整合用の
直列抵抗(最大47Ω)をSDMMC_CKの出力端(MCUの端子直近に)挿入
する、それでも駄目
ならさらに全信号ラインにフェライトビードを挿入する等の措置でクロック周波数を
落とさずに改善できるはずです。そこまでやっても駄目なら配線の引き回し自体に
根本的な問題があるのでmicronのeMMC使用時の設計ルールを参照して基板のレイ
アウト設計から見直す必要があります。

RTOSを絡めて使用されている場合はDMA転送用のメモリ領域がDTCMに割り当てられて
おらずキャッシュの整合性が崩れてこけている可能性もあるため切り分けのために
まずはDMA版ではなくポーリング版で動作確認してみてください。

STM32F7を使ってみる16 -USB-MSCを使ってみる応用編-

前回はSTM32F7のSDMMCインターフェースを用いてDELKINの工業用SDカードからSMARTの
情報をCMD56コマンドを駆使し読み出す事に成功しました。

その前にUSBカードリーダーに直接DELKINのカードを接続した時はDelkinDashboardなる
Windowsアプリを用いるとSMART値を読み出す事が出来る
のを確認しています。
そこで今回はUSB接続のカードリーダーに化ける奴でDashboardが使えるかどうか、
いくつか試してみました☆

1.OLYMPUS STYLUS TG-4
 ->SMART読み出しOK!
 
 TG-4はねむいさんが品質管理の証拠写真取る際やトレランで大活躍のでぢかめです!

2.STM32Primer2 GNSS Tracker(のUSB-MSCモード)
 
 ->SMART読み出しOK!!

いわずと知れたSTM32Primer2を用いたねむいさんのぶろぐ唯一の実用品です。
2009年から今に至るまで8年間、-10度〜+40度の過酷な環境を耐え抜き延べ3000km
以上の山道をねむいさんと共に駆け抜けてきたすごい奴です!

3.STM32F746G-Discovery(のUSB-MSC(HighSpeed))
 
 ->SMART読み出しOK!!

とりあえずSDカードが読めるUSBカードリーダー(USBマスストレージクラス)なら
何でもいけるような気がしてきましたよぅ・・・


"1."はともかく"2."と"3."についてはUSB-MSCに明示的にCMD56を発行するような
ルーチンは実装していなかったのでこれはつまりCMD56を用いなくても何か別の方法で
SMARTを読み出せられる手段があるのではないかと考えました。


そこでSTM32F746G-Discoveryを使って何が起こってるか解析してみる事にしました。
USB-MSCのSCSIコマンドを解釈するサブルーチンとSDMMCのRead/WriteにPrintfのトラップ
を仕掛けどのSCSIコマンドが発行されているか、またSDカードのどのアドレスに読み書き
を行っているのかを調べます。ファームウェアを柔軟に弄る事が出来るという市販のUSB
カードリーダーでは絶対に出来ない利点がSTM32F7にはあるのです!!



STM32F746G-DiscoveryのSTLinkV2の仮想COMを開いて待機しておいた上でDashboardの
"GO"ボタンを押すと全てが分かってしまった・・・

諸般の事情で細かい解説は省きますがある一定の順序でSDカードの特定のブロック
アドレス群に読み書きを行う事によりCMD56による取得方法と同じSMART情報を得ら
れることがわかりました・・・!

これなら特別なハードウエアを用意しなくても市販のUSBカードリーダーさえあれば
気軽にSMARTとかSDカードの寿命を確認できますね〜!
それを組み込んだこいつも更なる進化を遂げてさらに最強に強まることが出来たので
ねむいさんはこれからの近畿自然歩道の攻略に向けて燃えに燃えています!
20170308追:
このような工業用SDカードの寿命診断についてですが実際は頻繁なカードの
取り外しが困難な場所や機器に特に威力を発揮します。
性悪説的に言うとケーシングや樹脂化でSDカードを完全に隠ぺいし第三者から
"SDカードを使用している機器"と分からなくして"何らかのメモリデバイス"と
して見せることにより商売上でSDAのライセンス条件を完全に逃れている場合の
リモートメンテナンスの際にも役立ちます。
正攻法でもCMD56なりUSB-MSC経由でSMART取ればいいので品質管理の面から見て
仕事が進めやすくなるのでメリットだらけですね〜♥
20170308追:

でぢかめ向けには大容量品があるUtility+がよさそうですね。これも上記と同じくCMD56&
Windowsツール経由でSMART取れるので特にカードの寿命や動作環境を気にする
プロの人必須のアイテムだと思います。ねむいさんもお金に余裕が出来たら購入して
TG-4と併せて使った感想をレポートしてみたいと思います。


ちなみに民生品のSMART非対応のカードだと失敗しちゃいます。
TDKやApercer配布のSMART取得ツールだと非対応のカード使うと先頭1kb分のデータが
問答無用で破壊されてしまうのですがDelkinDashboardではそういうことはまったく
ありませんが興味本位で非対応のカードで試すのはやめておきましょう!!
とまぁこんなかんじで各メーカごとにSMARTの仕様がバラバラなのでSDAが早く統一
規格作るべきだと思いますよぅ。




さらにおまけですが・・・
解析途中でDELKINカードのパーティションの全容量と実容量が一致してなくてディスク
ユティリティーソフトが異常を検出してておかしいなと思っていたのですが・・・


STM32F7CubeのSDカードドライバ(v1.5.xまで)はSDHCにしか対応してなかったため
SDv1の初期化コマンドすらなかったのは周知のとおりですがUSB-MSCのサンプルも
その仕様を引きずっていたため正しい全容量を返していないのが分かりました。

20170329追:
SDv1どころかSDv2でも正しい全容量を返していないことが分かりました。
別な部分で一番最後の論理ブロックアドレスを示すよう-1している個所があり、
上記の部分で-1してしまうと余分に-1したことになるので実容量より1ブロック
分小さい値が返されてしまいます(ほとんどの場合は512Byte小さい値)。

具体的にはusbd_msc_scsi.cのSCSI_ReadFormatCapacity()で総ブロック数から1を
引いた数をホストPCに送っています。

一方SDHC/SDXC等の大容量のSDカードなら多少の容量の相違は無視できる
ほど小さいので問題はありませんでしたが、Delkinカードは1GBしかないため
ParagonHardDiskManagerではそれを見逃さず無効なパーティションと
見なしたようです。ちなみに値が微妙にずれた状態でもWin7からは普通に
読み書きできてました。
SDナビさん曰く、この値が容量偽装とかでズレが大幅になるとWindowsも
おかしいと検知してフォーマットを促すダイアログが出るようです。
20170329追:


そういえば今年になってv1.6.0が出てSDカード周りが刷新されたのですが待望のMMCが
追加されたのはイイのですがなんかいたるところが欠陥だらけで超やばいことになって
いたのですが話が長くなるので次回に続きます・・・

STM32F7を使ってみる15 -工業用SDカードからSMART情報をスマートに読み出そう-

あれ?ESP-WROOM-32が秋月から発売されて絶好のチャンスなのにESP-WROOM-32の
記事書かないのですって?
あああれね…去年の時点で飽きました・・・今更になって弄ってるとか時代遅れですよぅ!(挑発


今回はS.M.A.R.T.(以下SMARTと記)対応のSDカードからSMART情報を読み出してみます。
別にF7じゃなくてもよいのですけど次回以降のネタに繋がる内容なのでしばし御静観願います。
今回もSTM32F746G-Discoveryを使います

工業用のSDカードの中にはSSDやHDDのようにSMARTの情報が取れる希有なものが存在
しております。残念ながら一般に購入出来る民生向けSDカードではそのような機能は
搭載されておらず、SMART対応どころか工業用SDカードも入手がごく限られております。
もちろん値段も民生品に比べ極めて高価です。

なんで高価かと言うとカードの動作に関する"信頼性"を保証しているからにつきます。
皆さんご存知の通り2017年現在市販で流通しているSDカードは明記が無い限りはTLC
タイプのNANDフラッシュメモリが使用されており、TLCというのはSLCやMLCに比べて
大容量が取れる割にデータ保持のための寿命が短い、また書き換えできる回数も極端に
短いという代物となっております。

一方工業用SDカードは4GB以下はSLC,それ以上の容量でもMLCを保証しており(容量を
犠牲にして疑似的にSLC風の動作をするpSLCやaMLCなんで奴もありますが) さらにSDカ
ード内コントローラのファームウェアもデータ保護に特化した特別となっております。
たとえばECCチェック機能とかパワーダウンプロテクションとかオートリフレッシュ機能
とかバッドブロックマネージメント、ダイナミック+スタティックウエアレベリング等々
いろいろありますが、実はこれTLCカードを世に出すために必須の技術でそれが耐久性が
もともと高いSLCやMLCを使用した工業用製品にフィードバックされて最強に強まった
信頼性を謳うわけです。

というわけでこれらの機能実装は最早当たり前となった今、カードの健康情報を
把握するための機構を仕込む事が新たな付加価値として注目されており、各社で
SMARTもしくは独自の寿命診断を組み込んだ工業用SDカードが販売されております。


で、われわれホビイストが問題となるのはその工業用SDカードの入手から始まりさらに
SMART情報を取得するための"情報"を入手し利用せしめるまでに多くの壁がある
ことです!

まずDigikeyやmouser,RSの海外在庫くらいからしか工業用カードの入手法が日本
国内からではまず困難で、さらにSMART対応と謳っていてもカタログの隅っこに(※オプシ
ョン対応)とか書いてあったりして高い金出して購入したのに目当てのSMART機能が
実は搭載されてなかったとか悲惨なことがほとんどです。

それでやっと入手にこぎつけたとしてもSMART情報を取得するための手段やツールは
公開されておらずメーカに直接問い合わせることになりますがほとんどの場合対企業間
の問い合わせにしか対応してなかったり(もちろん個人事業主として問い合わせても
THE・シカト)、SDAのライセンスに加入していないと情報を渡すことができないよなど
つっけんどんの反応しかもらえません。

ねむいさんも方々に手を尽くしましたが個人レベルではなしのつぶてて困り果てていまし
たが灯台下暗し、DELKINというメーカの工業用SDカードを扱っている代理店が日本
国内に存在しておりました
。こちらは在庫があれば一枚から対応(無ければ受注生産
20枚単位)というホビイストにもうれしい対応でしたので早速1GB品を注文し、ゲッツ
しました。



でかいDELKIN箱に小さいMicroSDが対照的です。


今となっては微々たる容量の1GB、見た目も普通のMicroSDカードですが…
このDELKINのU331というシリーズは中身は某粉飾決算にチャレンジしたおかげで
倒産寸前の日本メーカのSLC型NANDフラッシュが使用されております!
なにルネサスより先に死んでんだよ東芝!!11!11!!1!!!!!!
動作温度範囲もやたらと広くて-40~+85度まで保証しております。

ひとまずUSB接続のカードリーダーに接続してパフォーマンスを見てみました

規格的には"2GB以下のSDSC"に位置するカードなのでUHS-1とかには対応しておらず
理論上最大でも25MB/Secの転送スピードとなりますがマイコンで使用する限りでは
ハイスピードモード(最大SCLK=50MHz)に対応さえしてれば全く問題ないです。


SMART情報をPC経由で取得するために"USBカードリーダ"を用いて"DELKIN DashBoard"
なるアプリケーションを使用する必要があります。
ねむいさんの持っているTranscend製のUSB3.0カードリーダーは無事にSMART情報を
読み出すことができました。やったぜ!
どういう理屈でSMART読み出してるかしらないけど(伏線)

ちなみに"DELKIN DashBoard"の動作保証しているDELKIN製カードリーダーは上記の
ねむいさんのもってるTranscendのとまったく同じチップが使用されております。



お次はSTM32を使って動作させてみます。

FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Dec 6 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 14338 kB/sec.
>ds 0
rc=0
Drive size: 1947648 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 5E 00 32 5B 59 A3 B6 FF FF FF 80 0A 40 00 6D .^.2[Y.......@.m
CID:
00000000 58 44 44 44 44 49 4E 43 30 6D 6D D4 59 01 0C 49 XDDDDINC0mm.Y..I

Parsing SD CID Register
Manufacturer ID :0x58
OEM/Application ID :DD
Product Name :DDINC
Product HwRev :3
Product SwRev :0
Serial Number :0x6D6DD459
DateCode.Month :12
DateCode.Year :2016

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 03 03 90 02 00 AB 00 00 .......(........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 25 80 00 01 00 00 00 .%......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :2
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDSC Card!
Available NS(or HS) Mode Only.
>

先ずはいつものでSDカードの情報を読み出してみました(これだけSTM32F429を使用)
2016年製!
ATPの工業用カードでもそうでしたが現在はW/R性能はSDカード内コントローラの
ファーム次第なのでSLCとはいえ転送速度がめちゃくちゃ早いとは言えません。
どちらかと言うとSLCを使う理由は速さよりもデータの確実性を求める方向に概念が
遷移していると感じます。


そしてついにSTM32F7-Discoveryを使いSMART情報の読み出しに掛かります!
このDELKINのカードはSDカードに昔から存在するCMD56という"汎用コマンド"を用い
てSMART情報の取得を行います。SMART情報を取得する方法は各社バラッバラで門外
不出の所もありますがDELKINは"CMD56でSMART採れるYO!"と公言しているためかなり
フレンドリーと感じます。

この"CMD56"は引数によってデータの受信送信を変えることができるコマンドでCMD17等の
シングルブロック転送と同様最小512Byte単位でやり取りをおこないます。
DELKINカードにおいては特別な引数で、ある一定の順番で、CMD56の送受信動作を
行うことにより目的とするSMARTの情報を得ることができました。





DelkinDashboardとCMD56で読みだしたSMART直値をUARTに吐かせて値の
比較です。カードに何らかの書き込み動作を行うと電源再投入時にDashboardの
"TotalPowerupCount"に相当するSMART直値が更新されているので正しく
SMARTが読めていると判断しました。
ところで具体的にどうやってCMD56投げたのと知りたい方がいると思いますが対価を
払って得た情報ゆえこのぶろぐ上で詳しく公表できませんが…
…おや?このデータシートDELKINと関係ないのになんだかそっくりだー(棒読み


詳しくは言えませんが512バイト分のSMART情報のフッタに相当する部分のデータが
CIDの情報と一致しておりました。何かのvalidationに使うのでしょうか(棒読み
まぁあまり重要な情報ではないでしょう(伏線




このDELKINカードを選んだ理由は拙作のSTM32Primer2を使ったGNSSロガー
信頼性向上につきます。一度Primer2の筐体中に組み込んでしまうと構造上
ケースの中にカードが封印されてしまうため簡単に取り出せなくなるのでSDカードの
寿命診断を何らかの形で外部から行いたいと思いSMARTが取れるカードを選んだ…
と言う経緯です。
次回のちょっとネタバレになりますがこのGNSSTrackerのマスストレージモードでも
DelkinDashboardを使いSMARTの取得に成功しています。
なんでCMD56発行してないのにSMART採れるんでしょうね(意味深


願わくばSMARTを利用した寿命診断機能がSDAで正式に規格化され、民生用の
SDカードでも気軽に寿命診断できる素敵な時代が来るようになることを願います。

だからSDAの中の人のPanasonicさん頼みますよ!
なぜか不自然なくらいパナ推しのねむいさん。






ここでねむいさんFAQ特別編
Q:ねむいさんねむいさん、確実にSLCのカードを見極める方法を教えてくださいっ!
A:
 SLCってカードにでかでかと書いてあるカード選べばOKです☆

STM32F7を使ってみる14 -HS ULPIでUSB-MSCを使ってみる-

みなさまあけましておめでとうございます

今年もねむいさんほか虹裏メイドたちをごひいきにm( )m
今年はねむいさんのイラストが100枚くらい増えますように
↑本音




さて新年早々ですがHALライブラリにバグを見つけたので解説しようと思います。

遡る事約一ヶ月前、ねむいさんはSTM32F7で新しい事をやろうとCubeF7に同梱されて
いるUSBライブラリとそのExamplesたちに手をつけ始めていました。
STM32F746G-DiscoveryにはULPIとかついているのでUSB-MSC(MassStorageClass)の
実装を試みました。もちろんUSBのバス速度はHighSpeed(480Mbps)です。

幸いにもSTM32F746G-Discovery向けのサンプルコードもあったのでそれをねむいさん
謹製のいつものをベースに実装しようとしましたがUSBライブラリがDMA使ってるくせに
キャッシュの事全然考えてない作りでそれにブチ切れながらGCC向けに移植していまし
たが最終的にL1キャッシュがないと足を引っ張るSRAM1,SRAM2を使わずにノーウエイト
でアクセス出来るDTCM領域だけでがんばることにしました・・・orz

Ac6STM32用のプロジェクトファイルのリンカスクリプトもそうなってますし・・・フォーラムでも
奇跡の積み重ねで動いてると情けない指摘をされています。
HALライブラリみたいなバグだらけの変なものリリースしっ放しにしてないできっちり
バグつぶせYO!←って言ったらたくさん非難されていっぱい哀しい…


と言いつつも何とか動いて認識しました♥


もちろんeMMCとかもしっかり認識しちゃいます★


とおもったらまだ問題がありました…幾つかのカードでデータが正常に読み込めない
事がありました。


64GBのカードでも容量はしっかり見えてるんですけどね…なんか4GB以上データを詰め
てるカードで動作がへんなのです…

…4GB…?これって…

かつてUSB付きのARMマイコンでMSCのサンプルではカード容量を示す変数が
uint32_tで現わされていて4GB以上の容量を正しく表示できないという4GB問題が
ありました。対策は単純に容量を示す変数をuint32_tからuint64_tへ変えるだけの
ものなのですがUSBライブラリを見る限りではそれはちゃんと64ビット変数に
なっており問題がありませんでした。


しかしブロックアドレスにブロック容量を掛け算し代入してやがる式を見つけました。
指定するブロックアドレスによってはuint32_tで扱える範囲を超えてしまう可能性
があります。このscsi_blk_addrって奴なのですがまさか…まさか…


デデーン

思いっきりuint32_tじゃん…

ば っ か じ ゃ ね ぇ の ! ?
ねむいさんのむなしい叫び越えが夜の闇にこだまする。


ていうわけでscsi_blk_addrをuint64_t化すると4GB以上データ詰めている奴でも正常に
読み書きすることができるようになりました…なんちゅう初歩的な。

一応フォーラムにも報告しておきましたがSTM32フォーラムのguruとも呼ばれている
clive師より「ブロックアドレスをいれた変数にバイトアドレスに変換した値を放り
込むSTの昔っからのコーディング姿勢自体が愚。scsi_blk_addrの安易な64bit化は
不必要」と指摘されましたがねむいさんもごもっともだと思いました。



そんなわけで漸く正常に繋がるようになったので読み込み比較です。今回はUSBの
転送用に確保していると思われるバッファの容量を増やすことで転送スピードが
どこまで変わるか見てみました。


条件STM32F746G-Diacovery,USB-HS ULPI,最適化オプションは"-s"
132MBのmp3ファイルをFastcopyを使ってPCのRAMDISKへコピーする時の平均転送速度を記録。
SDのクロックはNS(24MHz)とHS(48MHz)で比較。


ある程度分かっていたことですがやはり容量を増やしていくと転送スピードは上がっ
ていきましたがある程度(16kb以上)以上で転送スピードは横ばいになることが分
かりました。これはNSとHSもほぼ同様の傾向なので16384byte以上パケット容量確保
してもそれ以上は余り効果がないことが分かります。まぁこれだけ速度出せたら御の
字でしょう。とにかく16384byte分確保しておけば何の問題もないですね。


ちなみに今回はお仕着せEclipse環境のAC6STM32で一旦プロジェクトをビルドして
ねむいさん環境に移植しましたが(単にリンカスクリプトをDTCMしか使わないように
しただけですけど)もっと性能の高いF769I-Discoveryで何で試さなかったの?と言う
話になるでしょうけど理由が…


CPUが対応してない・・・このせいでボード対応しててもビルドが通らないorz



やっぱ自分でmakefile書いてコマンドラインビルドが最強ですって☆

STM32F7を使ってみる13 -STM32F769I-Discoveryを動かしてみる2-

>ARM、禿に喰われる
>ARMはもう終りDA!

うろたえるな小僧共ー!

(↑C.V.牡羊座のシオン様で)

禿の習性からして中身ろくに見ないでまーた買い物のための買い物やっただけだから
アリババの時みたいにどうせすぐにリリースしちゃうでしょう。
ていうか"買収する"と言ってるだけで20160803の時点で買収が完了"した"とは
言ってないのでまだ禿に喰われてすらいない段階ですね。

こと電子工作で使用するARMマイコンの範囲においてはまったく何の影響も出ない
と思います。尤もARMが禿に衰退させられるような程度のジョンブル野郎だったの
ならねむいさんのほうからお断りで自然歩道一本に絞ってこのぶろぐ続けます。

というわけでこの件についていろいろ質問もらったので虹裏メイドねむいさんとしての
見解をさせていただきました。かしこ。

20160906追:
正式に買収完了と同時に上場廃止になりました。
ねむいさんとしても今後の禿の動向に注視いたします。
最悪のシナリオは小規模マイコン向けのコアIPが捨てられることです。
20160906追:


20170411追:
少し前の話ですが予想通り早々に4分の一を売却するそうです…
ねむいさんの予想以上に売るの速かったわ!
今度はアラビア風ARMになるのですね…
20170411追:




































すみませんうっかり本日のぶろぐ終わらせそうになってしまいました。

今回は主にSTM32F769I-Discoveryに実装されたAudioCodecを利用してサウンド
再生機能つけるべく頑張ってみました。

●STM32F4-Discoveryからのサウンド再生機能の移植

STM32F769I-Discoveryはご覧のとおりAudioCodec(WM8994)とは生粋のI2Sでは
無くSAI(SerialAudioInterface)のI2S機能から接続されています。
基本的なものはSTM32F4-Discoveryの時と同じなので基本的な部分を押さえつつ
F7のHALに合わせるよう移植していきました。


困ったのがサンプルレートから実際のI2S用のクロックを生成する関数で既存の
BSPの関数を流用すると何でか2倍速で再生してしまうという現象にぶち当たって
しまったことです。
これなんとなくHALのバグっぽいな〜と思っているのですがeMMC対応したとき
かなり時間を喰って懲りているので深追いはせず、自作のテーブルを参照して
適切なPLL値をPLLI2Sに付与する関数を経由させるようにしました。
ややこしいですがSAIのクロック元はPLLI2Sから供給しています。BSPもそのように
なっています。


ていうわけで2作業日くらいで移植完了です。
画像はmp3ファイルを再生しているところです。画面のIART,INAMはID3v1もしくは
ID3v2タグを解析し表示しております。aac,wavファイルも同様に再生できます。


最初にmp3を移植した頃は良く分からなくて実装していなかったのですが、ID3に
格納されている"UTF-16LE"の文字列をChaN氏のFatFsに収録されているff_convert()
関数を用いてS-JIS形式の2バイト文字に直して表示するようにしました。もちろん
ascii形式でも崩れないように対策済みです★
ていうかID3関連はかなり長い期間適当に作って放置しててID3タグ解析の段階でコケて
mp3/aac形式ファイルが再生できない場合があったのず〜〜〜〜〜〜っと放置してました
ごめんなさいごめんなさい!!!!!
STM32F4のほうも今回の修正は横展開しておきましたのでご安心ください。

STM32F769I-DiscoveryなんてもってないYO!という方もご安心ください!
makefileの定義を変えるだけで秋月さんのところで購入できるSTM32F746G-Discovery
でも同じようにオーディオファイルの再生が可能です!



そいえばビットレートが高いデータをサーキュラDMAでバリバリ送る使い方すると
SDIO/SDMMCのDMA転送に干渉してコケる問題はSTM32F7になっても解消されていない
のでmp3/aac/wav形式対応にした場合SDMMCはDMAでは無くFIFOのポーリングで転送
するようにしておりますorz

さらにポーリングの場合はSDIOのクロック周波数が高い場合受信時のアンダー
フローが起こりやすいのでハードウエアフローコントロールを有効にするように
しました。STM32F4ではエラッタで使用不可とされてきましたがF7シリーズでは
解禁です★

さらにさらにですが昨年STM32F4で行ったアライメントズレ対策をSTM32F7に展開
して実装した際に大バグを作りこんでいた事が発覚しコレも修正しています・・・
一年以上ほっぽっていましたが皆raspberryに逝っちゃってSTM32F7に見向きも
しなかったのでばれずに助かりました・・・これもID3タグ解析の実装見直したときに発覚orz



●画面がでかくなったからでかいサイズの動画再生してみる
ChaNさんのLPC2388向けFatFs移植例には独自形式で動画を再生できる機能がありま
した。ねむいさんはこれを他マイコン向けに拡張しつつ使い続けてきました。

STM32F769I-Disccoveryになって画面サイズが800x480に一気に広がったので、
少しデカめのファイルを作ってちゃれんぢです。

とある動画からAVCフォーマットでエンコードされたmp4形式のファイルをAviutilで
無圧縮aviにしてそこからChaN氏のツールで独自形式のファイルに直します。

ちなみに独自形式に変換するavi2imgはChaN氏のFatFs実装例ffsample.zip内¥lpc23xx¥tools¥にあります。
今回のねむいさんの移植例ではDMA2Dの関係でビッグエンディアンが要求されるので
avi2imgを自前でビルドしなおさなければなりません。さらに最大サイズも変更する必要が
あります。真似される方はご注意ください。


再生するプログラムのほうも少し手を加えました。
ファイル名と現在フレーム/総フレームを表示できるようにしておきました。

また、display_basis.hのENABLE_PERFORMANCE_MEASUREMENTのdefineを有効にすると
上記の代わりに一秒あたりのフレーム数を表示できるようにしました。


この動画は640x360サイズあります。一ドットあたりRGB565の16bit=2バイトあるので
一画面あたりのバッファサイズは640*360*2=460800byte必要です。そこから30fpsの
動画を表示せしめようとしたら460800*30=13824000(byte),つまり約13.8MByte/Sec
の速度で読み出さないといけないためSDMMCのNomalSpeedMode(MAX12.5MByte/Sec)
ではまったく歯が立ちません。


この動画はオリジナルは29.97fpsとなっており、そこから生成されるimgファイルも
同じく29.97fpsのためノーマルスピード(ねむいさんの移植例ではSDMMC用のベース
クロックがPLLSAIから生成される48MHzからのため最大12MByte/Sec)では先に述べた
とおりまったく足らず20fps前後しか出ません。


SDMMCのクロックをハイスピードモード対応(ねむいさんの移植例では最大24MByte/Sec)
にすると転送が余裕で間に合うためきっちり29.97fpsが出ます♥
う↑ま↓ぃ↑やったぜー
さすがにこれ以上のサイズだと転送サイズも肥大化していくためスムーズな再生は
難しくなりますがねむいさんはタイチョウの作る動画がオリジナルサイズとFPSで再生でき
ればそれで満足なのでコレでよしとします。ぜんぜんよくないですけど。
使用するSDカードそのものの転送速度も重要になるはずなのでこちらを熟読して、
私の真似される方はカードもしっかり選んでみてください。







・・・ぇ?元の動画を見てみたいですって?・・・まあ別にいいですけど動画内コメントに
警告がありますが桁外れにヤバイ内容なので無理だと感じた方はすぐにブラウザを
閉じて退避した方がいいと思います

"すぐに"を具体的に言うと最初の3フレームめまでです。時間で言うと100mSec以下の
反応速度でブラウザを閉じれば安全となります。ねむいさんのぶろぐを会社や学校
から見ているクレイジーな方々はuSecオーダーで超反応できる人間だらけなので
多分大丈夫と思います。ちなみにねむいさんのSTM32F7のサンプルから再生した場合、
タッチパネルの読み込みが100mSec間隔のため逃れられません。覚悟してください。

ねむいさん的にはゼEROの中でもコレはテーマ性・ストーリー性・変態性・音楽性・
危険性・テンポ・○ンポの全てが危険水準を大きく逸脱した迷作中の冥作であり、
634タイチョウの無限の可能性と危険性を垣間見ることが出来る貴重な作品であると確信
しているのですがリアルタイムで投下されたときはこの人本当に気が狂ってしまった!
と思ったのですがこんなヤバイ動画ばっかり作っててラブライバーに自爆テロ食ら
わないのかYO!大丈夫か曜!とか思っているのですがねむいさんもイケナイお口のほむコラばっかり
やっててやってる事あんまし変わらないかもと思っているのです!
が!
虹裏メイドねむいさんは「ラブライブ!サンシャイン!!」を応援しております!
.見ないと注↑射↓なんですぅ♥










戯言はこの辺にしてちょっと早いですが上記の更新を追加したSTM32F7のいつもの
をいつもの場所に上げておきます
。この一ヶ月間でFatFsにも大量にぱっちが
当たってR0.12aになっていますので全て適用しております★
上のほうでも述べましたがSTM32F4にも横展開しましたのでSTM32F4-Discovery
しかもっていない・・・!なんていう方も安心です♥


次回は真面目にブログ更新します!!!!!!!!!!!

STM32F7を使ってみる12 -STM32F769I-Discoveryを動かしてみる-




超忙しい状態が続いてるせいかせっかく買ったのに半月ほど寝かせてたらその間に
円安が進んで損したF**K!!

それはおいといてSTM32F769I-Discoveryを私も手に入れました★昨年販売された
STM32F746G-Discoveryを機能的に踏襲しつつ新たな機能が更に盛り込まれています。


今回の目玉はMCUのF7系最強のSTM32F769Iなわけですが、今回ついに、ついに倍精度
浮動小数点ユニットが搭載されることとなりました!!長かった・・・
ついでに細かいCortex-M7のエラッタがさりげなく直されていますがあとで紹介します。



ハードウエア的には前回は16bit分減らされて容量も半分しか使えなかったSDRAMが
32bit分全開使えて容量もアップした事とすっかりおなじみになったQSPIも64Mbyte品
に容量アップでまさに最強に強まっています!!!


では早速電源投入を・・・
・・・ぁ・・・microUSBコネクタだ・・・


microUSBケーブルを引っ張り出してきて改めて電源投入!


なんかTouchGFXというのとEmbeddedWizardとかいうのが新たにメニューに追加
されていますね。


TouchGFXのBirdtheCoinとかいうのをやってみましょ


・・・!!!
クソゲーすぎる・・・
DMA2Dのパフォーマンステスト兼ねてるみたいですね。


さてお次はEmbeddedWizardです


容量性タッチパネルコントローラの機能を最大限に生かした入力デモが利用できます。


このようなオシロ風表示もらくらくです★




お遊びはこの辺にして私のいつものをF769Iに移植してみました。

移植に関してですがF746シリーズと決定的に違う点は内蔵RAMが増量、PLL-Rが追加
されているのと倍精度浮動小数点演算ユニットの対応です。
newlibで倍精度演算ライブラリを利用できるようにするためにはGCCコンパイラに
"-mfloat-abi=hard -mfpu=fpv5-d16"を渡すべきです。

後は液晶表示のためのペリフェラルがRGBでは無くDSIを利用している点です。
DSIは速度が速すぎるため、他ポートとの兼用はしておらず完全独立しております!
DSIの叩き方等の見本はBSPが充実していますのでライセンスに乗っ取ってまるっと
利用させてもらいます。

そんでもってSDMMCのポートは二つに増えましたがこのボードではSDMMC2のみを
SDカード用のポートとして利用していますのでこちらに替えるようにします。


そしてOpenOCDでビルドしたバイナリを焼く・・・!
ねむいさんのおきぱのOpenOCDバイナリはSTM32F76x/77x系にすでに対応しています★


いつものが無事起動しました。SDカードもしっかり見えてディレクトリを読めています!


libjpeg,giflib,libpng等の画像デコードもいつものように無事に表示できてます♥
でも展開時の表示がなんかもたついてる感じがするんですよね・・・
解像度が800x480に上がったせいかはたまたDSIとDMA2Dの連携が上手くいってないのか
この辺の調査は次回に繰り越します。


あと今回重要なポイントは冒頭で述べたCortex-M7コアのエラッタでデバッグ時に
ペンディングビットが立った状態だとブレークポイント張ってないのにもかかわらず
強制的にその割り込み処理の先頭でブレークしてしまうと言うちょっと厄介な
エラッタが修正されています。
画像はF746におけるUART割り込みでブレークポイント無効なのに何故かUARTの割り
込み処理の先頭でとまっちゃているのが分かると思います。


というところで駆け足で紹介しましたが今からF7に入門される人たちは上記エラッタが
修正されたSTM32F769が搭載されているSTM32F769I-Discoveryを購入して遊ぶのが
最も最適かと思います。

んでもって私のF7のサンプルはすでにSTM32F769I-Discoveryに対応している(もちろんmake
fileの設定でF746-G化も可能です)ので手前味噌でありますがどしどしご利用ください!


STM32F4シリーズを使ってみる15 - FatFsとSDカード再考その4(SDカードを手当たりしだい読み出してみる) -

一年以上ぶりの企画になってしまいましたが前回の続きです。
STM32F4を使ってSDカードのカード情報を読み出したり読み取り速度の比較を行います。


とりあえず手持ちのカードを全部!!!

MMCから始まり10年以上前のSDカードや最新のSDXCまで網羅します!!


条件は以下のとおりとします。
・各カードはあらかじめSDFormatterでFAT32でフォーマットする。
 64GB以上のSDXCもHardDiskManagerで無理やりFAT32でフォーマットします。
・プログラムはSTM32F4版のいつものの3/31日版とします。
・使用するボードは180MHzで動作可能なSTM32F427IIT6が乗った
 STM32F4全部乗せボードを使用します。
・SDのクロックはハイスピードモードとします。このボードでは
 SDIO_CLKの最高クロック周波数は51.43MHzとなります。
 また、SDIOの転送にはDMAを使用します。
・読み出し速度は132949600Byteのファイルのシーケンシャル読み出しの速度を
 比較します(128MBのMMCv3を除く)。また、ねむいさん的には読み出ししか興味
 ないので書き込み比較はやりません。


それでははじめましょう!


●Toshiba製eMMCv5 8GB

まずは前回のおさらい、Toshiba製のeMMC8GBです。

FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 22961 kB/sec.
>ds 0
rc=0
Drive size: 15269888 sectors
Erase block size: 1024 sectors
Default r/w block size: 512 bytes
Card type: MMC(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..
CID:
00000000 11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..

Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0>
Product Name :008GE0
Product Rev :0.0
Serial Number :0x5ADD4140
DateCode.Month :11
DateCode.Year :2015

Detected as MMCv5.0x Device!
OCR:
00000000 C0 FF 80 80 ....

読み出し速度が22961kByte/SecとSDカードを抑えてダントツに早いです!


●Transcend製2GB MMCplus
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21261 kB/sec.
>ds 0
rc=0
Drive size: 3939328 sectors
Erase block size: 256 sectors
Default r/w block size: 1024 bytes
Card type: MMC(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?
CID:
00000000 37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.

Parsing MMC CID Register
Manufacturer ID :0x37
OEM/Application ID :��
Product Name :MMC02G
Product Rev :1.0
Serial Number :0xF3026750
DateCode.Month :2
DateCode.Year :2009

Detected as MMCv4.0 Device!
OCR:
00000000 80 FF 80 80 ....

こちらもなかなかのお手前で。


●日本製MMCv3カード
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fl
D---- 2016/03/14 23:28 0 .
D---- 2016/03/14 23:28 0 ..
----A 2010/03/13 20:06 44679600 ftbt.mp3
1 File(s), 44679600 bytes total
2 Dir(s), 83640320 bytes free
>fr 44679600
44679600 bytes read with 1904 kB/sec.
>ds 0
rc=0
Drive size: 250880 sectors
Erase block size: 32 sectors
Default r/w block size: 512 bytes
Card type: MMC(Byte)
SpeedMode: NomalSpeedMode(17.14MHz)
DataBusWidth: 1bit

CSD:
00000000 8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}
CID:
00000000 11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}

Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0><0>
Product Name :0128M2
Product Rev :0.10
Serial Number :0x0580FECB
DateCode.Month :2
DateCode.Year :2005

Detected as MMCv3.xx Card!
OCR:
00000000 80 FF 80 00 ....

MMCv3は20MHz以下のクロックでなければいけないのでそれを守っています。
20MHz以上では確かに動作しませんでした。

ここから先はSDカードです。


●Transcend製x600のMicroSDHC8GB(TS8GUSDHC10U1)


昨年末に紹介したMLCアピールの奴です。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20025 kB/sec.
>ds 0
rc=0
Drive size: 15759360 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 3C 1D 7F 80 0A 40 00 63 @..2[Y..<....@.c
CID:
00000000 74 4A 60 55 53 44 55 31 20 3B A1 5F AA 00 F6 25 tJ`USDU1 ;._...%

Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :USDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x3BA15FAA
DateCode.Month :6
DateCode.Year :2015

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 08 11 39 00 ..............9.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

結構読み出しが早いですね。SDカードでは20000kB/Sec以上だと
早い部類です。


●Transcend製x600のSDHC32GB(TS32GSDHC10U1)

今度はさっきの32GB版、かつ通常サイズのものです。
今年春までTG-3の撮影用記録媒体として活躍していました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18130 kB/sec.
>ds 0
rc=0
Drive size: 63272960 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 F1 5D 7F 80 0A 40 00 79 @..2[Y...]...@.y
CID:
00000000 74 4A 60 53 44 55 31 20 20 46 F9 B9 1D 00 F5 67 tJ`SDU1 F.....g

Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :SDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x46F9B91D
DateCode.Month :5
DateCode.Year :2015

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 00 ..............9.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

まずまずですね。


●Transcend製MicroSDHC8GB

普通の廉価版の奴です。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15279 kB/sec.
>ds 0
rc=0
Drive size: 15456256 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 3A F5 7F 80 0A 40 00 43 @..2[Y..:....@.C
CID:
00000000 74 4A 45 55 53 44 55 31 02 05 B0 00 60 00 D1 E3 tJEUSDU1....`...

Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :JE
Product Name :USDU1
Product HwRev :0
Product SwRev :2
Serial Number :0x05B00060
DateCode.Month :1
DateCode.Year :2013

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 08 11 19 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

廉価版だけに速度はそれなりです。


●SuperTalent MicroSDHC 4GB

お店で同容量比で最安値に近い値段で買えたSupterTalentのSDカードです。
たしか780円でした。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 13677 kB/sec.
>ds 0
rc=0
Drive size: 7841792 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 1D E9 7F 80 0A 40 00 69 @..2[Y.......@.i
CID:
00000000 73 42 47 4E 43 61 72 64 10 19 23 6D 71 00 BB 81 sBGNCard..#mq...

Parsing SD CID Register
Manufacturer ID :0x73
OEM/Application ID :BG
Product Name :NCard
Product HwRev :1
Product SwRev :0
Serial Number :0x19236D71
DateCode.Month :11
DateCode.Year :2011

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

リードが13MB/Sec・・・ダメダメですね。


●SuperTalent MicroSDXC64GB(FAT32 Format)

続いては64GB版のSDXCの奴です。フォーマットは無理やりFAT32で
行ったうえで試しました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15772 kB/sec.
>ds 0
rc=0
Drive size: 125302784 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 01 DD FD 7F 80 0A 40 00 07 @..2[Y.......@..
CID:
00000000 28 42 45 20 20 20 20 20 02 00 33 3C 22 00 FA D3 (BE ..3<"...

Parsing SD CID Register
Manufacturer ID :0x28
OEM/Application ID :BE
Product Name :
Product HwRev :0
Product SwRev :2
Serial Number :0x00333C22
DateCode.Month :10
DateCode.Year :2015

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 08 11 19 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 80 03 00 00 00 00 .E......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :4
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDXC Card!

4GBの奴よりマシなものの15MB/Secちょっと・・やっぱしダメですね・・・
ちなみにSCRの値が示すとおりちゃんとSDXCとして認識できているので
カードとしてはれっきとしたSDXCです。

SDHCとSDXCの見分け方は容量のほかにSCRのSD Securityのバージョンから
分別することも可能です。


●KingMAX MicroSDHC32GB

こちらも廉価で替えるカードの筆頭です。
当時ちょっと値が張った32GBをFatFsの動作確認用に購入していました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 13668 kB/sec.
>ds 0
rc=0
Drive size: 62683136 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 EF 1D 7F 80 0A 40 00 27 @..2[Y.......@.'
CID:
00000000 13 4B 47 53 44 33 32 47 10 C2 00 51 1A 00 C7 A3 .KGSD32G...Q....

Parsing SD CID Register
Manufacturer ID :0x13
OEM/Application ID :KG
Product Name :SD32G
Product HwRev :1
Product SwRev :0
Serial Number :0xC200511A
DateCode.Month :7
DateCode.Year :2012

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

SuperTalentと同じ13MB/Sec...ダメダコリャ


●Toshiba EXCERIA 16GB Type2国内正規版

こちらはTG-3の購入と同時に購入した国内の正規品です。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21617 kB/sec.
>ds 0
rc=0
Drive size: 30867456 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 75 BF 7F 80 0A 40 00 93 @..2[Y..u....@..
CID:
00000000 02 54 4D 53 44 31 36 47 86 DE 58 C2 6E 00 E3 23 .TMSD16G..X.n..#

Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :SD16G
Product HwRev :8
Product SwRev :6
Serial Number :0xDE58C26E
DateCode.Month :3
DateCode.Year :2014

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 04 00 00 00 04 03 90 02 00 06 1A 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 80 03 32 02 23 82 ....2.#.

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

20MB/Sec越えです・・・やったね☆
値段張った甲斐がありました・・・


●Toshiba EXCERIA MicroSDHC32GB 並行輸入版


今度は並行輸入版の奴です。高速の信号のやり取りを意識してか
いかなる変換アダプターも使用不可と警告がありました。ねむいさんの
使用法では高々50MHzぽっちなので別に関係ありませんが。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 22154 kB/sec.
>ds 0
rc=0
Drive size: 61079552 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 E8 FF 7F 80 0A 40 00 AF @..2[Y.......@..
CID:
00000000 02 54 4D 55 43 30 44 33 20 E9 C2 CF A5 00 EC 01 .TMUC0D3 .......

Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :UC0D3
Product HwRev :2
Product SwRev :0
Serial Number :0xE9C2CFA5
DateCode.Month :12
DateCode.Year :2014

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 02 02 90 02 00 06 3C 00 ..............<.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 84 03 32 02 29 02 ....2.).

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Security :3
SD Bus Width :5

SD_Spec V4.xx!
Detected as SDHC Card!

おおっ!東芝のeMMCv5に匹敵するスピードですよぅ!!
こいつはオススメです☆


●Toshiba8GB MicroSDHC

廉価な東芝製のmicroSDHCです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20202 kB/sec.
>ds 0
rc=0
Drive size: 15564800 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 3B 5F 7F 80 0A 40 00 75 @..2[Y..;_...@.u
CID:
00000000 02 54 4D 53 44 30 38 47 56 C0 14 C0 4F 00 B1 C5 .TMSD08GV...O...

Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :SD08G
Product HwRev :5
Product SwRev :6
Serial Number :0xC014C04F
DateCode.Month :1
DateCode.Year :2011

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 03 90 08 00 F2 19 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 80 03 28 03 51 02 ....(.Q.

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

これもなかなかですね〜


●Panasonic 2GB MicroSD

380円でたたき売りされていたMicroSDです。
STM32Primer2用に控えで購入していました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 10776 kB/sec.
>ds 0
rc=0
Drive size: 3862528 sectors
Erase block size: 8192 sectors
Default r/w block size: 1024 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 7F FF 32 5F 5A 83 AE F6 DB DF FF 8E 80 00 4B ...2_Z.........K
CID:
00000000 01 50 41 53 30 32 47 46 12 43 20 E0 52 00 B6 E1 .PAS02GF.C .R...

Parsing SD CID Register
Manufacturer ID :0x1
OEM/Application ID :PA
Product Name :S02GF
Product HwRev :1
Product SwRev :2
Serial Number :0x4320E052
DateCode.Month :6
DateCode.Year :2011

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 02 02 90 00 10 05 00 00 .......(........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 25 00 00 00 F0 02 10 .%......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5

SD_Spec V2.00!
Detected as SDSC Card!

まぁこんなものですね・・・


●Panasonicの512MBSLC金色カード

これは他の奴らとは一味違います!!!
Panasonic製の工業用SDカードです!!!
そしてTLCが全盛になった今希少なS・L・C!!!!
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 17939 kB/sec.
>ds 0
rc=0
Drive size: 967680 sectors
Erase block size: 4096 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 0E 01 32 5B 59 81 D8 7F FF FF FF 12 40 00 FD ...2[Y.......@..
CID:
00000000 01 50 41 52 46 35 31 32 23 74 EF 95 6D 00 F6 B9 .PARF512#t..m...

Parsing SD CID Register
Manufacturer ID :0x1
OEM/Application ID :PA
Product Name :RF512
Product HwRev :2
Product SwRev :3
Serial Number :0x74EF956D
DateCode.Month :6
DateCode.Year :2015

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 14 03 03 80 00 08 07 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 98 DC 90 26 76 16 08 ............&v..
00000020 01 00 93 02 41 12 22 00 00 00 00 00 00 00 00 40 ....A."........@
00000030 29 29 00 00 10 20 82 88 00 01 C6 00 00 00 17 1F ))... ..........
SCR:
00000000 02 A5 80 00 01 F0 01 01 ........

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDSC Card!

あり・・・普通だ・・・ま、まぁ工業用ですからピーキーな性能よりも
安定性とかソッチのほうがすごいのでしょうね(脂汗)


●名も無き16GB MicroSDHC

1078円でたたき売りされていたMicroSDHCです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18257 kB/sec.
>ds 0
rc=0
Drive size: 31275008 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 77 4D 7F 80 0A 40 00 9D @..2[Y..wM...@..
CID:
00000000 28 42 45 48 30 33 30 39 10 00 00 19 C9 00 B1 ED (BEH0309........

Parsing SD CID Register
Manufacturer ID :0x28
OEM/Application ID :BE
Product Name :H0309
Product HwRev :1
Product SwRev :0
Serial Number :0x000019C9
DateCode.Month :1
DateCode.Year :2011

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 04 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

・・・たたき売りのくせにやるじゃない(ニヤ


●名も無き256MBMicroSD

こちらは10年位前に6800円で購入した古の256MBのカードです。
まだまだ現役バリバリなのですよぅ
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 12321 kB/sec.
>ds 0
rc=0
Drive size: 499712 sectors
Erase block size: 128 sectors
Default r/w block size: 512 bytes
Card type: SDv1
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 5E 00 32 57 59 83 CF ED B6 FF 87 96 40 00 D3 .^.2WY.......@..
CID:
00000000 4B 46 4D 53 44 20 20 20 10 03 00 25 63 00 69 7D KFMSD ...%c.i}

Parsing SD CID Register
Manufacturer ID :0x4B
OEM/Application ID :FM
Product Name :SD
Product HwRev :1
Product SwRev :0
Serial Number :0x03002563
DateCode.Month :9
DateCode.Year :2006

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 .......(........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 01 25 00 00 00 00 00 00 .%......

Parsing SCR
SD Spec Version :1
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5

SD_Spec V1.10!
Detected as SDSC Card!

大昔のカードなのでSDのバージョンは1.10です。
このカードはBIOSの更新用ブートメモリとしてUSBカードリーダと
組み合わせて今でも使用しております。


●RiDATA 256MB MiniSD

そして更に昔の11年前にMP3プレーヤー用に購入したMiniSDのカードです!
確か9870円くらいで買ったと思いました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 7666 kB/sec.
>ds 0
rc=0
Drive size: 492544 sectors
Erase block size: 128 sectors
Default r/w block size: 512 bytes
Card type: SDv1
SpeedMode: NomalSpeedMode(25.72MHz)
DataBusWidth: 4bit

CSD:
00000000 00 7F 00 32 13 59 81 E0 EE BB 3F FF 16 40 00 E9 ...2.Y....?..@..
CID:
00000000 04 00 00 53 44 00 00 2A 10 00 00 03 3A 00 48 97 ...SD..*....:.H.

Parsing SD CID Register
Manufacturer ID :0x4
OEM/Application ID :<0><0>
Product Name :SD<0><0>*
Product HwRev :1
Product SwRev :0
Serial Number :0x0000033A
DateCode.Month :8
DateCode.Year :2004

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 14 00 00 00 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 00 A5 00 00 00 00 00 00 ........

Parsing SCR
SD Spec Version :0
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5

SD_Spec V1.0x!
Detected as SDSC Card!

なんとSDのバージョンはHighSpeedModeにすら対応していないV1.0です・・・
私が持つ最古のSDカードです。


●ATP ProMAX MiniSD 1GB x150

ねむいさんイチオシのメーカーATP製のカードです。
こちらは箱にSLCと明記されておりました。15000円くらいでヨドバシで
買った記憶があります。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 19499 kB/sec.
>ds 0
rc=0
Drive size: 1999872 sectors
Erase block size: 128 sectors
Default r/w block size: 512 bytes
Card type: SDv1
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 5E 00 32 5F 59 83 D0 6D B7 FF 9F 96 40 00 8F .^.2_Y..m....@..
CID:
00000000 09 41 50 41 46 4D 44 50 10 45 30 00 C2 00 63 DD .APAFMDP.E0...c.

Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :AFMDP
Product HwRev :1
Product SwRev :0
Serial Number :0x453000C2
DateCode.Month :3
DateCode.Year :2006

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 38 00 00 00 00 00 00 00 00 .......8........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 01 25 00 00 00 00 00 00 .%......

Parsing SCR
SD Spec Version :1
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5

SD_Spec V1.10!
Detected as SDSC Card!

やりますね〜!


●ATP MicroSDHC4GB MLC (AF4GUD-ATP023)

こちらはSTM32F4のいつもので使用しているおなじみのATPのMicroSDHCです。
一般用なのでMLCです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21173 kB/sec.
>ds 0
rc=0
Drive size: 7861248 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5F 59 00 00 1D FC 7F 80 0A 40 00 97 @..2_Y.......@..
CID:
00000000 09 41 50 41 46 20 55 44 10 26 3B 15 32 00 83 A5 .APAF UD.&;.2...

Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :AF UD
Product HwRev :1
Product SwRev :0
Serial Number :0x263B1532
DateCode.Month :3
DateCode.Year :2008

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 00 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V2.00!
Detected as SDHC Card!

速度も文句なし!


●ATP MicroSDHC4GB SLC (AF4GUDI-5ABXX)

そして同じATPの工業用のMicroSDHCです!!!!!
もちろんSLCなのですよぅ!実力やいかに!?
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16330 kB/sec.
>ds 0
rc=0
Drive size: 7892992 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 1E 1B 7F 80 0A 40 00 B1 @..2[Y.......@..
CID:
00000000 09 41 50 41 46 20 55 44 10 12 60 75 7A 00 F2 39 .APAF UD..`uz..9

Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :AF UD
Product HwRev :1
Product SwRev :0
Serial Number :0x1260757A
DateCode.Month :2
DateCode.Year :2015

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 00 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V2.00!
Detected as SDHC Card!

ぁ・・・あれ・・・?ま、まぁ工業用ですからピーキーな
性能よりも安定性を強化しているのでしょう(脂汗)
大事な事なので二度言いました。


●Sandisk Ultra8GB MicroSDHC

トリはSanDiskのSDカードたちです!
偽者が乱舞するSandisk製ですがねむいさんいちおうちゃんとしたお店で
買っているので偽者には引っかかっておりません・・・はず・・・
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16421 kB/sec.
>ds 0
rc=0
Drive size: 15523840 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.
CID:
00000000 03 53 44 53 55 30 38 47 80 02 37 95 01 00 C6 87 .SDSU08G..7.....

Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SU08G
Product HwRev :8
Product SwRev :0
Serial Number :0x02379501
DateCode.Month :6
DateCode.Year :2012

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 01 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

ふつー・・・


●Sandisk Ultra 8GB SDHC

このカードはお尻にUSBの端子が付いていてUSBメモリとしても機能します。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 14268 kB/sec.
>ds 0
rc=0
Drive size: 15954944 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 3C DC 7F 80 0A 40 40 C5 @..2[Y..<....@@.
CID:
00000000 03 53 44 53 44 30 38 47 80 01 9C 01 36 00 84 65 .SDSD08G....6..e

Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SD08G
Product HwRev :8
Product SwRev :0
Serial Number :0x019C0136
DateCode.Month :4
DateCode.Year :2008

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 02 02 90 00 0B 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 00 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V2.00!
Detected as SDHC Card!

機能盛り込みすぎてちょっと速度が遅いですがしかたは無いです。


●Sandisk ExtremePRO SDXC64GB(FAT32フォーマット)

そして!現在TG-3用の記憶媒体としてバリバリに使っていますExtremePROの
64GBのカードです!!!
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 25 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16448 kB/sec.
>ds 0
rc=0
Drive size: 124735488 sectors
Erase block size: 32768 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 01 DB D3 7F 80 0A 40 40 DF @..2[Y.......@@.
CID:
00000000 03 53 44 53 50 36 34 47 80 F2 D6 14 07 01 01 D5 .SDSP64G........

Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SP64G
Product HwRev :8
Product SwRev :0
Serial Number :0xF2D61407
DateCode.Month :1
DateCode.Year :2016

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 C0 00 0F 05 3A 00 ..............:.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 84 03 00 00 00 00 .E......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Security :4
SD Bus Width :5

SD_Spec V4.xx!
Detected as SDXC Card!

ありゃりゃ・・・
ま・・まぁ・・・FAT32で無理糞フォーマットしてますしそのせいでしょう(脂汗)
カードのモノとしてはSDのバージョンも4の最新のやつです。
今回の評価でSDバージョンが4の奴はこれと並行輸入版EXCERIAだけでした。
どうでもいいですけどeraseblocksizeが32768セクタもあります。


●I/ODataのClass4 SDHC4GB

ねむいさんのおとうちゃんから「お前が山に行った時の写真分けてくれ」と
頼まれ手渡されたどっかの家電量販店で買ってきたかのようなデータ保存用の
やっすいカードです。どうせゴミみたいな性能だろうから哂ってやるつもりで
半ば冷やかしにベンチとってみたのですが・・・
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 25 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 19063 kB/sec.
>ds 0
rc=0
Drive size: 7878656 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 40 0E 00 32 5B 59 00 00 1E 0D 7F 80 0A 40 00 A5 @..2[Y.......@..
CID:
00000000 1D 41 44 53 44 20 20 20 10 A0 90 08 0A 00 02 E3 .ADSD ........

Parsing SD CID Register
Manufacturer ID :0x1D
OEM/Application ID :AD
Product Name :SD
Product HwRev :1
Product SwRev :0
Serial Number :0xA090080A
DateCode.Month :2
DateCode.Year :2000

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 02 02 90 00 08 11 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 51 00 00 00 00 32 00 00 00 00 00 00 00 ...Q....2.......
SCR:
00000000 02 35 80 00 00 00 00 00 .5......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!

>132949600 bytes read with 19063 kB/sec.
なん・・・だと・・・!?





・・・
こ、こう言うベンチマークの結果は特に気にせず皆様はそれぞれが納得し信頼できる
メーカのSDカードを選んで使用していただければよいと思いますよ(脂汗)

STM32F7を使ってみる11 -最新のeMMCを動かす-

前回までは古き世代の遺産であるマルチメディアカードをSTM32F7で再び動作せしめる
までになりましたが、今回は新しい世代へと進化したeMMCモジュールの動作に
ついに、ついに挑みます!


eMMCは最早カードの形状ではなく、ごく一般的なICの形となっていますがそれが故に使い
慣れたSDカードコネクタとかで使うには少々骨が折れます。市販のギャングプログラマ用の
SDカード変換付きソケットは100$以上する
のであんまし手を出したくはないです…
簡単かつ確実に使う良い方法ないかといろいろ探ってみるとODROIDと言うLinux系の
ARMボード向けのオプションパーツとしてeMMC実装済みのMicroSDの変換基板が販売
されているのを発見しました!

SouthKorea製なのがほんの少し心配でしたが値段も送料込みで38USD
(2016年3月下旬時点)だったので早速注文してみました!!


で、発注後4日くらいで親父の家に届きました。一週間以上かかるかと思いましたが
予想以上に早かったです。Androidを意識した質素の箱の作りで"Do it yourself"
なるコメントがあります。


一応ぷちぷちにくるまれていましたがこの色って静電対策してないやt


これって静電対策してないやt
まぁでもうごけばいいのですよぅ動けば!!



ボードとしてはコテコテの南朝鮮製ですが実装されているeMMCは東芝製で容量8GB,
そして規格はeMMCv5の最新版です!!!


一応コリアンボードのmicroSDへの変換パタンもやっけつではなく信号のIntegrity
を考慮した配線をしてくれているようです。


eMMCは古いタイプのカードリーダーでは認識すらしない場合があります。
ねむいさんが昨年購入したUSB3.0のTranscend製のカードリーダーでは無事に
認識できました♥
もともとこのeMMCはODROIDのオプションパーツとして販売されているので、
こんな風に最初から何らかのOSが仕込んであります。


ねむいさんはそんなもん関係なくeMMCを使用すること自体が目的なので速攻
FAT32でフォーマットして更地にてやりました!!!

前回の最後でちょろっと漏らしているように実は公開したF7のサンプルでは
既にeMMC(とMMCのブロックアドレッシング)に対応しております。


ビルド時間は結構長いので暇つぶしがてらF7からeMMCのルーチンを移植中の
STM32F4の板に差して反応見てみるかと思ったらなんと普通に認識してしまった…。
拍子抜けするくらいあっさり読めちゃって感動もへったくれもない…
ぇっ!?黒澤ダイヤちゃんのお口がイケナイことになってるって!?何のことやらハハ
虹裏メイドねむいさんは「ラブライブ!サンシャイン!!」を応援します。
↑"ねむいさん仮にも虹メなんだから流行りくらいおさえておいてくださいよ"っていわれたもので…
20170420追:
サンシャイン2期が決定しましたが漫☆画太郎氏の漫画みたいに一期の10話〜13話(特に13話)
は無かった状態からスタートすると思います。
20160928追:
破廉恥




さてビルドが終わってF7のプログラムの書き換えも終わったのでF4板から外すか
…と思ったら…


あ…あれ…???

・・・
案の定HELL朝鮮製ボードに罠がありました…微妙にサイズが大きいようで刺さる
には刺さるんですけど安易に抜けません(意味深)。
無理やり引き抜くと基板で擦れてMicroSDコネクタを壊してしまいます…


てわけで削ります。
いきなりF7-Discoveryで試さなくてよかった…


ゴリゴリ削ってこんな感じに…


うまいこと削れたのでF7-Discoveryのコネクタにスムーズに差さります。


F7でも無事に認識して画像や動画データも自由自在に読み出しできます♥


このeMMCは8GBの容量でSDHCと同じくブロックアドレッシングになります。
私の移植例ではMMCv4以降に新設されたブートパーティション等にアクセス
するための特別なコマンド群は使用しておらず、SDHC/SDXCと同じ感覚で読み
書きします。腕に自信がある人、私のコードを参考に拡張してください・・・(懇願)



そしていつも通りカード(?)の情報を読み出してみました。

>ds 0
rc=0
Drive size: 15269888 sectors
Erase block size: 1024 sectors
Default r/w block size: 512 bytes
Card type: MMC(Block)
CSD:
00000000 D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..
CID:
00000000 11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..

Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0>
Product Name :008GE0
Product Rev :0.0
Serial Number :0x5ADD4140
DateCode.Month :11
DateCode.Year :1999

Detected as MMCv5.0x Device!
OCR:
00000000 C0 FF 80 80 ....
前回述べたとおりMMCv4.xx以降はExtCSDレジスタを読み出すのは重要です。
MMCv4以降のバージョン判定はExtCSDREVフィールドを参照し解釈する必要
性があります。ちなみにこの東芝のeMMCはv5とのことですがですが読み出すと
ExtCSDREVは”7”となりちゃんとv5のデバイスであることが分かります。
ちなみにdatecodeが1999とあるのはCIDレジスタの年数を示すフィールドが4bit分
しかないので2012年を境に年数が一巡してしまっているからです。最新のMMCAの
データシートではExtCSDREVから2012年以降を判別せよというようになっていますので
次回リリースでこちらも修正します。差し替えました。
一方、SDカードでは年数を示すフィールドは6bit分あるのであと50年くらい安泰です。


FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 31 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 22000 kB/sec.
>
シーケンシャルライトも見てみました。F7のサンプルではSDIO_CLKはMAX48MHz
かつ4bitモードの設定がeMMCで可能ですがご覧のとおり理論値に近い読み出し
速度が出ました。やるじゃない!
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 31 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20753 kB/sec.
>
因みに前回紹介したMMCPLusも結構速いです。

と言うわけでユーザー領域のみですがeMMCでもSDHC/SDXCと同じく読み書きすることが
出来るようになりました!今秋くらいに市場に出回るであろうSTM32F777等の最強に強まった
F7シリーズではSDMMCが二つに増えるので基板付け置きのeMMC(とかMCP)が今後は
発言力を増してくると思います!!


今回の成果はSTM32F4系STM32F1系、そしてLPC4088のMCIにも移植しています
のでどんどん試して下さい!ついでにバグもこっそり教えてもらえると助かります☆

STM32F7を使ってみる10 -いにしえのマルチメディアカードを動かす(うごかす編)-

ぇえええぇぇえええぇええ(どん引き)
↑イレギュラー化した部下に突如愛の告白されるシグマタイチョウ風に

いったいいつからIF誌はねむいさんのお株を奪うようなシモネタを炸裂させる
ようになったのでしょうか…???今回はちょっと笑えたので許しますが。
ああプロテインってそういう・・・




そんなどうでもいいことは置いといてさっさと本題に掛かります!!!!!前回は
microSD->SDの変換アダプタ作っただけで力尽きましたが
今回は実際に動かします。



先ずはebayで購入した2GBのMMCPlusカードです!

MMCPlusの規格なので8bitバスで転送もできます…がソケットの互換性を考えると、
4bitバスモードで動かした方が無難でしょう。
因みに妙に汚いように見えますがUSEDでした。MMC自体最早新規生産なんかしてない
ので致し方なしです。カードとして正しく動作すればOKです。


で、その前に問題のソフトウエアの方ですが…こちらでも紛糾してるように
STM32CubeHALライブラリにMMCのサポートは全く有りません。それどころかなんと
過去のSPLには対応していたSDv1.xx系カードのサポートすらもHALライブラリでは
おもいくそぶっちされておりました!!!F**K!!

とりあえずSDv1.xx系のサポートは復活させて動作確認したのですがMMCネイティブ
モードにおけるイニシャライズはどうしたらいいのか全く分からなかったので暫くの
間ネットの海にダイブして情報を沢山漁ってきました。

幸いにもJEDECのMMCの規格は2016年現在は一般人でも公式のJEDECのサイトから
容易に入手することが出来るようにになっていてさらに中華圏のサイトでは動作する
かどうかは不明ですがSTM32向けのeMMCドライバも入手出来たのでそれを参考に
MMC向けのドライバをF7のHALライブラリ向けに組み込んでいきました。

当然最初は思った通りに動かなかったのですがSTM32のSDIO/SDMMCのハード
ウエア自身にかなりクセがあることが分かり、クセを理解して全種類のカードをイニシャ
ライズせしめるよう克服していきました。
以下にMMCPlus/MMCv3なカードを使い認識していく過程をデバッガで実動作を
追いながら解説していきます。

STM32のSDカードドライバは基本的にSDv2->SDv1->MMCの順に認識しようとして
いきます。これは現在のSDカードの規格においても推奨される初期化手順と
されています。カードをリセットするCMD0を除くと最初に放たれるのはCMD8です。


MMCとSDv1系ではSDHC用初期化CMD8:SEND_IF_CONDはタイムアウトエラーとなります。
過去のSTM32のSPLに収録されているsdカードのサンプルではその状態から
なぜかCMD55を単品で投げてから改めてCMD55+ACMD41を投げていました。

CMD8が撥ねられた後いきなりCMD55+ACMD41を撃つとSDIOモジュールがエラーで
コケる対策にCMD55を空撃ちしていた感じです(SPLではあったけどHALライブラリ
はそれすらない!)。これはCMD55を受け付けるSDカード系は問題ないのですが
MMCv3以前だとCMD8が撥ねられた後のCMD55の空撃ちがILLEGAL_COMMANDとなり
またまた撥ねられてしまい、先に進めません(※MMCv4以降はこのCMD55が通ります)。


と言うわけでCMD55の代わりにCMD0でカードをリセット状態にしてから改めて
CMD55+ACMD41を送るようにするとうまく先に進めました!勿論SDv1系でもCMD55の
空撃ちではなくCMD0で問題有りませんでした。


MMCではCMD55+ACMD41は当たり前ですがタイムアウトエラーとなります。


先ほどと同じくCMD0を送りMMCをリセットしますが、eMMC対応を考えて引数を
0xF0F0F0F0にしたCMD0の後0x0000000な引数のCMD0を送るようにしてみました。


ここまで来てようやく本来のMMCの初期化ができます。
CMD1を送ってSDカードの「ACMD41」と同じように初期化します。
が、ブロックアドレッシング必須のSDHCと同じくCCSビット(0x40000000)を
ORして引数に渡さないとブロックアドレッシングを必要とするMMCv4.x以降の
規格では初期化が完了できませんのでしっかりとおっ立てた状態で引数として
わたしましょう。ちなみにv3以前のカードにおいてはCCSビットが立っていても
影響は受けずスルーされて初期化がそのまま通るので問題ないです。


上手く初期化が出来たらOCRレジスタの0x80FF8080が読みだされます。
MMCPlusでDualVoltage対応なので上記の値となっています。
因みにv3以前のカードでは0x80FF8000,ブロックアドレッシングなv4系の
デバイスでは0xC0FF8080が帰ってきます。
ここまで認識が通ったらだいぶ気が楽になります。



所でMMCv4.x系のカードでは新たに追加されたExtCSDレジスタから512バイト分の
追加情報を取得可能です。実はこのExtCSDは4GB以上のeMMCの総容量計算では
必須のビットが存在しています。

212〜215バイト目がそのSEC_COUNTフィールドなのですがここに総セクタ数が
記録されていて512を掛けると総バイト数が分かる仕組みになっています。
この2GBのMMCplusではSEC_COUNTフィールドからの算出方法でもCSDレジスタ
から算出する従来の容量計算方法(計算式はSDv1系と全く同じ)でも両方とも
可能です。



初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
MMCv4系では最大52MHz,8bitバスモードまで動かせられます。当ぶろぐでは
4bitバスモードまでとします。MMC専用の呪文を投げる以外はSDカードの4bit化
やHighSpeedMode化と流れは同じです。そして…


無事ファイラーからディレクトリが読みだされました♥


サイズのでかい動画でもカクカクせずスムーズに動きます☆
(後でかなり早いカードなことが分かった)



お次はさらに古いMMCv3世代のカードです。容量はたったの128MB!
そしてもちろん中古品。


初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
10年以上前のものですがちゃんと現在のPCカードリーダーからも認識できます。


MMCv3系のカードなので数が7ピンしかありません。MMCネイティブモードでも
当然バス数が1bitです。早速こちらも動きを追ってみましょう!


CMD1の初期化を終えるとOCRレジスタの0x80FF8000が読みだされました。


初期化を越えたらクロックを転送用の高速クロックに上げていきますが…
MMCv3系はクロック上限値が20MHzできっちり線引きされていてそれ以上はまず
動作しないので20MHz以下にクロックを落とす工夫が必要です。もちろんデータ
バス幅は1ビットのままです。


さすがに遅いですけど無事認識です♥





上記2つのカードの各レジスタをSDカードと同じようにパースしてみました。
CIDレジスタの扱いがSDカードと微妙に違うので注意です。
そんでもってMMCv4以上の細かいバージョン識別はExtCSDの"ExtCSDVER"フィールド
を読みだして解釈する必要があります。
eMMCの使用をにらんでこちらも正しく解釈できるようにしておきました。
2GB MMCPlus

>ds 0
rc=0
Drive size: 3939328 sectors
Erase block size: 256 sectors
Default r/w block size: 1024 bytes
Card type: MMC(Byte)

CSD:
00000000 90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?
CID:
00000000 37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.

Parsing MMC CID Register
Manufacturer ID :0x37
OEM/Application ID :
Product Name :MMC02G
Product Rev :1.0
Serial Number :0xF3026750
DateCode.Month :2
DateCode.Year :2009

Detected as MMCv4.0 Device!
OCR:
00000000 80 FF 80 80 ....

128MB MMCv3
>ds 0
rc=0
Drive size: 250880 sectors
Erase block size: 32 sectors
Default r/w block size: 512 bytes
Card type: MMC(Byte)
CSD:
00000000 8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}
CID:
00000000 11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}

Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0><0>
Product Name :0128M2
Product Rev :0.10
Serial Number :0x0580FECB
DateCode.Month :2
DateCode.Year :2005

Detected as MMCv3.xx Device!
OCR:
00000000 80 FF 80 00 ....
>


いろいろありましたがMMCの動かし方も上手くモノにすることができるように
なりました!次はいよいよMMCから進化したeMMCの動作に挑みます!!

今回の更新はすでにおきぱに上げてあります。eMMCのSD変換アダプタを持ってるひとは
いいことあるかも・・・!?



おまけ
前回言及したCubeF7のバグですが、「とりあえずuint64_tでキャストしときゃ
いいだろ」が祟って出てしまったカルマなのですが実際どうなるかをSTM32上で
確かめて見ました。


先ず使用する変数/定数は以下とします。
#define SECTOR_SIZE 512
uint64_t unk0;
uint32_t tnk = 8388612; /*512を掛けるとオーバーフロー*/

まずキャスト無しの場合…
unk0 = tnk * SECTOR_SIZE;
この場合は、普通にuint32_tの演算として扱われオーバーフローしたぶんは
そのまま頭が切られます。よって0x100000800ではなく0x800がunk0に代入
されました。


次に括弧でくくってuint64_tでキャストしてみます。今回フォーラムで指摘
されてたのがこのバグです。
unk0 = (uint64_t)(tnk * SECTOR_SIZE);
これもunk0に0x800が代入されてしまいました。*の演算を括弧でくくってしま
ったためにやっぱり0x800になっちゃいました。

正しいキャストの仕方がこちらです。
unk0 = (uint64_t)tnk * SECTOR_SIZE;
uint32_t変数のtnkをuint64_tにキャストしたうえでSECTOR_SIZEを掛けることで
0x100000800がunk0に正しく代入されます。

これ結構引っ掛かりやすいポイントなので私も気を付けるようにします。
フォーラムで指摘されるまで私も気づいて無くて同じミスしてましたがorz


因みにMMCv4.x系のSEC_COUNTの計算で
(uint64_t)((uint64_t)(ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ¥
  ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥
ext_csd.EXT_CSD.SEC_COUNT[1] << 8 | ¥
ext_csd.EXT_CSD.SEC_COUNT[0]));

としてしまうと符号拡張されて上位32bitが1でパディングされてしまい異常
にでかい容量(0xFFFFFFFFxxxxxxxxになる)とみなされてしまいます。
ですので、
(uint64_t)((uint32_t)(ext_csd.EXT_CSD.SEC_COUNT[3] << 24 | ¥
  ext_csd.EXT_CSD.SEC_COUNT[2] << 16 | ¥
ext_csd.EXT_CSD.SEC_COUNT[1] << 8 | ¥
ext_csd.EXT_CSD.SEC_COUNT[0]));

が正解となります。

STM32F7を使ってみる9 -いにしえのマルチメディアカードを動かす(準備編)-

↓ま↑たバグかーーーーー!!!

ゲフンフゲフフン…失礼
例の副業先のトラブルは技術的なものから対人関係というさらに深刻な問題に
シフトしてしまい現在も継続中ですが意地でもこのぶろぐ更新してやります!!







さて、記憶メディアとして現在確固たる地位を築いたSDカードが世に出る少し
前にマルチメディアカード(MMC)という物が存在しておりました。可搬性に
優れるという最大の特徴を持っておりましたが後出してきたSDカードにその
役目を委ねて現在はe-MMC(エンベデッドMMC)と言う形で活躍しております。

今回はeMMCの使用を見据えて先ずは古のMMCを理解しSDカードと同様に動作
せしめる事を目的とします。

SDカードはMMCを基に物理的/電気的に互換性を持たせて作られたため、現行の
フルサイズのSDカードスロットはMMCも勿論使用可能です!




しかし軽薄短小を求めた今はmicroSDカードスロットが当たり前になりでっかい
MMCなんて挿せない!!

と言うわけでマイクロSD->SDカード変換アダプタを購入することにしました。
因みにこれ、登場した当初、電子工作でSDカードを利用した方々から総突込み
のキワモノ扱いされていたブツです。理由は言わずもがな。


なんか箱からして怪しいです。ハングルが書いてあるのに電話番号が大阪っぽい
んですけぉ・・・


中身はこんな感じです。マイクロSDカードスロットに差してなんと65cmも延長で
きます★車のダッシュボードの手の届く場所につけられます★…ですって!

なんというか「信号の反射!?波形の品質!?そんなものは見えやしねー!!
俺の眼に映るものはただひとつ!(※認識エラー※)」って感じですが日本国内で
販売してるサイトとかではひっそりとSDカード(notSDHC・SDXC)で動作させて
ください
とか気弱なこと書いてありましたそりゃそうですよねこんなに引き延
ばして動くわけが…


動…いた…!?ぇええええぇえええ・・・


sandiskのextremeマイクロSDHC8GBをわざわざSDカード変換にかまして不利な
条件で動かしてみましたが動画もこけずに再生できました…!!
すごいぞSandiskの高いやつ!

でも各信号波形が汚いダメダメな安っすいカードとかだと何やってもダメです…。
SuperTalentのSDカードがとにかくダメダメ

と、言うわけで引き延ばす線が長すぎて使い勝手も安定性も悪いので長さを
詰める事にしました。


SDカードスロット側のカバーを開けてみました。
チップタンタルと抵抗が乗っかっています。パタンを追って調べてみると抵抗は
SDカードのCLKラインに330ohmでVCCにプルアップしておりそしてチップタンタル
は+側がSDスロットの外部に繋がっているだけで他はどこにもつながっていない
宙ぶらりん状態でした…ナンダコレ

CLKラインを330ohmの抵抗値でVCCに無理糞繋げてもドライブ能力そこまでない
でしょうからGNDレベル引き切れなくなって益々安定性がわるくなるとおもうん
ですけぉ…ググってもそういう終端例はなかったです。


と言うわけで長さ詰めたついでに330ohmとチップタンタルは取っ払い、SDカード
スロット外郭のシールドはGNDに落としました。


長さ詰めてちょっとは認識するカードが出てきましたが認識しないへそ曲がりな
SDカードがまだ沢山いましたorz
計算上15cm以上引き延ばしてることになるので当たり前ですが…


今度は銅箔テープでフルシールド作戦だ!!!!!


まだあかん…


今度はCLKラインに直列にフェライトビードを投入しました!!
計算上配線路のど真ん中に置くことになり最悪逆効果になる可能性も
ありますが…!?
(※普通は直列終端はMCUのSDIO-CLK端子の最近傍に置き最大の効果を発揮させます)


最後まで粘っていた奴もようやく読めた…(もちろんHighSpeedモードです)


最終的にこんな外形になってしまいました…

でも貴重なマイクロSDスロット->SDカードスロット変換なので大事に大事に
使っていこうと思います。こういうの一個持ってると何かと便利ですものね〜


と言うわけで変換アダプタハーネスの改造だけでもう力尽きたので実際に
MMCを動かすのは次回にします…。

STM32F7を使ってみる8 -CubeF7のHALライブラリにバグ-

クリスマス前に副業先で超F**Kな出来事が立て続けに起こったおかげで土日もそれの
対応に追われホント超F**Kな気分でしたがやっと自体が収まりつつあるのでぶろぐ
更新してみました。あと本業(虹裏メイド)のほうもステキなクリプレ完成しましたから
としあき君たち替えのぱんつ用意して待ってなさい!!以上業務連絡終り。



●STM32F7Cubeが更新
少し前にCubeF7ライブラリがV1.3.0に更新しておりました。前回指摘されていたHAL
ライブラリ中のSDカードの容量を正しく取得できないバグは直っておりました。
容量計算のための変数をuint32_tで取っていたので32GByte以上の容量のカードだと
値がおかしくなっちゃうという昨今の大容量化では良くある光景です。

どうやらCubeF7に収録されているデモとかでは影響が無かった為かユーザーに指摘
されるまで気付かなかったようです。Cube系ライブラリに移行してからずっとこんな
調子ですがねむいさんも新たなバグを見つけてしまいました。


●おっと新バグ発見伝
今回の更新にあたり、fatfsのsdmmcドライバで今まで適当に作りこんでいたSDカードの
内部レジスタを読み出す部分のルーチンを見直して正しく取得できるようにし、更に
CIDレジスタをパースする機能を追加してみたのですが何でかいくつかの値がちゃんと
読み出せず、ちょっと困っていました。
デバッガで追って調べるとなんとHALライブラリ側にバグがありました。

HAL_SD_GetCardStatus()という関数の冒頭でステータスレジスタを取得する内部変数の
バッファをuint32_tで宣言しているのですが、取得後pCardStatusの各構造体要素に
代入する際にuint8_tの配列と勘違いして処理して代入してました。

↑HAL_SD_SendSDStatus()の2つ目の引数がuint32_t*なのでそれに合わせてしまった模様


実は過去のSTM32F4などの標準ペリフェラルライブラリ(SPD)ではHAL_SD_GetCardStatus()に
相当する関数内で最初からuint8_tとして宣言していたのでこの問題は出なかったの
ですが・・・完全にエンバグですね・・・(SPDのほうも微妙にバグってますが)
というわけで対策はSPDの真似して配列をuint8_tで64バイト分宣言すれば終りです。

このバグはSDカード使う人は結構踏んでると思うのでSTマイクロの公式のフォーラム
にも報告しておきました
。bugって文字が乱舞するようになったフォーラムですが
新たなbugがまたひとつ。

そんなわけで上記のバグを潰してUARTから操作するChaN氏のFatFsのデモでdsコマンド
を打った時のSDカードの各レジスタのダンプに加えてCIDレジスタをパースする機能を
無事追加できました。SandiskのExtremePRO microSDHC 8GBを読み出した際の表示は
↓こんな感じになりました。HALライブラリはSCRも取れるのでSCRもパースできるように
してます★


>ds 0
rc=0
Drive size: 15523840 sectors
Erase block size: 8192 sectors
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.
CID:
00000000 03 53 44 53 55 30 38 47 80 1B B8 C2 F6 00 C8 2F .SDSU08G......./

Parsing CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SU08G
Product HwRev :8
Product SwRev :0
Serial Number :0x1BB8C2F6
DateCode.Month :8
DateCode.Year :2012

OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......

Parsing SCR Register
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5


おきぱのF7向けFatFs動作サンプルには今回得られた成果を収録して更新しました。
ねむいさんからのくりぷれです!

STM32も進化を重ねF7になった今でもやってることは相変わらず、SDカードから読み出した
画像データや動画を表示せしめることしかできませんがねむいさんはF10とかになっても
きっと同じことしてるでしょう。いいか我々にはこれしか道はない!
私はロリ↓コン↑ではない!
↑ねむいさんの好きなゼEROのキャラはカーネルやジェネラルのレプリフォース勢


ついでに初期F4シリーズ向けLPC1788そしてLPC4088のFatFsサンプルもSDカードの内部
レジスタを正しく表示/パースできるよう更新しました。
そいえば今回の改修の際に気付いたのですがSTM32F4向けのCubeF4以前のSPDがなんと
今年秋にアップデートしていました
・・・しかもDSI使える最新のSTM32F469/479にも対応
してます。こちらももちろん反映してあります!

さらにGitHUBにあるSTM32Primer2 GPSTr@ckerもプログラム中では直接使用してはいま
せんが別のプロジェクトに流用した時すぐ使えるようにSDIOドライバを更新してます。
じわじわと外人さんからの需要が出てきているようでうれしい限りです★


CIDレジスタのパース機能を付けたおかげもあって他のSDカードだとどうなっているのかも
興味が出てきましたのでいろいろ読み出して試してみようと思います。

STM32F7を使ってみる7 -秋月さんよりF7Discovery販売記念-

※とある大切な方の訃報を受けて霊場めぐりをしていたため更新が一週間以上遅れて
 ます。すみません。


先々週末、秋月さんよりSTM32F7-Discoveryが販売されました
入手しやすくなった事によって皆さんもF7に触れるチャンスができたと思います。
ねむいさんもF7ネタで一つ記事を書きたかったのですがいまいち"ぱんち"が弱く
更新に躊躇していたので今回の販売開始は渡りに舟でした。しかももう一つ嬉しい
ニュースも同時にでてきました。


●OpenOCDがSTM32F7の内蔵フラッシュ書き込みに正式対応
7月上旬、私が最初にいじりだしたころからF2/F4系と別系統のSTM32F7のテスト用
ドライバは存在していたのですが秋月さんの販売と時を同じくしてOpenOCDにF7系の
フラッシュ書き込みサポートがF2/F4ドライバに正式にようやく追加されました


Corex-M7はL1キャッシュを持つのでフラッシュ書き込みルーチンを呼び出すとき
にメモリバリア命令を張って意図した手順で書き込みのための命令を実行させる
ようにしないといけませんでした。
最初にコミットされた時はそんな理由でF7専用のフラッシュになっていましたが
同じMPUを持つF2/F4系でも問題が無かったため結局stm32f2x.cに統合されています。

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32f7discovery_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0-dev-00104-gf3be0f6-dirty (2015-11-13-09:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.219974
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0803276c msp: 0x20010000
auto erase enabled
Info : device id = 0x10016449
Info : flash size = 1024kbytes
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20010000
wrote 786432 bytes from file main.elf in 18.501879s (41.509 KiB/s)
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
verified 600552 bytes in 2.451303s (239.251 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:21

書き込みはこんな感じです。以前と全く変わってませんね〜。
私が提供しているバイナリはもちろんSTM32F7-Discoveryに対応しています★
また、以前も伝えましたがSTLink/V2-1のファームは2.24.11以降にアップデートして
おいてください。古い番だとmbedのMSCの方のインターフェースと干渉して書き
込みが必ず失敗してしまいます。秋月さんで購入できる奴はさすがに最新版に
なってるはずですのでたぶん問題ないでしょうけど。


●MPUとSDRAMのキャッシュ設定
過去にも少し触れたMPUの事ですが、F2/F4系ではほとんど出番がなかった代物ですが
L1キャッシュが実装されたF7系では極めて重要な意味を持ちます。しっかり考えて設定
しないとパフォーマンスに大きな影響が出てしまいます。

書くいう私もキャッシュの概念をよく理解してなくてDMAで無駄に苦戦したりしていましたが
新たにFMCを使ったSDRAMで手落ちを見つけてしまいましたorz


AN4667より引用
通常はFMCはD-Cacheを通じてアクセス速度の向上が行われているのですが、それが
有効なアドレス領域はCortex-M7のコア上で制限があります。
SDARAMが割り当てられるアドレス(0xC0000000~)ではご覧のとおりキャッシュメモリの
恩恵にあやかることができません。


AN4667より引用
FMCのSDRAMのアドレスをリマップしてキャッシュが効くアドレス領域に変える
方法もありますがMPUでキャッシュ可の領域に設定してしまう方が簡単です。


MPUの設定はこんな感じです。キャッシュ有効の時に"MPU_ACCESS_NOT_BUFFERABLE"
とするとライトスルーとなります。ライトバックは"MPU_ACCESS_BUFFERABLE"です。

なお、FMCやSDRAMを有効にしてなくてもMPUはそれらと完全に分離しているので、
設定した瞬間にいきなりHardFaultとかになることはありません。
また、QSPIの領域については前途のとおり元からキャッシュ可になっていますので
特にMPUを設定する必要はないです。


てわけで早速いつものjpegファイルのデコード時間で比較してみましょう。
その1.フラッシュインターフェースはAXIM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


予想通りキャッシュ無効のデフォルト状態の方が断然はやi...

???
???どういうことなんだ???(←C.V.櫻井のイケボで)

キャッシュ無効が一番早いじゃないですかー!?たぶんAXIMバス経由でプログラムを
実行してるからバスのトランザクションとかキャッシュラインが干渉しまくって逆に
パフォーマンスが低下してしまったのでしょうね。
・・・すみません適当な考察で…てわけでAXIマトリクスの影響を受けないITCMからプロ
グラムを実行してみますか。

その2.フラッシュインターフェースはITCM

↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。


↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
 最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。

ITCM経由だとバスの競合が減りますので確かにキャッシュが効いているのが
分かりますね★
所で本来ならライトスルーよりライトバックの方が早くなるはずなのですが、ライトスルー
の方がほんの少し早い結果になりました。キャッシュを効かせているとキャッシュヒットと
ミスの時のブレ幅がかなり大きく出てくるのでそっちの方が気になるくらいですけど。

おきぱのF7のサンプルではAXIM/ITCMの両方でSDRAM領域のMPU有効・ライト
スルーキャッシュ設定にして更新しております。
以前はQSPI-ROMにFONTX2ドライバを置いていた場合文字の表示で崩れることが
あったのですがSDRAM領域もMPU・キャッシュ有効にするとそれが一切発生しなくなった
という副次的効果が見られましたのでAXIMだと若干パフォーマンスが落ちますが敢えて
MPUを効かせています。

もちろんキャッシュを経由するとDMAの問題がまた持ち上がってきますが私のサンプル
ではDMA2Dをそうなる使い方はしてないのが分かったのでDMA対策は特に行わず
様子見としております。

さらについでですがCubeF7もV1.2.0になってHALライブラリもV1.0.2にアップデートして
おりますので差し替えてあります。でもSDMMCのuint64で処理しなきゃならない処理が
uint32のままでまだ治ってないので私自らHALライブラリに修正を加えておきましたクソァ!

STM32F7を使ってみる6 -タッチパネル入力とQSPIの追加-

もう気づいた方もいるかもしれませんがSTM32F7向けのいつものを9月1日版に
更新しております。
変更点は細かいバグ潰しと容量性タッチパネル入力、そしてQSPIの対応です。

●CTP(容量性タッチパネル入力)対応
STM32F7Discoveryには上記のタッチパネル付きのTFT-LCDモジュールが搭載
されています。型番でググっても出てこないのでおそらく特注品なのでしょう。
CTPコントローラにはFT5336GQQなる物が使用されております。

さて、以前はもっとも単純なADS7843系、ちょっとインテリジェンスな機能をもつ
STMPE811等の抵抗膜式のものを扱ってきました。
容量性の場合はメカニズムが全く違い複雑になるので専用ICに頼らざるを得ない
のですがそれの使い方を把握するのでもこれまた複雑で正攻法で行くととても
時間がかかってしまいます。

そんなわけでSTマイクロ提供のCubeF7ライブラリ群にはBSPとしてFT5336GQQ用
のアクセス用関数がちゃんと用意されています。しかもF7-Discovery用にI/Oの
設定も御誂えております。

実装は拍子抜けするくらい容易でした。私の過去のタッチパネル入力の処理と
結合させてGPIOのエッジ割り込みの処理を追加するだけで済みました。
F7-Discoveryのデモではタッチした状態が変わらないと割り込み処理を抜けられ
ない構造になっていてデッドロックの危険性があったのでそこだけ省いています。


他の上位のレベルの処理は一切変えていないので過去の抵抗膜式のものと同じ
ような感覚で操作できるようになっています。

本来ならばFT5336GQQのBSPがやってる処理を分解・再構築して自分独自の
タッチパネル入力処理とすべきところなのですが残念ながら私の技術力はそこまで
及ばずあえなく安易な方法、"出来合いの処理"を提示されたライセンスに従って
利用させてもらうことにしました。F7になってからは複雑化も相まってそういう場面が
多数出てきています。
私も巨人の肩の上に乗る小人のうちの一人なのです。

前向きに考えるとソースコードを公式のものと互換性を持たせて問題を切り分け
易くするなんてことも言えますがゆくゆくはSeggerのSTemWinとかも使ってみたい
ので何でもかんでも自作にとらわれず柔軟にやってこうと思います。もなかさんもこう言ってますし
でも素のEclipseなんて絶対に使いませんよぅ!!!!!!!!
ゲホゲホ・・・ハァハァ失礼・・・次に進みましょう・・・

●QSPI-ROMをメモリマップドモードで使う

こちらはLPC4330の時にも紹介した奴と同じですね。SPI-ROMのメモリ領域が特別
な関数を経由せずにリニアにアクセスできるという便利な機構です。

ことSTM32F7に限ってはD-Cacheを挟むので従来のSPI-ROMではどうしようもなかった
速度的なボトルネックはある程度解消されるようです。


F7のHALライブラリにはQSPIの関数/BSPが用意されていますがメモリマップドモード
で使用する場合は一度イニシャライズしさえすれば後は普通の内蔵フラッシュ
メモリと全くおんなじです。


今回もBSPを最大限に利用させてもらっていますが、QSPIのメモリマップドモードでは
読み出し専用で使う場合は割り込み処理は全く不要なので初期化時のNVICの設定
を省いておくこともできます。

私はQSPI-ROMをFONTX2のデータ置場として利用しました。F7DiscoveryではN25Q128A
が搭載されています。N25Q128Aは一セクタあたり64kByteずつ分かれていますので
FONTX2ファイルを書き込むアドレスは半角を0x90000000、全角は0x90010000に配置
してみました。


あとQSPI-ROMにデータを書き込む方法ですがSTLinkUtilityのVer3.7からF7Discovery
用の外部フラッシュローダに対応しています。これを利用して書き込みます。


先ずは半角


お次は全角。
なんでか拡張子はbin,elf,hexしか駄目なのでFONTX2ファイル書き込む際は拡張子
をbinに変えて書き込んでください。


こうやってQSPI-ROMに書き込んだデータは上記のようにして参照します。
メモリマップドモードだからできる技ですね〜


無事に起動しました。S-JIS形式のtxt文書もごらんの通りです。
ビルド時に巨大なFONTX2ファイルを組み込む必要がなくなり、フラッシュ書き込み
に掛かる時間も節約できてテンポよくデバッグできるようになると思います。



デバッガからQSPIのメモリを参照するとこんな感じに見えます。もちろん参照時は
メモリマップドモードになっている必要があります。これは半角のFONTX2です。


こちらは全角です。



現在はまだ限定的かつ実験的な使用にとどまっていますがQSPI-ROMの有効な活用法が
新たに見つかったら紹介していきたいと思います。



●おまけ
いつもののmakefileみたら何をどうすればわかるとは思いますが、デフォルトでは
以下の"ひとまず確実に動く設定"になっています。

1:内蔵フラッシュインターフェース
 ->AXIM
2:SDRAM
 ->有効
3:タッチパネル
 ->有効
4:FONTX2
 ->内蔵フラッシュから参照かつQSPIは無効

"4:"のFONTX2のドライバでQSPI-ROMを参照したい場合は当たり前ですがあらかじめ
半角/全角それぞれのFONTX2ファイルを上で紹介した手順でQSPI-ROMの適切な
アドレスに書き込んでおく必要があります。

STM32F7を使ってみる5 -AXIMとITCM-

STM32F7の内蔵フラッシュメモリは以下に示す2系統のインターフェースで命令
コードを読み出し実行することが可能です。

The AXI-Master (AXIM) interface

TCM Interface

Embedded Workbenchマニアのページさんの記事を参考にして私なりに両者の
性能の違いを確かめてみました。また、各モードで上手く使いこなすための
コツも紹介します。


●AXIM経由のフラッシュ
こちらはCubeF7の各種サンプルプログラムでデフォルトで使用されているスタン
ダードなものです。フラッシュメモリのアドレスは0x08000000に配置されており
過去のSTM32シリーズと同様の感覚で使用できます。
フェッチされた命令はCortex-M7コア内のI-Cacheを有効にしていればフラッシュ
のアクセス速度の遅さを補うことができますのでフラッシュの素のアクセス速度
の遅さを気にせず過去のSTM32シリーズとほぼ同様に使用することができます。


そんなわけで早速表示です。SDRAMのタイミングを正しい値に修正したこと以外は
前回お見せした対策その1と同じ構成です。


●ITCM経由のフラッシュ
ITCMバスにはF2/F4シリーズでおなじみのARTアクセラレータが乗っかっています。
I-Cacheは経由しませんがアクセラレータのおかげでフラッシュの素の(ry
ちなみにITCM経由のフラッシュアクセスの場合、アドレスは0x00200000に配置され
ている事になります。ITCM経由で動かしたい場合はリンカスクリプトの開始アドレスを
0x00200000にしましょう。


なんとこちらの方が高速です!Embedded Workbenchマニアのページさんでも述べられ
ているとおり
AXIM経由の場合はフラッシュの命令の他に様々なペリフェラルが行き
かっているので命令はITCMに押しやるのが本来取るべきスジなのでしょう。


●ITCMるコツ
上記の結果だけ見るとAXIMのメリットないじゃんてお思いの方が多いと思います。
残念ながらITCMも結構ピーキーな性質でスムーズに開発を行うために知っておかな
ければならないいくつかのコツがあります。

1.ITCMのアドレスではDMA出来ない
 RMを読む限りではバスがDMAコントローラのどこにもつながってないのでこのアドレス
 ではDMAが一切出来ないと思います。DMA元にconstを決め打ちするような転送では
 HardFaultになって失敗するでしょう。
 もちろんITCMバスにぶら下がっているITCM-RAMもDMA不可能です。このへんF4の
 CCMと同じ位置づけですね。
2.フラッシュは0x08000000に焼く
 ITCMから見えるフラッシュのアドレスは0x00200000ですがそのアドレスにはフラッシュ
 メモリの実体はなく、過去のSTM32シリーズと同じ0x08000000にあります。
 0x00200000に無理やり書こうとしても弾かれます。
 
 ↑こんな風に駄目です。
 したがってOpenOCDではhexやelf形式のフラッシュ書き込みは100%失敗しますので
 binファイルを0x08000000に向かって書き込むようにしましょう。
 
 makefile上ではこんな感じです。9/Sにリリースする新版のいつものではフラッシュに
 ITCMを選択すると必ずbin形式で書き込むようにmakefileをいじって置きますので
 ねむいさんと同じ開発スタイルの人は特に気にせず快適に書き込み&デバッグが
 できると思います★

 おまけです。
 
 ↑AXIMで動かしてる時のデバッグ画面。
 
 ↑ITCMで動かしているときのデバッグ画面。PCの値に注目。

 F7シリーズはBOOT0の状態で起動できるアドレスの番地が可変になりましたが、
 デフォルトではフラッシュメモリからブートする場合、ITCMインターフェースの先頭
 0x00200000から開始になっています。AXIMでもきちんとスタートアップを記述
 していれば0x08000000の番地にすぐに飛んでくれるので問題ありません。



・・・徐々に、そして確実にSTM32F7の真の力が明らかになってきています。
今までの私の使ってきたワンチップマイコンの概念のままでは到底その力を引き出す
ことはできないでしょう。しかし私はそれに臆さずどんどん新しい概念に切り込んで
いきたいと思います!!

STM32F7を使ってみる4 -CPUキャッシュとDMAを考慮する-

前回DMA転送がうまくいかなかったと抜かしていましたが原因は至って単純な
もので私にCPUキャッシュについての知識が無かっただけでした!!!!!
めでたしめでたし♥




今回は上の三行で終わる内容ですが前回の記事そのものがCortex-M7アーキテク
チャを全く理解してないおまぬけなねむいさんのままで終わってしまう(あたしはまだ
終わってはない!)のでもう少し突っ込んで解説したいと思います。

STM32F7にはI-CacheとD-Cacheの2つのレベル1キャッシュメモリがありこれらを
有効化させることによりリアルタイム性が落ちる代わりに全体の処理の高速化を
図っています。今回はデータ用キャッシュメモリD-Cacheに着目します。
今回の記事を書くにあたってユーネクスト株式会社ビリー様のサイトを参考にさせていただきました。



私のいつものではプログラム開始時にI-CacheとD-Cacheを有効にし、さらにMPUで
SRAM1,2領域(256kByte分)のWriteThroughを有効にしています。CPUからのこの
SRAM領域(以下本メモリ)への読み書きはWriteThroughによって常に本メモリと
D-Cacheの一貫性(Cache Coherency)が保たれています。WriteBackよりも多少は
処理速度は落ちますがそれでもD-Cacheの恩恵に与かれるので確実で強力です。

しかしながらこの関係が破れるのがDMA転送をする時です。

DMAコントローラはキャッシュメモリを介さないのでD-Cacheと本メモリの一貫性を
保てなくなりDMA転送後に本メモリから読みだしたはずの本当のデータはD-Cache
に残った古いデータで正常に読みだせない&転送がコケる(ように見えた)という事に
なります。以下にlibjpegで画像をデコードした際の実例を示します。




こちらは虹裏的美少女画像をSDMMCのデータ転送にDMAを一切使わずFIFOのポーリ
ングで読みだした所の写真です。右下に表示にデコード完了に掛かった時間を表示して
います。I/D-Cacheは有効です。


無対策でDMAで読みだした時の写真です。途中でデータがおかしくなってひでぶ
しているのが分かります。上記のとおりD-Cacheに残った古いデータのせいでめちゃ
くちゃになってる訳ですが、当たり前ですが表示にすら至らないケースもあります。



その前に脇道にそれますがlibjpegとFatFsを結合している関数について、この関数
内ではlibjpeg側で先にmallocで取得したデータ読み出し用バッファをDMAの読み出し
先にしてしまいます。

つまり私のいつもので使うFatFsのデータ転送用汎用バッファBuff(上記画像参照)が
どのメモリ領域にいるかは関係がなく、リンカスクリプトでHEAP領域にD-Cacheの影響
を受けるSRAM1,2を割り当てているとDMA転送時の上記の問題に思い切り引っ掛かる
ことになります。それを踏まえたうえで本題の比較に入ります。



プログラム開始時の時点でD-Cacheそのものを無効にすると当たり前ですがデータ
の齟齬が発生する余地が全く無くなりますので表示がおかしくなることはありません。
しかしながらパフォーマンスはガタ落ちになります。これじゃF7使う価値がないです。


対策その1です。
8月5日付のおきぱに置いてあるいつものはこちらの対策を施しています。
効率はやや落ちますがかなりつぶしが利き、なおかつ確実に転送が可能です。
DMAで読みだす先をキャッシュの影響を一切受けないDTCMに設定して読みだした後
memcpyで本来の(D-Cacheの影響を受ける)バッファアドレスにコピーします。
実際はスタック領域にDTCMを割り当てているのでAuto変数設定時に特別なattribute
設定も必要なく他の環境にも転用できると思います。


対策その2です。
DMA転送する前にD-Cacheの無効(Invalidate)だけを行います。CMSISのヘッダライ
ブラリでは上記の無効にする関数が用意されています。STM32F7のキャッシュサイズ
は4kByteでlibjpegの一度に読みだすサイズもデフォルトでは4kByteとなってます。
(注:Cortex-M7のキャッシュは1ライン32byte*128本で合計4096Byte)
D-Cacheの1ラインごとにInvalidateする関数もありますが今回は読み出しサイズが
キャッシュサイズと同じなので全部Invalidateする関数を呼び出してます。
SDMMCのDMA転送を行う関数の頭にSCB_InvalidateDCache()を置いて実行してい
ますが対策その1よりも若干遅くなっています。

そういえば・・・Disableも無効って意味なんですがあちらさんではどう
使いわけてるんでしょ…



対策その3
です。
DMA転送する前にD-CacheのInvalidateとCleanを行います。
SCB_CleanInvalidateDCache()を呼び出しますが必然的に対策その2よりもさらに
遅くなっています。



対策その2と3は単純にCMSISヘッダライブラリの関数を実行すればいいという訳では
なく、DMA元/先として使うバッファのアライメントとサイズに制約があります。
D-Cacheのキャッシュラインのサイズにアライメントを合わせ、なおかつそのサイズの
整数倍にしないとやっぱりデータの齟齬が起こってしまいます。
特に読み出し時はDMA用に確保したバッファの近辺のアドレスに配置されている変数
までしっかり破壊してくれやがります。STM32F7の場合は1キャッシュライン当たり
32Byteの固定値となっているので32バイトのアラインメント且つデータサイズが32の
倍数になる必要があります。

もしバッファ用のメモリ領域が上の条件を満たさない場合はアライメントとデータサイズ
の丸め込みを行う必要性があり更にオーバヘッドが増えます。RTOS向けのデバイス
ドライバを作成される際はこの点も考慮する必要があります。

以上の点を踏まえると別に無理してDMAしなくてもいいんじゃないかと思われるかも
しれませんがそれではロマンが無いので是が非でもDMAらせていただきます!


そんなわけでD-Cacheを考慮した修正版のいつものをあげておきます・・・


おまけ
libpngやlibjpegは無対策でも平気だったのですが何故ひでぶしないで平気だったのかも
調べてみました。


giflibはSDMMCのブロック転送時にfptrがクラスタの境界になく、その際の一時
転送先がDTCM領域のFatFsオブジェクト内(のwin配列)に確保されています。
つまり対策その1とほぼ同じ事をFatFsライブラリ内でやってくれているわけです。



libpngもgiflibと同様になっています。


STM32F7を使ってみる3 -FatFsとLCDコントローラを動かす-

前回ねむいさんはUARTとFatFsをデモを参考にSDカード向けに組み替えて動作
せしめるところまで来ました。調子に乗ってDMA化しようと試みたのですがなんでか
正しく転送出来ませんでした


ねむいさん真っ先に悪名高いHALライブラリにバグがあると思って調べまくり
ました。SPLで組んだF4のSDIOの転送するルーチンやDMAの処理の部分などを
穴の開くほど見比べたのですがこれと言って悪い箇所が見当たらず、まさか
エラッタかと思ってエラッタシートやフォーラムもしらみつぶしに見たのですが
そもそもまだF7が広まってない段階なので手がかりすら見つかりませんでした。



20150807追:
ここまで読んで「あ、こいつキャッシュのこと理解して無い馬鹿野郎だ」と思った
方はさっさと次のエントリに進んでくだち
20150807追:




DMA転送用のバッファメモリをDTCMやSRAM2や外部SDRAMとかにおいてもダメダメ
で困り果てていたのですがF7のデモがDTCMを含めた複雑な構成のSRAMを単純に
320kbyteのでかいSRAMとして扱っていたのを思い出し、ねむいさんも細かい
RAMの割り振りをやめてデモと同じようにしてみました。


するとDMAでもちゃんと転送できた。


ぇえ〜〜〜何が違うのよ!とぶちぶち言いながら何が足を引っ張っているのかの
切り分けを進めていくと最終的にFatFsの構造体をDTCMに配置していないと、
DMAがコケる
ことが分かりました。デモではリンカスクリプトでDTCMの領域の
0x02000000から各種変数が割り当てられるため、問題だったSRAM1領域以降の
RAMまでは使用されていないことが分かりました。

データ用バッファとか話が分かるのですがなんでFatFsの構造体がDTCM領域に
無いと何故DMA転送できないのか理由が全く分かりません。F7はまだ世に出た
ばっかでエラッタも未知のものがたくさんあるでしょうから今は深追いは止め
てその先の作業に専念することにしました(しかしこのあとさらなる罠が)。
20150805追:
単にD-Cacheの取り扱いがわかってなかっただけでしたすみません。




と言う訳でFIFOポーリング版とDMA版の読み取り速度の比較を行ってみました。
ポーリング版でも効率化されてますのでDMAと遜色なくなってますね〜。ていうか早い
勿論条件は過去と同じ、スピードは双方ともSDHighSpeedModeにしております。
20150807追:
上の結果ですがPLLSAIの設定間違っていて実際はSDIO_CLK=44MHzくらいで測定
してましたすみません!!


↑PLLSAIの設定を正しく行ってSDIO_CLK=48MHzで読み出したときの
 真の速度です。



SDRAMを使用するとSTM32F7の最大クロック周波数は200MHzまでとなってしまい、
この時のSDMMCのクロックはSYSCLKから供給していると単純計算で48MHzよりも
若干低下してしまうのですがSAI用のPLLをSDMMCのクロック源とすることで48MHz
きっちり動作させることができます。



ひとまずFatFsはめどがついたのでお次はLCDコントローラ(LTDC)です。こちらも
以前STM32F429Discoveryで予習していたはずなのですがSPLとまっっったく構造が
代わっていたので難儀しました。

LTDCについては各種設定を行った後フレームバッファとするSRAM及びSDRAMの
ポインタを参照すれば何とかいつも通りに色を出せたのですが問題はDMA2Dでした。
ああでもないこうでもないを重ねてようやくF429で出来たのと同じように動作させる
ことができるようになりました。結局元のF4のSPLのコードを穴の開くほど読み込んで
CubeF7とどう違うのかの地道な切り分けです。

以下にDMA2D版のDisplay_wr_block_if()のF4版SPLとCubeF7の違いを示します。
両者とも色深度はRGB565の16bppです。


inline void Display_wr_block_if(uint8_t *p,unsigned int cnt)
{
/* Set Display Pointer */
lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(lcdc.x + MAX_X*lcdc.y);

/* configure DMA2D */
DMA2D_DeInit();
DMA2D_InitStruct.DMA2D_Mode = DMA2D_M2M_PFC;
DMA2D_InitStruct.DMA2D_OutputMemoryAdd = (uint32_t)lcd_c_buf_ptr;
DMA2D_InitStruct.DMA2D_OutputOffset = (MAX_X - ((lcdc.width+1) - lcdc.x));
DMA2D_InitStruct.DMA2D_NumberOfLine = (lcdc.height+1) -lcdc.y;
DMA2D_InitStruct.DMA2D_PixelPerLine = (lcdc.width+1) -lcdc.x;
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){}
}

↑F429の


inline void Display_wr_block_if(uint8_t *p,unsigned int cnt)
{
/* Set Display Pointer */
lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(lcdc.x + MAX_X*lcdc.y);

/* configure DMA2D */
Dma2dHandle.Init.Mode = DMA2D_M2M_PFC; /* memory to memory with PFC */
Dma2dHandle.Init.OutputOffset = (MAX_X - ((lcdc.width+1) - lcdc.x));
/* DMA2D Initialisation */
if(HAL_DMA2D_Init(&Dma2dHandle) != HAL_OK)
{
/* Initialization Error */
while(1);
}

/* Start DMA2D transfer */
if(HAL_DMA2D_Start_IT(&Dma2dHandle,
/* Source Buffer */
(uint32_t)p,
/* Dist Buffer */
(uint32_t)lcd_c_buf_ptr,
/* width in pixels */
((lcdc.width+1) -lcdc.x),
/* height in pixels */
((lcdc.height+1) -lcdc.y))
!= HAL_OK)
{
/* Initialization Error */
while(1);
}
}

↑F7の


DMA2Dを利用したレクタングルの塗りつぶし等の図形表現も無事再現できました。
F429で出来てたことをF7で再び出来るようになるまで1週間以上かかりやがりま
したがCubeF7が抽象化しすぎて逆にプログラムの流れが分かりづらいとかそも
そも作りこみが甘くbuggyとか公式のフォーラムでも未だに非難GOGOでF7版SPL
くだちとかいろいろ言いたいのですがまぁそれは置いといて…。


UART,FatFs,ディスプレイまで出来たら既にねむいさんのいつものができたと言っても
過言ではありません。ChaNさんの2009年作のLPC2388向けのデモをベースに足かけ
6年…もう6ねn…n…グハッ!!!







失礼、ちょっとむせました。

画像はpngないないさん♥
libjpeg,giflib,libpng3つの画像ライブラリを用いたデコードも紆余曲折ありましたが
いつも通り出来るようになりました♥
こちらについては話が長くなるのでDMAする時のD-Cacheの取り扱いと合わせて
次回解説させていただきます。


そういうわけでSDMMCのDMA転送でだいぶ足止め喰らいましたがようやく形になって
来ましたのでここでいつものの公開をさせていただきます。残るは容量性タッチパネル
の処理の実装ですがこちらも初めての分野なのでじっくりと取り組んでいこうと思います。


STM32F746G-Discoveryのいつものはこちら


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化できるので試してみました

が…!



なん…だと…!?


つづく!

STM32F7はぢめました

昨年秋にプレスリリースで発表されたSTM32F7ですが私がESP-ROOM-02弄りに夢中に
なってる間にひっそりと市場に流通しておりました。
ヒを見てたら国内外問わず既に入手してOpenOCDでバリバリ使い倒してる人たちもいて
STM32好きの私としてはすっかり流れに取り残された感じですがDigiKeyで大量に在庫
していたので私も一つ購入してみました。



目の前に現れたSTM32F7-Discoveryは私の知ってるDiscovery系のキットの想像を超えた
液晶もSDカードスロットも外部SDRAMもQSPI-ROMもついた夢の全部載せでした!!
ちなみに液晶のタッチパネルは抵抗膜式ではなくなんと静電容量式です!
なんてゴージャスな…


Cortex-M7コアを持つSTM32F746NGH6が搭載されています。スペックについては昨年
秋も触れましたが量産開始後に最大動作周波数が200->216MHzにパワーアップしてます。
デバッガはSTLinkV2-1が搭載されています。


当然のごとくSDRAMが搭載されています。Micronの128MBitのSDRAMです。


同じくSTM32F7シリーズの目玉の一つQ(uad)SPI-ROMです。LPC4000シリーズのSPIFIと同じ
くリニアなアクセスができるのが特徴です。FontX2ファイル等の大規模データは一切
合財ここにぶち込みましょう!


また、Ethernet用のPHYも搭載です。接続するピン数が少ないRMII方式でSTM32F7と
接続されています。


さらにUSB-HighSpeed用のPHYまでついています!!こちらはULPIで接続されます。
後で触れますがUSBメモリを接続するのにちょうど良いですね。


さらにさらにI2S-Codecも搭載されています!!!STM32F4でも搭載されていましたが
同じように"いつもの"が出来そうです。SAIインターフェースで接続されています。


そしてこれだけそろってお値段はなななんと$50ですよ奥さん!!(DigiKeyより)
こんな時代になったのですね…2009年のころは全く考えられなかったのですが…
しみじみ












しみじみするのはその辺にして早速いじってみました。
STLink側のUSB-miniBケーブルをPCと接続するとドライバを読み込んだ後STM32F7
側にも電源が供給されてプログラムが走り出します。
すぐにナウいロゴが出てきます。


すぐにメニュー画面になり、タップでいくつかのアプリケーションが選べるように
なっています。しかもCPUの負荷率もリアルタイムで表示されます。


200MHzで動いているので結構発熱します。F4シリーズと違ってΔTは10度以上あると
思ってください。それでも他の品種の同周波数のものと比べると低いほうですが。


静電容量式タッチパネル(CTP)なので物理で押してもだめです。指で操作しましょ。


先ずは"audioplayer"です。USBメモリに仕込んだwaveファイルを読み込んで再生し
ます。デモはHS側のUSB-OTGだけしか反応しませんのでご注意ください。FSやSDカード
は未実装のようです。


再生してる所です。音量調節が狭くて音量を上げようとすると指がメニューにあたっ
てしまって最初の画面に戻ってしまいがちです。どうでもいいですが。


infoメニューでは現在の動作周波数やファームウエアのバージョンが表示されます、
ファームウェアとやらは勿論STM32CubeF7の事です…。
どうでもいいことですがたまに異様にCPU負荷が100%になって動作が異様にもっさり
したり固まったりするのですが私の操作が早すぎるせいなのでしょうか???




さて、デモプログラムを触るのはこの辺にしてねむいさんのいつものの準備を、
GCCのコマンドラインビルドできる環境を固めて行こうと思います。OpenOCDはまだ
レビュー段階ですがSTM32F7フラッシュ書き込み用パッチが公開されています。

糞ややこしいのですがパッチはCortex-M7用とSTM32F7用の2種類か必要でした
http://openocd.zylin.com/#/c/2786/
http://openocd.zylin.com/#/c/2784/
http://openocd.zylin.com/#/c/2753/4
http://openocd.zylin.com/#/c/2753/5
2753は要注意です。#5のパッチだけあててもF7対応になりません!

まぁやり方さえわかればビルドはいつもどおりなのでらくちんです★
バイナリは既にSTM32F7対応に更新してあります♥
cfgファイル群も更新しましたのでどうぞ。


STLink/V2-1もファームがM11に更新されていますので事前にアップデートして
おきましょう。STLink-Utilityも3.6に更新しておいてください
20150714追:
M11に更新しないとOpenOCDで書き込むことができませんのでご注意!!!!



まだF7向けのGCCプロジェクトはこさえていないので記事を書く2日前に1.0.1にアッ
プデートしたばっかリのCubeF7のF7Discovery向けのデモプログラムのビルド済みhexを
OpenOCDから焼いてみます。その前にSTLink-Utilityで接続し、デモプログラムのhex
を読み込ませてみました


このhexファイル、19MByteも有るのですがフォントと画像データがあるQSPIの領域も
含まれているようです(0x90000000以降の領域)。まだ外付けのQSPIの読み書きには
対応していないので内蔵フラッシュしか書き込むことができませんがQSPIに仕込んで
あるデータはシカトして内蔵フラッシュのだけ無理やり更新できます。


STLink-UtilityのExternalFlashLoaderにF7Discovery向けのQSPIドライバ無いんです
けぉ・・・###それはおいといてOpenOCDに話を移します!!!!


案の定QSPIの領域ではエラーが出ますが何とかフラッシュは書き込みできてます。


無事ファームウエアをV1.0.1に変更することができました。



そんなわけでSTM32F7をほんとに触りだけでしたが触れてみました。
これからいつものビルド環境に合わせたプロジェクト作りを進めて行きたいと思います。
F4の時にCubeF4向けにペリフェラルドライバの移植を試みましたが結局UARTまでしか
実装できなかったので今度こそ本気出します!!
(2年ぶり4度目)

STM32F4シリーズを使ってみる14 - FatFsとSDカード再考その3(SDIOでDMAした時の不具合対策編) -

サブタイトルがどんどん長くなる・・・それはおいといて
前回の解説でまぐろ様と言う方より最初に4Byteの倍数以外の数のデータを書き込んだ際
に書いたデータがずれる
と言う不具合報告をいただきました。結局原因はDMAする
際にメモリアドレスがWORD(4バイト)のアライメントの境界にそろっておらずずれた状態で
DMAしていたことだったのですが、私自身も勘違いしたまま使っていたのでこの場で
情報を整理して根本的にどう対処すればよいのかを記しておきます。
その前にどうでもいいですが"Alignment"はアラインメントでもアライメントでも発音は
正しいそうですが以後はアライメントで統一します。

●ズレる
たとえばファイル"mankoi.txt"を書き込みモードで開き、ヘッダとデータの塊をf_sync()を
挟んで書き込むコードを実行するとします。ここで"sakisan","gff"は共に書き込む予定の
バイト数を満たす十分な大きさをもち4バイトの境界に揃ったconst charの配列のポインタ
とします。またf_系の返り値のチェックは下では解説のために省略していますが実コード
では付与しております。

f_open(&File[0], "mankoi.txt", FA_OPEN_ALWAYS | FA_WRITE);
f_write(&File[0], sakisan, 37, &s2); /* 4の倍数でないバイト数 */
f_sync(&File[0]);
f_write(&File[0], gff, 4096, &s2); /* マルチブロックで一気に書き込む予定 */
f_sync(&File[0]);
f_close(&File[0]);

期待される動作はsakisanで示された37バイトのデータを書き込んだ後gffで示された
4096バイトデータを書き込みファイルをクローズして無事終了…のはずです。

SDIOでDMAを使用しないFIFOポーリングによる書き込みではちゃんと期待される動作
となります。しかしDMAを使用した場合最初のブロック(=512バイト)を書き込んだ次の
ブロックの最初の書き込もうとするデータが1〜3バイトずれてしまいます。
このずれ方は転送予定だった最初のバイト数を4で割った余りと等しくなります。

STM32F4のマニュアルではDMAをする際のメモリアドレスの境界はFIFOバースト長さ/
INC値に合わせよと明記があります。STのサンプルでは送り元メモリ及び送り先ペリ
フェラルはそれぞれ4バイトとしていたのでそれに倣って4バイトの境界にメモリアドレスを
合わせる必要があります(私のサンプルのSPI版の場合はDMAの転送サイズはByte
のため今回の影響はありません)。
ねむいさんはてっきりFatFsのデータのやり取りに使用する為に静的に確保したバッファ
の配列を4バイトアライメントにしておけばそれで問題なかろう・・・という致命的な勘違いを
しておりました。

上記f_writeからはSDIOドライバと結合したdisk_writeが呼ばれますがこのとき渡される
内部バッファのポインタアドレスが4バイトの境界にそろっているとは限りません。
しかしながらdisk_write内のSD_WriteBlock及びSD_WriteMultiBlockはDMAで転送する
際は送付元メモリアドレスが4バイト境界(4で割り切れる数)になっている必要があります。
ズレる状況で実際にどういうことが起こっているかデバッガで追いかけてみましょう。


最初にシングルブロック転送で37バイト分書き込む時です。最初なので当然メモリの
アドレスも4バイトの境界にいます。


f_sync()の処理を終えてから次の4096バイト(実際は最初の512-37バイトを引かれた値)を
マルチブロック転送で書き込んだ時です。ご覧のように渡されたポインタbuffのアドレス
値が4で割り切れない数になってます。


当然のことながらmankoi.txtに書き込まれた文字列はズレます。

●対策
前回も述べましたがSTM32F2/F4は対策はとても容易でDMAの設定でメモリ側のデータサ
イズを1バイトの"Byte",FIFOバッファのメモリ側バースト長をSingleにすれば
1バイト
ごとの転送となり効率は落ちますがアライメントは関係なくなり問題は解決します。

しかしSTM32F1系はSDIOはF2/F4系と違いAHBバスにぶら下がっていてなおかつAHB
バスに直接ぶら下がったペリフェラルへのDMA転送は常にWORD(4Byte)単位でなければ
ならないという制約があり、F2/F4みたいな技が不可能です。したがって下記に示す根本的
な対策を行う必要性があります。
/* If unligned memory address situation,copy dmabuf to aligned by 4-Byte. */
/* SECTOR_SIZE = 512 (Byte) */
uint8_t dmabuf[SECTOR_SIZE] __attribute__ ((aligned (4)));

if((uint32_t)buff & 3)	/* Check 4-Byte Alignment */
{ /* Unaligned Buffer Address Case (Slower) */
for (unsigned int secNum = 0; secNum < count && Status == SD_OK; secNum++){
/* Use optimized memcpy for ARMv7-M, std memcpy was override by optimized one. */
memcpy(dmabuf, buff+SECTOR_SIZE*secNum, SECTOR_SIZE);
Status = SD_WriteBlock(dmabuf,
(uint64_t)(sector+secNum)*SECTOR_SIZE,
(uint8_t)SECTOR_SIZE);
}
} else {
/* Aligned Buffer Address Case (Faster) */
if(count==1){
Status = SD_WriteBlock((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE);
}
else{
Status = SD_WriteMultiBlocks((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE
,count);
}
}

f_writeから渡されるbuffのアドレスの下位2ビットを比較して4Byteの境界にない物は
整列された配列にコピーし直しシングルブロック転送を行うものです。
このアライメント補正したシングルブロック転送を行っていくとブロックサイズの境界
(512Byte=128*4Byte)に揃い改めて高速なマルチブロック転送が可能となるので効率を
なるべく落とさないような仕組みにしてあります。勿論Readの際もチマチマ読み込みの際は
同じような対策でズレを防止できます。

これの対策の元ネタはSTマイクロのフォーラムにあったやり取りです。かれこれ3年
以上経ってましたがねむいさんずっと勘違いしてたせいでこの対策の意味が今更分か
ったorzそれにしてもClive1...貴方は何者なんだ…!

そしてChaNさんのページでもズレるから各自対策してね★ってしっかりと
注意書きがしてありました
…orz見落としてただけジャン私orz

で、でも現行のSTM32F4Cubeとかのサンプルって1.4.0になってもアライメントの事ガン無視
ですし、ま、まぁこれに気づく人のほうがたぶんす、少ないですってハハ♥


・・・と言うわけでおきぱにあるSTM32F2/F4のサンプルは上記の根本対策を講じております。
好みに合わせてDMAの設定だけで逃げるお手軽対策もできるようにしてあります。

またF1系,LPC1788/LPC4088のFatFsでも根本対策を施していますのでご利用ください。
ちなみにLPC2388に関してはChaNさん謹製のMCIドライバを使用していますがちゃんと
アラインド/アンアラインド化をしているためもともと大丈夫です。

●そういえばFatFsの設定で・・・
FatFsの設定のためのffconf.hには_WORD_ACCESSなる定義があり、1にするとポインタの
参照が32bit単位になり高速化ができる・・・はずですが32bitマイコンの場合はCPUコアの
アライメントの制約で1にすると上で述べたDMAみたくCPU例外が起こってしまいます。
しかしながらCortex-M3/M4ではアンアラインドなアクセスが一部の命令で可能なため
1にする事ができます。"一部"なのでChaNさんは0を推奨しています。
20160620追:
FatFs0.12ではこのオプションは廃止されました。
コンパイル時にアラインド状態のアクセスになるようにコードが変わっています。
20160620追:

ねむいさんが試したところではff.cではまだDWORD(8Byte)やそれ以上のマルチバイトに
アクセスする状況が発生していないのでアンアラインド転送の制約に引っかかるSTRD,
STM,LDRD,LDMの命令は現状のコンパイラではff.c内では一切使用されず例外も発生
しないので1で問題はないと言い切れます!もちろんアンアラインドなアクセスではペナル
ティが発生してその時の速度は低下しますがそれでも全体的にはバイトアクセスの時より
速度もコードサイズでも優れているので積極的に1にしていきましょう!
さらにGCCのコンパイラ・オプションで”-munaligned-access"を有効にするとアンアラインド
アクセスを承知でコードの効率化
が図れます。

ちなみにアンアラインドなアクセスが起こった事を知るための機能もあります。
SCB->CCR |= SCB_CCR_UNALIGN_TRP_Msk;

SCBのCCRレジスタにはアンアラインドなアクセスの発生をトラップするビットがあります。
これを立てるとアンアラインド転送が起こった時にHardFaultにさせることができます。

一方Cortex-M0,M0+ではコアのアーキテクチャが違うのでアンアラインドなデータアクセス
は許されず、問答無用でHardFaultになりますので常にバイトアクセスかもしくはアライメント
がそろった転送をしましょう。

そういうわけで不具合もしっかりと修正されたので今度こそ実際にパフォーマンス比較
をやっていきたいと思います!

STM32F4シリーズを使ってみる13 - FatFsとSDカード再考その2(SDIO基本編) -

※今回の記事の内容は時勢/判明した事実に即して逐次変更していきます。


STM32にはSDIOというSD/MMCカードと高速でデータをやり取りができる機能があります。
今回は前回触れたハードウエアの接続の内容を踏まえ、ソフト的な話を展開していきます。
さらにSTM32F4に限らず他品種のSDIO相当の機能を使用できるマイコンについても考察を
重ねていきます。


●STM32のSDIOでFatFsる
SDカードSDIOは簡易な解説がSDアソシエーションのサイトで公開されております。
この"簡易な解説"が曲者で本当に知りたい細かい部分の事柄を知るためには会費を
払って会員になる必要があります。そんなわけでねむいさんみたいな金も地位も技術も
ないホビイストにとってはMCUベンダから提供されたSDIOモジュールアクセス用のコード
さんぷるをありがたく頂いて自分のプロジェクトに適した形に組み込んでいくことになります。

話は少しFatFsのほうに戻りますが、FatFsとMCU固有コードを結合させるためにはFatFs
自身が必要とする下部レイヤと呼ばれる関数群をこさえてやる必要があります。
このうちdisk_ioctl(),fat_gettime(),disk_write()はFatFsのオプション設定で無効状態にできる
のでdisk_initialize(),disk_status(),disk_read()の3つの関数は最低限作りこんであげないと
いけません。

かつてSTマイクロより提供されていたSTM32F4xx_DSP_StdPeriph_LibにはFatFsと親和性
が良いSDIOのSD/MMCカードW/Rサンプルライブラリがあり、私はこれをベースにSDIO
ドライバを実装していきました(現在配布されているSTM32F4Cube通称"HALライブラリ"
のFatFsドライバもこのサンプルライブラリとほぼ同じ実装です)。
私のSDIOドライバはリソース使用状況に応じてDMAとFIFOのポーリングと両方使い分ける
ことが可能です。以下に実際に私のSDIOドライバで使用している要点、特に初期化時の
SDIO_CK(=実際にSDカードに掛かるクロック)の設定を重点的にかいつまんで解説していき
ます。以下おきぱのSTM32F4向けのFatFs実装例内にあるsdio_stm32f4.c,sdio_stm32f4.h
を見ながら読み進んでください。


SD_Error SD_Init(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
NVIC_InitTypeDef NVIC_InitStructure;
SD_Error errorstatus = SD_OK;

/* SDIO Peripheral Low Level Init */
/* GPIOC and GPIOD Periph clock enable */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC | RCC_AHB1Periph_GPIOD | SD_DETECT_GPIO_CLK, ENABLE);

GPIO_PinAFConfig(GPIOC, GPIO_PinSource8, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource9, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource10, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource11, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource12, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOD, GPIO_PinSource2, GPIO_AF_SDIO);

/* Configure PC.08, PC.09, PC.10, PC.11 pins: D0, D1, D2, D3 pins */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9 | GPIO_Pin_10 | GPIO_Pin_11;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
GPIO_Init(GPIOC, &GPIO_InitStructure);

/* Configure PD.02 CMD line */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
GPIO_Init(GPIOD, &GPIO_InitStructure);

/* Configure PC.12 pin: CLK pin */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_InitStructure);

/*!< Configure SD_SPI_DETECT_PIN pin: SD Card detect pin */
#ifdef SDIO_INS_DETECT
GPIO_InitStructure.GPIO_Pin = SD_DETECT_PIN;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
GPIO_Init(SD_DETECT_GPIO_PORT, &GPIO_InitStructure);
#endif

/*
*NVIC_PriorityGroup_0: 0 Pre-emption priorities, 16 Sub-priorities
*NVIC_PriorityGroup_1: 2 Pre-emption priorities, 8 Sub-priorities
*NVIC_PriorityGroup_2: 4 Pre-emption priorities, 4 Sub-priorities
*NVIC_PriorityGroup_3: 8 Pre-emption priorities, 2 Sub-priorities
*NVIC_PriorityGroup_4: 16 Pre-emption priorities, 0 Sub-priorities
*/
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1);

/* Enable the SDIO Interrupt */
NVIC_InitStructure.NVIC_IRQChannel = SDIO_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
NVIC_InitStructure.NVIC_IRQChannel = SD_SDIO_DMA_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 2;
NVIC_Init(&NVIC_InitStructure);

/* Enable the SDIO APB2 Clock */
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SDIO, ENABLE);

#if defined(SD_DMA_MODE)
/* Enable the DMA Clock */
RCC_AHB1PeriphClockCmd(SD_SDIO_DMA_CLK, ENABLE);
/* Initialize SDDMA Structure */
SDDMA_InitStructure.DMA_Channel = SD_SDIO_DMA_CHANNEL;
SDDMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)SDIO_FIFO_ADDRESS;
SDDMA_InitStructure.DMA_Memory0BaseAddr = 0;
SDDMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralToMemory;
SDDMA_InitStructure.DMA_BufferSize = 0;
SDDMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable;
SDDMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable;
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Word;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_INC4;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;
#endif
/* End of LowLevel Init */


SDIO_DeInit();

errorstatus = SD_PowerON();

if (errorstatus != SD_OK)
{
/*!< CMD Response TimeOut (wait for CMDSENT flag) */
return(errorstatus);
}

errorstatus = SD_InitializeCards();

if (errorstatus != SD_OK)
{
/*!< CMD Response TimeOut (wait for CMDSENT flag) */
return(errorstatus);
}

/*!< Configure the SDIO peripheral */
/*!< SDIOCLK = HCLK, SDIO_CK = HCLK/(2 + SDIO_TRANSFER_CLK_DIV) */
/*!< on STM32F4xx devices, SDIOCLK is fixed to 48MHz */
SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV;
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;
SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Disable;
SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;
SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_1b;
SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;
SDIO_Init(&SDIO_InitStructure);

/*----------------- Read CSD/CID MSD registers ------------------*/
if (errorstatus == SD_OK)
{
errorstatus = SD_GetCardInfo(&SDCardInfo);
}

/*----------------- Select Card --------------------------------*/
if (errorstatus == SD_OK)
{
errorstatus = SD_SelectDeselect((uint32_t) (SDCardInfo.RCA << 16));
}

/*----------------- Enable SDC 4BitMode --------------------------------*/
if (errorstatus == SD_OK)
{
errorstatus = SD_EnableWideBusOperation(SDIO_BusWide_4b);
}

#ifdef SD_HS_MODE
/*----------------- Enable HighSpeedMode --------------------------------*/
#warning "Enable SD High Speed mode!"
if (errorstatus == SD_OK)
{
errorstatus = SD_HighSpeed();
}
#endif

return(errorstatus);
}

最初の要となるSD_Init内の関数です。DMAを使用するモードでもFIFOポーリングでも
割り込みは使用します。CLK以外のGPIOは一応プルアップしていますがこれに頼らず
必ず外付け抵抗でプルアップをしてください(前回参照)。
DMAモードの場合はここでDMA用の構造体の設定も完了させておきます。構造体変数は
グローバル化してDMAをキックする際に最低限の変数の設定にとどめるようにして少し
でもオーバーヘッドを減らすようにしております。
また、構造体変数の保持用にCCM領域を積極的に使用するようにして速度向上に努めて
います。ここで注意点ですがCCM領域に置いた変数はdata領域のようにスタートアップ
で初期化しておくようにはしていないのでプログラム内で明示的に初期化するように
しましょう。

その後はSTマイクロ提供のサンプルのとおりにSDカード初期化のための関数を実行して
いきます。デフォルトでは先ずSDIOCLKから作られるSDIO_CKを400kHz以下、データ幅は
1-bitモードでカードの初期化を実行し、成功が返ってきたらクロックをSDNomalModeが
サポートする上限付近まで上げてデータ幅も4-bitに拡張するコマンドを発行して高速な
データのやり取りの準備を行います。

現在流通しているSDカードはほぼすべての品種でSDNomalModeの最高値25MHzをサポート
していますので上げる場合はその周波数近辺まで一気にあげられます。このときのクロック
ですが、STM32F4ではUSB,RNG,そしてSDIO用の固定値クロック生成用のPLLが存在して
柔軟に対応可能となっています。F4系で一般的な168MHz動作の時はUSBで必須の48MHz
が生成され、同じくこれはSDIOでも都合よい値となっています。

そしてSDNomalModeの時は規格上SDIO_CKの値は25MHzが上限値なので上記のコードの
ようにSDIOモジュール内にあるクロックディバイダを通して48MHzを2分周した24MHzを
生成するような設定にします。過去に私はこの時点でクロックディバイダを通さず48MHzをモロ
に引き出して無理やり動作させておりましたがこのやり方は完全に誤りで本当はSDカード
の規格に存在するSDHighSpeedModeに切り替えたうえでクロックを48MHzに上げてやる
必要があることを知りました。

SD_Error SD_HighSpeed (void)
{
SD_Error errorstatus = SD_OK;
uint32_t scr[2] = {0, 0};
uint32_t SD_SPEC = 0 ;
uint8_t hs[64] = {0} ;
uint32_t count = 0, *tempbuff = (uint32_t *)hs;
TransferError = SD_OK;
TransferEnd = 0;
StopCondition = 0;

SDIO->DCTRL = 0x0;

/*!< Get SCR Register */
errorstatus = FindSCR(RCA, scr);

if (errorstatus != SD_OK)
{
return(errorstatus);
}

/* Test the Version supported by the card*/
SD_SPEC = (scr[1] & 0x01000000)||(scr[1] & 0x02000000);

if (SD_SPEC != SD_ALLZERO)
{
/* Set Block Size for Card */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)64;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_SET_BLOCKLEN;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
errorstatus = CmdResp1Error(SD_CMD_SET_BLOCKLEN);
if (errorstatus != SD_OK)
{
return(errorstatus);
}
SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;
SDIO_DataInitStructure.SDIO_DataLength = 64;
SDIO_DataInitStructure.SDIO_DataBlockSize = SDIO_DataBlockSize_64b ;
SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToSDIO;
SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;
SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;
SDIO_DataConfig(&SDIO_DataInitStructure);

/*!< Send CMD6 switch mode */
SDIO_CmdInitStructure.SDIO_Argument = 0x80FFFF01;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_HS_SWITCH;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
errorstatus = CmdResp1Error(SD_CMD_HS_SWITCH);

if (errorstatus != SD_OK)
{
return(errorstatus);
}
while (!(SDIO->STA &(SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))
{
if (SDIO_GetFlagStatus(SDIO_FLAG_RXFIFOHF) != RESET)
{
for (count = 0; count < 8; count++)
{
*(tempbuff + count) = SDIO_ReadData();
}
tempbuff += 8;
}
}

if (SDIO_GetFlagStatus(SDIO_FLAG_DTIMEOUT) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DTIMEOUT);
errorstatus = SD_DATA_TIMEOUT;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_DCRCFAIL) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DCRCFAIL);
errorstatus = SD_DATA_CRC_FAIL;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_RXOVERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_RXOVERR);
errorstatus = SD_RX_OVERRUN;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_STBITERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_STBITERR);
errorstatus = SD_START_BIT_ERR;
return(errorstatus);
}
count = SD_DATATIMEOUT;
while ((SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) && (count > 0))
{
*tempbuff = SDIO_ReadData();
tempbuff++;
count--;
}

/*!< Clear all the static flags */
SDIO_ClearFlag(SDIO_STATIC_FLAGS);

/* Test if the switch mode HS is ok */
if ((hs[13]& 0x2)==0x2)
{
/*!< Configure the SDIO peripheral */
SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV;
#if defined (STM32F40_41xxx)
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Falling; /* This is a baddest work around for STM32F40x and STM32F41x */
#else
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;
#endif
SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Enable; /* Set Direct Clock(48MHz) */
SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;
SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_4b;
SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;
SDIO_Init(&SDIO_InitStructure);
errorstatus=SD_OK; /* Enter SDHighSpeedMode */
}
else
{
errorstatus=SD_OK; /* Still SDNomalMode */
/*errorstatus=SD_UNSUPPORTED_FEATURE ;*/
}
}
return(errorstatus);
}

STマイクロのサンプルにはどこからも参照されていないSD_HighSpeed()なる関数がとある
バージョンから唐突に追加されてフルの規格を入手しないとわからなかったSDHighSpeed
Modeへの切り替え方が判明しております。そんなわけでこの関数を利用して正規に
SDIOのクロックを48MHzでドライブしたい と こ ろ で す が !


残念ながらSTM32F405/7系のSDIOモジュールには上記のエラッタが存在し、上記の関数
を実行してもハードウエア的に48MHzで安定動作せしめることはできません。

実際にRev.AのSTM32F407が乗った紅牛板で実験してみたのですがクロックディバイダを
無効にして48MHz直結の場合は動作しないカードが殆どで動作するカードは極めて限定
的なものでした。しかもreadはかろうじて成功するもののwriteは殆ど失敗してディレクトリ
まで破壊されることが判明したので一時はお蔵入りにしていました(このエラッタが明記
されたのは2012年の秋以降で、2011年当時はまだ判明していませんでした)。

てわけでワークアラウンドを講じるとSTM32F405/7系では動作が保証されたクロック上限
値は37.5MHzとなり、しかもPLLの分周値を変えてこの周波数に設定すると今度はUSBで
必要な48MHzが作られなくなってしまうので利用が限定的になってしまいます。
したがって潰しが効くようにコーディングするとSDNomalModeのまま、SDIO_CKも24MHzの
ままで使用するべしとなってしまうのです。一応STM32F2/F4にはGPIOの高速動作を安定化
させる"compensation cell"なるものがあり(こちらのテクニカルノートの75pに解説があります)、
有効にしてみたのですが改善はありませんでした。

一方STM32F42x/43x系では動作周波数が180MHzまで拡張されたせいかGPIOの絶対的
速度も強化され、168MHz動作時クロックバイパスをEnableにして48MHzのクロックで動か
してもRead,Writeとも安定して動作可能です。180MHzの時はSDIO_CKは52MHzまで増加
しますがこの状態でも全く問題はありません。
そんなわけで後で紹介する裏ワザを使わずどうしても48MHzのSDHighSpeedModeで動かし
たい場合は405/407系から42x/43x系にお引越しする必要があります。ほぼピン互換なの
でボードの改造は不要で単純なスワップでパワーアップできます!


…と言いたい と こ ろ で す が(こんなんばっかだ)このSTM32F42x/43x系も1MB
以上のフラッシュ領域を使っている時PA12の電圧レベルが変化すると動作がおかしくなる
という意味不明かつかなり致命的な不具合が存在しますorz。このやばい不具合、rev3で
FMCとともにようやく修正されたようですがPA12はUSBのD+に相当するためエラッタ持ちの
チップはUSB機能を殺すかもしくはフラッシュの1MB以上の領域を使用しないという2択を
迫られることになりますorz

/*!< Configure the SDIO peripheral */
SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV;
#if defined (STM32F40_41xxx)
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Falling; /* This is a baddest work around for STM32F40x and STM32F41x */
#else
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;
#endif
SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Enable; /* Set Direct Clock(48MHz) */
SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;
SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_4b;
SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;
SDIO_Init(&SDIO_InitStructure);
errorstatus=SD_OK; /* Enter SDHighSpeedMode */

すみません話がそれましたがSTM32F405/407系でどうしても48MHzでSDIOを安定して
使用したい場合の裏技があります。そもそも安定しない理由がI/Oの変化速度が規定に
追い付けずデータが1ビットシフトして取り込まれているせいなのです。ここでSDIO_CKの
クロック送出エッジをNegativeに変えることによってクロックは遅れて送出されるがデータの
取り込みタイミングは変わらない状態となるためビットシフトせずうまい具合に取り込んで
くれるようになります。これはクロックバイパスEnable時の直結でも有効(実際はディバイダ
噛まさないでもSDIOCLKがそのまま出ているのではなくゲーティングされてSDIO_CKが生成
されている事を示している)で安定して読み書きができるようになります。

この送出エッジをNegativeにすることはデータの破損を招く事になるとしてerrataとして
設定が禁じられています。ですが48MHz動作だとこの構成の方が都合がよくなります。
おきぱにあるSTM32F4のSDIOドライバは405/407系向け限定でSDHighSpeedModeを使う
際は敢えてこの技を行っています。もちろん禁を破った動かし方ですので物好きな人だけ
試してみてください。

DRESULT disk_read(uint8_t drv,uint8_t *buff,uint32_t sector,unsigned int count)
{
switch (drv)
{
case SDIO_DRIVE:
{
Status = SD_OK;

if(count==1){
Status = SD_ReadBlock((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE);
}
else{
Status = SD_ReadMultiBlocks((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE
,count);
}

if (Status == SD_OK) return RES_OK;
else return RES_ERROR;
}
}
return RES_PARERR;
}

だらだらとクロック設定の話ばっかり続けてしまいましたがdisk_read()はかなり単純明快
です。SD_ReadBlock()及びSD_ReadMultiBlock()をセクタ数に応じて呼び出すだけです。
SD_ReadMultiBlock()単体だけでも動作には問題ないですがセクタ数1の時はオーバーヘッド
の方が大きくなるのでちゃんと分けた方がいいです。

DRESULT disk_write(uint8_t drv,const uint8_t *buff,uint32_t sector,unsigned int count)
{
switch (drv)
{
case SDIO_DRIVE:
{
Status = SD_OK;

if(count==1){
Status = SD_WriteBlock((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE);
}
else{
Status = SD_WriteMultiBlocks((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE
,count);
}

if (Status == SD_OK) return RES_OK;
else return RES_ERROR;
}
}
return RES_PARERR;
}
ちなみにWriteの時も同じような感じで上記のようになります。


SD_Error SD_ReadBlock(uint8_t *readbuff, uint64_t ReadAddr, uint16_t BlockSize)
{
SD_Error errorstatus = SD_OK;
#if defined (SD_POLLING_MODE)
uint32_t count = 0, *tempbuff = (uint32_t *)readbuff;
#endif

TransferError = SD_OK;
TransferEnd = 0;
StopCondition = 0;

SDIO->DCTRL = 0x0;

#if defined(SD_DMA_MODE)
/* Ready to DMA Before Any SDIO Commands! */
SDIO_ITConfig(SDIO_IT_DCRCFAIL | SDIO_IT_DTIMEOUT | SDIO_IT_DATAEND | SDIO_IT_RXOVERR | SDIO_IT_STBITERR, ENABLE);
SD_LowLevel_DMA_RxConfig((uint32_t *)readbuff, BlockSize);
SDIO_DMACmd(ENABLE);
#endif

if (CardType == SDIO_HIGH_CAPACITY_SD_CARD)
{
BlockSize = 512;
ReadAddr /= 512;
}

/* Set Block Size for Card */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t) BlockSize;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_SET_BLOCKLEN;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);

errorstatus = CmdResp1Error(SD_CMD_SET_BLOCKLEN);

if (SD_OK != errorstatus)
{
return(errorstatus);
}

SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;
SDIO_DataInitStructure.SDIO_DataLength = BlockSize;
SDIO_DataInitStructure.SDIO_DataBlockSize = (uint32_t) 9 << 4;
SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToSDIO;
SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;
SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;
SDIO_DataConfig(&SDIO_DataInitStructure);

/*!< Send CMD17 READ_SINGLE_BLOCK */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)ReadAddr;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_READ_SINGLE_BLOCK;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);

errorstatus = CmdResp1Error(SD_CMD_READ_SINGLE_BLOCK);

if (errorstatus != SD_OK)
{
return(errorstatus);
}

#if defined (SD_POLLING_MODE)
/*!< In case of single block transfer, no need of stop transfer at all.*/
/*!< Polling mode */
while (!(SDIO->STA &(SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))
{
if (SDIO_GetFlagStatus(SDIO_FLAG_RXFIFOHF) != RESET)
{
for (count = 0; count < 8; count++)
{
*(tempbuff + count) = SDIO_ReadData();
}
tempbuff += 8;
}
}

if (SDIO_GetFlagStatus(SDIO_FLAG_DTIMEOUT) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DTIMEOUT);
errorstatus = SD_DATA_TIMEOUT;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_DCRCFAIL) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DCRCFAIL);
errorstatus = SD_DATA_CRC_FAIL;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_RXOVERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_RXOVERR);
errorstatus = SD_RX_OVERRUN;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_STBITERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_STBITERR);
errorstatus = SD_START_BIT_ERR;
return(errorstatus);
}
count = SD_DATATIMEOUT;
while ((SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) && (count > 0))
{
*tempbuff = SDIO_ReadData();
tempbuff++;
count--;
}

/*!< Clear all the static flags */
SDIO_ClearFlag(SDIO_STATIC_FLAGS);

#elif defined(SD_DMA_MODE)
/* Check if the Transfer is finished */
Status = SD_WaitReadOperation();

/* Wait until end of DMA transfer */
while(SD_GetStatus() != SD_TRANSFER_OK);
if (TransferError != SD_OK)
{
return(TransferError);
}
#endif

return(errorstatus);
}

SD_ReadBlock()及びSD_ReadMultiBlock()の関数は#defineの設定によってDMAかポーリ
ングかを分けています。上記コードはSD_ReadBlock()の例ですがブロック/マルチブロック
転送にDMAを使う場合はDMAのキックを関数の冒頭、SDIOコマンド送出前に行っておか
ないとラスト数バイトの転送漏れが生じてしまいますので必ずここで行ってください。
これはSTM32F1のSDIOモジュールのころに議論にあった問題でSTマイクロのフォーラム
で指摘され講じられた対策
がその後のF2/F4の公式のドライバにも反映されています。
コメントでも述べましたがDMAを行う際は転送に使用するメモリのアドレスを4で割り切れる
数、つまり4バイトの境界に合わせてください。GCCにおいては静的にメモリを確保する
際に" __attribute__ ((aligned (4)))"の修飾子を付けます。これをやっておかないと
転送がコケて失敗します。さらにブロック転送の際の転送するサイズを512バイト単位で
行ってください。これらをちゃんとやっておかないと(ry

ちなみにDMAを使用しない場合のFIFOのポーリング版でも転送速度の低下はほとんど
ありません。使用するリソース/ペリフェラルの優先度と相談してDMAを使うか否かを
決めてください。

また、Writeの際も同(ry

DSTATUS disk_status(uint8_t drv)
{
switch (drv)
{
case SDIO_DRIVE:
{
Status = SD_GetCardInfo(&SDCardInfo);

if (Status != SD_OK)
return STA_NOINIT;
else
return 0x00;
}
}

return STA_NOINIT;
}

disk_status()の実装は一番シンプルです。SD_GetCardInfo()を実行するだけです。


さて、LPC4088などの多品種のマイコンにも触れたかったのですがそろそろこのぶろぐの
一記事の文字制限に引っかかりそうなので実際に動かしてみたところは次回に紹介させて
いただきます・・・なんか内容をまとめるどころかどんどん内容が発散していくorz


20150227追:
まぐろ様よりコメントにてSDIOでDMAで4の倍数のバイト数でない数をf_write()で書き込んだ
際にデータが1〜3バイトずれて記録されるという不具合報告を受けました。いただいた情報を
元にこちらでも再現したのでさらに追ってみるとDMA初期化時のメモリ側インクリメント設定が
4(バイト)となっていたためか4で割り切れない数を書きこんだ際に次の転送でずれてしまうと
最終的に推測しました。

というわけで対策ですが一番手っ取り早いのは細かいデータを記録していく際はポーリング
モードで使用することです。どうしてもDMAしたい!場合について私ももうちょっと調べて
みました。するとChaN氏のページからも紹介されているSTM32F4のプロジェクトを専門に
取り扱っているtilz0R氏のサイト中のコメントにてTassilo(田代・・!?)という方が同じ問題に
直面した際の解決策を提示してくれました。私のプロジェクトでいうとsdio_stm32f4.cの
291行目以降を以下のように変更します。
変更前:
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Word;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_INC4;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;

変更後:
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_HalfFull;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;
上記の対策で不具合は発生しなくなることを確認しました。
太字の部分が変更点です。ねむいさんてっきりメモリアドレスもサイズも32bit(=4Byte)で
あるべきと思い込んでいましたのでこんな罠があったの知らなかったとはちょっと恥ずかしい
ですorzしかしながらメモリアクセスを4Byteから1Byte区切りにしたことによる転送速度の
低下や何かしらの弊害あるかもなので次回にみっちり動作検証して考察してみましょう。

また、STM32F4/F2だけではなく、STM32F1系のSDIOやはたまたLPC1788/4088等の
MCIでも4バイト区切りでDMA転送を行うものは同じ不具合がでますのでこっちも同じく
検証してできれば対策まで待っていきたいところです。
20150409追:
全ての品種で効果がある根本対策を講じました!

STM32F4シリーズを使ってみる12 - FatFsとSDカード再考その1 -

このぶろぐを始めてから今に至るまで「FatFsがうごきません><」という漠然としすぎて
すごく返答しづらい内容の質問をコンスタントに頂くのですがその9割が単なる配線ミス
でしたと言うオチだったのですが、残る1割にSTM32に潜んでいた未知のエラッタや
評価ボードの設計不備、および私の不備というクリチカルな問題が潜んでいたのが
分かっています。

STM32F4が世に出て早数年、いろんな情報やノウハウも出そろってきましたので
ここで基本に還ってF4中心にSTM32とSDカードを接続せしめる手法について今一度
考察していきたいと思います。まず予習としてChaN氏のFatFsMMCの解説のページ
は必ず目を通しておいてください。



●STM32F4との接続・ハードウエア編
STM32F4とSDカードを実用的に繋げるためにはSTM32F4の周辺機能であるSPI若しくは
SDIOを用いて接続可能です。SPIはデータ線が1bitのシリアルですがSDIOは4bit(8bitまで
可能だが8bitバスが利用できるカードは限られている)まで可能でSDIOの方が高速に
データをやり取り可能です。
その代りSDIOの場合はその機能を最大限に引き出すため使用するI/Oポートは固定化
されていてSDIOを使うときは重複する他の周辺機能は使用不可能になります。
一方でSPIは柔軟に割り当てが可能なためピン数がすくない品種で速度をそれほど
要しない場面でSDカードを使う際に重宝します。

おさらいですがSPIを使用するときはSD/MMCのSPI互換モード、SDIOを使用する
時はSD/MMCのネイティブモードとして接続します。当ぶろぐではSDIOを使用する
SD/MMCネイティブモードに特に焦点を当てていきます。


私のおきぱのSTM32F4向けのサンプルではSTM32F4Discovery,STM32F429IDiscovery
ではSPIを、その他のボードに関してはSDIOをそれぞれ使用するようにしております。

↑STM32F4Discoveryとの接続(SPI)

↑紅牛/ECH_BOARD改造基板との接続(SDIO 4bitmode)

SDIO,SPIのいずれの場合においてもSDカード/MMCの電源投入後の初期化時はオープン
コレクタで動作することが前提のため、CLKを除く全てのデータ線は必ず外付け抵抗でプルアップ
してください。プルアップ抵抗値についてはNxPさんのアプリケーションノートAN10911
極めて詳しい解説があります。私はそれらを吟味した上で10kohmよりちょっと上の
22kohmを常用しております。メーカ製評価ボードでは入手の容易なSDHCカードを想定
しているのか下限値の10kohmで吊っているのが非常に多かったです。また、今日びの
マイコンは内蔵プルアップを有する物が多いですがそれに絶対に頼ってはいけません。
面倒臭がらず必ず外付け抵抗を用いてプルアップしてください。

以前MCIを動作させるのに難儀していた中華LPC1788基板ですがEA互換のはずなのに
EA向けのFatFsのサンプルがそのままでは動かないもんで回路図をよく見たら…

SDIOの信号線にプルアップが無かったorzちゃんとつけましょう!
このブログ記事を書く際に久しぶりに動かしてようやく気づいたorz

CLKは基本宙ぶらりんです。リセット直後のI/Oの挙動が不安な場合は100kohm程度で
Loレベルに弱く固定すれば良いです。私が見た限りではEAのボードは「宙ぶらりん
(ダンピング抵抗有)」、ST系のボードも「宙ぶらりん」、中華系のは適当で他のI/Oと
一緒にまとめてCLKもプルアップしてたりそもそも基板の設計不良でCLK以外の必須
の信号線すらプルアップしてなかったりしますがCLKに関しては基本「宙ぶらりん」で
良いと思います。と言いたいところですが!!
STM32のSDIO_CLKは非常に高速なクロックが走り、パタンの引き回しによっては
信号の反射によって猛烈なリンギングを発生させるため信号の信頼性が著しく低下して
しまいます。よってSDIO_CLKの出力端のごくごく近くに純抵抗成分を配置して伝送経路の
インピーダンスのマッチングを図り信号の反射を抑える必要があります。
最適な抵抗値は回路構成や回路パタンの引き回しに大きく左右されるため0~47ohmを
目安にオシロとにらめっこしながら切った貼ったをして決めましょう。繰り返しますが
直列終端は信号源のすぐ近くに配置しないと後で述べるフェライトビードの配置と同じく
全く効果がないどころか最悪パワーアップさせてしまいますので基板設計の段階から考慮
しておくべきです。

20160110追:
直列抵抗入れてもダメならフェライトビーズも足してください。



プルアップの他に注意すべき点は3つあります。
1.ブレッドボードの使用は避ける
 ブレッドボードの使用は「SDカードが繋がらない」の諸悪の根源です。結線ミスが
 原因のトラブルでブレッドボードで実験していたという証言が非常に多かったです。
 ブレッドボードは確かに便利ですが、SDカードに限らず接触不良や接点抵抗の増大
 によるさまざまなトラブルのもとに繋がります。面倒でも半田付けを行う癖をつけ
 ましょう。とは言え何でもかんでも半田付けもだめです。丸端を圧着せず半田付け
 とかもってのほかです#

 
 同じ理由でSDカードソケットに接触圧が弱く金メッキの薄い中華製の安物を使うと
 接触不良につながります。注意しましょう。接触不良の問題は状態が変わりやすく
 不具合を特定しずらいので厄介です。

 ぇ?お前ブレッドボードより酷いやっけつな使い方してるじゃんですって!?
 わ…ゎたしは理解した上でやってるからいいんですよぅ!


2.結線はなるべく短く
 これもSDカードに限らず基本中の基本ですね。SDIOの場合はMAX52MHz、通常使い
 でも25MHzもの高速クロックが走ります。クロストークが起こらないような配線を
 考慮しなければなりません。
 
 
 とはいえ利便性も考えないといけません。私の場合はSTM32F4Discoveryで使う
 場合はトレードオフでカードコネクタに対してこんな配置にしております。
 配線長が10cmを超えてしまうとTCK=21MHzだと"あうち"です。なるべく太く短く
 目指しましょう。ちなみにパワーメッシュ基板を使うと配線もしやすくGNDも安定して
 いろいろ楽ができるのでオススメです。

3.電源
 電源は出来合いのボードを使う際の意外な落とし穴になります。SDカードの仕様と
 STM32F4で使用できる全てのSDカードのモードを考慮すると最大200mA必要とします。
 STM32F4Discoveryの3.3V(はショットキDi経由してるので3Vくらいに落ちる)から
 引っ張ってきても"何とか"動きますが高速で信号のやり取りをしていると特に書き
 込み動作の際に不安定になってきます。
 こんな場合は、フェライトビードを無暗に挟むよりもSDカード電源供給専用LDOを
 用意してあげると効果的です。このとき使うLDOはSDカードの高速アクセス時の大電流
 の吸い込み吐き出しに対応するためにセラミックコンデンサ対応の負荷の過渡応答
 性に優れたものを選んでください。
 STM32でSPI限定で使用する場合、仕様上最大で100mAあればよいので秋月さんの
 ラインナップでいうとXC6202P332PR-GTAR5SB33で十分です。勿論LDOの電圧
 供給源(ほとんどの場合はUSBの+5V)は評価ボートと同じ系統にしてください。

 
 ねむさいんは当然のごとく攻守ともに優れたLT1963Aです♥
 ↑秋月さんも私が指摘してた'A'付きにようやく気づいたようでMLCC対応と明記してます。

全然考を察していない内容になっちゃいましたが次回は既存のライブラリを駆使
してMMC/SDIOドライバを組んで実際に動かすソフト編をご紹介します。

STM32F7が発表になってCMSISヘッダファイルもようやくV4.00になった

20150717追
STM32F7はぢめました
20150717追


少し前にCortex-M4をさらに進化させたCortex-M7が発表され、ねむいさんを含む一部の
方の間で騒然としておりました。同時にSTMicroさんからも同コアが搭載されたSTM32F7
シリーズ
が発表され、既にBGA品がサンプルとして出荷されているそうです。

既にSTM32F7用のサイトもあってデータシートも公開されております(RMはまだです。)
Cortex-M7コアではAXI+AHBのマトリクスになり、密結合メモリ(TCM)もインストラクション
とデータ専用に用意されさらに外部メモリ用にI/Dとも4kByteずつL1キャッシュも搭載されて
おります。ねむいさんがSTM32F7で着目したのはLPC4300シリーズではおなじみのクアッド
SPI-ROMの対応
です。
これによりリニアなアドレスに配置されて内蔵フラッシュと同じ感覚で使用できることに
なるためFONTX2のような大容量のデータを扱うプログラムも組み易くなりますね♥
内蔵フラッシュが1MBに抑えられているのもデータの塊はSPI-ROMに押し込めよという
意図があると思います。

あとCortex-M7では浮動小数点演算ユニット(FPv5)が倍精度まで対応しています…が、
STM32F7ではSTM32F4と同じ単精度のみの対応となるそうでF**K!発表された当初は
データシートよく読み込んでおらず、ついに倍精度に対応かー!と思い込んでたので
ぬか喜びでしたorz

アーキテクチャとしてはCortex-M4Fと同じARMv7E-Mとなるのでバイナリは互換出来る
そうです。STM32F4ではTCMではなくCCMがありましたがそれが配置されていたアドレスは
TCMとは全く異なりますので凝った使い方されている方は結局リンカスクリプトから組み直し
になりますのでご注意ください。しかしながらCCMではできなかったDMA転送がDTCMでは
可能
になっていますのでかなり素直にプログラムを組むことができるようになるでしょう。


さて、発表されたばっかで商用はともかくGCCコンパイラもこれから対応開始となるようです
のでSTM32F7を実際に入手して遊べるようになるのは半年くらい先になるかなと思います。
STM32F2の時見たくES品が中華から流れてきてくれたらもっと早いかも。
20141001追:
LauchpadのARM-GCCがアップデートされましたがなんとCortex-M7の対応が
ギリギリで突っ込まれたようです!
STM32F7対応にする場合はSTM32F4からは以下のようにオプションを変えることに
より可能です。
STM32F4:
-mthumb -mcpu=cortex-m4 -march=armv7e-m -mtune=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16
STM32F7:
-mthumb -mcpu=cortex-m7 -march=armv7e-m -mtune=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16

そしてCMSISのサポートの方ですがこちらの方は発表と同時にCMSISもアップデートして
ヘッダライブラリもやっとこ3.30->4.00に更新されています。もちろんCortex-M7コアの
ヘッダも追加されております。ようやくメジャーナンバの更新になりましたが私が試した
ところでは全く影響はなかったのでそのまま差し替えて使用が可能かと思います。
おきぱのプログラムも10月度の更新から順次V4.00版CMSISヘッダファイルに差し替えて
更新していきますのでよろしくおねがいします。




おまけ

STM32F411RE-Nucleoが夏前に手に入りました。STM32F411シリーズはF401の機能拡張版
の位置づけのようです。PCM1723氏が非常に詳しく考察されています。
PCM1723氏もCubeMXのバグに言及されてますね…
なお、おきぱのF401-Nucleo向けのバイナリはそのままSTM32F411版でも使用可能です。

OpenOCDはSTM32F411シリーズは未対応だったので対応させております。本来はOpenOCD
小ネタ行きの案件ですが小ネタ過ぎて載せられなかったのでこちらで告知させていただきます。
次回は大物の更新が控えていますのでご期待下さい♥
おきぱにあるWindows用バイナリもすでに対応済ですのでご利用ください。

おまけのおまけ

ああああああああああああ!!
RTC用のチップコンデンサは位置的に物が当たり易い位置にあってすぐ欠けるorz

STM32Cube系ライブラリ移植への道


いうわけでSTマイクロの苦情隔離場でbugという文字が乱舞するいわくつきのSTM32Cube
ライブラリへの移行を順次開始しました!
NUCLEO-F030板
NUCLEO-F401板
NUCLEO-F334板
おしまい。ぁー憑かれた…












すみません冗談です冗談!春先にも少し触れてすでにこれちょっと微妙だと判断を下した
STM32CubeF4をはじめとするCube系ライブラリは今までの"標準ペリフェラルライブラリ"
とは互換性が全くなく、バグも多数報告されていたのでねむいさんも移植に難色を示して
いました。が、最近発売されたNucleo系のボードに搭載された新しいMCUはもはや過去の
ライブラリには未対応となっており、事態を重く見たねむいさんもようやく重い腰を上げた
わけでございます。早く座らせてくれ
(※以下、縮めて"HALライブラリ"と呼称します)


実はここ数か月でHALライブラリへの移行準備自体は着々と進めていて、その第一歩と
して手持ちのNucleo板のプロジェクトのライブラリを一気に移行していました。
現在手持ちは写真のとおり(って見た目同じですが) F030,F401,そしてF334の3つです。
それらのプロジェクトはごくごく基本的な動作のみを網羅した小規模なプログラムに
とどめていたのでまだ難易度は低く、移植の感触をつかむのにはうってつけでした。
私の公開しているプロジェクトは全てこちらの手順に準拠しているので移行後も不自由
なく同じようにビルドできるものを目指しました。

移行にあたってねむいさん的ポリシーは以下の要素に。
1.プロジェクトのディレクトリ構造は従来の物から大きく崩さない
 まぁ鉄則ですね。ケアレスミス防止目的でもあります。
 互換性を重視しすぎて不便になるのも本末転倒なので変えるべきところは変えます。

2.HALライブラリに依存する箇所をなるべく作らない
 これも鉄則ですね〜。またライブラリ大変更されたら目にも当てられないですし。
 抽象化のためにサイズが激増する冗長なコードがやたらと多いので分解・簡略化して
 別途作ったほうがいいです。一方でHALライブラリ使った方が分かりやすい周辺機器
 の初期化の箇所は割り切って利用していきます。
 
 ぇ?それじゃHALライブラリ使ってる意味無いだろですって!?
 無いですよ。

3.STM32CubeMXで生成されたひな形は利用しない
 STM32CubeMXは各開発環境ごとにHCLK/PCLKの初期化コードを含むひな形を自動
 作成するJAVAで作成されたプログラムを指します。ねむいさんの環境はGCCのコマンド
 ラインビルドに属する極めて原始的なものなのでひな形をそのまま利用できません。

 CubeFxのアーカイブにサンプルコードが収録されてるのでCubeMX使わずともそれ見たら
 殆ど事が足ります。おまけに生成されたコードが現状バグだらけでまったく信用出来ない
 ので100000000000000000000歩譲ってHCLKやI2C/I2Sクロック周波数の初期設定に
 軽く参考にする程度です。

4.メモリリソースはなるべくていうか絶対に許さ浪費しない!
 HALライブラリでは抽象化を上げるためインスタンスという概念が追加されています。
 それに付随する構造体が馬鹿でかいサイズなのでF0系ではSRAM領域を圧迫されすごく
 苦しくなります…なるべくグローバル変数で確保はしないように心がけましょう。


上記の点を念頭に入れて再構成したプロジェクトと従来のプロジェクトでビルドした
バイナリファイルのサイズの比較してみました。比較対象基板はF030板のです。
*STM32 StdPeriphDriver(STM32F030R8T6_NUCLEO_20140326.7z)

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 7216 0 7216 1c30 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
7096 120 328 7544 1d78 main.elf


*STM32 HAL Driver(STM32F030R8T6_NUCLEO_20140702.7z)
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 7916 0 7916 1eec main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
7796 120 412 8328 2088 main.elf

orz
フラッシュもSRAMも使用領域ががっつり増えてやがるorz

HAL Driverのスタートアップは"__libc_init_array"のリンクがあるのでC++の対応を
すててこれを取っ払ってみました
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 7828 0 7828 1e94 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
7708 120 412 8240 2030 main.elf

焼け石に水orz
SRAMを減らさなければ…

HALのSysTick関数"HAL_GetTick"は_weakで切られていてオミットできるのでやってみた
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 7820 0 7820 1e8c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
7700 120 408 8228 2024 main.elf

フラッシュメモリで8バイト、SRAMは4バイト減りましたが焼け石に(ry

bss領域がインスタンスの確保で100byteも増えやがるのはF0系でかなり痛いんですよね〜。
こいつを追い出してみました。
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 7776 0 7776 1e60 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
7656 120 300 8076 1f8c main.elf

雄々ッッ!!BSS領域が元より減りましたよ♥
もぅいいわこれで…もちろんスリムになってもちゃんと動作してます♥
※最初に取り除いた"__libc_init_array"はC++な人のためにリンクを復活させてリリースしてます。

今回の検証に当ってHALライブラリを使用したexampleの中で構造体の一部の要素が
未設定により起こる不具合がみつかりましたがまぁライブラリ自身の不具合じゃない
のでスルーで…(ねむいさんのプロジェクトでは明示的に初期化してます!)
そして話が冒頭の文章に戻るわけです。



ひとまずNUCLEO系板はすべて移行して最適化完了ですが残るDiscovery系の板のは
どうしようか考え中です。特にSTM32F4のいつものは多数のペリフェラルを使用して
いるので移植は本当に腰据えて一気に攻め上げないとバグを生んでしまいますからね…
しかしいずれは通らなければならない道だと思います。FATFSのSDIOとDMAの処理の
移植が峠になりそうです。

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はほぼコピペで同じようなことが可能です!!!
水面を優雅に泳ぐ白鳥も水面下ではせわしなく足を動かしているのと同じく抽象化さ
れたコードの下では頑張って下駄履かせてきた人たちの汗と涙が詰まっていることを
少しでもおもいだしてくれれるとうれしいでs


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

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



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

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

STM32F0版Nucleo(Nucleo F030R8)を使ってドットマトリクスI2C液晶を動かすその2

かなり間が開いてしまいましたがねむいさんが膝の治療をしてるうちに世間はまた
大きく変わり、秋月さんからついにF4版Nucleoが発売される運びになりました
ねむいさんの狙いはF073系のボードなので手元のボードを消化しつつ様子見です。

さて、今回の記事は前回の続きです。以前はF0版Nucleoを使ってGPIOによるソフト
ウエアI2C制御にて某I2C液晶を動かし茶を濁していました。が、今回はSTM32F0の
ハードウエアI2C機能を使用して同じことを行います。

しかしながら前回述べたとおりF0,F3系の物はI2Cモジュールの世代が進んでいて以前と
同じソフトウエアは利用できなくなっています。大きな違いはスタート/ストップコンディ
ションが自動で発行できるようになったこと、SDA,SCLにアナログ+デジタルフィルタが
追加されたことそしてSCLの周波数が直感的に設定できなくなったことです。
SCLのクロック設定はSTのサイトから落とせる"I2C_Timing_Configuration"なる物を
使用して得られた謎の16進数をtimingsレジスタに書き込まないといけなくなりました。
余計なことするなー!

とはいえ一度設定すると後から変えるような場所ではないですからまあ許容できる
範囲だと私は思います。どうせ潰しが効く100kHzでしか使わないですし!



F1/F4系のソフトとあわせるために結構苦労しましたが最終的にうまく動く組み合わせ
を見つけて無事F0系でもハードウエアI2Cをしようできるようになりました♥
(写真ではハード/ソフトI2Cの動作の見分けはつきませんが・・・)

おきぱのI2Cドットマトリクス液晶動作サンプルはすでに差し替えてあります。
実は4月頭にすでにハードウエアI2C版を作りこんでました。もちろん液晶だけではなく
前回動作させたI2C温度計もばっちり動きます♥


ちなみに私のサンプルを見て変なことやってるのに気づいた人も居ると思います。わざと
ドットマトリクス液晶とI2C温度計ほかI2CデバイスのHALの部分を分けています。こんな
ことやった理由は今回使用したI2C接続の液晶以外にSPI接続のドットマトリクス液晶を
接続せしめることを見据えているためです。TFT-LCDではすでに実践している手法ですが
こちらも次回以降に紹介して行く予定です。



ついでの話ですがOpenOCDもついにV0.8.0が正式にリリースとなりました!公式のペー
ジには新たに追加された主な機能の紹介があります。その中で私もフラッシュドライバ
周りでいくつか貢献しました。下の画像で黄色で強調している箇所が私が手がけた部分
になります♥

特にKinetis系のサポートは今後のFreeScale公式のツールにもとりこまれる程の影響力
でねむいさんも顔のパーツを真ん中に寄せて地獄のミサワみたいに得意げになりたい
・・・ところ で す が !上の画像に赤で注釈書いてあるように、以前ねむいさんが実装
したNuvotonのCortex-M0向けのフラッシュドライバがtfreakリンサンの勘違いにより無関係の
NUC910系のサポートと記されてしまい、V0.9.0リリースに向けて早くも釈明と大変更の
プランを練っている次第でございますorz
これ以前からずっと言及してきましたがマジでどうしましょうね・・・幸いにもOpenOCDの
Nuvotonドライバ自身が全世界探しても私しか使ってない状態なのでまだ被害が一切出て
ないのが救いですが(呑気)



あ、すみません最後までブログ書いてて気づきましたがNucleoの話に戻りますが同ボード
上に搭載されているST-Link/V2-1用のファームウェアが更新されています
デバッガとVCP同時使用やそのほかの安定性がかなり改善されていますので必ず更新し
てください。以前のSTLink/V2系のファームアップも同じアップデータで可能です。

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では上記二つの機能を体験可能です。同ボードに搭載された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 :フレームバッファとして確保したメモリ領域のベースアドレス
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を使用されている方が少ないのか指摘されず助かりましたうふふふふふふふf

また、この全部載せ基板は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領域にあたる)を一旦ゼロクリアしてから表示を行うようにしてバグを
潰しております。

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

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

STM32F4シリーズを使ってみる10 -CMSISがバージョンアップした-

STマイクロさんから超安価なArduino用拡張ボード互換且つmbedサポートなSTM32 Nucleo
なるボードが発表されすでに販売されております。
ねむいさんもSTM32F030シリーズが載ったタイプのnucleoボードをmouserから購入しました。
…のはいいのですが一緒に購入したEFM32のCortex-M4バージョンWonder Gecko
単品が輸出規制に見事に引っかかりてんやわんやがあったため今だ手元には届いておりま
せんorz入手出来たらぶろぐに書きますのでしばしお待ちを。

ちなみに元凶のWonderGeckoにはハードウエアAESが搭載されています。これが暗号に
関する技術のため他社のマイコンでも暗号化機能を持つ品種はしばしば輸出規制に引っ
掛かります。ちなみに"ZeroGecko"にもばっちりついていたのですがマイコン単品ではなく
評価キットという形で同時に購入したので引っ掛からず素通り。なんといい加減な…#
…まぁ海外またぐ流通では非にとてもよくある事柄ですねorz
EFM32の件については後日OpenOCDカテゴリでもご紹介します。



さて、前置きが長くなりましたが少し前にCMSISがバージョン4(以下CMSIS-V4)に上がって
おります。但し"ARM,LTD.が提唱しているCMSISという規格全体"がバージョン4になった
という意味ですのでcore_cm0.h等のコアに関するヘッダファイル単体はV3.20->V3.30
いうバージョン推移となっておりますのでご注意ください。
非常にややこしいですがV4.00ではありません。

あと以前も述べました気がしますがARM社がリリースしているCMSISのコアヘッダファイル
(本来はここまでがCMSISと呼べる範疇)とSTマイクロやNxP等各ベンダがリリースして
いるCMSIS"準拠"ペリフェラルライブラリまで全部ひっくるめて"CMSIS"と混同して呼称
される方が2014年の未だになっても非常に多いです。
ARM本家に日本語で概念が記されていますのでしっかり覚えておきましょう。ちゃんと
違いを理解しておかないと展示会とかイベントやセミナーで"CMSISって無駄にコード
サイズ増えるから使いづらいですね(地獄のミサワみたいな顔で)"と言ってしまい数か月
後に自分の言った言葉の意味を漸く理解して時間差で恥かきます。
かくいう私もえらそうなこと(地獄のミサワみたいな顔で)言ってますが最初にSTM32に
触れた時は思いくそ勘違いしておりましたがー!



…すみませんまた話が脱線しました。今回のCMSIS-V4からは前回の更新でヘッダファ
イルのみが付与されていたcmsis-osが全てのソースコードが添付されCMSIS_RTXという
フォルダに同梱されております。ライセンス的にもBSDライクなのでむしろFreeRTOSより
も自由度が高いかもしれません。GCCのコマンドラインでビルドできるようになったら
爆発的に普及すると思います。私もどのようにして実装するか試行中です。

そういう訳で私のいつものSTM32F4のプロジェクトは上記の最新のCMSISコアヘッダファイル
に差し替えさらにChaN氏のFatFs0.10aのかなりクリティカルな修正も反映済にしてあります。
Makefileやリンカスクリプトの記述も将来を見据えていくつか変更を加えているので、私の
サンプルをベースに何かを作成されている方はご注意ください。




そしてこの記事を書く少し前にSTマイクロよりまたまた新しいSTM32向けフレームワークが
提示されていました。STM32CubeMXと呼ばれるコードテンプレート作成のためのツールを
通してプロジェクトの土台作りの簡略化を狙うとのこと。

このSTM32CubeMXには今回のCMSIS-V4の思想を反映したCMSIS-Driverなるハードウエア
の抽象化を狙った規格に準じた新たなSTM32F4向けのペリフェラルライブラリが準備されて
おります。以前のSTM32F4向けCMSIS準拠ペリフェラルライブラリはすでにNRND(非推奨)
となっていますのでF4以外のSTM32品種も今後はこちらをベースとしたライブラリ群に置き換
わっていくことになると思います。
サラっとみた感じでは以前と同じCMSIS準拠なのですがマクロ定義や関数がかなり違うので
右を左にやる感覚で置き換えは不可能で実質全くの別物を移植する感じで挑みたいと思い
ます!まずはおなじみのF4系から攻めていきますのでこうご期待!

ちなみにNxPのLPCOpenではSTM32に先駆けて再配布の規約をようやく明確化し、そして
体系化もしたライブラリ群を提供していましたが微妙にCMSISに準拠していないのでChaN氏に
またDisられないように早急にCMSIS-Driverに基づいたペリフェラルライブラリ群の整備を行う
べきだと感じます。出た当初は少ない品種だったためまだまとまっていましたが周辺レジスタ
の構成が全く違うのに無理矢理LPC1xxx系でひとまとめで括ろうとしたせいで逆に冗長な
記述が増えてしまい結局各シリーズごとにLPCOpenが分かれだした始末で混乱を極めて
いる感がします。はっきり言って開発のしやすさ/ライブラリ整備の点ではSTM32やEFM32に
大きく引き離されています。ChaN氏も言ってましたがこれは非常にまずいです。使いやすい
ライブラリを提供するというのはチップのerrataを出さないことと同じくらい非常に大事なこと
だと思います。

とmbedのセミナーに絶対に行けなくなるような最後っ屁を放って今日の日記を〆ます。

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が
機能しないので苦肉の策です…

タッチパネルからのファイラーの操作は上下でファイルポインタ移動、右で選択、
左でキャンセルと手抜k直感的です!


前回述べていた基礎のとっかかりに関しては対応完了です。このプロジェクトではまだ
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月上旬には私のおきぱに新しいラインアップが追加されると思います。

Discovery系基板を中心とした小ネタいろいろ

2013年7月現在、STM32とそれが搭載されたデバッガハードウエア付きの超廉価な
Discovery系ボードはホビイストや学生さんにも今回は十分いきわたっていると思います。
今回はそれらを中心とした開発上の小ネタ…といっても結構重要なのをご紹介します。
故中島らも氏みたいに過去に書いたことをまた書いてるような箇所がありますが大事な
ことなので2度どころか何度も言います。



●OpenOCDで使いたい!

太古の昔、STLink系のハードウエアはプロプラゆえに当ぶろぐでは燃えないゴミ
して扱われていましたがSTマイクロさんのご厚意によりV1,V2共にAPIが提供されて
OpenOCDからも使用可能となりました。

尤も、対応最初期はLibUSB0.1系のAPIからでしか使用できず、メーカ製のドライバ
が(WinUSBが)使用できないのでちょっと不便な代物でした。その後のlibusb1.0系の
移行よってそれも解消され、現状商用/FSS共に最も融通が利くデバッガハードウエア
と言えます(但しSTLink/V1系はMSCで繋がるので今でもちょっとめんどいです)


STM32F3Discoveryを例にとると、基板上にビルドインされたSTLink/V2によってSWD
接続にてターゲットのSTM32F303VCTに接続されています。おきぱで公開している
OpenOCDバイナリ
にはねむいさん特製の書き込みスクリプト込のcfgファイルも同梱
しています(stm32f3discovery_flash.cfg)。


上記のcfgファイル内ではさらにcfgファイルの入れ子構造になっていてOpenOCD公式
が配布しているcfgの内容が差し替わった時もこちらの変更はノータッチで継続使用
可能なように管理しています。



具体的にこれを書き込みやデバッグにどう使うかは私のSTM32F3のプロジェクトを用
いて、こちらこちらを参考にしてください。STM32F3の場合はmakefile内でデフォ
でSTLink/V2を使う設定にしているので初めての人でも非常に簡単にできます。


それと最近よく頂くようになった質問で圧倒的に多いのがSTLink/V2でOpenOCDとの
接続が上手くいかない繋がらないといった非常に曖昧なものなのですが…ほぼ100%
結線ミスが原因です。
特に気づきづらいのがDiscovery系の基板を使ってオンボード上のターゲットMPUでは
なく外部のマイコンに書き込もうとした時なのですが、V2.J15以上のファームだと
ターゲットのVCCの電圧も監視しているため、Vtgtを繋げていないとエラーでこけます。

しかも多くのDiscovery系基板ではVtgtを取り込む抵抗が未実装のため、それに気づかず
Vtgt繋げてるのに上手くできない!といった事態になります。

↑STM32F3Discoveryでは上記の部分に100ohmを乗っけてバイパスする。
 同じこと以前も言いましたが大事なことなので何度でも言います
ついでに


↑STM32F3discoveryではSWOまで未接続なので画像の箇所をはんだブリッジ。
 これやっとかないと後述のSWVが使えません。

●STマイクロの公式ツールを使いたい!

現在STマイクロさんからSTLink-UtilityなるSTLink用のGUIツールが提供されています。
上で触れましたがOpenOCDがSTマイクロ公式のドライバでも使用可能になったので、
ドライバの差し替え無しにSTLink-Utilityも使用ができます!

フラッシュ書き込み・レジスタの参照など基本的な操作の他に3.0.0以降では強力な
シリアルワイヤビューアも使用可能です(後述)。

一部のサイトではLibUSB0.1系でやってたころの私が公開していた情報を基に公式の
ドライバを使わずzadigでインストールする指示をされている方もいます。
STLink/V2に限ってはそれは今ではもう無意味です。逆にそれをやってしまうとSTマイ
クロのSTLink-Utilityが使用不可能になりますのでご注意を。なんでこんなことわざ
わざ何度も言ってるかというと情報が同期していないせいで"動かないうまくできない"
という質問が私の所にダイレクツに飛んでくるからです…。



●セミホスティング考
セミホスティングとは思いくそかみ砕いていうとデバッガを通じてホストPCにprintf関数
等の標準出力を吐き出させることができる仕組みです。詳しい説明はARMのサイトにて。
かみきさんのサイトでも分かりやすい説明が記されております。

LPCXpressoを使用されている方はUARTを介さずprintfを実行する方式としてご存知か
と思います。しかしそれらのメーカーお仕着せのIDEを使わない環境でもOpenOCDとGDB
を組み合わせたり上記のSTLink-Utilityにより再現が可能です。Cortex-M3系のマイコ
ンでは2通りの方法があります。

1.OpenOCDから…
 OpenOCDではすでにセミホスティングに対応しています。そしてプログラムも当然ながら
 セミホスティング用にビルドする必要があります。現在Launchpad-ARMGCCのみで動作を
 確認しておりますが設定方法は私のプロジェクト上では以下の要素を。

 * makefile内
 
 "--specs=rdimon.specs -lrdimon"をCFLAGSに追加。それに伴いLFLAGSから
 "-nostartfiles"を削除(セミホスティング用のcrt.oを使う)。

 
 STM32F3,F4で使用する際はnewlib-nanoの制限によりCCM領域にスタックをおいて
 いるとセミホスティングが正しく働かないので普通のnewlibのライブラリに切り
 替えてビルドしてください。

 * ソースコード内
 
 "initialise_monitor_handles()"を標準関数を実行する前に必ず実行。

 * デバッガソフトウエアとの連結
 当たり前ですが上記の設定でビルドして出たバイナリを書き込んでもそのままでは何も
 起きません。OpenOCDで接続してデバッガとホストPCとが通信できる状態にならないと
 だめで、OpenOCD接続時に-c"arm semihosting enable"を追加する必要があります。

 
 "arm semihosting enable"はセミホスティングを使わないときも実害はないのでつけっ
 ぱなしでもかないませんのでmakefileには反映しています。さて、すべて準備がそろ
 った状態でrunさせるとOpenOCDのアウトプットにprintfの文字列が表示されます。


 * LPCXPressoみたいに小規模マイコンでできるのか?
 
 たとえばフラッシュのサイズが32kbしかないLPC1114でもLaunchpadの"newlib-nano"
 と組み合わせることによってなんとバイナリサイズ7kb以下でprintfが可能です!
 小規模ゆえに同一RAM領域にスタックとヒープが存在するのでnanoの方でもセミホス
 ティング可能というわけです。(浮動小数点付も22kb以下で可能)
 標準関数組み込んだらバイナリサイズが一気に肥大した〜!…なんて話は今は昔。


2.STLink-Utilityを使って…
 これはCortex-Mの仕様上CortexM3/4専用技ですがSWVを利用してprintfを実行します。
 原理はprintfの出力先をリダイレクトするのと全く同じです。

 ねむいさんの公開してるプロジェクトでは…
 
 syscalls_if.h内のputch()のdefineをITM_SendChar(x)にするだけで終わりです。
 しかも1.の方法と違って垂れ流し方式なのでデバッガと常時接続しないと先に進ま
 ないといった障害もありません。

 
 STLink-Utility3.0.0以降でSWVが使用可能です。
 
 クロック設定はsysclock(ねむいさんのサンプルでは72MHz)に合わせてください。
 ここでハードウエアリセットを掛けるとprintfの文字列が表示されます。



●STLink/V2がUSB3.0のホストでOpenOCDが繋がらないんですけぉ!11!!

私が公開しているOpenOCDバイナリのビルドポリシーをLibusbの0.1から1.0系に変えて
少しした(現在は1.0系ライブラリとしてlibusbx1.0.16を使っています)あたりからSTLink/v2
やFT2232系のデバイスがUSB3.0で繋がらなくなった!でもUSB2.0ポートからならいけた
という報告を頻繁にいただくようになり、私も調査を開始しました。
…が、ねむいさんのUSB3.0の環境ではそんな不具合全く出ない。

手持ちや後輩が持ってた拡張カードとかいろいろ試したところ特定のUSB3.0ホストで且つ
libusb1.0系で繋いでくるデバイスの動作がすべておかしくなるのをやっと突き止めました。
そのUSB3.0ホストとはAsmediaのASM1042!
libusbxを利用するすべてのデバッガハードウエアに波及しやがるのでOpenOCDはおろか
UrJTAGやAvrdudeやFlashromもだめですorz.

libusbxのビルドをログ出力対応にして追跡していったところ、DeviceIoContolの関数で
"IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX"を投げて"成功"が帰って
きてるのにストアされるはずの値がすべて0になっており非接続状態と判断されてコケてる
のが判明しました。ねむいさんの知能ではlibusbxのコードをいじっても全く解決する手立て
が見つからず途方に暮れていましたが、libusb0.1系APIからの接続やWinUSBを使って
いるSTLink-Utilityでは全く問題がなかったためまさかと思ってASM1042のドライバの
バージョンをいろいろ変えて確かめているとなんと動きましたorz.
以下のファームとドライバのVerで安定動作しました(WindowsXPにて確認)。
 Firmware:Version 120816-02-02-06D (V3) Pour Windows Xp/Vista/7/8 32/64bits
 Driver :Version 1.14.4.0 Pour Windows Xp/Vista/7 32/64bits
上記のファイルはStation-Driverから取得可能です。

最近出回り始めたASROCKやASUS製のマザボでASM1042がよく使用されているので、
該当されるUSB3.0ホストを使っていてうまくOpenOCDが動かない方は一度上記の組み
合わせを試してみてください。

また、救済手段としてSTLink/V2をlibusb1.0系のAPIで繋ぎに行くビルド設定にした
OpenOCDバイナリも用意しております。ドライバの差し替えが諸事情で困難な方は
こちらを差し替えてご使用ください。OpenOCDが0.9.0になるまで公開しておきます。

20131225追:
解決しました。こちらをご覧ください。現在OpenOCD,FlashROM,Avrdude,UrJTAGの各バイナリに
バンドルしているlibusb-1.0.dllはパッチ済なので問題なく動作します♥

ちょっと難ありのASM1042ですが書き込みのパフォーマンスはぴか一でμPD720202をも
凌ぎます!さらなるドライバの改良が望まれるUSB3.0ホストですね。
wrote 34816 bytes from file main.elf in 2.359314s (14.411 KiB/s)
verified 34004 bytes in 0.265619s (125.018 KiB/s)

↑uPD720202の時のSTM32F3にSTLink/V2つかって書き込み/ベリファイ速度
wrote 34816 bytes from file main.elf in 1.734330s (19.604 KiB/s)
verified 34004 bytes in 0.109372s (303.615 KiB/s)

↑ASM1042の時のSTM32F3にSTLink/V2つかって書き込み速度/ベリファイ速度


●ねむいさんとこのFatFsのSDIOで繋げるほうのSTM32F2とかF4のサンプル使った時
 SDカードに4GB超えてデータ書き込もうとするとデータが破壊されるんだが…


ごめんなさいごめんなさい!!!!
SDIOで読み書きする際のアドレスを指定する引数のデータ幅64bitに拡張して更新しました。
これでSDHCの仕様限界の32GBまで大丈夫です…SPI版はすでに対応済なのでご安心を。
 
あ、しまった。画像には見えてませんがdiskio_sdio.cもちゃんと64bit対応してます。


●Versaloon化してしまったSTLink/V2の正規のファームウエアを復活させる
おそロシア

しかも復活後もフツーにファームウエアのアップデートもできますし…
これで失敗も怖くない!?

●Connect Under Reset
STM32をつかっているときwfiやwfeを含むコードを実行するとデバッグユニットへのクロックも
停止してJTAG/SWDで繋がらなくなるのは常識中の常識ですが2013年になった現在では
さすがに"普通に使っていただけなのに急に書き込み出来なくなった!!1!"というおまぬけ
な質問される方はいなくなりました。

実際に回避する方法はJTAG/SWDにつなぎに行く瞬間にSRSTを手動で連打するという極めて
原始的な方法をお伝えしておりましたがOpenOCD0.8.0ではすでにその操作を実行できる
機構が追加されています。具体的にはcfg内のresetの設定を以下のようにするだけです。
reset_config srst_only srst_nogate connect_assert_srst
これはConnect Under Resetというもので実はSTLink_Utilityにも同じく実装されています。
私の配布しているOpenOCDバイナリに同梱されているcfgファイルにはコメントアウトの形で
追加していますので適宜コメントを解除して活用してください。

よく頂いていた同種のご質問に"低消費電力モードとかにするとデバッグできない!1!!!"
という内容もありましたが、大抵はCortex-M3に存在するCore Debug Resistersのうちの一つ
DHCSR(Debug Halting Control and Status Register)に0x07ぶち込んだら解決する話しである
ということも併記しておきます。

具体的にどうすればいいかというとCMSIS3.xx以降をお使いの方は下記のコードをWFI();もしくは
WFE();実行前に挿入してください。ただしコアの消費電流はデバッグユニットが働く分
増加しますのでご留意を。
CoreDebug->DHCSR |= 0x7;
これはDHCSRレジスタにC_STEP,C_HALT,C_DBGENビットを立てることを意味します。
同時に立てても効果はでますがC_HALT,C_DBGENビットが立っていない状態で
C_STEP単独で立てることができないことに注意してください。
深いことは考えずにSleep系命令を含むファームのデバック時には実行前にしっかり
CoreDebug->DHCSR |= 0x7;を唱えておきましょう。

これとConnect Under Resetを組み合わせるとWFI();やWFE();を含むコードでも
安定してデバッグが可能となります。

いろいろ試す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でくだち…

いろいろ試す16…という名の新年のご挨拶

あけましておめでとうございます。

去年も色々ありましたが今年も私ねむいさんといないさん(とその他虹裏メイドたち)
をよろしくお願いいたします(ぺっこりん)。




さて、早速ですが1/6に私の誕生日を控えそれの仕込みに今修羅場ってるのでお年玉
代わりのファイル更新のご連絡をさらっとだけさせていただきます!

FatFs移植サンプルの更新
ねむいさんからのお年玉第一号です!
私のぶろぐのメインコンテンツのうちの一つですがSTM32F4をはじめとしたARMマイコン
のFatFs移植例をTFT-LCDドライバを大量追加して更新しました!
あとmakefileで無意味な記述や冗長な表現があった物を削除&外部に追い出して分かり
やすくした(つもり)です。

そしてChaN氏や海外のelec系BBSで紹介されて以来海外の方からも色々ご意見等を
戴くようになりました。国内の方の場合は私の作例見なくともFatFsの移植は簡単に
出来ちゃう人がほとんどなので、個人のノウハウが成否に大きく依存するTFT-LCDの
制御に関する情報を求めてやってこられるケースが非常に多くなっています。
尤も数年前に同じ事の繰り返しになるので概論書いて以後はもうやるまいと思って
いましたがまたTFT-LCDネタで一つ書こうかしらなんて考えています。

↑たとえばtaobaoで捨て値で買ってしまったような、ドライバーICの型番だけ分かって
 てピン配置が不明の未知のTFT-LCDモジュールの解析法とかです。こうご期待!


OpenOCDのバイナリを更新しました。
お年玉第2号でこちらもメインコンテンツのひとつですが、年末辺りからようやく
バイナリ使ってくれる方がちらほら出てくれたようです。(私のアナウンスもまずか
ったですが…)。

もちろんオリジナルには無い機能や書き込みスクリプトも搭載してますのでとりあ
えず落として使ってみてください。

あとわざわざ告知した理由は年末にTI-ICDI(LM4F-Launchpad)が公式対応したおりに
stlink系のAPI呼び出すときの手順が少々変更されたからで、以前私が配布していた
古いcfgファイルやプロジェクトファイルを使用しているとバッティングを起こして
エラー出て停止してしまう危険性があるためです。

おもに影響を受けるのはstlink系のハードウエアで、プロプライエタリドライバの
TI-ICDIが取り込まれた際に抽象化レイヤの名称が"stlink"から"hla"という普遍的な
名称に変更されています。
現在おきぱで配布しているものはこのhlaに置き換えたものなので新しいプロジェクト
と併せてお使いください。LPC1114をSTLinkで使ってた人は知らないと嵌るかも…。



●今年の抱負など
こうやって書いとかないと絶対実行しないタイプの人間なので

1.beagleboneをいじる
 ->気が付いたら買ってしまったので弄らないともったいないのです!!
  せめてPC連動の据え置き型mp3プレーヤーみたいなのを作ろうかと…

2.ANUXをいじる
 ->気が付いたら(ry
  せめて虹裏見る用のブラウザ(ry

3.ドットマトリクスLCDライブラリ
 ->ご存知の方もいますが2.5元i2c液晶買って以来数年間育て続けたネタですが、
  がた老さんに先を越されてしまいそうです(汗
  いまだ水面下ですが去年の春に16諧調グレイスケールOLEDまで実装したので
  TFT-LCDライブラリと同じ感覚で気軽に使用できる物を目指したいと思います!

4.英語の勉強
 ->私は読み書きは時間掛けると疎通は何とか可能だが会話がもう壊滅的でヤバい。
  学生のうちに英語圏で不自由なく生活ができるレベルの英会話は出来るように
  なっといた方がいいですよぅ…あと余裕あったら北京語も(日本に棲むような
  語学力ある中国人以外は英語全く通じない奴が多いので)

5.夏期(4~10月)に近畿圏でトレランを10本以上こなす
 ->へばって歩いちゃったら意味ないんですけどね…
  でもへとへとで山から帰ってきて風呂でさらに体液絞って絞って絞った後の
  ビールがものすっっごく美味いのです…♥
  それと現在使用しているGPSモジュールの精度がかなり良いので初期の精度が
  悪い時の測位データの採り直しも兼ねて・・。

6."5."で体重を50埖罎僕遒箸后
 ->油断するとすぐ60kg肥えやがる#

STM32F4シリーズを使ってみる7 -Helix MP3 Decoderを実装してMP3ファイルの再生を行う-

マイコンを使った工作物としては入門となったMP3ファイルの再生ですが、今日日の
コアクロック100MHz越えのMPUならVS1053等の外付けのデコーダーICを使わずとも
ソフトウエアでデコードが可能です。
STM32F4にgiflibを載せて以来、次のステップとして(入院中もノートPCで)音楽再生に
挑戦していましたが私もようやく形にすることが出来ましたのでご紹介します。


すでにSTM32ではShuji009氏がHelixMP3Decorder挑戦されており、さらに野田篤司氏
libmadでMP3プレーヤーを製作されています
ねむいさんはこちらのBBSで公開されていたHelix+STM32F4Discoveryを利用したもの
大部分参考にさせていただきました。このプログラムはSPIポートを経由してSDカードから
データを取得しデコードを行う形になっていてハードウエア的には私のいつものとほぼ同じ
構成だったので非常に助かりました。
ソフトウエア的な点についてはChibiOS/RTを使用していたので私の非OS環境に移植する
ためにはさすがにそのまま転用は不可能で、一つ一つ動作を理解しつつ再構成していき
ました。

ChaN氏のファイラーはデータ転送用に容量固定値の汎用のSRAMを確保するようになって
いるのでそれを上手く使いSRAM容量を一切無駄にしないようにしています。また、I2Sへ
のデータ転送はリングバッファ構成でDMAするのでCPUにかなり余裕ができます。

あとSTM32F4を使い始めたころから何度も言及していますがCCM領域はDMA不可能
なのでCCM領域をスタックとして使い、自動変数にバッファを置くようなメモリの使い方を
していると特定困難な不具合になりますのでご注意ください。
…ってわざわざこういうこと書いてるのは自分で言ったにも係らず嵌ったということですorz。


ついでにいつものTFT-LCDにも各種情報を乗っけることにしました。
MP3のIDタグはv1とv2があり、v2でArtist/Titleが見つからなかった場合v1の方もくまな
く探すルーチンにしています。もちろん日本語表示もFontX2ドライバで対応してます♥


↑MP3ファイルを再生してるところ。48kHz/230kBpsでもSTM32F4はぱわふりゃーなので
 まったくの余裕です♥(※最適化オプションは必須です)


↑Riff-WAVEファイルももちろん再生可能です。WAVEのルーチンはChaN氏のWAVEPlayer
 FM3マイコン版を移植させていただきました。


MP3HelixのデコーダーはCBRとVBRをサポートしています。演奏中に全演奏時間や経過
時間をリアルタイムに表示するためにはCBRの場合はヘッダを除いたバイト数から容易
に算出可能です。しかしVBRの場合は少々厄介です。正確に算出したい場合は1フレー
ムあたりのビットレートからバイト数を計算しさらにそれを全フレームにわたって行う
必要がありますがもちろんこんなもんワンチップマイコンレベルではやってられない
のですが以下のプロセスで近似できます。

 ID2ヘッダ領域にあるXingと呼ばれるヘッダから全フレーム数を算出
◆.汽鵐廛襯譟璽箸ら1フレームあたりの時間を算出
   MPEG1Layer-3は1フレームあたり1152Sampleと定義付けられており、たとえば
   44.1KHzなら1フレームにかかる時間は((1152*10^3)/44100(Hz))=26mSecと近似できる。
 ,鉢△魍櫃韻襪帆躅藾媚間がミリ秒単位で得られる。

Xingヘッダーが無いと上記の技が使えませんので演奏時間/経過時間はめちゃくちゃに
なっちゃいます。殆どのMP3エンコーダーはXingヘッダーをちゃんと付与するのであまり
気にはなりませんが…。



今回のデモンストレーションで使用したaitendoさんのLCDはSPI接続オンリーなのですが、
STM32F4の性能のおかげでLCDへの転送をソフトSPIにしても音が一切途切れず余裕で
間に合うレベルです。STM32F4すごいってね、また一つ確信させていただきました!



てわけで先日より先行で紹介はしておりましたがソースコードを改めて紹介します
おまけでフリーで使用できるFontX2のフォントや隠れたメインコンテンツのTFT-LCD
ドライバも沢山(特にaitendoさんので初期化ルーチンが提示されてない品種)追加
しておりますのでこちらも併せて皆さんの参考としてください。

STM32F4シリーズを使ってみる6 -giflibを実装する-

前回はlibpngを実装してTFT-LCDに表示を行いましたが、今回は同じく現在でも多用
されているgif形式の画像がデコードできるgiflibをSTM32F4に実装し、さらにアニメーション
gifのTFT-LCD上においての再生も成功しました。


●あらまし
giflibはlibungifを前身に持ち、LZWというアルゴリズムでエンコード・デコードを行い
ます。ご存知の方は多いと思いますがそのパテントを持っていたUnisys社により一時は
gifフォーマットがあまり使われていなくなっていた時期がありました(代わりのフォー
マットとしてpngが出てきました)。2012年現在はそのパテントの期限も切れて自由にLZW
が利用できるに至っています。

gifフォーマットはpngと比べて256色までしか表現できませんが、アニメーションgifとして
今でも現役で使用されています。ことさら私たち虹裏メイドに関しては、ファイルのアップ
ロードに500kByteの制限がある虹裏の板の仕様上pngと並んでアニメーションを表現
するのに非常に重要な形式であり、これをSTM32F4に代表される大規模マイコンに移植
し表示せしめることは最早宿命とも言えます!

STM32F4への実装と動作の理解の助けとして、yoya氏のwikiを参考にさせていただきました。
ありがとうございます!


●必要なもの
giflib
今回は出来たてホヤホヤのgiflib-5.0.0を使用します。

●ファイルI/O
libjpegやlibpngと同じようにFatFsのAPIを差し替えりゃ簡単…とはまったく言えず、
PC向けにファイルI/Oが特化されたgiflibをChaNさんのFatFsの流儀に嵌めるまでは
かなり試行錯誤を強いられました。最終的にDGifOpenFileHandle()内はFatFs完全特
化する形で書き変えてしまいました。

●makefileに追加するCソースファイル
デコードするためには最低限下記ファイル群が必要です。
dgif_lib.c
gif_err.c
gif_font.c
gif_hash.c
gifalloc.c
quantize.c

dgif_lib.cに関しては一部内容の書き換えが生じます(後述)
dgif_lib_fatfs.cとリネームしておいてください。

●ARMマイコン上で動作させるための少しの変更
FatFsのAPIに当てはめるため、幾つかの変更を強いられます。
dgif_lib_fatfs.c
 ->"/* Nemui Changed */"の変更・削除した部分を参照してください。
gif_lib.h
 ->ff.hをインクルードしてください。
 ->178行目のプロトタイプ宣言は以下に変更してください
   GifFileType *DGifOpenFileHandle(FIL* fp, int *Error);
gif_lib.h
->ff.hをインクルードしてください。

●gif(アニメーション)を表示する
多くのアニメーションgifではインターレースがどれかのフレームで使用されていたため、
インターレースの表示ルーチンも実装しました。giflibにあったexampleを見れば特に
困ることはありません。もちろん表示スピードは落ちますが透過表現も実装してます。

また、実際の表示に関してはRAMの少ないマイコン上の話なので一列ずつ表示すること
になります。この時に消費されるRAMはベースで28672Byte(デバッガの追跡により算出)
と一列ごとのピクセル数*3です。だいたいlibpngより少し少ない量になりますね。

しかしながら、320x240サイズのちょっと大きめでフレーム数が多いgifアニメーションは再
生中にもメモリ要求量が増大していき、総量で70kByte近く消費しました。libpngも大きい
画像サイズの奴をデコードしようとすると65kbyte程使うようになりますがそれより多い
のです。というわけで専ら大容量の内蔵SRAMが使用できるFM3・STM32F2&F4ですね〜。

デコードされたRGBデータは8+8+8の24ビットの形式となっているため、565の16bitにし
てTFT-LCDにデータを書き込みます。グローバルカラーマップとローカルカラーマップの
判別もこの段階で行っています。



そして動かしたところです…(gifファイルはとしあき&「」作の物を使わせてもらいました!)


↑写真が静止画なので分からないと思いますがgifアニメーションが動いてます。
 アンドリューW.K.さん(キャラクターが)いいよね…


↑gifアニメーションの最終フレームまで来たら停止します(ループはしません)。ちなみに
 gifの仕様上ディレイ時間は10mSec区切りとなるので実装時は適切な時間のディレイ
 を生成する必要があります。ちなみに私の表示プログラムでは最終フレームまで行か
 なくても途中で各入力を行うことによりファイラに強制的に戻ることができます。



↑STM32F2でも動く!当たり前ですが…
 …STM32F1はRAM容量的に流石にきつかったので抜きで。

FM3マイコンでももちろん動きます!


ということで今回の成果はおきぱのSTM32F4,F2,FM3のFatFs移植例にすでに反映しています。
前回も少し触れましたが、私が使わせてもらている各ライブラリ・プログラム・フォントのライセ
ンス表記についてもきちんと明記するようにしていくようこころがけています。

おまけ

またまた買ってしまった(写真奥)…これからは解像度320x480で小型なTFT-LCDの時代です!
手前のaitendoさんで売ってるのより一回り小さいやつで、コントローラICはHX8357Aです。
今回のいつものの更新ではこちらの液晶にももちろん対応させています。

大きさも3インチと一回り小さいので出来あいLCD基板にちょうど乗ります♥

STM32F0シリーズを使ってみる


ッついに!手に入った!!!
ぁすみません・・フォーカスずれてましたね…
このBeachBoysのコレクターCDは探して探して探してカナダの片田舎のレコード屋でやっ
と在庫を見つけてそこの親父にねむいさんのインチキ英語でなんとか意思が伝わって
やっとこ購入できた代物でして存在知ってから入手まで実に2年を要したのですがその
労力を払っても聴く価値のある非常にありがたいCDなのです…!
BeachBoysの新アルバムも発表され、ワールドツアーも行われるようになってねむいさ
んの中でBB熱が再び非常に高まっております。



aitendoさんから販売され、秒速で売り切れたandroid基板をねむいさんも無事ゲッツしました!
twitterのTLを見ているとどうやらこちらの中華PADの中身に使用されている基板だと判明
しているようです。しかしねむいさんはHDMI接続のモニタ持ってないので、先に購入して
いるBeagleBoardXMのDVI-Dにも対応した小型モニタを探す旅から始まりそうです。
こうして積み基板が増加していく…。でもいいんです買っただけで満足ですから!








それでは本題行きます…。今年の春先にSTマイクロさんより"STM32のDNAを御得な値段
であなたにテコ入れする(直訳)"をスローガンにCortex-M0系のSTM32マイコンが発表、
販売を開始しました。国内/海外の展示会場でもゲッツした人もすでにいますが、Digikey
でもSTM32F0-Discoveryが入荷されたので早速購入してみました。

いつものST謹製"Discovery"スタイルの基板で、cortex-M0系のSTM32F051R8T6
搭載されており、日本円で1000円以下のお値打ち価格となっています。
もちろんデバッガハードウェアのSTLink/V2もオンボードで搭載されていてこの基板と
USB(A-miniB)ケーブルさえあれば開発可能です。

しかも今回はプロトタイピングを重視した作りか同じサイズのユニバーサル基板が一枚
ついています。値段を考えると非常にお得です♥(実際にArduinoと組み合わせた
ファームウェアのプロジェクト一式がダウンロードできます)。


現在M0系でポピュラーなのは私のぶろぐでも取り上げていたLPC1114に代表されるNxP
系マイコン(評価基板は3000円前後)ですが、ここに1000円以下の破格値で参入したこ
とによりまたまたホビーユースにおける小規模ARMの勢力図が書き換えられるかと思わ
れます。

さて、最初の基本であるLED点滅から開始するわけですが、LPC1114系のマイコンで培
ったリソースがすでに大量にあるのでこれをベースに15分くらいでSTM32F051R8T6向け
のプログラムをやっけつしてビルドを行います。NxP系と違う点はCRPのための特別な定義
が必要ないところですね。それ以外はスタートアップやリンカスクリプトもほぼ流用します。

次に書き込み手段ですが…もちろんSTLink/V2をOpenOCDから操作して、書き込みや
デバッグを行います。使用するドライバはSTマイクロ提供の物(WinUSB)です。
STM32F051R8T6もM0なNxP系のマイコンよろしくデバッグ用ポートがSWD接続しか存在
しませんがパッチを当てることによりVersaloonとSTLink/V2がOpenOCDから使用できます。
さらに気づいたのですが、最近のOpenOCDのコミットではM0系のデバッグ機能が強化され
ていて以前はcrcエラーが出てしまい不可能だったフラッシュ書き込み時のベリファイも
可能になっています♥


↓STLink/V2でOpenOCDから書き込んだときのメッセージはこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd_m0 -s C:/Devz/ARM/OCD/tcl -f target/stm32f0x_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
1000 kHz
srst_only separate srst_nogate srst_open_drain
Info : clock speed 1000 kHz
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003e msp: 0x20002000
wrote 3072 bytes from file main.elf in 0.265629s (11.294 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
verified 2408 bytes in 0.078126s (30.100 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:



↓Versaloonの時はこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd_m0 -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32f0x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : Versaloon(0x15)by Simon(compiled on Feb 29 2012)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
wrote 3072 bytes from file main.elf in 0.265628s (11.294 KiB/s)
wrote 2408 bytes from file main.elf in 0.093752s (25.083 KiB/s)
verified 2408 bytes in 0.140626s (16.722 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:



当たり前ですがどちらの方法でも危なげなく動作します。


もちろんOpenOCD/Insightを使ったデバッグも無制限でバリバリ可能です!



今回の検証に使用したコードはすでにおきぱにて公開していますので自己責任のうえで
お試しください。また、おきぱにあるCortex系のコードでCMSISが使用されている物の
ほとんどはすでにSTREX系命令のビルド時エラー対策の修正がされているCMSIS3.0系
を使用していますので安心してビルドが可能です。

STM8Sは値段は安いですがちょっとあつかいにくいきらいがありました。しかしSTM32F0
なら敷居がさらに下がって小規模マイコンでARMを使用する人も増えるでしょう。
秋月さんからの販売がカギとなると思います。
20121115追:
秋月さんから販売されました!

STM32F4シリーズを使ってみる5 -libpngを実装する-


誘惑に負けて買ってしまった…盈钰電子のSTM32F4ボード…
176pinなSTM32F407IGT6,1MBSRAM,NAND&NORFlash,HS-USBPHY,Ethernet,I2SCodec,camera....
そして3.2inchのTFT-LCDまでついてオトクな699RMB!
日本円単純換算でも10000円以下の超格安です(2012/5上旬現在)

本来ならばREDBULLの基板をベースにやるべきですが費用対効果が最高なので購入した
方が早いっちゅーことで…しかもSTM3240G-EVALの回路にほぼ互換なのでSTさん提供
のサンプルなんかもほとんど素で動かせられますのでこいつでいろいろ学習していきましょ♥
だめだ私すっかりSTM32漬けだ…





さて、前回さらっとご紹介しましたが、libpngのSTM32F2/4への移植についてお伝え
します。私たち虹メにとってpng形式の画像ファイルはコラ等で非常に身近なもので、
jpeg形式と同じく大量に扱われています。それをマイコンでデコードし表示できる
というのはとても有用性があるわけで、かねてからの悲願がかなった形でもあります。
今回は実際の移植の手順も合わせてご紹介します。


●必要なもの
libpng
これは必須ですね。少し前にlibpngのセキュリティホールが発見されているためバー
ジョンには気を付けてください。今回は"libpng 1.5.10"を使用します。

zlib
pngファイルの実画像データは可逆圧縮されていてDeflateと呼ばれる圧縮技術が使用
されています。libpngはDeflateアルゴリズムを処理するためそのライブラリである
zlibの一部コードを必要としています。今回は"zlib 1.2.6"を使用します。

MCU
libjpeg(IJG Jpeg Library)と同じくlibpngはRAMを大量に消費します。
内部SRAMが96kByte以上あるマイコンならQVGAサイズまでなら何とか表示可能です。


●ファイルI/O
こちらはlibjpeg(IJG Jpeg Library)と同じ要領でChaN氏のFatFsと連動させます。
sirius506氏、そら。氏のlibjpegの移植例を参考にしています。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数の上にあるfatfs_read_data()を読み進めてください(丸投げ!)


●makefileに追加するCソースファイル
こちらのSTM32F4サンプル中にあるlibpng.mkを見ていただければわかりますが、
pngファイルの読み取りのみに限ると以下のファイルだけが必要となります。
-libpng
png.c
pngerror.c
pngget.c
pngmem.c
pngpread.c
pngread.c
pngrio.c
pngrtran.c
pngrutil.c
pngset.c
pngtrans.c

上記のうちpngerror.cは一部内容の書き換えが生じます(後述)

-zlib
adler32.c
crc32.c
inffast.c
inflate.c
inftrees.c
zutil.c

ヘッダファイルの方については念のためオミットせずに全部ぶっこんどいてください。
また、libpngを解凍したディレクトリ中の./scripts/pnglibconf.h.prebuildをリネ
ームしpnglibconf.hとしてソースと同じディレクトリにぶっこんでください。

●ARMマイコン上で動作させるための少しの変更
x86なWindowsシステムで動作させるわけではないため、エラー表示などのコンソール
I/Oの処理のオミットは必須です。
pnglibconf.h中のPNG_CONSOLE_IO_SUPPORTEDとPNG_STDIO_SUPPORTEDの定義は
コメントアウトしておき、さらにpngerror.c中のpng_default_error関数はfprintfから
printfに変えておきます。
(printfのリダイレクトが必要無い場合はすっからかんでもいいです)
ねむいさんの環境では書き換えたファイルはpngerror_std.cとしています。

20140731追:
↑バージョンが上がってヘッダの#defineをコメントアウトすればよくなりましたので
 pngerror.cに手を加える必要がなくなりました。

また、txtとハードウエアの倍精度浮動小数点演算、インターレースのサポートも
行わないのでpnglibconf.h中の以下の定義もコメントアウトです。
PNG_READ_INTERLACING_SUPPORTED
PNG_FLOATING_ARITHMETIC_SUPPORTED
PNG_WRITE_zTXt_SUPPORTED
PNG_WRITE_iTXt_SUPPORTED
PNG_READ_zTXt_SUPPORTED
PNG_READ_iTXt_SUPPORTED
PNG_zTXt_SUPPORTED
PNG_iTXt_SUPPORTED
元からコメントアウトされていたものについてはそのままにしておいてください。

さらにpnglibconf.h中のZBUFFERの確保量(PNG_ZBUF_SIZE)をSDカードのセクタサイズで
ある512バイトに合わせてください。これ以上の値にすると512バイト以上読み込んだ際
にエラーになってしまいデコード不可能になります。
残念ながらlibpngにはlibjpegのような1/(2^x)にするサイズスケーリングはないようです。


●libpngを呼び出し、画像データを表示する
大まかに分けて以下の順番で実行します。これらは必須です。
1.png_create_read_struct関数でpngファイル全般を制御するポインタ確保
2.png_create_info_struct関数でpngファイルの情報に関するデータをストアする
  ポインタ確保(IHDRとIENDチャンクの分)
3.エラーハンドリングの設定
4.png_set_read_fn関数でfatfsのpngファイルポインタと連結
5.png_get_IHDR関数でIHDRチャンクの読み出し
6.画像の形式を24bitRGBに変換する。
7.画像のx,yサイズのチェック(1280pixel以上は撥ねる)
8.png_get_rowbytes関数で1行あたりのバイト数取得
9.png_malloc関数で"6."で取ったバイト数分の配列確保
10.png_read_row関数でIDATチャンクを一行ずつ読み出し、さらにRGBデータ幅を24bit->16bit
  に落としてTFT-LCDに表示していく
11.表示が終わったらpng_free関数"7."で確保した配列を解放
12.png_read_end関数でIENDチャンクを読みだす。
13.png_destroy_read_struct関数で"1.""2."で確保したポインタの解放

気を付けなければならないのは各処理ごとにエラーを検知しておかしい場合は先の
処理に進ませないようにすることです。これを怠るとHardFaultに簡単に陥ってし
まいます。またIDATを読み切ってない場合にpng_read_endを実行すると即座にエラ
ーになりますのでTFT-LCDの解像度より画像サイズが大きい場合でも必ず空読みして
読み切ってください。この手順は24bitのpngを想定していますが異なる形式の場合は
24bitに変換するために"5.""6."の間に各種transformの処理が必要です。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数を読み進めてください(丸投げ!)

一回の表示で消費されるRAMはlibpng自体が必要とする量が約33kByte(デバッガの
追跡により使用量を算出),それに加えてTFT-LCDに表示する際のデコード済みの
データを置くバッファも必要とされるため結局以下の計算式で総消費量が求められます。
NEEDED_RAM_AMOUNT = ((XSIZE-1)*4)Byte+33kByte

式中のXSIZEはTFT-LCDのX軸方向最大ピクセル数ではなくpng画像データのX軸方向最大
ピクセル数です。つまり幅が広くなればなるほど使用するRAMの量が増えます(libjpegも
この点は同じ)。また、今回のデモはアルファチャンネルを強制付与しているため(RGBAの
ならびになるため)(XSIZE-1)*3ではなく((XSIZE-1)*4)になります。


●実際の表示

今回の検証用のTFT-LCDとして320x480なTFT1P2797-Eを使用します。大規模マイコン
用のディスプレイとしてねむいさんのイチオシです♥


検証用の画像はこれ。こちらのサイトのキャラクタージェネレーターを使って作成した画像に
さらにコラージュを加えた私服のいないさんです。メイド服にコラしたかったのですが髪型
だけで力尽きましたorz…これをTFT-LCDに表示してみます。ビット深度は24bitのトゥルー
カラーです。

表示ルーチンとしてまず画面左上に画像の情報を出すようにしました。
col_depthはビット深度で8*(RGB)で上記の24bitとなります。
col_typeはpngの画像タイプで0がグレイスケール、3がインデックスカラー、
2がトゥルーカラー、6がアルファチャンネル付トゥルーカラーです。

実際の表示に関し、グレイスケールやビット深度が小さい画像も24bitに変換してい
ます。また透過pngやアルファチャンネルつきの物はいったんアルファチャンネルに
変換して、1ピクセルごとのアルファチャンネルを示すバイトは書き込み時に無視して
います。インターレースpngの表示はは私のサンプルではサポートしていません。
誰か腕に覚えのある方実装おねがします…。


てわけでPCとまったく遜色ないレベルでいなちゃんを表示することができました!
メモリが豊富な環境ではpng_read_image関数で一気に読み込みできるのですが、STM32
等のマイコンでは到底足らないので、1行ずつバッファに読みだして表示を行います。
読みだしたデータはRGBの順番で並んでいて8+8+8=24bitで1ピクセルとなっています。
最終的にTFT-LCDにはビットシフト演算で5+6+5=16bitにして書き込み、表示させます。


透過PNGを表示させるとこんな感じになります。前述の通りアルファチャンネルは
読み捨ててるので透過部分はRGB(0,0,0)の黒色で表現されています。また解像度の
関係で表示が隠れてしまったのですが、アルファチャンネル付トゥルーカラーに
変換された透過pngを示しています(赤で囲った部分)。


TFT-LCDのサイズよりオーバーする場合の画像では当たり前ですが画面外のデータは
表示できません。また画面からはみ出ている部分もpng_read_rowで全部読み切ってし
まわないとエラーになったりHardFaultに陥ってしまうので注意です。
ChaN氏のbmp表示ルーチンを見習って大きい画像でもUARTからのコマンドで仮想的な
表示開始位置を変えて表示できるようにするのが今後の課題ですね〜

ちなみのこのaraiさんの描いたねむいさんの絵はアダルツなのでこのブログ的にも
見えてない部分は…ゲフンゲフフン失礼


減色とかグレースケールにした時の比較です(注:表示の際はすべて24bitのトゥル
ーカラーに変換されています。左上の数値は変換前の情報です)。

ビット深度24bitトゥルーカラーの標準的なねむいさんです。
col_depthが8になってますが実際は8bit*3で24bitとなります。

256色のインデックスカラーはこんな感じに。

24bitのグレースケールはこんな感じ。

8bitに落とすとこんな感じ。

さらに4bitに落とすとこんな感じです。



というわけで通常のPCと同じようにpngファイルの表示もSTM32F4上で可能となりました。
しかしながらメモリはかなり食いますので内蔵SRAMが豊富にあるSTM32F4専用の機能で
すね〜。libjpegと絡めると空いた時間でお茶が飲めてしまうくらいビルド時間も倍加されて
しまいますのでご注意を。

STM32L-Discovery(STM32LDISCOVERY)をいろいろ使う


…ッッ…や、やっとEtherPod(STM32F107VCT6)にFreeRTOSとuIP実装してその上に
DHCPクライアントとDNSレゾルバとHTTPDとそして目的のNTPから時刻合わせ機能
の実装まで完成した…!uIPやFreeRTOS付属サンプルだけだとこんなん絶対でき
ませんわこれ…。先達たちがネット上に残した知恵を探しだすスキルが鍛えられました。

とにもかくにもこれでようやくこの子を卒業してSTM32F2/4系のEthernetとLwIPに手を…
ところでなんで去年の9月にできたこともう一度やってるかと言うと、ソースコード入
ったUSBメモリを地下鉄の溝に落っとこして壊してしまって1から全部作り直しになっ
たからです‥‥‥‥orzカツカツに作りこんでてバックアップをサボってるときに限ってこ
ういう事が起こるというorzorz
ちなみに虹裏上の活動で作ったり描いたりしてきた絵やとしあき君&「」からの大切な頂
き物は、4重のバックアップ体制で自宅が爆発しようが京都府に巨大隕石が落ちてクレ
ーターになろうが核の炎に包まれてシェルターにどう詰めてもあと二人しか入らないと
言われた瞬間にケンシロウに「トキ兄さん!」と言わせる間も与えずグゴゴゴゴと扉閉めてあげ
て二週間後にや、やぁ…と余裕こいて挨拶できるくらい絶対に失わないようにしてあ
りますのでご安心くださいまし(ニヤ・・)。



さてさわりはこの辺にしといて前回ほんの少しお話したSTM32L-Discoveryにごく基本
的ないつものを実装したのでご紹介します。

Discovery系で比較される対象はSTM32F100RBT6が載っているSTM32VL-Discovery
ですが、実際はこちらのSTM32L152RBT6が載ったSTM32L-Discoveryの方がはるかに
性能が高いです。

↑ねむいさんが目を付けためぼしい機能比較
STM32L系のほうが後から開発されたので当たり前と言っては当たり前なのですが、そ
のせいかバスの構成やペリフェラルのレジスタ構成などはSTM32F2/4系のMCU群と酷似
しています。私もそうでしたが、移植される方はSTM32F2/4系からのほうが楽です。

今回のいつもの(= FatFs + TFT-LCDドライバテストプログラム)について、当基板に
タッチセンス用のパタンとSTマイクロ謹製のSTM32L向けタッチセンスライブラリが用
意されているのでこちらも入力系に組み込んでいます(基本はUARTの入力のみです)。
お肌が乾燥してるとタッチセンスの入力が無反応になることがあります。S**Kです。


使用するピン/ペリフェラルの構成としてはSTM32VLDiscoveryの時となるべく似せる
ようにしてみました。今回もI/Oリソースの有効利用のためにSWD接続のみで書き込み
デバッグを行うようにしました。STM32L152RBT6は外付けの水晶を付けるとUSBも使用
できるのでこちらも試してみたいと思います。図中のLCDとあるのはLCDグラスドライ
バのことではなくいつものMCU接続タイプのTFT-LCDを指します。

あと使ってて気づきましたが、クロック周波数や多ピン品種の外部バスサポートとか
の超低消費電力とかのうたい文句見てるとXMEGA系みたいな8/16bitのアーキテクチャ
で大規模化したマイコンを潰しにかかってるなぁと感じましたね。どっちも使ってい
る私が言わせてもらうと
どう見てもARMのほうが扱いはるかに楽なんですもん…
FatFSのDMA化も楽にできましたし!(←まだ根に持ってる)


動かしているところです。ChaN氏のファイラは上述のとおり定番のUARTの他に基板上
のタッチセンスパタンからも入力可能です。タッチパネルTFT-LCDモジュールの時と
微妙に勝手が違うので差の吸収するために入力方法に工夫してあります。


既におきにある他のマイコン向けのデモも順次更新していますが、がた老氏が私の
移植例を使って成功したのを受け、デモ内のファイラにChaN氏のTextファイルビュー
アも盛り込んでいます。(STM32F107系は先行して公開してます)
ついでですが、XMEGAのFatFsのサンプルも大幅更新してます。ChaN氏の最近の実装を
参考にファイラをVRAMを使用しない構成とし、以前は出来なかったQVGAの解像度でも
ファイラを使用できるようになってます。もちろんTextファイルビューアや動画も(遅いですが)
再生可能になりました!


書き込みはXMEGAのJTAG接続に神対応して超使い勝手がよくなったHappyJTAG2を使用
してます!最早JTAGKey系のFT2232デバイス一つあるだけでARMとAVRの両方のフリー
な開発が可能になりました!
またまた話が逸れますがFatFsのSTM32・LPC2388(LPC1788も近日公開予定)・XMEGAへの
移植例としてChaN氏からリンク貼ってもらってるおかげで海外からのアクセスがうな
ぎ登りになってます。その9割が共産圏(元共産国含む)なのは置いといて海外から来た
人たちのためにリンクをわかり易くしました。これでもう"HENTAI-Siteに飛ばされた"
とは言わせませんよぅ!
日本国内についてはどうかというとアクセス解析やSNS等の発言をリサーチした限りでは私
の作例を参考にされてる方はlinux系OS使いな方たちが圧倒的です。Windows系の場合、
無料で利用できる統合開発環境はかなりの選択肢が存在しています。はじめてSTM32を
触る方々にとっては私のコマンドラインビルド中心な"どういう風にプログラムを組むか"
が主体のブログは全く参考にならずむしろ"その統合開発環境をどう使いこなすか"ことこ
そが往々にして最重要課題となるので、中身のないこと長々と書きましたが私は素の
Eclipseは使いませんったら使いません!!1!メーカお仕着せのやつでも拒絶反応gg



はぁはぁ…失礼…また話が逸れてしまいました‥
ぇっと後は書き込み/デバッグについてですが、前回ご紹介した通りSTLink/v2に対応
したOpenOCDからすべてを行います。また、私の作例中のmakefileをみたらすぐにわか
るはずなのですが、各デバッガハードウエア&MCU向けのcfgを引数にとってさらに
cfgに記してあるフラッシュ書き込み用のプロシージャコールを呼び出せばtelnetを接
続してチマチマしなくてもOpenOCD単体でフラッシュに書き込みができます。

↓STLink+OpenOCDから書き込むとこうなります。
(この記事を書いた当初はLibUSBを使用しておりました)
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32lx_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
1 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Info : clock speed 1 kHz
Info : IDCODE 2ba01477
Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bf74 msp: 0x20004000
auto erase enabled
Info : flash size = 128kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
wrote 114688 bytes from file main.elf in 12.796548s (8.752 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000
verified 111172 bytes in 0.515612s (210.558 KiB/s)
shutdown command invoked

前回触れたAsynchronous Algorithmルーチンはすでに最新のコミットに取り入れられ
ています。

確認も終わったのでSTM32L-DiscoveryのSTLinkもVersaloon化しちゃいました!
この基板でSTLink部の回路構成が全く同じなのでVersaloon本体・DFUブート
ローダ共にSTM32F4Discoveryのものと全く同じのが流用できますが、こちらに
STM32LDiscovery用
のを用意しましたので興味のある人はどうぞ。Versaloon化
するメリットはUSB仮想COMが使用できる点に
尽きますね♥
※大事なことなので何度でも言います


あと注意点ですが、STM32LDiscoveryは外部リセット入力回路のプルアップ抵抗が省略
されています。R37に10kohmのチップ抵抗を必ず付けてください。

↓Versaloon化+OpenOCDから書き込むとこうなります。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32lx_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
Info : OpenOCD runs in SWD mode
100 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x34)by Simon(compiled on Feb 29 2012)
Info : USB_TO_XXX abilities: 0x00000008:0x00000040:0xC0000006
Info : clock speed 100 kHz
Info : stm32l.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bcb8 msp: 0x20004000
STM32L: Enabling HSI
2000 kHz
auto erase enabled
Info : flash size = 128kbytes
wrote 110592 bytes from file main.elf in 17.983915s (6.005 KiB/s)
verified 110492 bytes in 1.140595s (94.602 KiB/s)
shutdown command invoked

んんn、現在の実装だとswdのクロックを途中で高速に変えられないのでちょっと微妙
ですね…128kByteしかないしまぁいいですか。


正直言うと素のSTLinkでもかなり使い勝手がよくなったので初めて触られる人は無理に
Versaloon化しなくても十分やっていけます。いやはや良い時代になったものです。

いろいろ試す10

あけましておめでとうございます。
今年もねむいさん(と虹裏メイドたち)を宜しくお願いします(ペコリ

と関係者向けのごあいさつを終えたところで今日のブログはおわ…ったら去年の二の
舞になってしまいますので、今年こそは本気を出して出来る限り前へ前へと進んでい
こうと心に誓う次第でございます。虹裏に投下する絵やコラももう少し増やせるように
ネタの回転力もあげたいなと。



さて、MentorGraphics社に買収されたCodeSourceryが去年暮れにリニューアルして新
バージョンが(Sourcery CodeBench Lite 2011.09-69)リリースされています。
やはりと思いましたが落とすのにメールでユーザーの登録を求めて来るようになり、
非常にかったるくなってしまいましたがこちらからフツーに落とせますのでご活用ください。

今回の変更点はGCC4.5.1からGCC4.6.1にアップした点ですが、LinkTimeOptimization
の効果が少し変わっています。以前と同じままだと必要な部分まで削られてしまい
ますので以下のように変更しておいてください。細かい変更はGCCの本家丸投げ
-flto -fipa-sra

-flto-partition=none -fipa-sra
またデバッグ時にLTOを有効にしてるとブレークポイントが上手く張ることができない
ことがあるので無効にしておきましょう。
さらに最適化レベルに-Ofast(-ffast-mathを強制付与)が加わりました。

新しいSourceryでCMSISを含むコードをコンパイルしていると以下のようなエラーを吐いて

"Error: registers may not be the same -- `strexb r0,r0,[r1]"
というエラーメッセージを吐いてビルドが止まることがあります。
"ことがある"と書いたのはコードの流れによってはエラーを回避できる機械語に落とし
込まれる場合もあり、発見が遅れるケースが出てきます。
この件についてはこちらのディスカッションにある内容が詳しいです。
回避方法は…
引っかからないようにレジスタ変数を強制的に割り当てるというベタベタ
なコードに置き換えるのが唯一の方法です…。_STREXBとか_STREXHとか使わないから
コメントアウトするというのは後で困ることになるのでなるべく避けましょう。
__STREXB関数の変更例。__STREXHも同じような感じで変更してください。
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
uint32_t result=0;

__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
return(result);
}




uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
register uint32_t result asm ("r2");
register uint8_t value1 asm ("r0") = value;
register volatile uint8_t* addr1 asm ("r1") = addr;
__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr1), "r" (value1) );
return(result);
}


audin氏のブログのコメントにてiruka氏によりスマートな回避方法が提示されています。
上にあるディスカッションにも記述されていますがインラインアセンブラに早期破壊
オペランドを示す修飾子"&"を付与することによって__STREXB、__STREXHをコンパイル
した時にオペランドが同一レジスタとなりエラーが出るのを回避するとのことです。

CMSIS1.x系はcore_cm*.cに記述されていますが、CMSIS2.0以降はcore_cmInstr.hに記述
されています。変更する内容はどちらも同じです。CMSISの方が修正されるまでこれで
回避しておきましょう。
20120529追:
CMSIS3.0xでは早期破壊オペランドを使用する修正になっています。
おきぱにおいてあるサンプルはすべてCMSIS3.01にしておりますので安心して
お使いください。

これらは液晶表示デモも兼ねています。今回の更新にあたり、多数のSPI液晶を含め
た液晶モジュールのドライバも追加しています。少し前にaitendoさんより販売された
S95591-AAA(コントローラIC:S6D0129)TFT1P2797-E(コントローラIC:ILI9481)のドラ
イバももちろん作り込んでいますので参考にどうぞ。
あと業務連絡ですが、S95591-AAAとTFT1P2797-Eの初期化手順は全く違いますので
勘違いされないようご注意ください。




おまけ
もうキリがないから辞めようと思ったのにまたやってしまった中華液晶モジュール
のコレクションたち…さらに詳しい詳細は私までご連絡を…




176x220サイズのQCIFなSPI専用液晶。コントローラICはHX8340Bなのですが…
なんとHX8340B(N)という細かい型番が存在しているようで初期化手順どころかレク
タングルの指定・GRAMの書き込みコマンドまで全く違う別物でした…以前紹介した
HX8340Bは本当はHX8340B(T)という型番だそうです。
しかもSPIは9bit固定でした!!!!orz
てわけでハードウエアで9bitシリアルがサポートされてるMARY(LPC1114)とかには
いかがでしょうか?ちょっと解像度的にきついと思いますけど…



Mouserで購入できるSDT018ATFTと言う液晶モジュール。コントローラICはILI9163C
だそうですがこいつも外に出てるピンの関係でシリアル接続は9bit固定でしたorz
てわけでハードウエアで9bitシリアルがサポートされてるMA(ry
(8-bit 8080,9-bitSerial接続)



これはセカンドソースがたくさんあり、ebayでも最安5USD前後で購入できるNOKIAの
液晶です。情報元はこちらの方のページです。
コントローラICはSPFD54124Bです…が案の定外に出てるピンの関係でシリアル接続は
9bit固定でしたorzてわけでハードウエアで9bitシリアルがサポ(ry


それとねむいさんのぶろぐ見てる人なら楽勝でしょうが、0.4mmピッチのハンダつけが
出来る人向けです。
(8-bit 8080,9-bitSerial接続)






最後に128x128以上の解像度がなかなか手に入らないアクティブマトリクスOLEDの中で
176x220のQCIFサイズなC0200QILC-Cを


視野角とか素晴らしいのですが、OLEDの弱点である焼きつきが起こるので同じ画像を
ずっと表示することはできず、フォトフレームとかに使うと泣きを見るでしょう。
ここ最近は広い視野角TFT液晶がどんどん出てきているので無理してOLEDを選択する
必要も無くなってきました。

クリスマスの時の頂き物を…。いなちゃんは性的すぎる…♥

STM32F4シリーズを使ってみる4 -STLink/V2をversaloon化-

Versaloon本家がSTM32F4対応したのを受けて今回はSTM32F4 Discoveryに仕込まれている
STLink/V2をSWD接続方式のVersaloon化する方法を紹介します。

もう何度も行っていますが、Discovery系の基板をVersaloon化したことによるメリット
は以下の通りです。
1.書き込み・デバッグにOpenOCD(ただしVersaloon対応にビルドしたものに限る)が
 利用できる。
2.VersaloonのファームウエアにUSB-CDCも仕込まれているのでUARTの通信手段を別途
 用意する必要がない。
3.Versaloonはソフトもハードもファームウェアも無償で利用できるので自分の好き
 なように改造できる。

と言ったところでしょうか。ねむいさん的には"2."が実際のデバッグや情報表示等にか
なり使えると実感しています。



●Versaloon化手順 on STM32F4-Discovery
概念についてはこちらこちらで詳しく紹介しているので基本的な部分ははしょりますが、
Versaloon化するSTLink/V2(STM32F103C8T6)にいつもながらのDFUブートローダを仕込
んでおいてその後にversaloon本体(DFUファイル)を書き込みます。
DFUブートローダのバイナリはUARTブートローダ若しくはSWD経由でフラッシュに書き込み
を行います。各々の方法も基板に下準備が必要です。

1.SWD経由でDFUブートローダを書きこむ場合
 SWDで書きこむ手段として今回はvsprogを使用することにします。
 用意するものはVersaloon化したSTLinkですが素のSTLinkでも書き込むまでの
 下準備は同様です。
 
 まず基板をひっくり返して写真の箇所のジャンパ抵抗をそれぞれ移転させます。

 
 上記写真の要領でSWCLK,SWDIO,GNDをそれぞれ接続してください。

 
 STlink/V2が仕込まれているSTM32F103C8T6にはReadProtectionのヒューズビットが
 掛かっていて、これを解除しないとフラッシュの書き換えができません!これはOpenOCD
 のflash unlockコマンドでも解除できません。
2013年現在ではstm32f2x.cにバグ修正
 が入ったのでOpenOCDからでも解除可能です。
 vsprogを立ち上げSTM32マイコンを認識したら上記画像の要領でヒューズ設定を行って
 ください。エラーが出まくりますが無視してください。この状態でWriteを押すとエラ
 ーが出まくりますが無視して書きに行ってヒューズを消すことができます。

 その後はこちらに用意したSTM32F4Discovery用のDFUブートローダ(の中のmain.hex)を
 フラッシュに書き込み、ベリファイまでエラーが出ずに行えたら書き込み成功です。


2.UARTブートローダ経由でDFUブートローダを書きこむ場合
 この方法は以前細かく説明しているので、ここではSTM32F4-Discovery基板上ではどの線を
 引き出せばよいかという点に絞ってお伝えします。
 DFUブートローダはSTM32D4Discovery用を書き込んでください

 
 実はSTM8S,STM32VLDiscoveryの時と比べてすっごく楽です。UARTブートローダ用の
 線が引き出されていてなおかつ線を引き出しやすいSMDの抵抗がライン上にあります。
 書き込みの手段を持ってない人はUARTブートローダしか方法がないので比較的
 やりやすいと思います。"TO_+3.3V"のジャンパは書き込みが終わったらはずすのを
 忘れないでくださいね。
 UARTブートローダを起動するためのBOOT0につながる抵抗はR7ですが、シルクの位置が
 上にずれてるので間違えないようにご注意ください。

3.Versaloon本体のDFUファイルを書きこむ
 STM32VL-Discoveryの時と同じくSTM32F4-Discovery基板上のResetボタンを押し
 ながらPCとUSBケーブルで接続してください。DFUブートローダが正しく書きこまれてい
 たらPCがDFUを認識します。その後、STM32F4Discovery用VersaloonのDFUファイル
 書きこみます。書き込み方法はこちらを。

 書き込み後はPCとST<32F4-Discoveryの接続を切り離し、Resetボタンを押さずに再
 接続した時にVersaloonとして認識すればVersaloon化の成功です!
 Versaloon本体のLibusbドライバのインストールはZadigで行ってください。
 USB-CDC用ドライバ(COMonVersaloon)は本家のリポジトリを手繰って取得してください。
 これでおしまいっ!

 …と言いたいところですが、Versaloonとして使用する前に下に述べる処理を絶対
 に忘れないでください。

4.後始末
 
 
 SWDでDFUブートローダを書いた場合は最初に移動したジャンパ抵抗とジャンパを元
 の位置に戻します。次にDFU・UARTブートローダ共通ですが、R68を取っ払ってください。
 これはSTLink/V2側からターゲットのSTM32F4マイコン外部クロックを供給するための
 もので、Versaloonではこのピンは使用されていません!このジャンパ抵抗を外して
 8MHzクリスタルが効くようにしてやらないとSTM32F4は16MHzの内部RC発振に強制
 されてしまいます。一見普通に動いてしまいUART等のタイムベースが重要なペリ
 フェラルの動作で異常になってしまうので注意してください!



というわけでSTM32F4-DiscoveryもVersaloonで快適デバッグ/書き込みができるように
なりました♥先に書いた通り私のお目当ては複合デバイスとしてVersaloonと
ともにに仕込まれているUSB-CDCです。ごてごて外付けのデバイスを接続せずに済みま
すのでとってもスマートになります。



おまけ
今のOpenOCDでデバッグした際に浮動小数点レジスタは見えるのか!?

ねむいさんがバリバリ使っているOpenOCD(V0.6.0)+Insight(GDB7.25)でやってみましたが
レジスタ表示をALLにしても浮動小数点レジスタは見えませんでした(; _ ;)
OpenOCD+InsightがCortex-M3というか無印のARMV7M扱いでデバッグしてるせい
(Cortex-M4FのコアはCortex-M3と上位互換してるから整数演算部は普通にデバッグ・
書き込みできる)でしょか???情報待ちですね。


も一つおまけ
ぜんっぜん関係ないですがtaobaoで超掘り出し物の液晶モジュール見っけました!
2.6inch,240x400のWQVGAサイズでタッチパネルつきのTFT-LCDがたったの20元でしかも
新品!もちろんデータシートなんて無かったのですが運よく推定したピン配置がドンピ
シャでバッチリ動いてくれました♥しかも類似品種のピン配置を調べるとSPIも使用可能な
のが分かりコストパフォーマンス最高だと思います。

あーしまったこの角度で撮るとせっかくのゆっこちゃんの肢体がー(棒)

STM32 Value Line Discovery(STM32VLDISCOVERY)をいろいろ使う

CQ出版さんから"世界の定番"との触れ込みで大々的に宣伝されたSTM32ディスカバリ本
が発売されました。これはSTM32F100RBT6が使用されたSTM32ValueLineDiscovery基板
を扱い初心者向けに解説されたものであります。ちなみにSTM32なんちゃらディスカバリ
な基板はVL,L,F4と3種類あって"STM32ディスカバリ"と書かれてしまうとどれを指すのか
非常にややこしいのですがまぁそれは置いておいて…

以前からSTM32VLDiscovery基板については私も秋月さんからひっそりと販売されて
以来ちょこちょこと触れてきましたがこの基板に関する質問のメールをちらほらと頂くように
なったので改めて単独の記事として紹介したいと思います。
ちなみに便乗ではない!!


FatFsとTFT-LCD表示のデモプログラム
私のブログでいうところのいつもののことですが、STM32を扱う中でごく基本的な
要素を抑えてあります。私の他の物と同じくChaN氏のLPC2388向けのFatFsのプログ
ラムをベースにしていますが、移植しやすいように抽象度をかなり上げています。

フリーのコンパイラを使ったコマンドラインビルドに対応
・基板上のLED操作
・基板上のSW入力(外部4+1方向SWはオプションで)
・printf系標準関数がリターゲット可能なUART
(サイズ節約のためChaN氏のxprintfを割り振ってます)
・sprintf/malloc系標準関数のサポート
・systickとタイマを利用したAVR-Libcと同じ感覚で使えるDelay関数
・STM32間のポートの移植性を容易にしたFatFsのデバイス依存部
・容易に移植が可能なTFTLCD/OLED表示用ライブラリ
 SPI-LCDを使った時のブロック転送はDMA化可能。

ほかのマイコンからSTM32というかARMマイコンを始めた人が真っ先に引っかかるのは
sprintf/printf系標準関数がうまく動作しない点だとおもいます。今となってはFAQレ
ベルの事なのでここを熟読したり私のUARTへリターゲットしてる部分のコードを読んで
うまいこと動作させられるようにしてください。

上記のプログラムについては各ペリフェラルに対しポートの割り振りは以下のように
しています。特筆すべき点は、後述するSWD接続のVersaloonを使いデバッグすることに
限定してSWDでは使用しないJTAGポートの一部をSDカードアクセス用に割り振り、使用
可能なI/Oをさらに確保したところでしょうか。

※1:STM32VL-Discoveryデータシートより引用・加筆。
※2:単にポート振っただけでSW入力や8bitLCD等実際に使用してない個所があります。


定番のSPI接続のTFT-LCD(128x160)を動かしてみたところ。
ChaN氏のTJPegDecでjpeg画像を表示している最中です。

次回紹介予定の2.5元のi2c液晶モジュールも。素晴らしい掘り出し物です!



●STM32VL Discoveryに仕込まれてるSTLinkをVersaloon化
最早これも定番でしょう。STマイクロの**ディスカバリー系な基板にSTLinkとして仕込まれ
ているSTM32F103C8T6は各基板ごとに微妙にポートの配置が異なっていて同じVersaloon
のバイナリは使いまわしはできませんが、すでにVersaloon本家ではSTM32VLDiscovery
向けのファームウエアがサポートされています。

さて、肝心のVersaloon化の方法ですが本家ではDFU等のブートローダを仕込まずに直接
Versaloonのバイナリを書きこむようになっていますが、私はアップデートを容易にする
ためにいつも通りのDFUを仕込むようにしました。以下に私が行った手順を示します。
DFU仕込まない場合は"1."の書き込み時にいきなり本家の方のSTM32VLDiscovery用の
バイナリを書きこんでください(この場合別途ビルドする必要あり)。

1.DFUを仕込む
 こちらにSTM32VLDiscovery用DFUブートローダのバイナリを用意しました。
 (Versaloon_DFU_Bootloader_for_STM32VLDiscovery_.zip) 最初に書いてください。
 書きこむ方法はSTLink等のフラッシュを書きこむ手段が別に用意されてる場合はそちら
 を使ってください。Jim氏のTakenApartの記事にSTLinkをつかった手順が示されていま
 すのでそちらの記事をもとにDFUブートローダを書きこんでください。

 また、STM32はこの基板が初めてでフラッシュを書きこむ手段を他に持ってない人は,
 UARTブートローダーを使う方法を、こちらの改造手順2〜8を参照して書きこんでください。
 UARTブートローダを有効にするためのジャンパの引きまわしはSTM32VLDiscovery基板
 上では以下の写真の通りとなります。
 
 この基板上では足あげ等の加工も水晶の付け替えも必要なく0.5mmピッチの足からリ
 ードを引き出すだけなのでまぁ楽勝ですね。DFUを書き込んだ後はもちろんジャンパを
 はずすのを忘れないでください!

2.DFUを起動
 さて、DFUを書きこんだらPCに接続するわけですがSTM32VLDiscovery基板上では下
 画像のリセットボタンがDFUの起動キーとなります。リセットボタンを押しながらUSBケー
 ブルでPCと接続してください。
 
 USBデバイスとしてDFUが認識されたら成功です。
 
 そうだね画像使いまわしだね。言い忘れてましたがDFUseをインストールした時に
 DFUドライバがインストールされますので忘れずにインストールしておいてください。

3.Versaloonを書き込み/起動
 STM32VLDsicovery用のVersaloonのDFUファイルはこちらに。書き込み方はここの"14."を参
 照にしてください。向こうにあるDFUファイルは別物だから使っちゃだめです!
 書き終わったら基板を一度PCと切り離し、再度接続します。この時にVesaloonとして
 認識されたら成功です。VersaloonはLibUSBが使用されていますが、LibUSBのド
 ライバはZadigでインストールした方が確実です。
20120105追:
 以前はSWDのジャンパはあべこべになっていましたが、現在では
 差し替え無しでそのまま使用できます。



4.Versaloon化したSTM32VLDiscovery基板上でターゲットのSTM32F100RBT6をデバッグ
 冒頭で述べたプログラムをビルド・書きこみを行うわけですが、用意するものは
 STM32マイコンをビルドする環境のほかにVersaloonに対応した特別なOpenOCDが必要
 です。おもな手順はこちらこちらですでに紹介しています。

てわけで丸投げしまくりのやっけつ手順になってしまいましたが簡単に改造可能なの
で(自己責任の上で)お勧めします。しかも今のVersaloonはUSB-CDCが同時に使用でき
る複合デバイス構成になっているため、これを利用してこの基板上でUARTの通信手段を
完結させることができます♥

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

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できません!!大事なことだから2度言います!!

この構想をリンカスクリプトに落とすと下図のような感じです。

この下にも長−く各セクションの定義が続きますが省略。
この構成で前回の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を生成するとこの記述が欠け
ているのでほとんどの場合は自分で追加しないといけません。




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も組み込ませてもらってます。

STM32F4はぢめました


…きちゃった♥


…STM32F2すら使いこなせてないうちにCortex-M4コアのSTM32F4が来てしまいました。
CPUクロックが168MHzにアップした上にFPU&DSPユニットが付きさらにメモリも192kByte
までお付けしてお値段据え置き(購入当時日本円換算で1280円)ですって奥さん!!



チップ単体はまだ手に入らないので(これも時間の問題ですね)すが、評価キットとして
STからSTM32F4Discoveryがすでに販売されています。この評価キットはI2Sコーデックに
MEMSセンサもついていてアナログ信号の処理も手軽に扱えそうです。ていうかそういう
風に使わざるを得ないでしょうね…苦手ですが。

20111201追:
秋月さんからも1650円で販売されました!



てわけでさっそく動かしてみました。すでにSTM32F4Discoveryのファームウエアパッケ
ージで予習済みなのでいつものTFT液晶に何か表示するプログラムをビルドし書き込ん
でみます。


CodesourceryはすでにCortex-M4Fに対応しています。ビルドオプションとしては
少しの変更でビルド可能です。
(注:上記のオプションではまだ不完全で、FPUを使った演算になりません!
  FPUを有効にする方法はこちらを)



STM32F2系(Cortex-M3)とアッパーコンパチであるため、OpenOCDはそのまま読み書き
とデバッグ(FPUレジスタ除く)を行うことが可能です!ねむいさんはビルドしたプロ
グラムの書き込みにVersaloonのSWDを使用しました。
(注:エラッタのせいでSTM32F2系とまったく同様のMCUIDとなっているようです。
   VersaloonはコアIDのほうは判別は行っていないようなので引っかかりませんでしたが
   FT2232系のJTAGアクセスではコアIDの判別に引っかかり、STM32F2系のcfgファ
   イルのまんまだと警告を出しますが、先に述べたとおりアッパーコンパチのため、
   とくに実害はありません。私が公開しているOpenOCD用のCFGファイル群はすでに
   STM32F4対応済です。)



びぃぶろくんが、かわかわ美人さんに欲情すると困るので小さく
20120124追:
Gaijinさんがinai-sanはHENTAIだって


とりあえず今回はほんのさわりだけですが、次回はせっかく192kByteに増強してもアド
レスが連続してるのは128kByte分でそのうちの16kByteはEthernet&USBOTG-HSの
DMA専用に事実上取られてしまうので実質112kByteで残りの64kByteはバスマトリクス
上にないから微妙に使いどころがないという内蔵RAMの効率的な使い方とかをリンカ
スクリプトの組み方と交えて実践していこうと思います!

STM32 EvoPrimerを買った...

世間ではSTM32F4シリーズが発表、音系に特化したSTM32F4Discoveryなんかも
もうすぐ手に入るようになった昨今ですが、8月末に秋月で纏め買いしてるついでに購入
してしまいました・・・。こんなの買ってしまった時点で「私は情(に)弱(い)です」って言って
る様なもんですね・・・orz
・・・まぁいいや。

un
↑STM32Primer1,2の後継となるEvoPrimerです。

un
↑今回のはCPUカードを差し替えることによりSTM32F103系、STM32F107系、STM8S系の
 評価を行うことが出来ます。逆に言うとEvoPrimer本体だけ買っても何も出来ません!

un
↑ねむいさんはSTM32F103VET6が載ったPrimer2を持ってるのでSTM32F107系
 CPUカードを選択しました。

un
↑カードを挿して(めっちゃ硬い)真ん中のボタンを押すと"Welcome to STM32!"のボイス
 とともに初期設定画面がでます。ちなみに初回購入時はEvoPrimer本体からCPUカー
 ドからスタンバイ電源を供給するためのスイッチをONにしておかないと起動の度に
 初期設定をする羽目になるので注意です。

un
un
un
↑早速中身を開いてみました。
 QVGAの液晶やI2S等のデバイス盛りだくさんです。ちなみにこのQVGA液晶はピンの設
 定で8bit,16bit,SPI(←これ重要)が使用可能な逸品です!

 液晶モジュールのデータシートを穴のあくほどよく見ましたがこのモジュールは
 SPIの設定はできるもののSDI/SDOのピンが出ておらず実質8/16bitしか使用
 できません。しかもEvoprimerとしては8bitバスしかサポートしてません。
 さらに言うとCタイプだと素直なピン配置になっておらず、わざわざビットシフト
 してから書かなければならない回路構成になってやがるので描画がSPI並みに
 くそ遅いですorzorz

20130107衝撃の事実判明!!!
ちゃんと調査したところコントローラICはちゃんとILI9325でしたが、なんとFPC
内部でSDOがD0に、SDIがD1に直結されていてSPIでもデータの読み書きが
可能なことを確認しました!!!!


un
↑STM32Primer2で致命的となってしまった電源回路ですが、回路図を見渡す限りでは
 対策がされている様なので今回は大丈夫だと思いますよ。た ぶ ん
un
↑STM32Primer2と並んで動かしたところ。一回りおっきくなってて持ち運びができません…。


その他EvoPrimerと同じく買ってしまったもののまったく触っていない物達・・・
un
↑LPC1227LPCXPresso(上)とLPC11U14LPCXPresso(下)ですって奥さん!

 11U14の方って反対側にUSBminiBコネクタついてるわりには3.3Vのレギュレータ無い
 からうかつに切り離せられないじゃないですかーやだー!
 あとXmegaでよく分かられたとは思いますがねむいさんはLPC系のARMマイコンで
 DMAを使いこなす知能がないのでLPC1227の方はあつ氏やtodotani氏の作例を
 参考に弄ってみようと思います。

 ちなみに上記二つのデバイスはSWD接続しかなく、まだVersaloonが対応してないので
 手も足も出ません!・・・といいたいところですが・・・(下記に続く)


un
↑お次は台湾NuVoton製のcortex-M0マイコン、NUC120さんだ!
 基本的なドキュメントやサンプルコードは出揃ってるのでこちらも時間を見て・・・
 もちろんまったく触ってま(ry

 ちなみに書き込みはNulinkと呼ばれるSWD接続可能なライタです。KeilやIAR等の開発
 環境からしか使えないと思いきやCooCoxCoFlashというフラッシュ書き込み専用ツ
 ールを使うとスタンドアロンで書き込みできたりします♥

un
↑このCoFlashというツールですがハードウエアが上記のNulinkに加え、JTAGkey,JTAGkey2
 やST-Link等の有名どころにも対応してるので書き込み専用としてもかなり使える
 と思います!


un
これも脊髄反射で購入してしまった・・・
 ほんっとマイコンしか触ってない私ですがFPGA忘れてしまわないうちに何とかした
 いですはい・・・



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

4月から本当に少しずつ使い始めたSTM32F207ですが、公式の方もやっとこ資料が出そ
ろってきてだいぶ扱い方が理解できるようになってきました。

とりあえず一つの通過点ということでいつものchan氏のLPC2388向けのFatFs+OLED表
示プログラムの移植をしました(ほとんど原形とどめてませんが…)。いろいろやってきた
中でjpegデコーダ乗せたり(デコードが1.8倍速くなってる!)FONTX2の使い方覚えたりで
今回はM+フォント(FONTX2)を使いFilerの日本語表示を可能にしてみました。
un
↑やっとここまでこれた…
なんと当のchan氏も6/11更新のLPC2368向けFatFsサンプルでFilerの日本語化をされていた
ようで今度はこちらを元にしておりぢなるなFilerの構想を練っていきたいと思います。

そうそう、気になるFatFsの読み取り速度ですが、SDIOが出せる最高速度の48MHzまで
クロックを引き上げた場合、最大21MB/Secを叩き出すことができました!
un
↑てかいつも比較に使ってるATP製のmicroSDカードもすごい…class6なのに。
しかし、48MHz動作は8bitモードしか保証していない(rm0033.pdfより)のでsdカードで
使うときは実際は24MHzで動かすことになるのですが…それでも十分早いですね。



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

また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を開発した時の生基板を利用して無理やり乗っけてみました!
un
次はこれで行こう。

そしてaitendoさんからはもう一つQCIFサイズのタッチパッドつきの液晶が発売されま
した。これ確かtaobaoで捨て値で売られてて私も10枚くらいまとめて買って動かして
(飽きて放置)してました。これ8/16bit選択できるのは良いのですが、ピン間隔が0.7mm
なので手配線ではきつい人がいるかもしれないですね。専用の変換ボード出るの待った
方が良いと思います。どちらかというとこっちとかこっちとかこっちの方がピン間広
いし8bit固定で小難しいこと考えなくて良くてよいと思います。思いますよぅ!!(重文)
un
↑AS021350DをXMEGAで動かしてみたところ。
実はATXMEGA128A1にもchanさんのFilerを日本語対応して移植に成功してます。
しかしXMEGAはFatFsを結局DMA化できないまま白旗降ってクローズします…。

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

てなわけで前回の記事からはや一ヶ月、手探り状態でいろいろ進めているうちにST公
式でやっとこF-2デバイス用のペリフェラルライブラリが出たりBeagleBoard-xMの購入
合戦に勝利したもののまったく火入れしてなかったりDE0-Nanoを購(ryたり今後を見越
してステーション型半田こてPicoScope 3206A購入したり東海自然歩道のサブルート
探訪も笠置まで進んでたり
そうこうしてるうちにSTM32F2シリーズも普通に購入でき
ようになってたりする昨今、いかがお過ごしでしょうか?
震災を境に身の回りの状況が一変してしまいましたが、ねむいさんはいないさんをひ
ざに乗せてくんかくんかしつつできることから着々と取り組んでいく所存でございます。





勘違いや無知無学が祟って時間を食ってしまいましたが、STM32F207VGT6でSDIOと
Chan氏謹製のFatFsを連結させて安定動作できるまでになりました。SDIOはもちろん
DMAを使って高速に転送可能です♥以前のSTM32F103VET6のものと同じ条件でRead
の速度を比べると若干の向上が得られました!
un
un
SDカードだとSDIOは25MHzまでしか出なかったり(MAX48MHz)カード自身の転送速度
もボトルネックになってるとは思いますが、小規模のマイコンでもこんだけ早かったら御
の字ですよね〜。


さらに前回ちょろっと紹介しましたが480x272pixelの4.3inchTFT-LCDのドライバも組
み込んで"いつもの"をやってみました。こちらもFSMC使った高速転送です!
ねむいさんへたれだからSSD1963っていうコントローラつきの液晶モジュール基板使っ
てますが・・・。

un
↑タッチパネル入力にももちろん対応。
un
↑再びぽぽぽーん
STM32F2になってフラッシュも1MByteまで増えたことだし、フォントも扱えるように
なって機は熟したからそろそろ私もChan氏のファイラーは卒業しておりぢなるなファ
イラーを作ろうかな、と。



んでもってSDIOとFSMCの高速な転送を利用して動画再生も試みました。Chan氏のLPC2388
向けの動作再生ルーチンをチューンアップしないでまんま利用してもQVGAサイズで29.97fps
な動画も余裕で再生できたので相当"ぱわふりゃーなので余裕"なの確認できました。やっけ
つだけど一番乗りだからどっかにアップしたいな〜
・・・と思ってるてるうちにどこかの誰かが私と同じようにSTM32F2シリーズのMCUを使った
らしい作例で先を越されてしまいました・・・。扱ってる動画の内容とかアップロード先が虹裏
メイド的に一発アウト
なヤバい代物なのは置いといて動画が暗くて荒くて何をしたいのか
分からないとかもういい加減にしろって感じだよ(棒読みで)




とりあえず次の一手としてはオリジナルなファイラーの実装に着手しつつ先日がた老氏
FreeRTOSがらみの質問をもらった機会にご無沙汰だったRTOSのおべんきょもふたたび
進めていくつもりです(BeagleBoard-xMとDE0-Nanoから目を逸らしながら)。





おまけ:
て言うかこっからが本題です!!!!
LatticeのispVMがいつの間にかFT2232デバイスに対応していた件

いままでsvfとかUrJTAGとか使って手間のかかる方法しかできなかったのが嘘のよう
です!もうこれでLPTポート無くてもいいです!

un
un
↑ふつーに認識
un
↑そしてふつーに書き込み
JTAGkey2Cloneで使うためにはJTAGのOEを常時イネーブルにしておく必要があります。
※ispVMに対応するようにスルーモードをつけて回路図差し替えときます。

un
un
もちろん外付けSPI-ROMにも書き込むことができます♥ispVMは多種のSPI-ROMに
対応しているわけですが・・・つまりこれはLatticeのデバイスがJTAGで繋がってれば
USB接続のSPI-ROMライタが安価にかつ確実に構築できるというものすごいことで
まさに神対応なわけなのです!!これでマザボのBIOSいくらすっ飛ばして怖くない!
xilinxさんやalteraさんもこういうの見習ったらイイナー・・・絶対ありえないですが…


STM32F207はぢめました

un
ツイニキタヨー
去年くらいに発表されて以来トンと音沙汰なかったですけどES品ですがやっっと一般
ユーザの手にもわたり始めましたSTM32 F-2シリーズ。
従来のSTM32と違う部分は最大動作周波数が120MHzまで増加したのとメモリ保護ユ
ニットがついたのとフラッシュアクセラレータが(やっと)強化されて120MHzまでノーウエ
イトで動作可能となったのとその他諸々のペリフェラル機能が追加された点しょうか。
ライバルに相当するLPC1769も似たような機能をすでに備えているのでいまさら目新し
ものではなくなってしまいましたがー…。あ、そうそうフラッシュ容量も1MBまで増加
してます。低速な外付けのメモリとか用意しないでも結構でかいサイズのフォントもぶ
ち込めるのがうれしいです。

てわけでさっそく使用してみましたが、STM32F107VCT6とは一部ピンの定義が違います。
そこだけ注意してデータシートのmigration guideを参考に配線を変更しました。
un
使用したボードは元はSTM32F103VET6が乗っかっていたebayで格安で購入した基板です。
STM32F207からはFSMCが使えるので(←これ重要!)あえてこのボードを選びました。

次に開発環境ですが、もちろん従来から使ってきたCodesourceryG++を使用します。
しかしまだSTマイクロの公式サイトではF-2デバイス用のペリフェラルライブラリなんぞは
用意されていない(10x系とはレジスタ定義は全く違う)のでKEILのサンプルに含まれてい
るF-2用のbeta版に当たるV0.01と記された定義ファイルのみと上記のごく簡単なサンプル
コードを頼りに手探りで進めていきました。

ちなみにフラッシュの書き込みもF-2デバイスは手順が違うようでOpenOCDではSTM32F1xx
系とは別に用意されていました。後述しますがOpenOCDはSTM32F103xF/G系の512kByte
以上のフラッシュを持つ種への書き込みも対応しています…これはありがたい。
un
書き込み時はこんな感じです。

un
ぽぽぽぽーんと動かしてみたところです。480x272も一瞬だわ…流石120MHzとFSMC…。
そして国内のホビーユーザーでF-2のデバイス動かした人間としては今度こそねむい
さんが初めての人ですね!一番乗り!
次はSDIOに進みたいところですが、上で述べたとおりライブラリが無い状態なので手
探りで進むことになりそうです。まぁ10x系のものを参考にしたら何とかなるでしょう。
実はここまで動かすレベルになるのにかなり手間かかった…何せ資料が全くない…。


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

un
お約束カワウソ。

SWD専用Versaloonクックブック

20120210追:
OpenOCDが0.6.0の2月以降のコミットでSTlink&STLink/v2の素のハードウエアに
対応しました!!もはやVersaloon化すら必要ありません!!



20110829追:
Versaloon本家の対応により、STM8S/STM32Discoveryに組み込まれたSTLink
のハードウエアにもめでたく対応となりました!!以下に長々と書いているかなり
無理やりなハードウエアの改造は、現在行わなくても済むようになっています!
それでもねむいさん(の方法)がだいすきなんだーい!って言う人だけ読んでください!





デバッガを備えた扱いやすい32ビットのプロトタイプボードたちが群雄割拠する現在、彗星の
ごとく電子工作シーンに現れそのまま大気圏に突入して消滅したSTM8S-Discovery
には32bitMCUを使用した2線式デバッガハードウエアSTLinkが搭載されています。

このSTLinkの本体はSTM32F103C8T6というSTM32のARMマイコンで、これはVersaloon
というリソースが公開された汎用のデバッガハードウエアにも使用されているものです。
今回は、そのままでは糞の役にも立たないSTM8S-DiscoveryのSTLink部分に物理的改造
を施し、SWD接続専用の簡易Versaloonとして再生する手順を紹介します。

注:制限事項
 ・この改造はVersaloon-miniのハードウエア互換にする改造です。
 ・VersaloonはARMの他に多数のマイコンをサポートしているが
  この改造はARMの、それもCortex-Mx専用になります!
 ・てわけでSWD接続以外の接続はできない(ていうかできねぇ!)
 ・頑張ってTDIとかTDOとか引き出せばJTAG接続も使えるけどめんどいからやらないよ!
 ・3.3V以外の信号レベルでは接続できない(一応5Vトレラント)
 ・作業工程はWindowsXP以降の環境を使用。Windows7x64環境で動作確認しました!
 ・真似して改造して基板がゴミになっても泣かない
 ・ていうかJTAGKey/JTAGKey2Cloneをすでに持ってる方の補助的な位置づけです
 ・ハードの改造がめどいですという方はiruka氏のオレオレblaster化をお勧めします。
 ・SWD専用ですが、本家の対応でめでたくSTM8S/STM32DiscoveryのSTLink
  のハードウエアにも対応となりました!!↓に長々と書いているハードの改造を
  無理にしなくても済むようになっています!大事なことなので2度言います!



●必要なもの
 1.STM8S-Discovery
  これが無いと話になりませんね。750円でSTM32単体買うより安いです。
  必要部品はすでに乗っていて一から回路起こすより断然楽です!

 2.12MHzのクリスタル
  Versaloonの標準的なハードウエアは12MHzの外部クロックを必要としています。
  STM32の103系って標準が8MHzなはずだが…
  ソフトが苦手なねむいさんとしてはハードウエアの方をカチ合わせる方
  針で改造を進めます!いちいち修正してビルドするのめんどいし!

 3.チップ抵抗
  1608~2012メトリックの100ohmを2つ・10kohmを3つ。これはポート保護&フローティ
  ング時の信号レベル固定用です。

 4.1列ピンヘッダ
  SWDやUARTの信号を外部に引き出す用途に使用します。

 5.0.26mm位のUEW・AWG26位のジャンパ線
  UEWは48PinTQFPから足を引き出したりジャンパしたりに使用します。
  ジャンパ線は3.3Vの電源ラインをバイパスするのに使用します。

 6.USB-シリアル変換若しくはパソコンとUARTで通信できる何らかの装備
  改造工程でUARTによるブートローダを立ち上げてDFUを書き込む必要があります。
  もちろん信号レベルはTTLレベルに各自で合わせておいてください。
  (JTAGでも書き換えられますがここでは触れません)

  また、DFUを書き込むためにPC側のプログラムはFlashLoaderDemonstratorを使用
  しますので各自インストールしておいてください。
  DFUを書き込んだ後はDfuSeを使いVersaloon本体を書き込みます。同じくインストールして
  おいてください。

 7.2.54mmピッチのショートピン
  パソコンでも使用する標準的なショートピンを。STM8S基板にひっついている奴を
  流用しましょう。

 8.TQFP(0.5mmピッチ)の足を上げたり一本ずつはんだつけしたりが余裕で出来る技能
  まぁこのブログを普段から見られている方はデフォで出来るでしょうからからあ
  えて言わずもがなですね…(カメラ目線)



●改造手順
 ※一気に改造するとなにが悪かったのか切り分けできなくなるので
  逐次動作確認を行い、改造していきます。

 1.先ずSTM8S-Discoveryのミシン目をカットしSTLinkと燃えないゴミにわけます。
  un


 2.次にUART用のPinをUEW線にハンダ付けで繋げ、外部に引き出せられるようにします。
  un


 3."2."で引き出したUARTのピンはピンヘッダを使って外部に出しましょう。UART-TX(TxD)は
  10kohmで必ずプルアップしてください。
  un

 4.丸内の部分をジャンパします。ここから+3.3Vを外部に出したいなんて人は
  AWG24位の太い線でジャンパしましょう
  un

 5.次に丸内のBOOT0のPinに当たる部分を丸内の+3.3Vラインに
  ジャンパで飛ばします。
  un

 6.USB-シリアル変換と"3."で付けたピンをTxDとRxDを間違えないようにして接続します。
  そしてSTLink側のUSBコネクタをPCに挿しこみます。USBデバイスが認識されないエラ
 ーがでますが無視で。

 7.FlashLoaderDemonstratorを起動します。STM32のUARTブートローダーが正しく起動し
  ていればこの画面が見えるはずです。操作法などの細かい説明はこちらにうっち
  ゃりますが、先ずここでDFUのプログラム(Versaloon_DFU_Bootloader.zip)を書き込みます。
  STLinkのファームウエアははこの時点で消去されてしまいます。
  un
  un
  un

 8.元STLinkをPCから外し、"5."で行ったジャンパはもう必要ないので外します。
  てか外さないと何やってもSTM32のUARTブートローダーが立ちあがっています。
  un

 9.次に書きこんだDFUの起動確認を行います。クリスタルを8MHzのものから12MHzの
  ものに差し替えます。丸内の箇所にショートピンを挿し替えます。
  un

 10.再び元STLinkとPCをUSBケーブルで接続します。USBデバイスとしてDFUが認識
  されたらOKです。まだVersaloon本体は書きません!
  un

 11.DFUが起動するのを確認したら一旦PCから抜きます。Versaloon本体を書く前に、SWD
  を外部に引き出すための改造をします。四角内の部分の足を丁寧に上げます。
  un

 12.足を持ち上げたらまとめてUEW線をハンダ付けして引き出します。
  un

 13.ターゲットにSWD接続を行うためのピンを引き出します。JTAG用のポートが余っ
  ているのでこれを利用しましょう。
  VersaloonはPB6,PB7をSWDIO用,PB13をSWCLK用のポートとして使用します。
  図中の表記はこれに倣っていますので間違えないようにしてください。

  un
  un
  un

 14.SWDに使うポートを引き出す改造が終わったら"10.の操作を再び行いDFUを認識させます。
  そして"DfuSe Demonstrationを立ち上げ、Versaloon本体のDFUファイルを書
  き込みます。
  un


 15.書き終わったらUSBケーブルを外し、"14."で行ったショートピンを丸内の位置にします。
(以後Versaloonのプログラム本体の書き換えはDFU経由で行います。)
  un

 16.再度元STLinkとPCをUSBケーブルで接続します。USBデバイスとして、今度は
  Versaloonが認識されたらOKです。LibUSBのドライバを読み込ませてください。
  非常に操作が簡単なzadigを使ってLibUSBのドライバをインストールしてください。
  un
  

 17.vsprog等を使用しSWDで繋がるCortex-Mx系のマイコン(LPC1xxx,STM32,ATSAM3x,etc)
  でVersaloonが使用できるか確認します。
  結線さえあっていればこの時点でSWD接続で操作できます。
  JTAGのTMS = SWDのSWDIO
  JTAGのTCK = SWDのSWCLK
  un
  Simonquian氏のページで配布しているvsprog/vsgui等のソースをビルドして利用するか
  SWDのパッチを当てたOpenOCDをビルドし使用しましょう。
  おや…これは…



…というわけで余り物の材料かき集めたら1000円以内でCortex-Mx系のライタ/デバッガ
が手に入ってしまいます。STM8S-Discoveryを買ってしまった人は玉砕覚悟でVersaloonへの
改造を試してみてはいかがでしょうか?

いないさんのおしりに顔をうずめてくんかくんかしたい

※今日の日記は7月上旬くらいまでの内容です

(いないさんの)ぱんつだけカフェ…ぱんつだけカフェ…ぐふふ…
……おお失礼、ここ最近会社近くのカプセルホテルで寝泊まりするような生活になって
から意識が夢うつつな状況が多くなって…(注:6月末〜7月上旬の頃の話です(重文))


最初はTFT液晶モジュール使ってなんか作るのが目的のはずでしたが今やいろんな種類
のモジュールを手にいれて動かすこと''だけ''が目的になってしまっています…。
でも8~16bitバスorSPI制御タイプのモジュールはあらかたやりつくしたのでそろそろ次
の段階に進もう か な と思っています(←同じこと言ってばっかですがー)


さて今回も、前回taobaoやaitendoで購入した液晶モジュールの火入れをやってきたい
と思います。まずは国内でも売られているのでご存知の方も多いでしょうけど3.5inch,
QVGAな少し大きめのモジュールを…。


un
コントローラICはSSD2119。8,16bitバス&SPI&(改造でRGB)も制御に使用できます。

un
いつものごとくSTM32で…powerMCU製のTFT液晶モジュール基板はコネクタに出ている足
配置が2.8,3.2,3.5"とすべて共通で、後はプログラムをこさえるだけなので楽です。
…と思いきや3.5"のモジュールだけタッチパネルのPENIRQポート番号が違ってました!!
いやぁ慣れって怖いですねぇ…(しれっと)

un
てわけでタッチパネル制御も…コンパイルオプションでタテヨコ対応です。STM32ライ
ブラリのバージョンも上がったことだしそろそろSTM32/LPC2388用の液晶モジュール
制御プログラムも更新しましょうかね。

液晶モジュール&SSD2119のデータシートを眺めているとこのモデルは上記CPUバス・SPI
バスインターフェースの他にもSH2Aで使えるRGBインターフェースも使用できるようです。
ただし基板には足が出ていないので自分で残りの足が出るように改造する必要があり
ますね。まぁこちらは追々と…。



un
次に3.0inchでWQVGA(240x400)の縦長なLCDモジュールです。これはモジュールのデー
タシートを貰うことができませんでしたが、ネット上には同じ型種のモデルが存在し
ピン配置も容易に推測できます。IM0,IM1が外部に引き出されており、8bit,16bit,
18bitCPUバスで制御可能です。コントローラはR61509Vだそうです。得体が知れないの
でタッチパネルが無い安い方を購入しましたが案の定バリバリのユーズド品でした…。

16:9のWQVGAな画面を利用して某シングルCDのジャケットを…ドンピシャの画像…

un
今の若い子って(まぁ私もわかいですけお)シングルCDとか知ってるのかしら…あ、
…失礼、さぁ次、次…(使ってるうちに反射板が剥がれました。なんじゃこりゃorz)



最後にaitendoさんで20%引きセールやってた頃に購入した0.94inch,96x64ピクセルの
OLEDモジュールALO-095BWNN-J9を。こちらはキャリーボードとセットも販売されて
いて、なぜかセットで購入した方がOLEDモジュール単体で買うより非常に格安でお得と
なっています(2010/07/05現在)
…???何で??値段設定間違えてる??それともセットのはなんかの不具合品??

まぁいいや、STM32でとにかく動かしてみました。現在Lynx-EyED氏も活用されていますね。
このモジュールは8bitCPUバスでも行けますがピクセル数が少ないのでSPIの方が
繋げる線も少なく楽でしょう。

un
un
ちっさ!めっちゃちっさ!…いつも3.2inchとか弄ってるのでやたら小さいです。

それとLynx-EyED氏も経験されてしまってるようですが、私もOLEDは焼きつくという事実を
すっかり忘れてしまっていて、冒頭のいないさんの臀部の絵を表示したままうっかり
放置して焼きつかせてしまいました!!!みんなも気をつけよう!



…とまあ液晶モジュールはこのくらいにして次回は塩漬けにしていた各種評価ボードを
消化していこうと思います。


まずはCortex-M0なLPC1114のボード…

つずく

ペプシバオバブ

20101228追:
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め!!11!



※内容的には4月下旬の頃ものです。古いです。

un
ぉ…結構いけるじゃん!
何時も二度と飲みたくないような味だったのにこれはイケるんじゃないでしょうか!?
コンビニにも今も置いてます♥


とりあえず生存確認の為に月一くらいは更新したかった今日この頃(駄目だったけど)。
春先にtaobao経由で安価な電子デバイスをたんまり購入しました。主な目的はaitendo
でも未だ手に入らない3.2inchの液晶モジュールだったわけですが壊したれたのと
全く同一の物が運よく見つかったおかげで復活しました。


un
●牙復ッ活ッ!刃●復ッ活ッ
考えて数揃えて買うと輸送量+手数料合わせても国内で少量買うより滅茶苦茶安く
つきますね…感動的だな。

ついでに目を引いた幾つかの液晶モジュール(そうだよまただよ)も買ったのですが、
これには罠が待ち受けていました…。


un
先ずはこれ。上で述べたものとは別の種類のさらに安価な3.2inchのTP付きな液晶モジ
ュールで、交渉のさいにモジュールコントローラICをILI9320と指定して購入しました。
しかし…実際に届いたブツはILI9320用の初期化コードではどうしても動かず、コントローラ
のIDを読みだしたりして(JTAGkey2+OpenOCD+insightのデバッグがすごく役に立った)
調べた結果、R61505UというILI9320と一部動作互換のICであることが分かり、モロに
足止めを食らってしまいました…。
一瞬フェイクつかまされたかとビビってしまいましたが、初期化手順を正しく行うとしっ
かり動いてくれて使えることがわかったので…まぁいい経験になりました。
20100817追:
3.0インチ以上は16bitバス制御しかできないモジュールが多いのですが、なんとこいつには
バス幅を切り換える抵抗が存在していました!!一気に使える液晶モジュールに!!
ちなみにaitendoの3.2inchQVGAの奴は出来ないです

un
いつもの。
un
んでもってタッチパネル(触摸屏)付きなのでBlueScreenの凡例をお手本にさせてもらっ
てタッチスクリーンセンサADS7843を使用したタッチパネル入力化にもやっとこ対応。


un
次にこちら。QVGAなLCDモジュールで国内でも手に入りやすく扱いやすいものは8/16bitの
CPUバスな物しか選択肢が有りません。こちらはそれに加え、なんとSPI/RGBインターフ
ェースによる制御も可能な一品です!いろいろできそうだと勇んで6個くらい購入してし
まいました!しかし…
実際に使用してみてわかったのですが、動作が安定しません…具体的にどういうことか
というと電源投入して約5秒以内に初期化動作に入らないとコントローラIC(LGDP4531)がや
たらと過熱しだして暴走状態になり、何やっても画面が真っ白のままとなってしまいます。
そしてその状態に一度はいるとモジュール内の残存電圧が抜けきるまで電源落としてほ
っとかないと電源再投入後また即暴走の憂き目に…。

私にも落ち度があるのかと↓の項目いろいろ試してみましたが改善しませんでした…。
未使用ピンを全部GND直結->×
未使用ピンを全部VCC直結->×
スタンバイモードになってなくてもとりあえず強制解除操作->×
RESET端子にRESETICを付けてPOR出来るようにしてオープンドレインで制御->x
マイコンのVCCを3.3Vから2.8Vに落とす->×
MicroChipが配布しているグラフィックライブラリのLGDP4531用初期化コード->x(オイ)

同モジュールが乗った出来合いの基板も購入したのですが結果は同じでした。つまり
モジュールそのものに問題があるっぽいです…。(初期化手順が不完全なだけか
もしれませんが、これ以上は情報が少なくて手出しができません)このモジュールを使用して
いる他の方も(Unstable)とされてますから同じ問題に直面されているようですね…。

まぁ一応電源投入してすぐに初期化動作を行うということを守れば言うこと聞いてくれる
ので、自分の中でだけテストするのであれば問題ないのですが…現時点ではこれ使って
売り物製作るのは無理っぽorz 以下にいくつかのモードで動かした画面をば…。

un
↑STM32F107VCT6でソフトウエアSPIモード
READして帰ってくるデータのバイトオーダーがデータシートの記述と違うんだが
…おいおい

un
↑STM32F107VCT6で16-bit,i8080cpuバスモード。出来合いボードの方。
ゆっこちゃんかわかわ

un
↑LPC2388で8-bit,i8080cpuバスモード,伝説のデス○リOP動画再生。
LGDP4531はさきに紹介したR61505Uと同じくILI932xと一部動作互換です。
動作不安定なトコ以外は。なんとかならないだろうか…。


つづく

またTFT液晶モジュールかよ

20101228追:
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め!!11!


un

え?この前買った3.2"の中華製TFT液晶どうしたって?…どうしたもこうしたも…
物理的につぶしt"ワタシ大陸に帰るアル"って言って去っていきましたよぅ…
……さよなら5980円!!!!




…さて、つぶしt去っていった液晶さんの代わりにaitendoさんから2.8"のTFT液晶モジュ
ールEGO028Q02
を購入しました…。コントローラICは前回使用した2.4"TFT液晶モジュール
YHY024006A
と同じILI9325です。

コントローラICが同じだから前回のと同じソースコードが使えるかなと思って繋いで
試して見るとお案の定同じでふつーに表示できました!今までで一番楽だったです。
公開しているおソースは試用にあたって気づいたバグや記述ミスも順次つぶして
更新を続けていますが、試される方は自己責任でどうぞ。

un
↑まずはいつもの癒し系小動物を。

そしていつもはいないさんのえろす絵でお約束するのですが2/9に彼女が20歳の誕生日
を迎えたこともあって今回は真面目に行きます!おめでとう!ぐふふ…
見えてる方の画像は虹裏に投下していますのでびぃぶろぐでは無害です…無害です!

…さぁつぎいってみようか…えっと…今回はaitendoさんからは変換基板は販売され
てないので自分でユニバーサル基板使って製作しました。この基板は秋月の定番のや
つですね〜。

un
↑まぁお試しなので広めにとっています。広いとミスも減って組みやすいですし。

un
↑裏にはバックライトLEDドライバとタッチスクリーンICのADS7843を載せています。
 ADS7843のおべんきょはこれからです。


また、今回の液晶を使用するにあたり、同じくEGO028Q02を試用しているそら氏より
YHY024006Aと同じく8bitバス幅でアクセスできる手法を教えてもらいました。
XMEGAみたいな8bitマイコンでも動かすことができるようにIM0端子を細工して外部
からプルアップ/ダウンでデータバス幅を切りかえられるようにしています。

un
↑EGO028Q02を改造したついでにYHY024006Aも同じ改造を。こちらはADS7843は無しです。


実物見た方は分かると思うんですけどね、データシート上ではIM0端子が出ているよ
うな感じがするんですが実際はNCなんですよね(中華サイトを巡るとNCと明確に記述
されてる同型異番種の物が存在する)…
以前触ったH161T01やYHY024006Aもそうですが、この辺実にチャイナクオリてi(ry

aitendoさんのTFT液晶モジュールを使う2

20101228追:
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め!!11!



aitendoさんから抵抗膜式タッチスクリーン付きの2.4inchTFTモジュール、YHY024006A
が販売されました。そろそろコントローラIC付きのおっきい液晶をと考えていてので
ねむいさんはすぐに飛びつきました!(変換基板込みのやつを買いました)
この液晶モジュール単体は某中華製エミュレータ端末(コントローラICが同じだけかも)
やDSO nanoにも使用されているそうです。

データバスは8,16bitが選択できると書かれています。以前のSPI接続TFTモジュール
中華クオリティはよく知っていたはずですが最初安易に8bitバスで挑戦して敢え無く撃沈
ちゃんと16bit接続でやり直しました。使用したMCUはもちろんSTM32F107VCT6です。
他のマイコン使うときは8bit分しか接続できなくてもラッチかましてあげれば16bitに
仕立て上げられるんで速度の低下に目をつぶれば何の問題もないでしょう。
変換基板にはIMOとかIM3とかバス幅切り替えられるようなシルク表記がありますが
どこにもつながっていないです!。
20100121追:vvtune氏が8bitバス接続でアクセスする方法を見つけられています。
これは…ありがたい…!


TFTの動かし方はSTM32に繋いでサンプルプログラムをSTM32用に移植(コピペ)して
そのまま"いっせーの ポン"で終了です(はしょるはしょる)。この辺は一度TFT/OLED
モジュールを制御する枠組み作ってしまえば容易なものです。

んでお約束のいつもの
un
↑私は新しい液晶モジュール手に入れたら必ずこれやらないと体の調子が…
 例の如くびぃぶろ君に怒られるので鮮明な画像は乗せることはできません(棒


…失礼しました…お口直しに小動物を…
un
↑ううむ、やっぱ画面が大きいってのは良いもんだ!?
 このモジュールもとても安いので複数個購入するつもりです…

このモジュール使ってDSO nanoでっち上げられるので、107系使うためにCQ-STARM基板
から外したSTM32F103VBT6を使用して試してみる価値はありそうですね。





てわけで今回はこれにて!…と言いたいところですが実はかなり前に別経路で
中華製TFTモジュールを購入していたりする…しかも5980円も払って!!!
un

…悔しいので涙目になりつつもこっちも表示テストしてみます…
コントローラICは先のモジュールのものと同じメーカーのILI9320。ILI9325と酷似したレジ
スタ構成でしたがデバイスの叩き方は微妙に違っていました。コントローラICが同じでも
モジュール内の結線の違いで制御方法がだいぶ変わってきたりもするので吟味は必要です。
しかし提供されているサンプル片手に"ゲタ合わせ"しておけば後にやることは同じです。

un
あらよっと。

STM32 Primer2にFreeRTOSを乗せる2 -液晶表示のタスクを追加する-

あけましておめでとうございます(した)。
自分の誕生日(1/6)の準備してたりなんやかんやであっという間に10日になっちゃい
ましたね。忙しくてなかなか手が割けなくなってしまいましたが、今年もお気楽に、
たとえば"砕けた表現やアニメ調のイラストが目に障るので授業で資料として使いやす
いようにブログの記事を修正してほしい"って教育関係者とみられる方からまたクレーム
もらうくらいの感じでやっていこうと思います。これがゆと(ry



それはさておきSTM32 Primer2にFreeRTOSを載せる試みを進めていっていますが、
今回はLCDのタスクも追加しました。さらに、ProjectC3氏のフォントドライバも使いや
すく汎用性を上げて実装しています。フォントは8~16ptまで対応で今回のデモには
フリーのM+フォント(10pt)と美咲フォント(8pt)をCヘッダファイル化した状態で使用
させていただきました(デフォルトはM+フォント)。


簡単に文字が扱えるようになると、出来ることの範囲もぐっと広がりますね〜。引き
続きFreeRTOSの動作を勉強しつつSTM32 Primer2で未使用の機能に手を出して見よう
と思います。また、STM32 Primer2とは別にもう少し大きい液晶を使用したデジタル
フォトフレームの構想なんかも練っている最中です。

un
↑だんだんサマになってきた!?

仕事納め

何とか時間取れました…なんか忙しくってホントに年末って感じがしませんね…

それはさておきaitendoさんのSPI液晶、時間を見て少しづついじってきましたが、ようやく
使えるようになってきました。使用の上での分かったことをいくつか…

●この液晶モジュールはSPI接続でしか使えない。
●SPI接続だと書き込み専用でしか使えない。よってシリアルINは要らない。
●バックライトLEDは3つ。一つ当たりの電流値typが15mAなので
 全部で45mA流す必要がある。
●3.3V系でも使用可能だがやっぱ単一だとやっぱ暗い。バラつきを考えて定電流
 制御ができるDCDCコンバータICを使用するのが良いでしょう。
●45mA流してもまだ暗いんで55mA流すとそこそこかしら。
ZY-FGD1442701V1と比べると青みがなく自然に近い色です。
●少ピンでのマイコンシステムには最適でしょう。しかし変換基板が…

といったところでしょうか。変な癖も無く、使いやすい液晶だと思います。


んでもってこのSPI液晶を使用した応用編…

un
↑以前紹介したEtherPodにFreeRTOSを乗っけたときは外部表示機能がなかったのですが
今回SPI液晶を表示機として使用してみました。文字の表示法もセクスィ部長氏ProjectC3氏
のページから勉強させてもらいました。
フォントはフリーの美咲フォントを使用しています。他のサイズのフォントもいろいろ試
してみようと思います。

un
↑実は日本語フォントは上手くいかなくでず〜っと詰まってたのですがやっと一つの壁を
超えた感じです。さぁつぎは避けまくってるUSBデバイスだ!…はまだ無理なので追々と。



と、今年はこんなところで…。仕事の中でマイコンや回路設計を覚えていってその折にこの
ブログも始めて、さらに他の方とも共同で作業をするようになって来ると一人で制作
している時は見えてなかった部分がいろいろ見えてきたりもしました。
この業界に身を置く限り、常に新しいことの勉強勉強の連続の日々なわけですが、これからも
気力の続く限りずっと続けていきたいものです。

女主人超多忙に付き

現在死ぬほど忙しいです。
駆け込みの案件が何個かあって、まぁ年末は去年もこんな感じでしたけど…。

年末までの短い期間にSTマイクロ以外のCortex-M3のマイコン攻勢が勢いを増してきました
ね〜。STマイクロがこのまま逃げ切るのか、はたまた他のメーカーがシェアを奪うのか気
になるところです。どこも新しいのだすのはいいんですけど必ず付きもののerrata何とかし
てほしいなと思ふ。


話は変わりますがaitendoさんでSPI接続のTFT液晶モジュール、H161T01が販売されていま
す。詳細は不明な点が多いのですが購入して試してみました。変換コネクタも必ずいるので
実質1400円しますね…。この前のが安価で高性能すぎるのかしら。

データシート見る限りではパラレルとシリアルでつなげられるように見えます。しかしパラ
レル制御に必要なRD,WR,(68k系ならEもかな)がどこにも見当たりません。したがってシリアル
でしか制御できないようです。"ウソつくんじゃねーパラレルでもできるぞ"っていう方は
やり方教えてください…。

今回"も"電源電圧+3.3V単一でも可能ですが、バックライトLEDのVfが+3.7Vです。まともに
使うためには5V供給するなり昇圧するなりの工夫が必要でしょう。今回は制御だけが目的
なので3.3Vのままで…。

un
というわけで動かしてみました。
データシートの額面通りだと50nSec(=20MHz)のクロックサイクルがtyp値となっています。
STM32のIOは18MHz以上のトグルスピード出せるのでいつもの如く組むのが簡単なソフトSPI
で。表示速度は以前のと比べると少し劣りますがストレスは全く感じません。さかさまに
なってるけど表示方向としてはデータシート通りになっていて正しいのでしょうか???
まぁいいや…。

un
ハイお約束。めくるめくいなちゃんの肌色世界。ここは未成年の学生さんでも楽しめる
超健全なぶろぐなのでちゃんとピンぼk…やめて石投げないで

un
…大変失礼しました。こちらはカナメ・ワタツミ氏からのいただき物の私(ねむいさん)の
イラストです。使わせてもらいます!



ということでリセット線すら省けば最低CS,D/C,SCLK,SDATAのたった4本で動くので小ピン
のマイコンとかでもきれいな画像が扱えるようになるでしょう。aitendoさんが専用のキャ
リーボード出してくれたらもう一寸売れると思います(オイ




さらに話は変わりますが多分今日ので今年最後の日記になると思います。来年も安泰に
続けたいものです…もう少し時間に余裕が欲しいですな…。
んでもってCodeSourcery G++の新しい奴(4.4.1系)で少し前のソースコードをビルドすると
ビルドできなかったりビルド通ってもまともに動かなかったりすることが分かったので
(特にFreeRTOS絡み)そちらの保守の対応と説明にも時間がとられそうです…じかんg(ry

STM32 Primer2にFreeRTOSを乗せる1

年末に差し掛かって糞ほど忙しくなっています。そんな中でも合間を縫って更新ッ…!


前回はSTM32 Primer2上にRIDEやCiecleOSなぞガン無視のBARE-METALな自分環境で
USBマスストレージクラス対応のミニフォトフレームなんか作ってたわけですが、今度は
すっかりおなじみのFreeRTOSを乗せてちゃんとしたシステムを作ることにします。
こちらもフォトフレームの制作時と学習を兼ねて段階的に進めていくつもりです。

えーと先にもいいましたがSTM32Primer2のコミュニティサイトに既に移植されたのが
ありますが
それはあえて一切視界に入れない方向でやっていきます!!!!

un
↑後発だから一味違う!!1!
まずは第一歩、以前CQ-STARM向けに一番簡単なのをこさえていたのでこれを2Primer2
(STM32F103VET6)向けに移植を…。プログラムの内容はLEDのタスクだけを動かすとい
ったごくごく単純なものです。しかーし!!コミュニティにあるのと違う点はFreeRTOS
が最新なのと真中のボタン長押しで電源が切れるという革新的n
…や やめて石投げないで
※公開停止しました。ソースコードほしい人はメールください。

このプログラムがこれから先のFreeRTOS+STM32Primer2のたたき台になります。今度
こそ横着しないでRTOSをまともに使いこなしていこうとおもいます。ついでにUSBもち
ゃんと学習していきたいとおもいます。今度は本気出す!



また、↑のと並行してNuttXという別なフリーのRTOSの勉強も初めています。これはGenie
氏が手掛けているEtherPodというSTM32F107が乗ったマイコンモジュール(まだ試作段階
ですが)に標準で搭載され、またそれに合わせた様々な機能がサポートされる予定に
なっているのでEtherPodと併せて非常に注目すべきOSとなるでしょう。

un
↑…実はすでにFreeRTOS+webserverのデモまで私が動かしててさらにこれのロー
 レベルドライバもこしらえてる最中だったりしたり

STM32 Primer2をBARE-METALで使ってみる(終) -フォトフレームを作る-

大きなバグ出しも終わってやっとこ使用に耐えるものが完成です。上位層の作り込みは
Chan氏のFatFsやターミナルプログラムの凡例のおかげで開発期間の大幅な短縮が
できました。そしてCircleOSに頼らないBARE-METALな試みも今回でいったん終了です。

昨今の電子工作は回路検証はもちろんケーシングも非常に重要なファクターになって
いますが、もとからケースに入っているSTM32Primer2はとてもありがたいですなぁ。
…ってことで、


以下今回製作したフォトフレームの使用例を…
※20091226:電源監視機能を強化しました。

※20091126:USB-MSC(マスストレージクラス)機能を追加しました

un
↑4+1入力キーの"真ん中"を押して電源投入。これはハード的に処理されています。

un
↑電源投入->タイトル表示後はSTM32Primer2に挿入されているSDカードを読み込み、ファ
 イラを起動します。ファイルシステムはFatFsを使用しFAT12,FAT16,FAT32のフォーマット・
 およびロングファイルネームが使用可能です(画面上の表示は8.3形式ですが)。

un
↑ファイラ画面の基本操作は↑↓がファイルポインタの移動、→がEnter,←がCancel
 に相当します。

un
↑画像はbmp形式が表示可能で128x160pixelまでの物が使用できます。それより小さいサ
 イズは、真ん中合わせで表示されます。画像はひねもすのたり氏画の私(ねむいさん)。
 …びいぶろ君が欲情すると困るからピンボケ!

un
↑…すみません…お口直しに癒し系小動物を。otter-beerは結構有名らしいです。

un
↑動画はimg形式。img形式のファイルは同梱のChan氏謹製の付属ツールでaviから生成
 できます。再生中→キーで一時停止、その後↑↓キーでコマ送り、戻しができます。
 上の画像のは虹裏で活動している名無しの絵師さんの動画をお借りしました。

20091126追加
un
↑USBマスストレージモードに入るためにはUSBケーブルをSTM32Primer2の
 "STM32"側のコネクタに挿し、ファイラのルートディレクトリでLeftキーを押します。
 LCDの画面が暗転し、PCにディスクドライブがマウントされたら成功です。

20091126追加
un
↑MSCモードからファイラに戻るためにはLeftキーをもう一度押します。ディスクドライブが
  アンマウントされ、ファイラの画面に戻ります。、


un
un
↑UART2からの通信にも対応。上記結線(TTLレベル)でホストPCと接続。

un
↑ホストPCのターミナル(230400bps,8,N,1)上からESCキーを押すことで、ファイラは
終了し、FatFsのUART上のモニタプログラムが走ります。

un
↑現状では時刻設定はUART上のモニタプログラムからのみ可能です。

un
↑電源OFFは"真ん中"のキ―長押しで行います。この画面が出てからキーを放すと
 FETスイッチが切れ"電源OFF"となります。

と、こんな感じです。ミニフォトフレームに機能を絞っているので以下に挙げる機
能は基板上には存在しますが使用していません。後は各人がソース変えてお好みで
付け足してくださいね(ひでぇ)。
*Not Used Devices
-Touch Sensor
-3D MEMS Sensor
-I2S Peripheral
-IrDA

また将来搭載予定の機能は以下に。
*Future Features
-USB-MSC 実装済
-LCD-Backlight Adjustment
-Adjustment Configuration which does not rely on host PC.
-Improve Backup Register Function.
-Improve Power Management 実装済
最優先はUSB-MSC。SDカードの抜き差しは面倒ですもんね。
USB-MSC実装しました。
IJG JPEG Library を実装しました!

んでもって修正すべき項目は以下に。
*Known Issues
-Cannot execute program if there's no Li-Ion Battery jumper. Fixed.
-Cannot execute backup function. Fixed.
現状Li-Ion電池のジャンパしてないとNo Batteryと判断されてしまいすぐに強制shutdown
されてしまいます。電源電圧の上手い監視方法見つけたらこちらはすぐに修正します。
修正済


ということでまだまだ手を加えるべき点はありますが、興味を持たれた人は試して
みてくださいね。ご利用は自己責任で〜

un

STM32 Primer2をBARE-METALで使ってみる5 -FatFsの実装-

もともとBARE-METALで取り組むのを決めたいきさつは、Chan氏のLPC2388向けのOLED
表示プログラムを"STM32で再現できたら素敵じゃないか"って構想から始まって少しずつ
実現して来たわけですが,STM32Primer2でも再現してみたい!という思惑からはじまっ
てます…。

今回その要であるFatFsの実装にとり掛りました。STM32F107VCT6ではSDカードのアクセス
にSPIを使用していましたが、STM32Primer2(STM32F103VET6)ではSDIOインターフェース
が搭載されているのでこちらを使います。またSDIOのドライバはSTマイクロさん本家から
MassStorageClassのデモの形で提供されているのでRowleyのサイトにある移植例を手本
に"ゲタ"合わせを行いました。(ベースはSTM32F107VCT6のFatFs)

LCDの時よりかは手こずらずに移植は完了しました。が、いくつか引っかかる点が…

ヽ笋蟾み版のUART-Txを使うとxprintf関数を実行したときうまく表示できない
 いろいろやってみましたが文字の送信がうまくいかなかったので折角割り込み版をこさ
 えたのにポーリング版に戻したorz(Rxは割り込みでも問題なし)
私の経験と知識の無さはこういう形で表れてくるorz

20100317:FIFOバッファの処理が不完全なだけでしたorz

RTCの初期化がうまくいかない
 STM32Primer2は電力消費を抑えるためにVbat周辺の回路も同じく低消費電力化されて
 います。以前の回路ではうまくいってたバックアップ方法は今回は動きませんでした。
 具体的に言うとバックアップレジスタにマジックナンバを書いておいてその有無でバッ
 クアップされているか判定していたのですが、STM32Primer2の回路だとそこが正しく
 読めない…仕方ないのでマジックナンバが書かれているかの判定部分は削除しておく
 と時刻情報はかろうじて保持されているのでひとまずこれで進めることに…

開発が落ち着いたらバグ出しついでに上記2点の問題おっかけます。特に大きな支障は
ないので今は対策を保留…。

20100317:RTCの初期化に問題があってバックアップレジスタへの書き込みを
      禁じた状態で書こうとしてましたorz



とりあえずFatFsが動いたので読み込み転送速度の比較を行ってみました。使用したSDカー
ドはATP製の4GBSDHCカード。Class6のものです。比較検証用のファイルはL氏のwebラジオ、
"Lの虹裏ピアノラジオ"を録音したmp3ファイル(132MByte)を使用しました。

un
↑まずSTM32F107VCT6の(SPI,18MHz,DMA使用)で…まずまずです。

un
↑次に今回STM32 Primer2に実装したの(SDIO,4bitmode,24MHz,DMA使用)…あれれ、思った
ほど伸びませんでしたね…。
今すぐ下の方見ろ!!!11!

un
↑最後にChan氏のLPC2388用MCIアクセスプログラム(MCI,4bitmode,18MHz,DMA使用)。
ううむ…ぶっちぎりですなぁ…。

STM32のSDIOはもっと伸びるとおもうんですけどどっかでフン詰まりになっているようで
すね・・・まぁ現状でも十分すぎるのでこちらの件は以後の改善課題としておきます。


20110201追:
アシッド氏のブログの"シングルセクタ転送->マルチセクタ転送"の部分を見てねむい
さん気づいた!
私のも川内氏のもFatFsはRowleyのSDIO実装例を源流にしているはずだから、
FatFsのR/Wの部分ってシングルセクタ転送でしか実装してnほらやっぱり!!


〜小一時間後〜

un

やばい超早い♥


20111111追:
時は流れ、STM32F4では48MHzのSDIOクロックでも安定して動かせられる
ようになったので、約21Mbyte/Secの読み出し速度を常にたたき出してます!


次回は今まで検証してきた成果をすべて組み合わせ、BARE-METALなプロジェクトの到達
目標としていたPrimer2用フォトフレームの制作に挑みます。

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

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

ST7735の時と同じ風にやったら楽勝だろうと考えていたらモジュール内部で完結して
いるICのモード設定ピンの関係に気づくまでどうしても表示がうまくいかなくてうnうn唸って
いました。コントローラ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を切って
しまいます。(リチウムイオン電池の詳細な特性については他の専門に解説されて
いる方たちにうっちゃる(うn?)として、)実際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は全く使用したことがないので少々手こずりそうです。

STM32Primer2をBARE-METALで使ってみる2 -Systickタイマと電源制御-

前回は一番基本的なLEDの点滅を行いました。点滅だけなので、STM32 Primer2のバッ
テリーの制御(電源OFF)ができません。これから先いちいちUSBケーブルを抜き差し
するのは不便なので今回は電源制御を行います。


電源の制御にあたって、STM32(というかCortex-M3)に搭載されているSystickタイマ
を利用し、定期的にSWポートをスキャンしてある条件を満たしていれば電源をOFFに
することにします。これはCircleOSと同じ仕様ですね。

具体的には1mSecごとにCenterキー(PA8)を走査して5000mSecの間連続してHiレベルに
あったときにSHUTDOWN(PC13)をHiレベルにしてFETスイッチをOFFにします。4入力キ
ーの定義も行っていますが、今回は使うのはまだCENTERキーだけです。

un
↑4+1キー入力と電源制御(SHUTDOWN)周辺

またRLINKのフラッシュの方法も少し工夫しました。RFlasher7でちんたらやってた
ら非常に煩わしいので、OpenOCDを使ってた時よろしくmake programでコマンドラ
インのフラッシュライタを呼び出し、バッチ処理しています。これでOpenOCD使って
た頃とまったく変わらない操作性になりました。やっぱこっちのスタイルの方がい
いですね〜♥もちろんRLINKのデバイスドライバはWinUSBの方で!

un
↑OpenOCDのフラッシュプログラムの処理をRLINKに置き換える


土台が整ったので、ここから先は駆け足になると思います。同じ事やってても何も
身につかないのは自覚してるので浅く広く早くでやっていくつもりです。
一応ねむいさんの基本スタンスは…
●無償で公開されてるライブラリ・プログラムは極力有り難く利用させてもらう。
●↑のことした場合は"ネットで見つけた"とか書かずに公開元のルールのもと引
 用先をブログやソース内で明示させてもらう。
●使わせてもらう前にざっとでいいからコードを眺めて流れを把握する。
●ここは自分でやらないとだめだ!って部分は自分で調べてフルスクラッチで書く。
●真似てやって壊れても潰れても燃えても泣かない(これ重要)。一度壊したけど。
●他の方がされていることに過度に干渉しない(これ重要)
この辺虹裏内での立ち回りと全く同じなわけですが、気をつけます。

STM32Primer2をBARE-METALで使ってみる1

BARE-METALとか横文字でかっこつけてみたけれどつまりCircleOS(とそのAPI)使わないで
やってみるというわけです。STM32F103VET6(を使ったSTM32Primer2のハードウエア)
に合わせたフレームワーク作りをやって行きます。

今までSTM32F103VBT6(CQ-STARM),STM32F107VCT6とやって来てリンカスクリプトや
スタートアップの組み方は熟知してますので定義だけ変えてあげれば終わりです。
STM32F107VCT6をベースにしてPrimer2上の2つのLEDを交互に点滅するプログラムを
こしらえるのが今回の最初の目標です。(FWライブラリは勿論V3.1.2の最新で)

STマイクロさんが用意してくれているCソースのシステムクロック用の設定は、デフォルトが
103,101系は8MHz,107系は25MHzの外部クロックを想定しています。STM32Primer2は
12MHzのクリスタルを使用するため、system_stm32f10x.cにあるクロックPLLを設定する
関数内で一部定義を書き換える必要があります。提供されたライブラリにはなる
べく触りたくなかったので、コピーしたファイルをリネームしてmain.cと同じ場所に置きました。
un
↑赤で囲った部分がPLLの定義を書き換えたところ

さらに、使用している外部クロックを決める定義(HSE_Value)はmakefile内で行っています。

プログラムの書き込みは先日無理やり適用したWinUSBのドライバで安定して動くよ
うになったRlink(ビルドイン)を使い、RFlasher7で書き込みます。

un
まだ電源制御は乗っけていませんのでtodotani氏のブログ内の記述にある
とおり電源のONは出来てもOFFはできません。電源切る時はリチウムイオン電池の
ジャンパとPCにつなげてるUSBケーブル引っこ抜いて切る必要があります。

次回はこの電源制御を中心としてsystickタイマ・キー入力の実装を行うつもりです。

ペ プ シ あ ず き

un
…うおえっぷ。子供向けのシロップ状の薬思い出してしまった…。

そしてそんなことやってる間にも私の周りの世界はどんどん回っていく。LPC2388のコ
ンテスト受賞者が発表されていますね〜。私がFreeRTOSを知り、使うきっかけとなっ
た今井健太郎氏やUSBデバイスの開発で詰まったときに参考にさせてもらっているマイ
コン工作実験日記氏の作品が入賞されています。

私はチェンジニアリング(=他人の成果物使って切った張った)しかできないから一つの
プロジェクトを決められた時間でフルスクラッチでバシッと組めるってのは尊敬して
しまいます。この業界に転職して早一年と少し、なんとかしがみ付いてきたけどこの先
数年もしないうちにまた違う職種に移ってるんだろうけども何かひとつくらいはでっか
いの残していきたいな〜なんて妄想してます(げんぢつから目をそらしながら)。


久しぶりの日記がここで終わってしまうと歯切れが悪いのでもうちょっと書いてみます。

●STM32 Primer2
以前から少しずつSTM32F107系の記事書いてきましたが、そちらと並行してSTM32Primer2
をCircleOS無しで動かす構想を考えています。目標は…FreeRTOSを乗せて動かす!

…と書いてしまいましたが実際ことに移すとコレ結構厄介です。まずは開発環境が…。
STM32Primer2にはビルドインされたRLINKがあるのですがこれがSWD接続の為にOpen
OCDから直接操作ができません(20091104現在)。
そしてRLINKのデバイスドライバ(Windriver)が未だにバージョンが低いものを要求し
ているため、AVRJTAGICEmk2等で使用されている最新のVerのものを使用することがで
きません!無理やり使うと確実にB.S.O.D.になってしまいますorz(XP環境の話です)

実はねむいさんがSTM32Primerを使用することに消極的だったのはこのドライバの問題
なわけで、よくよく調べてみるとWindowsVISTA以降のOSはマイクロソフト純正の汎用
USBドライバであるWinUSBなる物が提供されていてVISTA以降のOSではRLINKのドライバ
としてこちらが適用されているようです。ねむいさんはこのWinUSBってやつを無理やり
XPにも適用して難を逃れました!!
(セコいな)
FreeRTOSを乗せる過程は一気にはできないので次回以降でぼちぼちとやっていきます。

●aitendoさんのTFTモジュール
たくさん売れたおかげで専用の拡張ボードまで起こしてもらって再販になっています
(20091104現在)。一枚絵の表示くらいならAVRでも十分にできるのでひとつくらいは持
ってても良いかと思います。私もLPC2388,STM32F107で表示させてきましたがそら氏と
同じく青みがかかった画面を何とかしようといろいろあがいてみました。しかし結局
大きな改善はできませんでしたがVMCTR1(VCOM control1)というレジスタの値を変え
るとコントラストは変えることができたので少しいじって濃いめに出すようにしました。

un
↑こんな感じで。少しは見栄えが良くなった!?

STM32F107VCT6のプログラムはUSBライブラリのリリース待ちの関係で公開を保留して
ましたけど一項に出る気配がないのでW.I.P.ですが置いておきます。
FatFsは先日R0.07eがリリースされていましたのでこちらも適用してあります。

LPC2388の方もSTM32とおなじ修正を施しておきました。以前はUART版とVCOM版は
分けていましたが今回からmakefile内で切り替えられるようにして一本化を行いました。
こうしておくと管理楽ですからね〜。ついでにchan氏のmp3プレーヤーで使用している
mp3モジュールを使用したスイッチ入力にも対応しています。詳細は同梱のdocフォルダを。

●OLIMEXのAT91SAM7S256プロトタイプボード
ず〜〜〜っと前からやるやる詐欺してましたがこちらも腐らせるにはもったいなさす
ぎるので手をかけることに決めました。こちらの目標はいくつか買い込んであった
TFTモジュールを使用したUSB接続のミニフォトフレームの製作をしてみようと思います。
un
↑やるやる詐欺

aitendoさんのTFT液晶モジュールを使う

20101228追:
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め!!11!



かねてから興味があったaitendoさんの液晶モジュール、ZY-FGD1442701V1が手に入っ
たので早速使ってみました。現在はそら氏がATMEGA644Pで画像の表示まで達成されて
いますね。私はいつものSTM32F107VCT6で攻めてみました。

この液晶モジュールのコントローラはST7735で、データシートみる見る限りではchan氏の
OLEDの時とほぼ同じようなアクセスの感じに見えたので、前回STM32に移植したOLED用
のコードとサンプルコードをもとに新たにST7735用のコードを作りました。STM32のローレ
ベル部分はこさえてあって表示部分はchan氏の非常に柔軟なコードがほぼそのまま使えた
ので、はんだつけ工作も含めて移植は半日も掛かりませんでした。

で、OLEDでやってたミニフォトフレーム(?)をTFT液晶モジュールでも再現。
un
↑やや青みがかってますがOLEDモジュールに引けを取らないほど発色がよいです。そら氏
 がされているようにガンマ値いじればさらに綺麗になるでしょうね。

un
↑周囲を暗くして写して見ました。デジカメでうまく撮るための工夫を考えねば…。


un
↑ああ、残念だ。美しいいないさんの肢体が輝度が高すぎてで光学迷さ(ry

un
↑おやくそくはおいといてコツメちゃんを表示。うまくいった後はBEERがうまいぜHAHA!
 タプタプ


液晶モジュールのデータシートはロジック3.0V,LEDバックライト3.3Vまでと謳われていますが、
ロジック部のコントローラST7735は3.3V(絶対最大定格4.6V)で運用可能です。
ねむいさんはST7735のほうのデータを信用したので(良い子は真似しちゃだめよ!)
STM32F107VCT6動かしてる3.3Vの単一電源だけで液晶モジュールを動かしています。
多分稼働寿命対策でモジュール単位では低い電圧で運用してもらううつもりで書いてある
んでしょうけど、遊びで使うなら3.3Vでもなんら問題ないでしょう。

STM32ではうまくいったのでお次はLPC2388でもやってみます。安い上に非常に使いやす
いのが分かったのでもう5〜6個ほど買うつもりです。

色々直す…

…前回の検証でSTM32 Primer2に乗っかっているSWレギュレータIC(L6928D)を、2つ
とも吹っ飛ばしてしまったのですが、これらはU9:メインMCU電源供給(2.8V)、U17:バック
ライト用電源(3.1V)向けという非常にクリチカルな部分に使われていてどちらか一つ
でも壊すと、もはやPrimer2は使用不可能になります!!

仕方がないので代替で使用できそうなレギュレータを探してはっつけることにしました。
L6928Dは非常に繊細だとのことでもう使わない方向で…(手に入りづらいですし)

うー
まずバックライト電源生成部。元の設計上では3.1V出力ですが実際は3.2V近くあります。
また、カラーLCDのバックライト電源は3.3Vまで使用可能でなおかつSTM32Primer2が
監視しているリチウム2次電池のシャットダウン電圧が3.5Vな点から、いつものLT1963A
先生に代役してもらうことに。電流は500mAも引かないので3.5Vまで落ち込んだ時の
ドロップアウト電圧も気にならないレベルです。これでもう一寸安くなってくれたらねむい
さん的に最強のLDOなんですけお…性能が高い分お値段も高いんだよ…

うー
次に2.8V生成部なんですが身近にすぐ手に入る2.85V出してくれるちっさいサイズのレギュ
レータがこれしかありませんでした。残念ながら150mAしか引けないのでSTM32Primer2回
すだけで精いっぱいです。外部に機器を接続する時は別口でとらざるを得ないです。
耐圧はL6928Dよりも0.5V高いので過渡電圧余裕も確保…かしら?

うー
一度は死んだSTM32primer2でしたが措置を施し電源が修復強化されて無事復ッ活!!
ちなみに10月11日は同僚のヤクいさんの誕生日なのでした!



そしてもうひとつ、不注意で壊してしまった(輝度が異様に下がってしまった)OLEDの代わり
に新しいOLEDの基板がやってきました。前々回もお見せしましたが、chan氏のLPC2388用
のOLEDアクセスプログラムをSTM32F107VCT6に移植しています。LPC2388のFIOはI/O
クロック36MHzの高速アクセス(最高I/Oトグルスピード18MHz)ができてOLEDも非常にスム
ーズに表示できたのですが、STM32もほぼ互角のI/Oアクセス性能を持ちます。

ただし、STマイクロ提供のライブラリ関数からだと呼び出しのオーバーヘッドが掛かるので、
直接GPIOレジスタにアクセスする必要があります。さらにSTM32に(というかCortex-M3)
ビットバンドによるアクセスができるのでうまく組むとLPC2388より早くアクセス可能でしょう。
今回は便宜上GPIOEのみを使用してOLEDを制御したので1命令分多くかかっています。

というわけでSTM32F107VCT6でOLED動かしたところ↓
うー
嗚呼残念だ、せっかくのいなちゃんのえろすな絵が輝度が高すぎて光学迷彩が掛かっ
たみたいな写真になってしまったー(棒

うー
…とふざけるのはここら辺にしといてカラー写真とかもOLEDでは綺麗に表示できてい
ます。モデルはコツメ氏。カワウソって良いですよね♥特に頭の形とか♥

はてさて、STM32の新(OTGを含む)USBライブラリの正式リリースはもう少しのはずです
が…。待ち遠しいですね〜…これが出ないとソースを公開する踏ん切りつかないし…。

涙目のネムイ2(STM32 Primer2壊しました)

うー
STM32F107VCTでもOLED使えるようになりました。64kBもあるRAMのおかげです♥
え?"なにも映ってないだろこの茶デブが!"ですって!?よっっく見てください!!
うっすらとシルエットが見えるでしょう?…OLEDを物理的に潰さなければもっと綺麗に
写ってるはずなのです!なのです!!
…いないさんの美しい肢体は新しいOLEDモジュールが来るまでおあずけ…







…さて本題、先日STM32 Primer2について黒田さんより電源IC(U9,U17のL6928DというIC)
が破損対策がされているのにもかかわらず破損したとのコメントをいただきました。
遊びでも仕事でもも電源周りのトラブルで泣かされているねむいさんはこれ以上Primer2で
憂き目にあう人が出てしまわないように調査を開始しました。

まず問題の部分、以前はU17のGNDが信号線扱いで間違って細いパタンが引かれてしま
ってGNDのインピーダンスが高い状態になってしまって電源投入直後の入力の過渡電圧
でIC死亡となっていた問題は、出荷時にU17のGND(4Pin)を太いジャンパで強化するこ
とによって回避しています(したはずでした)。
うー


しかし対策されたはずの基板でも破損が発生したということは同じ問題が解決していな
いかもしくはまた別な問題があると思われます。とにかく現状何が起こってるかをオシ
ロで観測することに。
うー
VCCINとGND,実際はC23の+と-の電位差をモニタし、FETスイッチがONになった瞬間の電圧
遷移を測定しています。


うー
VCCINの波形は電源供給元によりかなり特性が変わります。これはリチウム2次電池のみ。

うー
こちらはUSBケーブルの給電のみ。裏のジャンパは外した状態。

うー
最後にUSBケーブルの給電+リチウム2次電池。

L6928Dの絶対最大定格が+6VですがFETスイッチが入った瞬間の過渡電圧が+5V近くまで
迫っています。私の環境では定格内に収まっていますが、違う環境(USB給電で使用時、かつ
Vbusが+5Vより少し高いようなPCの環境)では+6V以上に跳ね上がる可能性がありますね。



また黒田さんが教えてくださったRaisonance側の見解は、
>The two L6928D regulators (U9 and U17) are very sensitive.
>To solve this issue, the patch on U9 is the main measure.
>But it seems not to be sufficent.
>A second measure consists in replacing the input capacitors (C23 and C56)
>by multilayer ceramic capacitors (instead of tantalum).
>We will modify the web page to recommend this additional measure.

これはESRが低い大容量のMLCCを使って過渡電圧を抑制しようという試みでしょうか??
十分な性能を持ち、手に入れやすいMLCCを使って私も検証してみました。
参考になる記事
…ほんとは電源周りに使うなら十分な耐圧持ったX7R、最低でもX5Rは欲しい。

うー
とっかえました。撮影の際見やすいように電源ICは一旦取り外してあります。
>2012サイズではちょっと取り付けが苦しそうですね。
はい。確かにちょっと半田しずらいですorz。半田で盛って何とか取り付けました。


この状態でもう一度、FETスイッチがONになった瞬間のVCCINの電圧遷移を測定しました。

うー
これはリチウム2次電池のみ。

うー
こちらはUSBケーブルの給電のみ。裏のジャンパは外した状態。

うー
最後にUSBケーブルの給電+リチウム2次電池。

波形に関しては目に見える効果が表れています。チップタンタル使ってた時に発生して
いた過渡電圧の"ヒゲ"がバッサリ削られています。これだと十分にL6928Dの定格に収め
られますね。

L6928D破損の原因がFETスイッチのON時に発生する過渡電圧ならばC23,C56の
チップタンタルをESRが低いMLCCに交換する手法は非常に有効でしょう。


20120522追:
Achan22氏のさらなる解析によると、出力段FET(Lxピン)に外付けのフライホイール
ダイオードを付与して回生エネルギーによる破損からFETを保護する必要もあるようです。



この後もいろいろデータ取りたかったのですが残念ながら続行できませんでした。何
故かというとオシロのプローブあちこちつなぎ換えてるうちにどっか変なトコ触っちゃ
ったのか知りませんがL6928Dを潰してしまったからです…。
しかもU9とU17の2つとも!!!!orz

>The two L6928D regulators (U9 and U17) are very sensitive.
>very sensitive.

繊細すぎる…さてと代替品探しに行くか…。

STM32の新しいライブラリを試してみた

前回も終わりのあたりでさらっと触れましたが、まず標準周辺ファームウエアライブラリ
(STM32F10x_StdPeriph_Lib)がv3.1.0->v3.1.2に変更しています。それとまだRC版ですが
USBライブラリ(STM32_USB-FS-Device_Lib)もV3.0.1->V3.1.0RCになっています。前回
はさっと見ただけで済ませてましたが、もう少し深く立ち入って検証してみたのでその
所感をば…。

●STM32F10x_StdPeriph_Libの方
 全体的に大変更は無く、若干のコメント記述の変更やデモプロジェクトの追加等でお
さまってるようです。ライブラリそのものもごっそり入れ替えるだけ公開してきたいくつか
のサンプルで正常動作を確認しています。

 また、前々回FreeRTOSを動作させた時スタートアップ周りのコードをそのまま使っていると
数秒で止まってしまった問題
は私が設定したスタートアップのdefine漏れと私自身が作成
したi2cローレベルルーチンのバグ(ACKフラグの消し忘れ)が原因だということが分かり(orz)、
結局そこを直しただけでわざわざ変更修正していたsystem_stm32f10x.cも配布の物を
そのまま使える状態で動かすことができています。
つまらん時間食ったぜ…orz

●STM32_USB-FS-Device_Libの方
 現状まだRC版ですが内容物を見たところ、7月頃に公開されていたConnectivity-Line
用のUSBOTG-LIBと合併した形で公開されています。おそらく正式リリース版もこの形で
提供されることになるでしょう。また、評価ボードごとのヘッダ・ソースファイルも今回より新
しく提供されていました。私のようにCQ-STARM基板を改造しまくって使用し、かつライブラリ
付属のサンプルを流用してる人は要注意です。

 ちなみにSTM32F103系で使えてたUSBライブラリはUSB-OTG(とOTG用のPHY)が乗った
107系には転用できません(だからライブラリもわざわざ別にされてたわけなんですが)。今回
のライブラリの合併(サンプルプロジェクト付き)によって107系でも手軽にUSBが扱えるよう
になりました。でもって肝心の動作の方なのですが、STM32F103系はそのまま差し替える
だけで問題なし。STM32F107系もOTG-LIB関連のファイルを追加してビルドするようにすると
USBデバイスとして動かすことができるようになりました。現状では、USB-CDC・MSCの
二つは動作を確認できています。提供されているサンプルは今のところターゲットデバイス
のみに絞られており、OTGの機能をフルに使ったものはまだないようです。
今後の充実に期待ですね…私もUSB-miniABコネクタ買っとかないと…。


前回は新ライブラリで動作を確認次第公開していたサンプルコードも順次差し替えていくと
言いましたが、上述のとおりUSBのライブラリももうすぐリリースされそうなのでこちらの
正式リリースを待って公開としていこうと思います。今から急いでも仕方なしですからね〜
…特に107系は。




あ、いちおう言っとくけどLPC2388はUSB-OTG用のPHYチップ付けないとOTGの機能使えま
せんから!USB-TargetだけもしくはUSB-HostだけならPHY無しの直結でも動きますけどね…。

STM32F107VCT6に乗り換えた

今をさかのぼること数年前、まだ私が「」がいるほうの二次裏で活動していた頃、タッチ
ペン使ってめどいさんと云々なDSのゲームの妄想ネタがあった(はずだとおもう)のです
が、STM32Primer2使って似たようなこと再現してみました。

bare-metalで組んだ方が勉強になる(キリッ とかでかい口叩いてしまいましたがやっぱし
APIとか提供されてたらそっち使った方が楽ですよね〜ハハ、ハハハ…。今回紹介したのも
CircleOSにビルドインされてるDRAW関係のAPI呼んだだけ。アプリよりこれ用の絵を
引き直してる時間のが長かったです。


うー
↑いないさんとあそぼう(性的な意味で)。びいぶろ君が欲情すると困るので画像をぼか
 してる上にちいさいのはあしからず。そのかわり虹裏には鮮明な画像を投下しておいた!

Primer1と比べると発色・視野角ともに良好で美しいいないさんのイラストがさらに際だち
ますね♥写真はぼけてるけど。

うー
↑もちろんタッチペン入力に対応。ペンの先っちょで"先っちょ"をつんつんすると…♥




…ごめん、もう二度とこんなことしないからゆるして…






さて本題、先日digi-keyよりSTM32F107VCT6を購入したので以前CQ-STARM基板に載
せ替えていたSTM32F107VBT6と交換しました。当たり前ですが先日走らせたFreeRTOS
もそのまま無事に動作しています。また懸念されていたシステムメモリから起動する方
のブートローダーが動かない件はVCT6になってもやっぱり駄目でした(リビジョンは同じ'Z')。
まぁJTAGあるから良いでしょう…。

そしてSTM32の Standard Peripherals Library(FWLib)がv3.1.2 に上がったのでこちらの
ライブラリもFreeRTOSのデモに組み込んで無事動作確認。あとは過去に公開した
STM32F103VBT6,STM32F107VBT6用のプログラムも順次FWLibを3.1.2に最終アップ
デートしてclosedとし、以降はSTM32F107VCT6一本で遊んでいきたいと思います。

と書いているうちにUSB-OTG対応のUSBライブラリのRC版がリリースされたようです。
こちらも早速評価してみます。

STM32F107にFreeRTOS乗っけてEthernet-PHYを動かすっッ!

前回からやるやる言ってたSTM32F107でFreeRTOS動かしてEthernet-PHY動かすと言っ
てた件ですが、デモコードのRowley用のサンプルを参考にあれやこれややってLPC2388
で達成していたことと同じことができるよう目指しました。

移植の際に気になったのですが、もとのRowleyのデモので使用されているビルドの定義
が本来ならばConnectivity Line(以下CL)でなければならないのに何でかMedium-device
(以下MD)になってて何でこんな意味のない事やってるんだろうか?と思って自分はCLで
makefile組んでビルドしたら見事に爆死

よくよく調べてみるとスタート時のクロック設定のルーチンでCLの定義された部分を実
行するとOSが走りだしてから数秒後に必ず止まることが分かり、仕方ないのでこの部分
だけをMDで定義されたルーチンをマージしてなおかつメインクロック・周辺回路に矛盾
が出ないようにして難を逃れてます。

また、Ethernet-PHYの接続はLPC2388の時と同じRMII接続にて試みています。手本の
STM3210-C EVALのデフォルト回路はMII接続なのでemacのコードはRMIIに書き換える
必要がありました(と言っても書き換えるの一行だけでしたが)。それとOLEDは同じものを
持ってないのでいつも使ってるi2c液晶さんに代役をしてもらってます。後はデータシート
&マニュアルを地図代わりに一本道。そんなこんなでFreeRTOS上でWebServerとかi2c
液晶にステータスとかの表示ができるところまでたどり着きました。

うー
↑FreeRTOSを本格的に動かすためにベース基板新調しました。Ethernet-PHYの基板
 はLPC2388の時の使い回し。

うー
↑WebServerが動作しているところ。OpenOCD+Insightのデバッグで動きをおっかけてくと
 FreeRTOS上でどうやって桶屋が儲かってるかが分かって面白いです。


人それぞれの所感があるでしょうけども私的にはやはり自分で設計したとおり&意図した
とおりに動作が得られてニヤリと出来る瞬間が、別の言葉に例えると(例えがアレですけど)
いないさんのスカートの中身が見えた時のイヨッシャー!感が電子工作の醍醐味だと思って
ます。ねむいさんはこれからもその感触を求めて精進してきます!非性的な意味で!


今回のコードはまだ動作が確認し切れてないのでW.I.P.にしときます。
※STM32F107VCT6に統合したので削除しました。
そしてそうこうしてるうちにdigi-keyで発注していた本命のSTM32F107VCT6がやってきたので
サンプルで頑張ってくれたSTM32F107VBT6は短い期間でしたが今回で任務を完了。
お疲れ様〜。

STM32F107をもうちょっと使ってみる

CQ-STARMの基板に乗っかっている3.3V出力のLDOは、たったの150mAしか電流
容量がありません(てかこんだけの電流容量でSDカードとかよく動かせてたな…、
無茶な設計したもんだ)。
STM32F107に載せ替えてこれからもいろいろやって行くつもりなのでそれを見据えて
同基板にもうちょっと多く電流が引くことができるLDOを載せ替えました。

うー
元のLDO周りの回路は全部取り外し…

うー
裏のやたらにワイドなパタンを利用してLT1963AMLCC(X5R,16V,10uF)を取り付け…。

このLT1963Aという石は逆電圧保護・逆接保護・過熱保護などの各種保護回路があり、、
なおかつMLCCが使用可能というナイスなLDOです。その分値段は張りますが…。
昔秋月にL1087というのがあったのですが値段も安くて使いやすかったなぁ…という
思ひ出。

(レギュレートする前の電源ソースにもよるけど)最大1.5Aも電流が引けるので3.3Vで
動くいろんなデバイスをぶら下げられます。秋月のGPSモジュールとかも+3.3Vだと常
時190mA近く食ってるけど改造後は余裕です!でもGPSは次回以降のネタにとっときます…。

これで電流容量的にも安心してSDカードが使用できるようになったのでSTM32F103で
やってたFatFsのテストプログラムを107系に移植しました。といっても移植性が
非常に高いMCUなのでリンカスクリプトとスタートアップとmakefile以外はほとんど
変えずに動作確認できました。次はいよいよ本懐のFreeRTOS上でEthernet-PHYを
RMII接続で動かす!ですね。
うー

本日のソースはこちらに…ご利用は自己責任で…。
STM32F107VCT6に統合したので削除しました。
また、STM32F103のFatFsのテストプログラムはR0.07cに変えたときに見落としていた
処理があったのですがこれの修正を施した上で107系に移植しています。

STM32F107はぢめました

http://belogic.com/uzebox/
いつ見てもすごいなこれ






…は置いといてSTマイクロさんにサンプル請求していたSTM32F107VBT6
ねむいさんちにやってきた!!!!
うー
このSTM32F107xxxってやつは今年の7月にリリースされたSTM32の新機種、Connect
ivitiy-lineという種で、今までのSTM32の機能に加えてEthernet-MAC,USB-OTG(PHY
も内蔵),I2Sインターフェースとてんこもりになっています。NxPのLPC2388も同じ
数だけ周辺がありますが、多分どっちも使い切れんだろうね…orz


このチップはCQ-STARMに乗っかってたSTM32F103VBT6とピン・機能互換なので、その
まま載せ替えが可能です。というわけで早速載せ替え〜!
うー
まずCPUだけ。STM32F107はUSB-OTGなので以前のUSBライブラリはそのまま使用でき
ません。しかしそれ以外は互換性があります。以前のプログラムをJTAG経由で書
き込み、UART,RTC,ADC,I2Cの動作を確認。載せ替えは(物理的に)上手くいっている
ようです。

次に上記のプログラムをベースにSTM32F107VBT6(Connectivity line)用にリンカ
スクリプトやスタートアップを適用していきました。またEthernet-PHYを使用
することも考えてメインのクリスタル(HSE)は25MHzの物に差し替えています。

少しの変更で作成したSTM32F107用のプログラムですが問題なく動作しました。

うー
後はUSB-OTGのライブラリのちゃんとしたのが出そろうのを待つばかりですね〜。
それまではFreeeRTOSのSTM32F107用デモ(Ethernet-PHY制御含む)の完全動作を目標に
していきたいと思います。





あと雑多な所感とか…

STM32 Connectivity lineのMCUはシステムメモリにUART1,UART2,CAN,DFUの
ブートローダーが仕込まれているとのことで特にシステムメモリからDFUが使えると
スタートアドレスやリンカスクリプトをいじる必要もなくなりさらにやりすいかなぁ
…と思って早速試してみたのですがなぜか起動しない…orz

STマイクロのフォーラムを当たると私と同じ症状の人がいた。ううむ所詮はサンプル品
なのかはたまたerrataなのか…情報がたまるまで待ちましょうか…まぁJTAGで書き込み
とデバッグは出来るのでそちらの方法で行えばいいのですけれども(涙目で)。

STM32のコネクティビティ・ラインはブートローダーに致命的なバグがあります。


そんでもってSTM32ではJTAGで書いた消したやってるとうっかり__WFI();でループす
るようなプログラム書いちゃうとJTAGにすらアクセスできなくなってしまうのですが、
これはWFI実行したことによってJTAGの周辺回路のクロックまで止まってしまうからです。
内蔵フラッシュメモリじゃなくてシステムメモリからブートした状態からだとJTAGが
ひっかかってくれますので
改めてフラッシュの内容を全消去によって復活しますので
やっちまった時の逃げわざと思っていてください。

それともうひとつ…OpenOCDでフラッシュ書き換えたときに出てくるメッセージとかを…

> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/stm32_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.3.0-in-development (2009-09-03-18:39) svn:2663
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Warn : use 'stm32.cpu' as target identifier, not '0'
Info : device: 4 "2232C"
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001b40 msp: 0x2000c000
Info : device id = 0x10016418
Info : flash size = 128kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 44704 byte from file main.elf in 2.812626s (15.521527 kb/s)
verified 44704 bytes in 1.125051s
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)

> Process Exit Code: 0
> Time Taken: 00:05

STM32F103VBT6の時はJTAGチェーンが見つかったときに
nfo : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
って出てましたがさすがに違いますね(あたりまえか)
続くdevice idも
STM32F103VBT6では
Info : device id = 0x20016410となっていましたが
STM32F107VBT6では
Info : device id = 0x10016418
となっています。

あとあともうひとつ…
リンカスクリプトいぢってみて分かったのですがSTM32F107VBT6はRAM48kByte
のはずだと思ったのですが、実際には64kByteありました…。
…なんだこれ???…やっぱサンプル品だから仕様外の物もあるってことでしょうか???

涙目のネムイ(STM32 Primer2のあれ)

秋月さんとこからもSTM32マイコン評価キットのSTM32 Primer2が販売されています
大量在庫で6100円の格安です!
ねむいさんは4月頃にDigi-keyで9600円くらいで購入していたので今すげぇ涙目です。
くやしい…でも…使用記書いちゃう!

20110824追加:
超実用!!USBマスストレージ機能つきGPSロガー


20091206追加:
USBマスストレージ機能付きいないさんのえろす画像表示機の制作





20091114追加:
ねむいさんがついに重い腰をあげましたの巻

早く座らせてくれ

20091012追加:
電源IC壊れたけどヤクいさんのために気合いで直しましたの巻


20091008追加:
電源ICが壊れて涙目の巻


20091004追加:
STM32 Primer2を使用したアプリ"いないさんと遊ぼう(性的な意味で)"を追加



うー
オレンジのボタンを押して主電源を入れると"Welcome to STM32Primer2!"と喋ってくれ
ます。おお、なんかすげぇ!入力デバイスはおなじみMEMS加速度センサ、そしてPrimer1
には無い4方向キーパッドやタッチパネルなんかもついていたりします。
少し4方向キーパッドがおしづらいです。日本携帯ゲーム機に慣れている方は戸惑うかも〜


うー
タッチパネルはのほかにもペンタブの先っちょでも使えます。というか画面が小さいので、
ペン入力デバイスをペンタブ売ってるとこで買っといた方がいいでしょう。指でやるとすぐ
指紋だらけになるし。
画像はmp3を再生するアプリ。音質はそれなりです。


うー
裏蓋を外したところ。Primer1ではガバガバだった蓋はけっこうかっちり閉まるように
なってます。裏には拡張用コネクタ、リチウム電池、デバッグ用・アプリ用USBコネクタ、
ステレオジャック、MicroSDカードスロットなんかがついてます。カードは別売りです。


うー
基板のRevは1.1です。

うー
表蓋は木ネジで固定されています。結構固いです。壊さないように丁寧にはずしました。
基板表面には部品がいっぱいのってます(はしょるはしょる)。
……おや?何かリワークしたあとが…


うー
細いラインを太いジャンパで補強しています。グランドを強化してる感じです。これは…


調べるとこういう記述がありました。
うー
多分アートワーク設計の時にGNDをただのプルダウンと勘違いして細いライン引いちゃ
ったのでしょうね…それでインピーダンス上がって寄生インダクタンスが出来てしまって
共振して高電圧が出てレギュレータ壊したと…あれ?どっかで聞いたような…まぁいいや…
どっかの基板と違ってちゃんと対策されて出荷されているので安心して使用できます。


うー
むき出しの状態で使用してみる。タッチパネル液晶の発色がきれいですね〜。


うー
STN液晶のPrimer1と比べてみる…視野角が全然違いますね…さすがTFT液晶


うー
おまけ。Primer1の表蓋外したところです。ねむいさんはCQ-STARMだけでもひいこら
言ってるのでPrimer1,2で遊んでる余裕なんて無いと思います。他の方の応用例に
期待をしたいと思います!

この記事を書いて約1年後、時代はmbedを使ったクラウド環境の開発が栄えてしまい、
ふつーに使っただけで電源回路が破壊されるSTM32 Primer2とかすっかり情弱基板
扱いになってしまったのでしたorz

STM32(CQ-STARM基板)にFatFs乗っけてみる

20150331追:
"STM32 FatFs"でググってこのページに飛んでこられる方が非常に多いのですが、
現在では通用しない過去の情報となっております。
代わりに普遍的なもう少し切り込んだ内容のFatFsの実装事例を紹介しております
ので、こちらをご参照願います。
20150331追:















i2cキャラクタ液晶制御のためのシンプルi2cライブラリ群に少し修正を加えました。
ライブラリ作りの折、他の人の作例をいろいろ見てると同じデバイス動かすのにも
いろいろな流儀があるなぁととても感心してます。

んで修正はいいんだけど私の場合AVR,LPC2388,STM32,(まだ公開してないがAT91SAM)の
多岐にわたって作っちゃってるんで、(過去の記事いちいち修正して回るのは大変な
ので)ソースの公開方法をちょっと考えなおそうかと思ってます。
とりあえず今回"は"おきに誘導で…。(やっけつ)
来週1週間かけてリンク周りは大改装しておきます…。そして今回も異様に長い前振り…。






こっからが本題ですが今年4月ごろにMartin氏が、Chan氏作FatFsのSTM32への実装を
実現されています。私もこれに倣ってCQ-STARM基板で使えるように移植を試みました。

Martin氏と大きく違う部分は評価ボードが違うのと、RTCの処理にnewlibのtime関数群
使ったのとFWLibV3.1.0系なのとスタートアップとリンカスクリプトを私がいつも使ってるのに
してあるのくらいdけっこうおおいぢぁないかおい!
…まぁ詳しくは後で示すソース見てねということで(はしょるはしょる)。

そんなこんなで難なくFatFsが動いてます。ロングファイルネームも日本語ファイル名
も全く問題無しです。
うー
LFNとか使うとこのプログラムは90kb近く容量喰うのでDFU(12kb消費)使うこと考えると
残り26kb程しか余裕がありません。当然この状態からsprintfとか組み込むと容量オーバー
で使用不可になってしまうのでちょっと考えてプログラム組む必要があります…。
CQ-STARM基板で動くFatFsはこちらに。ご利用は自己責任で…。
FatFs実装を中心としたGCCプロジェクトを取り揃えております。

ここから出来ること…とりあえずOLEDで画像表示をやってみますか…

STM32(CQ-STARM基板)にV3.XX系のライブラリでFreeRTOSを移植する。

うー
買ってしまった…もう戻れない、太陽の牙ダg…もうええっちゅうねん

残念ながらCMSIS規格がおっ建つ前に原書が刊行されているので原書を忠実に
日本語訳したこれは、CMSISのことについてはまだシの字も触れられていません。
…まぁでも「ねむいさんてこんなことも知らないでCortex-M3弄ってきたのか」
なんて言われないためにも持っておかなければならないのです…たとえコヤシに
なろうとも…





話変わって、以前はLPC2388上でFreeRTOS動かしたー!なんて記事書いてましたが、
最新版のFreeRTOSV5.3.1ではgcc環境下でSTM32F107への移植されたデモが公開
されています。しかもCMSIS規格にのっとったV3.XX系のファームウエアライブラリで行われ
ていたので、機は熟したとばかりにSTM32F103VB6なチップが乗ったCQ-STARM
基板への移植を試みました。

とはいったものの移植というほどのたいそれたことやってなくて今あるファイルを
実装例に基づいて(STM32F107のデモのCrossWorksのプロジェクトの構成を真似て)
右を左にやっただけ。
リンカスクリプトも私が今まで使ってきたものがそのまま使用可能でした。
スタートアップファイルもFreeRTOSの流儀に合わせて関数を定義してやるだけで、
エラー無くビルドが通ってます。(Codesourcery/RaisonanceRIDEのビルド環境下)

肝心の動作の方ですが、LED点滅のタスクとprintf関数の出力をUart経由で吐かす
タスクだけの簡素なもので試したところ正常な動作を確認しました。
うー
うまく行った日はBeerがうまいぜHAHA!(タプタプ)
…今回のソースはこちらに…いつものことながら、試される場合は自己責任で〜…
※公開停止しました。ほしい人はメールください。
これ単体ではビルドできないのでFreeRTOSのソース本体を別途ダウンロード
しておいてください。



あと、もう知ってる方も多いと思いますが、PICマイコンで有名な後閑氏がFreeRTOSの
使用&移植方法などをまとめられています。
PICのみならず他のマイコンにもすぐに応用が効くようなとても分かりやすい内容に
なっているのでFreeRTOSを使われる方は必読です!

VCP(仮想COMポート)経由で標準関数使ってみる

今週の成果…塗り2枚、コラ2つ…まずまずかしら…
それとかなり目立ってきたけどRP中の寝堕ちだけはなんとかしなきゃいかんです。
スレのホストが告知せずに堕ちるってのは参加してくれた人たちにすごく失礼なこと
ですから…とにかく反省…。






話変わって本題…少し前にがた老氏がSTM32(CQ-STARM基板)にてダブル
バッファを用いたCDCのファームを公開されてましたので、私も試してみました。
氏のソースはV1.0のファームウエアライブラリを用いたものでしたが、私の
V3.0.xの環境に移植しても全く問題なく動いてます。
特に仮想COM経由の一文字入出力の関数が使いやすかったので、printf関数等
標準関数のリターゲットも容易に出来ました



と言うわけでそれを組み込んだ今回のソースはこちらに。※ほしい人はメールください。
UARTにリターゲットしてた時となるたけ似せるようにしてますが、COMポートを
開いたときの挙動が先にキーボードを打つ必要がある等少し違います。

他は、RTCの割り込み中の処理で、Vccが落ちてVbatのパワードメインだけで
動いている場合、2〜3日置いてVccを復活させると76時xx分xx秒とか
なってしまうおまぬけなバグを修正してます。
(修正と言ってもSTM32PrimerのRTCの処理真似しただけですが〜)
なにはともあれ先達の知恵達に感謝ですね。

STM32の基板にもRTCとこいんでんちいっこいれる

ゴトッ

来たわよ

これはUSBのJTAGデバイスの普及間違いなしですね〜
いい時代になったものです…私はもう作ったからいいや(しれっと




昨日はLPC2388の基板にRTCとバックアップ用の電池付けましたが、STM32にも
同じ事やってみました。STM32もLPC2388と同じくVbatでバックアップできる
独立したパワードメインがあるのでコイン電池一個でRTCを動かせます。


CQ-STARMはVbatはジャンパ抵抗で切り離せられるようになっているので
改造も楽ちんです(他のリワークがきついけど)。こんな感じで各部品を実装です。


RTCのプログラムのサンプル
は以前のstdioのライブラリ使ったprintf
のプログラムをベースにRTC部分の割り込みと、UARTの受信割り込みを足しこんで
昨日のLPC2388のプログラムになるべく似せるようにしてます。
(どっちかと言うとSTMのがオリジナルなんだけどまぁいいや)
自己責任でどうぞ。あと32.768KHzの水晶は必ずつけるように!

ARM7TDMIに並行してCortexも本格的に覚えようかしら…ブログで公開するに
当たって深いとこまでいじって来たけどなかなか面白い。




VCP(仮想COMポート)DEMOを動かす

SkyDriveにうpしたソースコードのファイルのURLが全部別のに
変更されていた!少し前に仕様が変わって10MB以下のファイルでも
直リン不可になってしまっていたらしいorz

人が見に来るようになる前にソースのダウンロード先だけは
確実に落とせるように変更しておきました。(←うつけ)
幸い画像の直リンはまだ出来るみたいだから画像の処置は様子見ですよぅ。




マイコン使って仮想COMポートを実現する…今ではいろんな手法があります。
tiny45などのAVR使って簡易なCDCなんかもできたりしていやはや
すごいな〜なんて。CQ-STARMに乗っかってる石にもUSBのインタフェ
ースがサポートされてるので当然のごとく仮想COMポート(以下VCP)の
デモなんか用意されてるわけですが…

これがなぁ…コンパイラのバージョンにシビアでコンパイルすら通らなか
ったり通ってもwarningわんさか出たりそれ潰してフラッシュしてUSBが認
識された!と喜んだのもつかの間ポート開いた瞬間に固まったりでもう一回
warningで出てたとこ穴のあくほど見て修正してやった開いた!と思ったら
今度は文字が送信出来てなくてもう一回ソースや海外の掲示板の投稿を穴
のあくほど見てまわりまわった挙句結局最適化のせいだとわかって修正し
てやっとこ使える代物になれたかなでも所詮はDEMOだと言ってしまえば
それで終わりですがそう言い切るのもなんだかな…あーつかれた。
いかんまた前振りが長い。

20110129追:
107系のUSB-OTGの物とソースを一本化し、なおかつエンドポイント3をダブルバッファリング
にしてさらに大量のデータを受信したときに取りこぼすバグを修正しました。こちらからどうぞ。

おソースはこちらです。USBライブラリV3.1.0のデモを適用してます。
上で長々と書いた私の無駄な努力が修正されています。
(どうやらV3.0.0でもまだ不具合あったみたいですねorz)
20101221追:
 今気づいたけどダブルバッファリング化して動作をさらに安定化させたverにふつー
 のバグ満載verを上書きした状態で放置してました。でもローカルのソースも破棄して
 残してないからもう修正できないやごめんね(テヘッ♥



でもこのV3.X.X系ってライブラリの構成が大幅に変わってますね。
調べてみるとこの規格に合わせたといったところでしょうか。
てかこれだいぶ前の情報じゃないか…。
ねむいさんの知識は断片的で非常に危ういです。日々お勉強はつづきます。


あと私が使いやすいように独自の修正加えてます(これまで
公開したのもほとんど私仕様にしちゃったけど)。"Nemui"でコードを
サーチすると何やってるか分かると思いますが、重要なのを一つ。

void Virtual_Com_Port_init()関数開始直後にあるGet_SerialNum();
をコメントアウトしてUSBシリアルナンバを"STM3210"固定にしてます。
どうもこの関数がとってくるユニークIDとやらがうまくシリアルナンバを
反映してくれない。他のUSBデバイスだとあまり気にならないのですがVCPは
COMポートが増設され、違うUSBポートにさすごとにどんどんCOMポートが
増殖していくのでシリアルを固定にしてそれを防がなくてはなりません。
(多分うまくやる方法があるんでしょうけどね、現状はこれで満足…)






以下ねむいさん流仮想COMポートの消し方(WinXP32bit用)
1.提供された仮想COMドライバにアンインストーラがあれば
  それを使用する。
2.1.が無い場合、
  環境変数に画像の変数を追加する
  変数名:DEVMGR_SHOW_NONPRESENT_DEVICES
  変数値:1
3.パソコンを再起動。
4.ファイル名を指定して実行で"COMPMGMT.MSC"と入力、実行。
5.「デバイスマネージャ」を選択し、ウインドウの表示(V)をクリック。
6.プルダウンメニューの「非表示のデバイスを表示」をクリック。
7.「デバイスマネージャ」-> ポート(COMとLPT)をクリックすると
  半透明のCOMポートが見える。不透明は現在物理的に繋がっているデバイス。
8.「削除」で憎いあいつを消す!これでCOMポートが消えます。

でも何度も言いますが提供された仮想COMドライバにアンインストーラが
あれば必ずそれを使用しましょうね。












9.たまにB.S.O.D.になって泣く

STM32にJTAG経由でDFUを書き込む

20121108追:
内容がものすごく古てもう実用に耐えない内容なのでこちらを参照してください。
STM32に限らず普遍的な内容を網羅してあります。








急に冷え込みましたね…えっくし
あの子は今寒さに凍えて体を冷やしていないだろうか…?
…温めてやれないのでしんぱいです。




ARM系のCPUでJTAG経由のフラッシュプログラミング方法なんて
巷にものすごく詳しく解説付きであふれてるので、ねむいさん的には
皆さんに全く参考にならない方法を紹介していきたいと思います。

20120517追:
レガシーポートを使用する方法はもうお勧めできません!


●レガシーなLPT経由の方法
私はM570RUのユーザーです。こいつにはLPTなんてレガシーなもの存在
しません。じゃぁどうやってやんだよ!というとExpressCard接続のLPT拡張ユニット
をつかってLPTポートを"物理的に"設けます。昔ながらのIOポート直叩きができます♥

認識されるとこんな感じ。しかし!エクスプレスカード=PCIExpress接続の拡張
LPTなので物理アドレスがいつもの0x378とかじゃなく0x3CD8とかへんてこりんな場所に
置かれます。もちろん0x378にアドレスの変更なんてできませんでしたorz
(物理アドレスもらえるだけマシだが…)

というわけで使えるアプリケーションは限られます。H-JTAGというJTAGサーバー
を提供するソフトは0x3CD8でも設定可能なのでこれが使えます。
LPT接続用のJTAGインターフェースの回路図はこちら。Wiggler互換です。
なんでJTAGのコネクタをわざわざ10Pinから20Pinに変換してるのかというと、
AVRJTAGICE/JTAGICE mk2とALTERAのJTAGインターフェースがこの10Pinの配列で、
ねむいさん的にはこれを基準としてすべての制作物を合わせているからです。
ARMしか使わない人は元から20Pinでいくか各自のやりやすい配置で行きましょう。

H-JTAGの基本設定はこんな 感じに してください。
実はWiggler互換じゃなくてもLPTにつながりゃ何でも行ける。
Coretx-M3専用のTAPコントローラの設定は必ず行うこと。
そして難なく認識
書き込み消去もほとんどストレスなくサクサク行けます。


話変わりますが、なひたふ氏のMITOUJTAG評価版0.31&トラ技特別版は
上記の拡張LPTは一切使用不可でした。0x378,0x3BC,0x278の物理アドレス
しかサポートしてないみたいです。残念。(まぁ評価版だし…)
ちなみにlinuxのioperm()関数とかもサポートするアドレスの範囲が
0x3ffまでなのでそれ使ってる直叩き出来るアプリも全滅。全アドレスに
使えるiopl()関数に適宜書き替えてやる必要性があります。



●USB(JTAGkey互換回路)経由の方法
アマチュアのARM開発ではこちらが今現在最もポピュラーな方法ですね〜。
私のM570RUでもこれならスマートかつ無問題です。
(なぜかM570RUは物理COMポートがある。Linuxのデバッグ出力用だろうか?)。

先にも紹介しましたJTAGkey互換回路はかみき氏のものを流用させてもらって
います。扱える電源電圧範囲が1.65V〜5Vとだだっ広いです。
+5Vトレラントな2電源レベルシフタのおかげなのですが、JTAGkey単体の評価や
レベルシフタの実力は別件で測ってますのでまた後ほどにでも。

また、かみき氏の回路にAT93C66Aの外付けEEPROM回路をさらに追加して、
Amontec JTAG keyと全く同じVIDとPIDにしています。EEPROMの設定を含めた
ドライバファイルはこちらに
MProg書き込んでください。


STM32基板との接続も最もポピュラーな構成を流用しています。
STM32(というかARM全般)--JTAGkey互換(FT2232レイヤ)--OpenOCD(server)という
つなげ方です。

20120517追:
OpenOCDを使用したフラッシュの書き込みはこちらを参照にしてください。




前振り長くなりましたが、DFU(DeviceFirmWare)をJTAGkey互換回路で
STM32に書いてみます。今回のおソースはこちら。最新のSTM32-USBファーム
ウエアライブラリ
とDFUのデモソフトウエアを適用してます。わかっているとは
思いますけど試される時は自己責任でよろしくお願いします。
開始アドレスは0x08000000固定です。makefike内で0x08003000開始も設定
できますけど当然動きません。気を付けてください。

新しいDFUをJTAG経由で書きこんで見ます。成功したときのログは
以下のようになります。STM32はJTAGデバイスが2つ見えます。


> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd-ftd2xx -f interface/jtagkey.cfg -f target/stm32_flash.cfg -c "flasher main.elf" -c "resume" -c shutdown
Open On-Chip Debugger 0.2.0-in-development (2009-05-09-21:00) svn:1606M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS

500 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Info : JTAG Tap/device matched
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Info : JTAG Tap/device matched
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000ed8
Info : device id = 0x20016410
Info : flash size = 128kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 8508 byte from file main.elf in 0.640630s (12.969411 kb/s)
verified 8508 bytes in 0.437502s
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Info : JTAG Tap/device matched

> Process Exit Code: 0
> Time Taken: 00:05

DFUが正しく書きこまれていれば、DFUseを起動するとこの画面が見えるはずです。

これでJTAGさえあればDFU書き潰して0x08000000でスタートするプログラム
書きこんでも大丈夫ですね。…と言いたいところですが!
STM32のコアクロックが停止する__WFI命令等を実行しっぱなしの
プログラムを不用意に書きこんでしまうと起動->__WFIでクロック停止->JTAG
インターフェースも仲良くおだんまりとなってJTAG経由のアクセスが
一切できなくなってしまいます!

これを回復するには先日紹介したシステムメモリからのブートでシリアル
経由でフラッシュの消去を一旦行うか、リセットボタン連打しながらJTAG経由で
うまく引っかかるまでひたすら消去動作を行い続ける方法があります
(ファミコンの裏ワザみたいだ)。私としては後者前者の方法を強く強くお勧めします。

STM32のフラッシュプログラミング

当記事の内容はもう古すぎるのでこちらを参照してください。





…あづい…あづいですね…まだ5月なのに〜…
まぁおかげでバイト帰りのいなちゃんの汗n





CQ-STARMは最初からUSB経由でファームウエアのアップロードができる
DFUというプログラムが書きこまれているため、外部のプログラマーが
必要ないのが特徴です。

その代り、開発に際してプログラム開始位置は0x08000000->0x08003000
からになる。という制約を受けます。
DFUを使用してアプリケーションを作るときは、0x08003000からプログラムが
スタートするように考慮しなければなりません。DFUのプログラムは
0x08003000に決め打ちですっ飛んで行きますので。
(この辺AVRだと楽なんですよね〜、ブート領域がメモリの後方にあって
ヒューズビットでいつでもスイッチできるからアプリの方はプログラム
メモリ容量以外は何も考えなくていいという)

考慮の方法は以下の2点です。
1.ソースコード内の割り込みベクタのアドレスを
0x08000000->0x08003000にする。
2.リンカスクリプト内のスタートアドレスを
0x08000000->0x08003000にする。
デバッグはDFU経由で書いて本ちゃんはまっさらからスタートしたい、
もしくはDFUなんていらんという人もいるでしょう。そういう時こんなの
いちいち書き変えてたらめんどいのでmakefileの記述で一発で切り替え
できるようにしちゃいましょう。

1.の部分、こんな感じで
2.の部分、ここをこうして
最後にmakeで切り替えられるようにする

と後あと楽です。ケアレスミスもなくなりますし。
以前のMassStorageClassDemoにもこれを適用していますので詳しくはこちらをご参照ください。
(RAMスタートの記述も形だけあるけど未サポートです。)

ちなみにCQ-STARMでDFUを使う場合、USBディスコネクトの回路を追加して
いると「Leave DFU mode」が正しく動くようになります…ってこれが当たり前か。
DFUなぞ使わないという人にはJTAGで書く方法とシリアルで書く方法が
あります。今回はシリアルで書く方法を紹介します。JTAGは次回にでも。

STM32はオンチップフラッシュROM、オンチップSRAM、オンチップのシステム
メモリの3種のブートモードをサポートしていて,DFUや通常のアプリは
フラッシュROM、RAMスタート時はオンチップSRAM、そしてSERIAL経由で
STM32のフラッシュを書き換えたい時はシステムメモリからの起動を選択できます。

JTAGあるしシリアルなんていらんジャンなんていう人もいると思いますが、
変なプログラムを書きこんでしまってJTAGが一切アクセス不可能に陥った
場合、強力な回復手段となるので、このモードがあるというくらいは
覚えておいてくださいね。

私はフラッシュ、システムメモリの2つのブートモードが選択できる
ように拡張基板にタクトスイッチを追加しました。どことどこを繋ぐかはこんなかんじで
シリアルは、USB-SERIAL変換のICしか使う気がないのでレベル変換かまさ
ずにTTLレベルのままで置いときました。
USB-SERIALのユニットはCP2102使って、TTLレベルでRxD,TxD,GNDの3つだけ
しか使わない凄く小さいのを
一つ作っておくと使い回しが効いて楽です。

用意ができたらBOOT0をVCCに吊ったままリセットを解除してシステムメモリ
からの起動を行います。その後PCにインストールしたFlashLoaderDemonstratorを起動します。USB-SERIALが繋がってる仮想COMポートを選択し、正常に通信ができていれば
こういう画面になります。そっからはフラッシュを消したり読んだり
書き替えたりプロテクト掛けたりと自由自在です。
CQ-STARMを仮想COMポートに化かしてももちろん行けます。基板2つもってる人は
一方を仮想COMポートにして試してみるよいでしょう。



おっと言い忘れてた、毎度毎度のことですが、自己責任でどうぞ!

MassStorageClass DEMOを動かす

最近工作ものばっかに手を取られて本業の二次裏メイド業が
おろそかになってる私。下描きでほったらかしているいないさんの絵が
早く仕上げてと訴えている。もうちょっと待っててね♥




さて本題、てDWM誌2008年5月号の付属基板と同梱のCDには
DFU経由でCQ-STARM基板に書き込みができるように
いくつかのデモがすぐに使えるようにとdfuファイル形式で
入っていました。しかし、紙面の説明がとても乏しく、そのとおりに
やっても動かない云々の意見と(その対策)が出ていたのは
みなさんご承知のとおりと思います。

この同梱されたdfuファイルというのはCQ-STARM向けではなく
STマイクロが提供する評価キットSTM3210B-EVAL/STM3210E-EVAL
向けのものです。

CQ-STARMはSTM3210B-EVALの回路構成を真似て設計されており、
STM3210B-EVAL向けのdfuデモファイル群も一応動くのですが、
その中でMassStorageClassの奴をそのまま使ってしまうと
ちょっとまずいことが起こります。

CQ-STARM上ではSDカードを挿入したときに必ずLになるポート
が出力になっており、ショートしてCPUおよびSDカードに
ダメージが行きます。どうなってるかはここ見てくださいね。
この件も私が見つけたわけではなく、去年すでに騒がれたこと
なのですが、忘れ去られた頃に新たにCQ-STARMに触る人がいる
かもしれないから書き残しておきます。


以下私が行ったわーくあらうんど。
●ソフトウエア
 初期のデモでは確かSTM3210B-EVAL上のLED4つが同時点灯するという
 コードのようでしたがV3.0.0/V3.0.1のデモコード見ると最小限のLEDのポートが
 出力になるようになってました。前回のコードはV3.0.0を適用してあるので
 そっちを使ってもらえればいいかなと思います。
 LEDの出力もCQ-STARMに合わせて変えてます。でも下のパタンカットは必須ですよ!

●ハードウエア
 STM3210B-EVALは本来MicroSD搭載なのでライトプロテクトと挿入検知は
 存在しない。だからここにつながるパタンいらないからカット!
 こんな感じで

ついでだから他の便利な改造も基板に施してますので紹介します。

●USBディスコネクト
 USBのデモにはRESETをかけるとUSBが切り離される"USBディスコネクト"
 のコードが含まれているのですが、CQ-STARMはハード的に駆動させるための回路
 が存在しません。したがってDFUで書いてはUSBケーブル抜きを繰り返す
 必要があり非常にめどいです。だからこの部分を追加。
 具体的な改造はこんな感じ。パタンカットもなくビアとポリイミド
 テープを駆使してなんなく達成。これでUSB-miniBコネクタが激しい抜き差しで
 ガバガバマ●コイになるのを避けられます。


●加速度センサにコンデンサ追加
 加速度センサ周りに10uFのチップセラコンと1nFのチップセラコンを追加する。
 これは加速度センサの指示ですね。つうか本来はじっそうすべきなのですがなぜか
 この基板を設計した人はそれを無視して動作不安定になるような回路設計を
 してらっしゃいます。

 10uFのチップセラコンは+3.3V系以下の系では秋月のこれを愛用してます。
 こいつは2012サイズなのに大容量でかつ静電容量変化率も少ないので、
 セラミックコンデンサ対応のLDOとも相性バッチリです。
 
 1nFのチップセラコンは1608のをビアと近接のGNDパタンはがして実装。
 10uFの方は元の1uFは一旦どいてもらってポリイミドでガードした上
 に仲良く同居。こんな感じで



使ってみた感じですが、わたしの手持ちの256Mb,512MB,1GB,2GBはすべて
Windows上のディスクドライブとして認識、読み書きもできました。
残念ながらSDHCはファームウエアで対応しておらず認識できないようです。

開発環境を整える(自分流に)

今日は日が照って暑いですね〜。私はここぞとばかりに押し入れにしまってた
夏服をひっぱりだして片っ端から洗濯していました。もう夏は目の前です。


それはおいといてネット上ではGCC+Eclipseを用いて無償でできる
ARM開発環境の構築法がすでに一般的に広まっていますね。
私もタd…GCC派ですがEclipseは使わず自分流の環境をおっ立ててやってます。
…うn、使いこなすまでのあれやこれやの設定とかがめどかっただけなんだ…。


20110728追:ビルド方法はこちらに誘導します


雑誌付録基板CQ-STARM(STM32)

去年、同基板の幾つかのサンプルをGNU Cにポーティングしてそれっきりに
していましたが、がた老氏が同基板で奮戦されているのに感化されて私も過去に
やってきたことを残すことにしました。


とりあえずマイコン工作基本の'き'であるLEDチカチカから始めてみましょう。
私はARMの開発環境としてRaisonanceのRIDEをインストールしてます。
実際RIDEも中身は「Codesourcery G++ lite for ARM」のツールチェインなんで
CodeSourceryでやってる人はそっちでも行けます。


プログラムはこちら。自己責任でどうぞ。
※ソースコードほしい方はめーるくだち

Martin Thomas氏のLED点滅プログラムをベースにSTM32の最新のファームウエア
ライブラリ
を組み込んでSTM32基板に対応したものを作りました。
printf,sprintf等の標準関数を正常に動かすためにRaisonance付属のリンカスクリプトや
その他もろもろをいじりまくりです。
この辺は長くなるのでまた改めて説明します。とりあえず動かす!

…今Martin氏のページ見にいったらChanさんのFATFS乗っけた作例を
アップデートされてますね〜。試してみたいが時間が…

いなちゃんかわかわ

思うところあって私もブログ始めてみました〜。
虹裏メイドな私ですがジャンルは技術系で
攻めてみよう か な と思います…。


STM32-Primer
↑とりあえずSTM32Primer使っていなちゃんを写してみる
…はぁ〜…やっぱりかわいいなぁ♥♥

…いいのかいきなりこんなんで

Go to top of page