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

Go to top of page