いろいろ試す27

ああ・・・2016年が終わってしまう・・・
今年は年始から本業副業合わせてやばい系のばっかリに絡まれまくりましたよぅ
(※本業は虹裏メイド)

●OpenOCDがビルドできなくなる
これホントはOpenOCD小ネタ扱いですけど小過ぎてここでやります。
12月上旬の更新で"Convert to non-recursive make"という更新が掛かりそれに伴って
Automakeのバージョンもあげる必要性が出てきました。
しかしmsysのビルド済みバイナリは数年前に更新停止ししていて結局全部一からビルド
するハメに!!ねむいさんの環境では結局以下の3点の最新化が必要でした。
・automake-1.15
・pkg-config-0.29.1
・libtool-2.4.6


これでOpenOCDをはじめ他のライブラリやライタプログラムにも悪影響がないを確認
しましたので当面は大丈夫だと思います☆
・・・また数年したらこう言う相違の問題出てくるんだろうなと考えると気が重いです。


●DropBoxがPublicフォルダを廃止し強制的にプライベート化する
ねむいさんのぶろぐの画像保管庫として機能しているDropboxからメールがあり、来年
3月15日でPublicフォルダ(有料ユーザーも7月15日で)強制廃止するよ!というふざけた
内容の文章が来やがりました#########

Publicフォルダというのは直リンクが可能なDropboxの特殊フォルダで、ぶろぐで画像
サーバとして使うのにはうってつけだったのですが・・・便利ゆえに児童ポルノなどの
やり取りに頻繁に使われまくったせいか規制されてしまったようですクソァ!!!
公式の掲示板でも異を唱えたまっとうな使い方をしている人たち(有料ユーザー含む)が
いましたが粛々と無言で粛清されていくさまを目の当たりにしねむいさんは今後の
画像置き場とにかくどうするかしらと悩んでおりました。
と、そこにとある方のツイートによって一手間掛かりますけど直リンが可能な方法が
あるのが分かり今後はそちらの方法でDropboxを使い続けることにしました。
(やはり真姫ちゃんは有能・・・)

ねむいさん的な使い方はCarotDAVと連動して使う方法で行きます。

まずCarotDAVを使って前もってDropBoxの非共有の個人フォルダにアップロードします。
ここで共有化したいファイルをドラッグして選択し右クリックで"Create Shared Link"
を選びます。確認ダイヤログでOKを押して少し待つと共有リンクのURLがずらずらっ
と出てきます。

あとは末尾の"?dl=0"の部分を"?raw=1"に変えれば以前と同じ感覚でぶろぐに画像
として表示が出来るようになります。CarotDAVではこのように一括で共有リングが
作成できるのでねむいさん的使い方する方にとってもオススメです!

ただ方法は純粋な直リンではなく一旦エンコードを噛ましています。そのせいで今度は
FaceBookに自分のぶろぐを紹介する時にOGPがエラーとなって弾かれてしまいました。
こちらですが現在はぶろぐのヘッダに以下のメタタグを埋め込み固定の画像を拾わ
せるようにして対処してます。↓こんな奴です。




FaceBookからはこう言う風に見えます。


とりあえずこれでPublicフォルダ廃止後の新規ぶろぐエントリの画像問題は解消され
ましたが・・・問題は過去5年間、数千枚に及ぶ大量の画像のURLの変更だ・・・
orz


●Naverまとめの所業に憤慨す
現在Naverをはじめ、「キュレーション」なる単語で言葉を濁し実際は無断転載でコンテ
ンツをパクり広告収入で儲けるという企業の行為が社会的な問題となっております。

猫にコ・ン・バ・ン・ワ」の管理者のたま吉さんが自身の記事をNaverまとめに無断
転載されていたことで大変怒っておられ、その顛末を記事にされております
私もそれを受けてパクられてないか調べてみると私もやっぱりパクられてました。
しかも直接関係ない別の人の記事に私の画像が添付されてます!!!!!!!


パク

ラレ
パクられた箇所の一部をトレパクスレ風にやってみました★

超めどいですが年の瀬も迫る中早速Naverに攻勢を仕掛けました。南朝鮮企業のNaverが
普通の言伝で簡単に削除対応するわけが無いのは分かりきっていたので、逃れられない
証拠を突きつけた上で期限内に対応しない場合は内容証明郵便を送りつけ、それでも
応じない場合は簡易訴訟を起こす手立てで親父と相談し作戦を実行しました!1!!

・・・が、ねむいさんの徹底抗戦の意思とは裏腹にNaverがあっさりぱくったことを認め
パクったと指摘した箇所を秒速全削除。一週間も掛からぬうちに勝負はついた。

SDカードの一件でみなさんご存知とは思いますがねむいさんのぶろぐでも各ライセン
シーについてはもっっっっっっっのすごく気を使うようになっており、自身が取り扱う
ぶろぐ記事や写真につきましても当ぶろぐ立ち上げ時からCreative Commonsの非商用
掲げております。そういった姿勢が相手に「こいつはやばい奴だ」と思われてすぐさま
パージする方向に傾いたのでしょう。

しかしながらNaverはその一方で冒頭のたま吉さんに対しては著作権侵害を認めておら
ず(たま吉さんはねむいさんとは比べ物にならない量をパクられているのに係わらず)
態度に一貫性がまったく見られず極めて不信感が感じられます。
「こいつらはいつもこんなもの(だからこれ以上追求するな見過ごせ)」で済ませるとたとえ
Naverまとめが今回の問題で閉鎖したとしても暖簾替えて同じことやるのは1000%確実
なので今のウチに根治しないといけませんね・・・(使命感)

というわけでこの件に関する公の発言はここで一旦〆ます・・・が、以後は裏で暗躍して
みようと思います
。これから先、もし事態が良い方向に向かったらねむいさんや他の
有志の方ががんばったおかげかもしれませんよ★




あと気になる事ですが今年に入ってから不自然な内容の質問もどきを多く伺うように
なっています。名前も「ななし」とか「匿名希望」とか適当で、なおかつ質問内容は異口
同音に「オマエが持ってる(ぶろぐに書いてない)情報あるだけゼンブヨコセ」。
で、ねむいさんも相手の質問内容や文体の癖を注意深く調べぐぐるとアマゾンアフィや
グーグルアドセンス等のアフィ大盛りのはてなorFC2orライブドア系の広告収入特化型で
技術的価値が殆ど無い内容の薄い質問者と思われるブログに行き着いたりします。

ねむいさんとしましてはねむいさんのぶろぐ上で公表した事はいくらでも"参考(←転
載じゃないよ)"してもらってもかまわないというスタンスですが直接応対する案件は
内容の如何によっては対価を頂くようにしてます(それ言ったとたんに相手の反応が
いつもゼEROになっちゃうんですけど)

んでもってねむいさんもだいぶ痛い目にあってきましたので聞いてくる人の素性は必ず
調べてから対応するようにしています。それでもねむいさんを利用してやろうと考えて
らっしゃる傾き者は伊達にしてお帰ししますので覚悟するでござる(若先生風に)


●Launchpad ARM-GCCの各種バイナリがARM本家預かりになる!
今期のアップデートからLaunchpadで公開されていたARM向けGCCツールチェイン各種が
なんとARM本家から装いも新たに堂々と公開される運びになりました
ARMを買収した禿がこんな粋な計らいするわけないのでARM内の別の人たちの発案でし
ょうけど。

そしてGCCのバージョンは6.2.1にアップしております!
地味にオプション表もアップデートしていますので見逃さないように!


まずは同一条件でビルドした時のバイナリサイズ比較
新:2016q4版(GCC6.2.1)
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_RK043FN48H_RGB_TFT
USING_DEVBOARD = USE_STM32746G_DISCOVERY

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 721292 0 721292 b018c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
718700 2592 822180 1543472 178d30 main.elf

旧:2016q3版(GCC5.4.1)
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_RK043FN48H_RGB_TFT
USING_DEVBOARD = USE_STM32746G_DISCOVERY

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 726736 0 726736 b16d0 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
724148 2588 822188 1548924 17a27c main.elf

GCC6.2.1版のほうが5kByte近く小さくなってますね〜



お次はjpegファイルのデコード速度比較!!
ぁ・・・ちょっとだけ遅くなってる・・・
・・・
・・・
まっいっか!


ついでにProgrammers Notepad2も4年ぶりくらいにアップデートしております。
ねむいさんの環境構築手順ではほぼ影響は無いのでそのまま差し替えてお使いいた
だけますのでまだの方はアップデートしておきましょう!

20170108追:
ちゃんと新規追加されたオプションつけろよバカヤロコノヤロと突っ込みもらいましたので
付けた奴で再比較します!
1.「-mslow-flash-data」を付与
このオプションはフラッシュメモリのアクセスが遅いMCUにおいてリテラルプールを極力
行わないようにするものです。Cortes-M3/M4のみ有効でldr系の命令がmovw+movtに
なるべく置き換えられます。
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_RK043FN48H_RGB_TFT
USING_DEVBOARD = USE_STM32746G_DISCOVERY

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 727908 0 727908 b1b64 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
725316 2592 822180 1550088 17a708 main.elf
コードサイズはかなり増えてしまいました。

遅くなってるー!?ダメじゃん!
このオプションはSTM32F1/F2/F4系だと有用だったのですけどアーキが一新され、
キャッシュが追加されたM7系では相性が悪いようです。

2.「-mpure-code」を付与
前回のGCC5.4.1から追加されておりますがGCC6系から真価を発揮するそうです。
このオプションは定数値をコードセクションに置かないようにするものでリテラルプールは
当然ながら全排除、ジャンプテーブルもldrを使用しないよう徹底されます。
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_RK043FN48H_RGB_TFT
USING_DEVBOARD = USE_STM32746G_DISCOVERY

Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 726884 0 726884 b1764 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
724292 2592 822180 1549064 17a308 main.elf
GCC5.4.1のオプション追加無しと比べると少しコードサイズが減りました。

おおっ!結構早くなってる!!!
これはイケてますね〜♥
とりあえず後方互換性の事も考えてmakefileでは"-mpure-code"はまだ無効のまま
としておきますが2017年中旬以降は積極的に有効にしていきたいと思います!
ちなみに-mslow-flash-dataと-mpure-codeを同時に有効にすると-mpure-codeが
優先的に働き-mslow-flash-dataは実質上無意味になります。



●複数スレッドでmakeのスピードアップ!
STM32F4STM32F7いつものはさまざまなライブラリが混在していてビルドしあがる
のにやたら時間がかかります。現在は複数スレッドでmakeを走らせるのでが当たり前に
なっているので私もちゃれんぢしてみました。

複数スレッドのmakeはそれに適応したmakefileの書き方をしなければならずねむい
さんのmakefileでは普通に-j2オプションつけたら最後のリンク段階でこけますorz

仕方が無いのでmakeを入れ子にしてオブジェクトが出来上がる段階まではj2でビルド
するようにしました。入れ子にする場合は「XXディレクトリから入ります出ます」のメッ
セージが鬱陶しすぎるので"--no-print-directory"オプションも付与しております。


おおっ!同時にビルドが走ってる!!



-j1と-j2の速度比較です。-j2はめっちゃ早くなってますね!
スレッド数はCPUコアの数と同じが丁度効率が良いそうですがうっかり数字をつけずに
-jとしてしまうと大変な事になってしまうので皆様試してみたください



うっかりやってしまったorz




●年末恒例ねむいさんFAQ
今年はやばいのしか来ないと言ってましたがぶろぐでも公開できないマジで
やばいのは個別に処理しましたので例年通り虹裏における活動時や当ぶろぐに
きた中から当たり障りの無い方のやばい系の質問について公開回答いたします。


Q:mbedを使っているのですが!?シリアル通信が上手く出来ないのですか!?
 これはどういうことでしょうか!?ちょうさをおねがいます(←原文ママ)!
 それと液晶プログラムを動かしたいのですがどのファイルをさしているのか!
 初心者がわかる文章で希望します!
A:無理して日本語使わなくていいから人間の言葉しゃべってください!
 mbedって!対象が増えすぎてどのmbedかわからないんですけど!
 ねむいさんに分かる文章で希望します!
 ぁれれ・・・文体が感染してしまった・・・

 まじれすしますがねむいさんArduinoとかmbedとか難しすぎてまったく
 分かりません><

 それと液晶のライブラリに関してはこちらのエントリをちょっとだけ
 補修しましたのでとりあえずお目当ての初期化の呪文にはたどり着けると
 おもいます。章仁さんにも紹介していただきました

Q:(GNUARMECLIPSEのOpenOCDバイナリを使った上で)ねむいさんのバイナリを
 使うとOpenOCDが正しく動きません。これはどういうことでしょうか?
A:・・・ろすぞ!!!
 ゲフンゲフフンすみません物騒な物言いになりましたがねむいさんがあずかり
 知らない他所ビルドのOpenOCDバイナリを使ってエラーがでてもねむいさんは
 一切対処いたしませんし助け舟も出しません。嘘言ってねむいさんと同じの
 使ってる!って言ってもすぐにバレますよ!

Q:(中華製ぱちもんJ-Link使った上で)ねむいさんのバイナリを使うとOpenOCDが
 正しく動きません。しかも弄ってるうちにJLinkが動作しなくなりました
 しっかりしてくださいよ(めっちゃえらそうな口調で)
A:・・・ろすぞ!!!!!!!!!!
 もうね、昨年からずっとだけどJ-Linkとkinetis関連は対人トラブルの元だから
 ご意見無用にしたいと思います###今はぱちもん使ってると突如brickedする
 トラップがSegger側からされてるんですけど詳細はねむいさんも言いま
 せんから!!あと詳細は言いませんけどOpenOCDでもぱちもんだと動かない
 やつあるからバレますよぅ!

Q:小生は(極めて性的な内容なので略)
 少ない年金ですがねむいさんにお小遣いくらいはあげられるとおもいます
 それではよろしく。
A:・・・(やべぇぞこれマジでやばい)
 というわけでねむいさん気持ち悪すぎて答えたくないのでこの件に関して
 年齢が近そうなねむいさんの親父からのスペシャルコメントです
 「俺の歳で再婚するなら20代の元気な女の子がいいなぁ〜」
 ねむいさんよりコメント:お母ちゃんに呪われてしまえ!!!1!!!!

Q:手軽に高収入!アフェリエイトを始めてみませんか!?
A:帰れや!!11!!!!
 この手の変な情報商材詐欺勧誘が今年に入って爆発的に増加しています!!!
 
 ・・・しまった真面目に答えてしまった。

Q:ラブライブ!の東條希さんを描いて下さい
A:ねむいさんがあんまり知らんキャラ(2016年1月上旬当時)の話を
 分かっていながらあえて無茶振りする子は
 オ シ オ キ ヤ カ ラ ♥
↑良く分からなかったのでゼERO見ながら描いた

Q:ラブライブ!サンシャイン!!の黒澤ダイヤ様を描いて下さい
A:・・・ダイ煮よ♡♡♡♡
↑なんか知らないけど別の方に私の手描きをブラッシュアップされて
  しまいました。ハートマークが敷き詰められてこれは・・・♡

  ・・・・おかわりがほしいですって!?まったく・・・貴女は本当にしかたのない娘ね♡♡♡♡

Q:ねむいさんこんにちはいつもブログを拝見させております。
 今回のねむいさんのエントリにてラブライブメチャシコ画像集なる
 とても興味を引く動画が紹介されており期待に胸と股間を膨らませて
 再生ボタンを押したのですが再生が始まったとたんに突然青色の
 ロボットが現れて尻をこっちに向けイチジク浣腸を自ら刺してで
 てきたカレーライスを何度も食しては不味いだのふざけるなだの一々
 偉そうに注文をつけて助けに来た仲間のロボットにも浣腸を刺して
 でてきたカレーライスに今度はうまいと言って満足したのが勝手に
 自爆して動画が終了してしまったのですが多分ねむいさんが想定
 していたものと違う動画でしょうか?僕は一体どうしたらいいので
 しょうか???今回は桁違いにやばいのでとか動画の中で警告
 されても今更どうしようもないじゃないですか!
A:お前は・・・イレギュラーだ・・・処分する!!

Q:オマパンとか言う気が狂った異常な概念がmayで流行ってますけど
 ああいうの喜んでワーオ!とか言ってる連中って絶対頭おかしいと思います。
A:ワーォ!





来年は本当のホントに真面目にがむばります!!!!
それでは皆様良いお年を〜

いろいろ試す26

今回SDカード中心です。


●ついに発見!Transcendの4GBのSDカード

当初SDHCをつかまされてしまった私ですがSDコンパチブルな奴をついに見つけ出し
ました!!というかebayで新たに発売開始(???)されていました!


SDHC版と比較…ものすごく似てるけど色が微妙に違う…知らなかったこんなの…

一応SDカードの情報を抜き出してみました(あえてSDv1による初期化です)。

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

CSD:
00000000 00 0E 00 32 5B 5B 03 B6 9D B7 FF 80 0A C0 00 21 ...2[[.........!
CID:
00000000 74 4A 45 53 44 43 20 20 10 3C D5 6B 7B 00 08 AB tJESDC .<.k{...

Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :JE
Product Name :SDC
Product HwRev :1
Product SwRev :0
Serial Number :0x3CD56B7B
DateCode.Month :8
DateCode.Year :2000

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 20 03 03 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 0F 17 00 04 00 00 20 00 00 00 00 00 00 00 ........ .......
SCR:
00000000 02 25 80 00 00 00 00 00 .%......

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!

製造年月が2000年とかなってますけど思い切り嘘ですね。2016年産でから。
一応製造元はTranscendの製造協力会社のものになっており真贋の方は分かりかね
ますが…一応PC上で容量チェックを行った所、4GB分正しく読み書きが可能でした。

SDHCだった方のカード情報はこんな感じです。

FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Nov 7 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21688 kB/sec.
>ds 0
rc=0
Drive size: 7812096 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 CC 7F 80 0A 40 00 D5 @..2_Y.......@..
CID:
00000000 1C 53 56 53 44 43 20 20 10 01 D2 00 BC 00 82 DB .SVSDC ........

Parsing SD CID Register
Manufacturer ID :0x1C
OEM/Application ID :SV
Product Name :SDC
Product HwRev :1
Product SwRev :0
Serial Number :0x01D200BC
DateCode.Month :2
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!

れっきとしたTranscendの奴ですね。

ちなみに読み出し速度は圧倒的にSDHC版の奴の方が上でしたorz


このSDコンパチブルなTranscendのはSDv1の初期化でバイトアクセスとなり、SDv2の
初期化ではブロックアクセスとなりました。この辺以前紹介した4GBカードたちと同じ
ですね。(ていうか同一の会社がガワだけ別で中身同じの作ってそうです・・・。)


そしてそのうちの前回紹介した4GBのドイツカードなのですが端子の埃をふき飛ば
そうとエアダスターを吹き込んだからカードのプラスティックの隙間に圧縮空気が
入り込み、内部から分解してしまいましたorz貴重な4GBカードがッ…!!!


とりあえず分解して荼毘に付しました。基板がこんなにペナッペナです。工業用の
堅牢な奴に比べて明らかに強度的に弱いですね。値段も安価なのでいたしかたなし
なのですけど。




●CMD1の初期化はどのカードまで可能なのか!?
12月頭にCMD1による初期化がSDカードのライセンスの影響を避けるために必要だ
えらそうに言ってしまいましたので今回は実際にCMD1のカードで初期化が通るん
かいな?という疑問を実際に動作させて検証していきたいと思います。


使用するカードは256MB〜4GB(SDHCじゃない奴)までの容量のSDカードです。
これは春先にひたすら読み込みまくった時の連中をセレクトです。


前回同様STM32F4-DiscoveryのSPI互換モードでSDにアクセスするほうのいつものを
使い、ChaN師謹製の初期化ルーチンからCMD1による初期化のみ残したプログラムを
動作させてファイラーが起動してディレクトリが見えたら初期化成功とします。

結果ですがATPProMAX 1GBのminiSDを除きすべてCMD1による初期化が成功しました!
もちろん成功したカードの中には冒頭で紹介したSDこんぱちなTranscendの4GBの
カードも含まれております。


もちろん2016年製造のPanasonicの工業用SDカードもCMD1の初期化が通ってます!
こいつはCMD8の初期化も通るんですよね〜。CMD8で通っても4GB以下なのでバイト
アクセスになります。

ちなみに私が持っているeMMCはSPIモードが既に削除されている品種のため、どう
がんばってもSPIモードに突入することができずだめでした。SDカードと同一の形状を
保って方のいるMMCplusなどのv4系カードなら問題無いです。


お次はネイティブモードでCMD1の初期化だけを残した奴を試してみましたが…。
・・・
結果は全滅orz

Argumentとか0にして見ましたが何してもどのカードでもタイムアウトで全滅ですorz
ネイティブモードだとCMD1は通らないのか!?

答えはSDIO Specificationに有りました。以下13ページ目のフローチャートを抜粋。


・・・
ネイティブモードが相手ならMMCの例外な実装によってSDカードがたまたま
偶然に動作せざるを得ない!11!!1(CV:リョウ・サカザキ)




♥ねむいさんのおまとめ♥
電子工作においては現在も入手可能な4GB以下のSDカードに対してSPI互換モードで
CMD1による初期化のみでカードを動作させることは十分可能であり、この方法ならば
SDAのライセンシーにも全く抵触しません。

CMD1が確実に通るカードの中でねむいさんの激押しは
TOPRAM製4GB
ドイツ製4GB
Transcend4GB
この3種の4GBカードです!値段も安いですし4GBもあれば十分でしょー

それ以外の方法(SDネイティブモードによるアクセス、もしくはSDHC/SDXCカードを
使う)をどうしても施行したい場合はソースコード中にMMCが実際に動作できるCMD1
による初期化を残しつつMMCまたは互換カードの例外的な実装によってたまたま動作
しているように見せかけてあげればよいと思います。よくない。




●SD Specfication Version5のカード

テレッテレッテーテッテー テレレレレッテー(テュィーーーン)

V!V!V!
もういいわ

2000円ちょっとで売っていたのでつい購入してしまいました。以前私はロゴだら
けや!って予言しましたが本当にロゴだらけですね
V30のビデオ規格のロゴが付与されたものがSDSpecV5のカードの証です。
これにA1ロゴとかもつく予定なのでさらにカオス状態になりそうです。

ねむいさんの予想では山盛りになってしまった性能表記のロゴのすべてを包括する
新たな統一ロゴが来年あたりに登場すると思います。

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 19787 kB/sec.
>ds 0
rc=0
Drive size: 62333952 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 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.
CID:
00000000 03 53 44 53 45 33 32 47 80 A4 38 40 2C 01 07 C7 .SDSE32G..8@,...

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

OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 00 90 00 0F 05 3A 1E ..............:.
00000010 00 08 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 84 43 00 00 00 00 .5.C....

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

SD_Spec V5.xx!
Detected as SDHC Card!
Available UHS-I Mode.

おやくそくのSDカードの情報を抜き出してみました。
予想通り確かにSD_Specは"5"を示しておりますね★

いろいろ試す25

今回はSDカード関連中心です。


●SDカードの規格がバージョンアップ
SDカードの規格(Specification)が今年夏にV5.00にバージョンアップしています。

主な変更点は4Kや8K等の高精細映像録画に対応した"Video Speed Class recording"
略して"VSC"の追加です。これに対応したカードは「V6」とか「V30」とかの転送MB数を
保証する"V値"の付いたロゴが付きます。
既存の速度規格もすべて付与されるのでカードはロゴだらけのゴテゴテ状態となっ
ちゃいますね…実際そうなってるようですけど。
市場には現実的に購入可能な値段で既に出回っております。私も金銭的に余裕が
出来たら買って試してみるつもりです。


また、SCRレジスタのSDSpecにはV5.0を示す値が新たに付与されています。V値が書か
れたロゴが付いているカードはこの値が"5"になるはずです。私のいつものの今月の
更新でこちらにも対応していますので、既に入手した人は試してみてください。

20161201追:
ねむいさんいますぐSDAのサイト見てください!!!ってメール頂いたのですが
お昼にSDAのサイト見たら早くもSDSpecV5.1のアナウンスがされていました…。
今度は"Application Performance Class"の追加だそうで…これに対応した
奴は新たにA1なるロゴが付くようです。
もうロゴだらけですよぅ!!!!!


●ところで電子工作でSDカードを使用する際のライセンスの件について
SDカードをシステム用ストレージとして使用する組み込み機器の開発の際に必要な
ライセンスについて、SDAの中の人(具体的にはP@n@s○nic(@と○は伏字)の人)に
確認を取ることになりました。それのついででさりげなく電子工作においてSPI互換
モードでSDカードを動作せしめる際のライセンシーの扱いについても尋ねてみました。
巷でよく言われている「SPIモードでSDカードを動かす時はSDAとライセンス契約を結ぶ
必要はあるのか!?」っていう定期的に話題に持ち上がるもやもやしたアレの事です。

本当は枝葉末節の細かい条件に至るまで尋ねたかったのですが、そこまでやって
しまうとさすがにコンサル料を取られてしまいそうなのであくまであたりさわりの
ない範疇で"さりげなく"です。

ね「そいえばSPI互換モードだとライセンス不要とかトラ技とかにたまに書いて
  あるんですけどやっぱSPI互換モードでSDカード使う場合でもちゃんと契約
  結ぶ必要ってあるんですよね?」

P「はい」



ねむいさん藪をつついて蛇どころかオロチだしちゃいましたごめんね(テヘペロ
外人さんも正攻法で尋ねた方がいたみたいで同じ回答をもらっています。

別ジャンルですが今年頭に似たようなことやった人がいてちょっとした騒ぎ
なったケースがありますね。


そもそもの「SPIモードなら云々」経緯ですがこれに「2GBまでのカードなら云々」
「SPIモードはCPRM使えないから問題ない」とか尾ひれが付いたりした文章も
散見されますがMMCとSDカードの歴史を掘ってみると以下の経緯で現在の概念に
変質していったと私は推測します。

MMC登場!SPI互換モードも搭載!MMCホストはロイヤリティ不要!
           ↓
MMCをネイティブモードで動作させる際はお金払って動かし方教えて
 もらう必要がある(2016年現在は「あった」)。
           ↓
だけどSPI互換モードについては当時すでに解析されたり一部情報公開
 されたりでホビイストにもMMCの動作方法が知れ渡っていった。
           ↓
い討錣韻MMCをSPI互換モードで動かすだけならお金の心配は不要!
           ↓
SDカード登場や!MMC互換のインターフェースやけどSDホストの開発時
 とかSDホスト採用した製品とか売るときはしっかり銭取るで!

           ↓
Δ押次SDって開発だけでも金取るのかYO…
 ぁ…一部のSDカードはMMCの初期化(CMD1による初期化)が通るやん…
 これはMMCカードとして動かしてるよSDカードじゃないアルよ(棒
 「MMCホスト上で"たまたま"SDカードが動いてしまった場合開発側はSDAに
  対してロイヤリティを払う責は無い

           ↓
MMCの初期化が通るSDカードはSDv1のカードのみで一般的に流通している
 のは当時2GBが上限だった(例外はあるが)。当然4GB以上のSDHC(SDv2)は
 CMD8による初期化必須なのでMMCとしての初期化は一切不可能。
           ↓
─弔修靴童什
  銑Г泙任了柄が伝言ゲーム形式でまぜこぜになり「全てはMMCとして
 の動作である」という大前提も忘れ「2GBまでのSDカードでSPIモードで動
 かすならばライセンス不要って聞いた」とか挙句の果てには「SPIモードなら
 ライセンス不要
はず」と勝手に危険な解釈しだす。

これはいけない。



2016年現在ではJEDEC(旧MMCA)にもMMCネイティブモードについての簡易資料が
公開されてます。
また、アマチュアでもMMCネイティブモードでMMCeMMCを動作
させた作例
なぞ沢山溢れかえっていますからSPI互換モードがとかネイティブモードが
とかは実際はあまり関係はなくMMCとしての動作、つまりCMD1によるカードの初期化
にてカードを動作させているか否かが本当は重要
なのです。
それをしっかり理解して情報を公開されているのはサンテック社の製品解説の
ページ
ChaN氏の解説です。

マイコンでSDカードを使いたければ筋を通すのであればSDAとNDAを結び、さらに
maker系イベントで製作物を販売したいのならHALAも結ぶ必要があります。
企業ならともかく一個人がSDA+HALAの3000USD(2016年現在)の大金を毎年
払うのは荷が重すぎますしSDA側も民事訴訟を仕掛けて利益を回収できるレベルの
悪質な例を除いては黙認している状態なのでしょうね(この辺の関係ってなんだか
同人誌みたいだ…おっと現在は同人ではないケースもあるから薄い本でしたっけ)。

話を戻してわれわれ一個人のホビイストとしてどうすべきかですがねむいさんと
しましてはChaN氏の解説にある「MMCまたは互換カード対応」をお題目とすることを
支持いたします。MMC以外の形状互換のメモリーカードを「MMC互換カード」と纏めて
看做す作戦です。SDカードもFlashAirも立派なMMC互換カードですからね☆

ここまで徹底する必要があるのかと問われそうですがあなたがweb上で成果を
発表したりmaker系イベント等で成果物を販売したいなんてときにSDカードの
ライセンスを盾に正義感をはき違えたハナクソ野郎に絡まrt
問題点を鋭く見つけ出し
追及することに余念がない方の目に止まり貴重な時間を浪費しないためにも論理的
防御策を講じておくのはとても重要なことです。

そのためには実際にMMCもしくはeMMCを動作させることができるのは必要条件です!
これだけはしっかりと行ってください。メーカー配布のライブラリ等ではMMCは最早
過去のものと断定されCMD1による初期化そのものがソースコード上から消去
されてやがるケースもありますので
復活させてあげましょう!作品を展示する際も
eMMCをかっこよく使いこなしているところを魅せると一目置かれるかもしれませんヨ!?
↑なんかすでに「SD対応じゃなくてMMC対応といっておけばいいらしい」と都合よく
 曲解してる者たちがいるようですが何度も言いますがその製作物上でMMCが実際に
 動作できなかったりCMD1による初期化ルーチンを記述していないソースを公開し
 ちゃったりしてる場合はそのエクスキューズが一切まかり通りません。
 結局嘘ついてることになりますのでSDカードを「MMCの例外的実装」と主張できる
 ようにするためにもCMD1にて初期化するMMCが実際に動作するコードは必ず記述
 しておきましょう。



…ぇ?もしかしてねむいさんがわざわざ昔のMMC変換基板付きのeMMC入手して
動かしたぜアピールしてた
のってまさか…ですって?
はいそのまさかです。
でもAndroid等のボードだとロイヤリティフリーなeMMCが花形ですし凝った使い方
しなければSDHC/SDXCとおんなじ使用感覚ですし使い方は覚えておいて損はないと
言い切ることができます!さぁ今日から皆さんもお題目を唱えましょう!
MMCまたは互換カード対応!

MMCまたは互換カード対応!

MMCまたは互換カード対応!

20170107追:
CMD1の初期化がどこまで通るか実際に試しました。
20170107追:


でもめんどくさいのでこのぶろぐでは普通に「SDカード」って書いちゃいます。
SDAの中の人に怒られたら書き換えます><



肝心な事言い忘れていましたがこれは皆さん存じてるかと思いますがSDやMMCAの
ロゴを各組織のライセンス契約を結ばずに勝手に成果物や展示物に使用した場合、
商標権を侵害したこととなり非親告罪の刑事罰の対象になります!!!
おふざけでやっても御用となるので絶対にやめましょう!!!!!!!


●74クロックの怪
MMC/SDカードは電源投入後、VDDが2.0V(VDDmin)を越えたら74クロック分カードに
クロックを送出し最初のコマンド(CMD0とか)を受け付ける準備をします。


(part1_500.pdfより)
SDSpecV5.00では電源立ち上がりの規定がさらに詳しく描かれていますのでこれを
参考にしてドライバを組むとどんなカードでも安定して動くと思います。

SDカード/MMCに供給するクロックは400kHz〜100kHzに設定してマイコンのSPI
 若しくはSDIOモジュールを有効にする。
 (SPIと違いSDIO/SDMMCの場合はこの時点ですぐにクロック垂れ流しになる)
▲ードに電源投入してカードの電圧がVDD(2.7~3.6V)に達してからさらに1mSec
 待ち、その後最低74クロック供給する。SDIOの場合はクロック垂れ流しなので
 最低74クロック分供給されるまで待つ。
SPIモードならCS(DAT3)をLOにしてCRC付きでCMD0送信してSPIモードに移行。
 SD/MMCネイティブモードならそのまま各カードの初期化へ

SD/MMCの規格には上記の際のデータラインの信号レベルはどうすべきかが明記
されていませんがSD/MMCはネイティブ/SPI互換に限らずスタートビットで始まり
ストップビットで終わるクロックに同期したビットストリームによって処理されて
いるデバイスである
ためビット列の同期を取るため(=スタートビット(LOレベル)を
ちゃんと受けるため)には無信号時はデータ線をHIに固定しておくべきです。

SDIOではコマンド投げてないときはHIレベルでありさらにCLK垂れ流しのため勝手に
74クロック分進んでビットの同期が取れてしまい問題は無いのですがSPIモードの
場合は明示的に74クロック(SPIは8bit単位なので実際は80クロック)送信する必要が
あり、その際のデータとして0xFFを送信してビット同期をとっておかないといけません。

で、説明が長くなりましたがこの74クロックをわざと省くとどうなるか、SPIモードで
SDカードを動作させているSTM32F4Discoveryで実験してみました。


↑80クロック送信してる行をコメントアウトしただけです。

まずは大昔のSDV1.10の256MBのMicroSDカード
 ->無事動作
 ・・・あれ?
お次はさらに超大昔のSDv1.0xの256MBのMiniSD
 ->余裕で動いた
  あれれ???
超最新の東芝Exceria並行輸入版MicroSDXC64GBの奴!!
 ->余裕で動いた
  ?????
Sandiskの金色の奴!!
 ->余 裕 で 動 い た
  ?????
じ、じゃぁMMCPlusの2GBの奴!
 ->余裕余裕♥
  は?(CV:スパーク・マンドリラー)
  んぁ〜すまんが〜ねむいさんが正しくてお前が間違ってるってことはぁ〜ないかぁ?
さすがにMMCv3の128MBの骨董品なら74クロック抜きじゃ初期化できないでしょ!!
 ->余裕のよっちゃん
  ・・・・
・さっきのMMCPlusの2GBは1.8V動作も出来るからこれなら絶対動かんでしょ!!
 
 ここでちょっと素敵デヴァイスの紹介です。
 今年春にヘル朝鮮製のSD->MicroSDの変換アダプタ買ってウボァーしました
 その後台湾製のちゃんとした作りのSD->MicroSD変換基板を購入しました。
 これは信号も安定していて安心して使えます♥カードに供給する電圧も
 1.8Vに切り替えられますし♥
 ->1.8Vでも正常動作♥
  ?????????????????????????????????????????


・・・・・・・・・・・・・・
わけがわかりませんよぅ・・・

・結論・
結構いい加減な初期化でも大抵のカードは動いた。STM32はこういう結果になり
ましたが他のマイコンやChaN氏の作例に沿ったコーディング以外では動かないかも
しれませんのしっかり規格を守って動かしましょうね!特にCLKを除く信号線の
外部プルアップは必ず施しましょう!



20161214追:
xilinxのサイトで今回のSDカードの74クロックについて言及しているページ
ありました。やはり電源が+3.3Vになりさえすれば74クロック放たなくても
実際は殆どのカードで余裕で動いてしまうようですね!

その一方でChaN氏からコメントいただきましたとおりねむいさんのSTM32F4向け
SPI互換モード版ではCMDを発行する前にビジーチェックする先行ビジーチェックの
方式をとっていますのでこれにより最低3バイト分のSPIクロックを空撃ちをする形と
なります。xilinxの見解と合わせるとこれだけでもう十分なクロックを放っている
と言えますね。

そしてFatFsとSTM32F4のSPIを結合するHALに相当する私のコードはChaN氏の
AVR向け実装例を源流としています。今回の検証でChaN氏のコードのロバスト性の
高さが判明し今更ながらChaN氏の偉大さがまた一つ確認された形となりました。

・・・サスガダァ♥


●UHSモードの識別とか
現在主流になった"UHS-1"モードは通電中にI/Oの電圧を1.8Vに遷移させ消費電力の
低減と電圧スイング幅が狭くなった事による速度の向上を図るモードです。
しかしながらSTM32ですらマイコン単体でI/O電位を3.3V->1.8Vに遷移できる機構を
持つ品種は存在しないのであんまし意味は有りませんがUHSに対応しているか否か
程度は判別できるので組み込んでみました。



具体的には初期化動作時、つまりACMD41送出の際の引数にS18Rビット(24ビット目)を
立てるだけです。対応していればOCRレジスタに24番目のビットが立った状態で
返事が返ってきます。


通常OCRレジスタが0xC0FF0800と読み出されるところでS18Rビットが有効だった場合
0xC1FF0800となります。UHS-IIをサポートしたカードだと28ビット目がたちます。
でもそういったカードが私の手に入るのはまだまだ先でしょうけども。

ついでに今月のいつものの更新でSPI互換モードで取得できるSDカードの情報を大幅に
強化しています。SDIO/SDMMCとほぼ同じレベルとなりました♥


それはさておきちょっと興味深い発見をしました。
殆どのカードはSDネイティブモードでもSPI互換モードでも読み出された値は同じに
なるのですがSandiskのカードだけはSPI互換モードの場合はS18Rビットを立てた
引数でACMD41を送出しても反応がありませんでした。
いくつか試しましたがUHS-I対応を謳うUltraやExtremeのカードは全てダメでした。
もちろんSDネイティブモードの時は問題ないです。

Drive size: 15523840 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
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 SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SU08G
Product HwRev :8
Serial Number :0x1BB8C2F6
DateCode.Month :8
DateCode.Year :2012

OCR:
00000000 C1 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
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!
Available UHS-I Mode.
SDネイティブモードの時

Drive size: 15523840 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
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 SD 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 00 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
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :3
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDHC Card!
Available NS(or HS) Mode Only.
SPI互換モードの時


そもそもSPI互換モードではUHSモードは一切サポートせずNS(MAX25MHz)どまりなので
反応しなくても実害はないのですけど。


SDカードは奥が深いですね。

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

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


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


















以下はおまけです。






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



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

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

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

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

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

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


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

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



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



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


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




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

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


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

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

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

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

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

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

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


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

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

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

数年前にこのLCDが最強最後とか言いましたが・・・
ありゃウソですよぅ




これがっ!480x800でッ!IPSの広視野角でッ!しかもCTP(容量製タッチパネル)
までついったっ!MCUバス向けの最強最後のTFT-LCDモジュールです!!!!!
そしてサイズは4inch!!

中華通販で変換基板付で購入しました。配線の手間が省けて超ラクです♥


TFT-LCDのコントローラICはRM68120という480x800サイズに対応したものです。

ここでちょっと気をつけなければならないのは、大きなサイズのLCDコントローラIC
では内部RAMが半分もしくは全部ない場合があり、そういった品種では8-bit,および
16-bitバスなどのMCUバス経由ではマトモに表示することが出来ません。中華通販で
買うときはご注意ください。

容量製タッチパネル(CTP)は抵抗膜式タッチパネルよりも処理が複雑でマイコン
単体では賄いきれないため専用ICがほぼ確実にセットになっております。


ICの頭にFT5216GM7と書いています。FocalTech社のICですね。
ネットでいろいろ調べてみたのですがFocalTech社のデータシートでよい物が
なかなか見つかりませんがこのCTPコントローラICは2.8〜5インチで相互容量
方式となっています。STM32F7-Discvery(F769版も)にはFT5336GQQというマルチ
タッチサポートな相互容量方式のものが使われています。

容量性タッチパネルコントローラの自己と相互の方式の違いについては
ノリタケLCDさんちの説明がとても分かりやすいです。

さて、このFT5216はタッチポイントが一つしか搭載していません。結局抵抗膜式と
あんまし変わらない感覚ですので使い勝手を抵抗膜式の時と同じになるように、
いつものにCTP向けの処理を追加していきました。

世に出回っているCTPコントローラはI2Cインターフェースと外部割込み
用端子がでているものが殆どです。当然ながらSPIよりも速度が遅いくせに
シビアなI2Cペリフェラルの操作が要求されるのでご注意ください。
また、殆どのケースでINT割り込みの処理が必須になるでしょう。


で、動かしているところです。まずCTPコントローラICのdeviceIDを読み
取って表示できるようにしました。0x79はFT5216の証です。


そんでもっていないさんの全身図を♥
480x800の世界ってスバラシイ♥


昨年まではWVGAサイズなTFT-LCDも容量性タッチパネルもなかなか手が伸びにく
く実験レベルで終わっていたジャンルでしたが、現在では気軽に利用できる段階に
までなったと感じております。これから先どんどん活躍していく事でしょう。



なんとこの記事、次回につづきます・・・


コスプレ大好きいないさん
どうでもいいですがねむいさん自身いなちゃんが誰のキャラのコスプレしてるのか知らなかった・・・

いろいろ試す24

今年の暑は夏いですね・・・・
頭が沸騰して凝固しないように少しでも文章を残す訓練をしないと・・・


●LPC11U14の悲劇
マジかよ・・・ユーザーマニュアルにはROMディバイダあるって明記してあるのに・・・


というわけで実機で調べてみました。ねむいさんの持っていたLPC11U14Expressoは
最々初期のLPC11U14が乗っています。


0x1FFF1FF8にはROMドライバのアドレスが格納されています。実アドレスは
0x1FFF1E38となっています。

LPC11UxxのROMディバイダへのポインタが格納されているアドレスはその先頭
から16バイト先にあります。つまり0x1FFF1E48に有効なアドレスが格納されて
いない場合ROMディバイダは使用不可能となります!


ア"ア"ア"ア"ア"ア"ア"ーーーーーーーッ!!!!

・・・
NxPのLPCマイコンはこう言う罠がたくさん張り巡らされていますのでユーザー
マニュアルとか鵜呑みにしないで海外のフォーラムも積極的に巡って情報を
収集してください。

そいえば2年位前ねむいさんが指摘したLPC1500のIAPのアドレスが間違ってる件
2016年現在まだ治ってない・・・NxP(xは伏字)さんにメッセ送ったのに・・・。


●STM32Primer2を使ったGNSSロガーのリポ電池を変更
ねむいさんはトレランのトラックログ取り用にSTM32Primer2にハード的改造を施し、
それをGNSSロガーとして使用しております。電池もSparkfun製の1000mAhのリポ電池に
乗せ買え12h以上稼動できるようにしていました。
そして2010年から約6年間もの間戦い続けてきたそのリポ電池もかなりへたってきたので
交換する運びとなったわけです。

・・・がしかし!!!なんと昨今の規制強化のせいか850mAh以上の大容量のリポ電池が
軒並み販売終了となっていて購入する事が出来なくなっておりました!!!

探しに探しまくってこちらの通販会社さんから1000mAhのリポ電池を購入する事に
しました。最悪中華直販から輸入も考えたのですがチャイナボカンされたら困るので
国内から購入できる店があって助かりました♥


で、来たのはこちら。
6年前に購入したSparkFun製のものより薄く少し長くなっています。もちろん保護
回路付コネクタ付です。


元からついているコネクタは不要なのでJSTのRCYコネクタに付け直しました。
これで電池の脱着が自由に出来ます。・・・以前はテストのために直付けしたので
6年間そのままにしてましたが今回の電池交換でようやくです。

ぁーちなみにハーネスの力がかかる部分をポリイミドテープでガチガチに固定して
ますがこいつ意外と剥がれません!wifiモジュールをポリイミドでガチガチに固定してた
EnchantMOONのこと「こんなん振動ですぐ取れるやん」とさんざ馬鹿にしてましたが
前言撤回ですすみません!!でもよい子は真似しちゃだめだよ!


もちろん交換後も無事正常起動しました。
2016年真夏の炎天下の近畿自然歩道でバリバリ活躍しております!

たぶんねむいさんが世界でSTM32Primer2をいちばん長く使い続けてる女だと
思います・・・!もちろんあと30年は電池交換し続けて使い倒しますよぅ!


●FatFsに大量のぱっち
今年の四月にExFatに対応したChaN氏のFatFsですが、ねむいさん含めた有志からの
使用報告を受けパッチがパチパチ当たってます。現在はpatch7まで行っていますが
ねむいさんもそれに即追従してアップデートしております。

私が特に力を入れているSTM32F7をはじめSTM32F4系、STM32F1系も順次最新のものに
アップデートしております。皆様どしどしご利用ください★


●ウィルキンソンドライコーラ

・・・
甘味抜いたタブクリアだこれ


●おそロシアふたたび
Latticeの提供しているプログラミングツールはFT2232H系のデバイスに対応して
いてJTAGKey2CompatibleでもEEPROMを書きかえるだけでLatticeのプログラマに
化けるナイスな対応をしてくれましたが、AlteraとXilinxのツールはかたくなに
FT2232系のデバイスには対応しておりませんでした。
しかしながらロシアから恐ろしい刺客がやって来たのです・・・!もちろんLatticeと
違ってかなりダーティな裏技なので詳しいやり方は伏せさせていただきます・・・。

こちらのロシア系BBSのリンク先にあるとあるファイルにAlteraのプログラミング
ツールにFTDI系デバイスを対応させるdllがあり、それに差し替えるだけでQuartus
からAlteraのCPLD/FPGAのプログラミングツールとして使えちゃいます!!!


↑実際に使ってるところ。書き込み速度はもちろん超★爆★速!
 もうこれでUSBBlasterもどき作らなくてもいいんじゃ♥


そして問題のXilinx....
ねむいさんは過去に何度もXに挑戦し敗れてきましたがおそロシアのおかげでついに、
ついに攻略せしめました!!!!
注:ただし以下の条件を全て満たす必要があります。
  1.FT2232Hのみ有効。FT232HやFT2232Dは不可!
  2.FT2232Hにぶら下がるEEPROMは93LC56もしくは93LC66のみ有効。
    93LC46はユーザー領域が足らず不可!
  3.JTAGKey2 Compatible Rev.5を使用する場合、メインモジュールの
    DLP-USB1232Hに搭載されたモジュールが93LC56or93LC66である事。
    これは何が来るか分からないのでばくちですね・・・しかもQFNパッケなの
    で引っぺがすのは普通の人にはちょっと無理でしょう。
    かわりにFT2232H Minimoduleがオススメです。これ93LC56乗ってますし。


↑コツですがMProgを使ってEEPROMのデータを書きこむときにシリアルナンバを
 "有効"にしておきます。この後FTDI_User_Area_Writer.exeを起動しMprog/FTProg
 からは書き込めないユーザ領域にデータを書きこみます。


やったぜ。Digile○ntのJTAG-HS2として認識されました♥ちなみにISE14.7は
プラグインの調達の必要もなくIMPACTから普通に使えます。


実際にSPARTAN3をつなげてJTAGチェインを見てみます。


やったぜ!


もちろんふつうにコンフィグレーションできます♥


2010年からずっと奮闘してきた内容ですがようやくつっかえていた小骨が取れた
感じです♥EEPROMを書き換える少しの手間はありますがこれでねむいさん謹製の
JTAGKey2Compatibleが更に強力なフラッシュ書き込み/デバッグツールとして
活躍していけると思います!!

いろいろ試す23

せっかく貴重なGWの休みだというのに何をやっているんだ私は・・・
でもこれを消化しないと先に進めないというBADハマリ状態なのです・・・




●FTDIのFT232Rはぱちもんを撥ねるドライバが出てFT232Rの安いぱちもん
 使えなくなったから中華製のCH340G使おうぜムーブメント

みなさんはすでにご存知のこととは思いますがFT232Rはぱちもん対策が仕込んで
あってあんなことこんなことでぱちもんを使えなくさせています。
中華製のFT232R基板はまずぱちもんなのが前提だそうでぱちもん愛好家の方には
FTDIのドライバ改変で使えなくなるのは死活問題なのは必須です。そういうわけで
中華製のUSB-シリアル変換ICであるCH340Gを使おうという動きがあるようです。

ねむいさん的には何か大前提が思いっきり間違ってる気がしますが「自己責任
なら良いのではないでしょうか自己責任なら」といい居たいところですが大抵は
ぱちもんに分かって手出す人はケチなくせに文句だけは百人前でそういう人に
関わると時間と金を浪費してしまいますので皆様方はそういう人種を機敏に察知し
いち早く距離を置かれることが良いと思います。

…すみません話がそれてしまいましたが残念ながらCH340Gにもぱちもんが存在している
ようです。こちらをご覧ください。真ん中あたりにくわしい解説の画像があります。

CH340Gのぱちもんの見分け方として1Pinのマーキングの丸の削りが大きく広い
物が正規品で丸が小さくクレーター状に削られてるものがぱちもんだそうです。


ねむいさんも何故かCH340Gの出来合いボード持ってました・・・そして・・・

ぱちもんでしたー!!!!
クソァ!!1!1!!1



ちなみにぱちもんCH340Gは公式のドライバ宛がっても上手く動作しないようで
やっぱし中華メーカといえどもしっかりドライバでぱちもん対策してるようです。
このへんFTDIやProlificも同じなのでたとえイタチごっことなろうとも
メーカの自衛策としてぱちもん対策を仕込むのは必然となっているようですね。

安物買いの銭失い、安全/安心は金で買うものとはよく言ったものです。
たまにその売り物の安全安心すらぱちもんのことがありますけど…ふふふ。

20160512追:
こちらの方のブログのコメントに具体的な情報を見つけました。以下引用。

Commented by 中華マニア at 2015-04-24 10:11 x
CH340G自体にも通電していると内部のボンディングワイヤが焼き切れて
すぐ使えなくなる粗悪な偽物があふれかえっているそうです。

あれ…副業先で生産が間に合わず海外の別ルートで購入したNxP(xは伏字のx)製の
FETで似たような経験したような…


●FatFsが0.12にアップデートしてついにexFATに対応!!
GW前にChaN氏のFatFsがexFATに対応してアップデートしておりました。
64GByte以上のSDXCカードが安価で販売されるようになった今、exFATへの対応は
必然であるといえるのです!
・・ぇ?FAT32で無理やりフォーマットできるですって!?それはおいといて・・・

ところでSDHCとSDXCの違いは何か、どうやって見分けるのかという素朴な疑問が
わきますが規格では64GB以上の容量を持つカードがSDXCとなっています。
一般の方が単純明快に見分けられるたった一つの方法です。
SDHCはどう頑張っても32GBどまりです。この辺はこちらの方の解説が詳しいです。
逆に言うと128GBのSDHCとかは絶対に存在しないのでぱちもんであるとわかります。
海外通販でだまされないように注意してください。

ソフトウェア的に見分ける方法はいくつかあって前回もさらっと触れましたが
SCRを読み出しSD_Securityフィールドの値を見ることでも簡単に判別できます。
SDXCはここの値が必ず4になっています。ここの値はSD_SpecのVerには関係あり
ませんのでSDSpecのVerが4でもSDHCだったり3のカードでもSDXCなのが存在する
のは前回の読み出し比較でご存知だと思います。


さて、exFATにすることでFatFsがどういう挙動になるかを実際にフォーマット別
に比較してみました。使用するカードは前回へなちょこ判定したSuperTalentの
64GBのカードです。


前回無理やりFAT32にフォーマットして使ったといいましたがWindows上ではSDXC
カードはほぼ強制的にexFATでフォーマットされてしまうのでParagonHardDiskManager
を使いFAT32にフォーマットして使いました。
exFATのフォーマットについてはもちろんおなじみのSDFormatterV4.0です。

というわけでChaN氏のFat情報を読み出すfsコマンドといつものシーケンシャル
リードの速度比較を行ってみました。STM32F7-Discoveryで行ってます。

※FAT32フォーマット
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 4 2016
>fs
FAT type = FAT32
Bytes/Cluster = 16384
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 30576
Number of clusters = 3913672
Volume start (lba) = 2048
FAT start (lba) = 2080
DIR start (lba,clustor) = 2
Data start (lba) = 63232

Volume name is SDXC_64GB
Volume S/N is 7022-3F80
...
19 files, 520994673 bytes.
2 folders.
62618752 KiB total disk space.
62109728 KiB available.
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15414 kB/sec.

※exFATフォーマット
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 4 2016
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 0
Sectors/FAT = 16384
Number of clusters = 489208
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536

Volume name is SDXC_64GB
Volume S/N is DF51-7DE4
...
19 files, 520994673 bytes.
2 folders.
62618624 KiB total disk space.
62107904 KiB available.
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18442 kB/sec.

なん・・・だと・・・!?
exFATにしたらへなちょこじゃなくなった・・・!?
exFATになってクラスタサイズがデカイのが効いているのかもしれません。

FatFsのexFATの対応はまだ始まったばかりでバグも洗い出されて洗練されて
いく真っ最中ですのでこれからの発展に期待ですね。


ついでにFatFsのexFAT対応する時の注意点をいくつか・・・
1.常にLFN対応が必須
 exFATはロングファイルネームしか存在しないためです。それに伴って従来の
 8.3形式ファイル表記に頼ったプログラムだと既存のものから0.12にアップ
 デートする際にかなりの改修が必要です。

2.そんなわけでメモリ消費量が多くなる
 これも致し方ないですね。SRAM容量32kByte以下の小規模マイコンはexFAT
 対応はやめたほうが無難でしょう。尤も32GB以下のSDHCもまだまだ生産されて
 流通しているのでSDXCしかカードが無い!って事態は当分の間無いといえます。
 無理にexFAT対応にするべきではありません。ライセンスの問題もありますから。


・業務連絡・
ChaN様へ
もしここ見てたら"Well written implementations for STM32F/SDIO and LPC2300/MCI"
の"STM32F/SDIO and LPC2300/MCI"のところを"STM32F/SPI & SDIO and LPC4088/SDMMC"
に書き換えておいてください・・・。

↑ご協力ありがとうございました(ぺっこりん


皆様へ、
おきぱSTM32F4STM32F7向けのいつものはFatFs0.12に対応してすでに公開
しております!もちろん0.12向けのパッチも適用済なのでどしどしご利用ください!



●4GBのSDカード
かつて4GB以上の容量をサポートするSDHCの規格が登場し実際に市場に出回り
はじめる過渡期に4GBの容量を持ちながらSDv1規格で動作するいわゆる"規格外"の
SDカードが存在していました。

いったいこのカードはどのような動作をするのか!?実際に現在でも流通している
カードを購入して調べてみることにしました。


ebayでドイツの販売主から購入しました。SDV1.1規格の4GBのSDカードでSDHCに対応
しないちょっと昔の機器で活躍するかも!ていう触れ込みです。

さっそくねむいさんのいつものでSDカードの情報を読み出してみました。
が・・・・
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...

Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015

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!

・・・
なんですかこれ単なるSDHCじゃないですかーヤダー!!!
・・・ちなみにh2testwでも調べましたがカードとしてはちゃんと4GBの容量をもった
"SDHC"でした・・・ビキビキ


ぱちもんつかまされたと思って捨てるのもあれなので副業先の修理品撮影用でぢかめ
の記憶素子として利用することになりました。
が・・・
後輩から「ねむいさんこのカード1GBしか認識しないんスけど?」と文句を言われ
このカードのホントの力を知ることになります。

後輩が撮影した画像データを取り出そうとして使ったUSBカードリーダーは10年
以上前の骨董品で、4GBに替える前のでぢかめ用SDも時代遅れの1GBでした。
もちろんこのカードリーダはSDHCを一切認識しないため私が提供した4GBのカードが
容量が変だとはいえ認識すること事態がおかしいのです。

ねむいさん後輩からそのカードを取りかえし、デバッガで動きを追ったところ以下の
事実が分かりました。

1.イニシャライズ時に最初にCMD8(SDv2専用の初期化コマンド)を投げていると
 SDHCとしてブロックアドレッシングモードで動作する。
2.ACMD41をいきなり投げると(SDv1の初期化)SDSCとしてバイトアドレ
 ッシングモードで動作する

つまり新旧の初期化方法のどちらでも正しくカードを初期化できて正しく動作する
ように作られたいわば魔法のカードだったのです!!!

ねむいさんのおきぱのFatFsの移植サンプルはSDカードの初期化手順がCMD0->CMD8->
ACMD41というSDv2もSDv1も包括する流れだったので必ずSDHCとして初期化されて
しまうのでぱちもんだー!と誤認してしまいました。

以下に通常のSDv2の初期化とわざとCMD8を飛ばしてSDv1で初期化したときのカード
情報の違いの差を示します。
・SDv2
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 28 2016
>fl
----A2011/07/27 23:51 351416 0c4f42da.jpg
----A2015/03/03 15:07 307254 1c3e744f.bmp
----A2010/07/20 13:52 1993197471 91sp2_quartus_free.exe
----A2011/06/04 06:07 324588 1c3e744f.jpg
----A2010/03/24 17:47 132389 002.jpg
----A2016/01/30 10:54 244527 2d35e710.jpg
----A2013/06/20 22:49 47566 2ecd0b3e.jpg
----A2010/03/24 17:48 198903 003.jpg
----A2011/05/25 01:11 53023 3c3ba2bd.jpg
----A2010/03/24 17:48 137038 004.jpg
----A2013/05/29 21:02 22235 4b62585a.jpg
----A2012/09/19 23:32 80490 4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg
----A2010/12/02 23:28 102769 4e61b17f.jpg
----A2010/03/24 17:48 148307 005.jpg
----A2015/07/08 14:32 318848704 install_sw4stm32_win_32bits-v1.2.exe
----A2016/02/26 11:57 421760368 MDK518.EXE
----A2008/09/12 20:19 47341 2005-03-24otter02.jpg
17 File(s),2736004389 bytes total
0 Dir(s), 1239515136 bytes free
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 948
Number of clusters = 121334
Volume start (lba) = 8192
FAT start (lba) = 14488
DIR start (lba,clustor) = 2
Data start (lba) = 16384

No volume label
Volume S/N is 3688-4D7E
...
17 files, 2736004389 bytes.
0 folders.
3882688 KiB total disk space.
1210464 KiB available.
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...

Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015

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!


・SDv1
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 28 2016
>fl
----A2011/07/27 23:51 351416 0c4f42da.jpg
----A2015/03/03 15:07 307254 1c3e744f.bmp
----A2010/07/20 13:52 1993197471 91sp2_quartus_free.exe
----A2011/06/04 06:07 324588 1c3e744f.jpg
----A2010/03/24 17:47 132389 002.jpg
----A2016/01/30 10:54 244527 2d35e710.jpg
----A2013/06/20 22:49 47566 2ecd0b3e.jpg
----A2010/03/24 17:48 198903 003.jpg
----A2011/05/25 01:11 53023 3c3ba2bd.jpg
----A2010/03/24 17:48 137038 004.jpg
----A2013/05/29 21:02 22235 4b62585a.jpg
----A2012/09/19 23:32 80490 4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg
----A2010/12/02 23:28 102769 4e61b17f.jpg
----A2010/03/24 17:48 148307 005.jpg
----A2015/07/08 14:32 318848704 install_sw4stm32_win_32bits-v1.2.exe
----A2016/02/26 11:57 421760368 MDK518.EXE
----A2008/09/12 20:19 47341 2005-03-24otter02.jpg
17 File(s),2736004389 bytes total
0 Dir(s), 1239515136 bytes free
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 948
Number of clusters = 121334
Volume start (lba) = 8192
FAT start (lba) = 14488
DIR start (lba,clustor) = 2
Data start (lba) = 16384

No volume label
Volume S/N is 3688-4D7E
...
17 files, 2736004389 bytes.
0 folders.
3882688 KiB total disk space.
1210464 KiB available.
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 512 sectors
Default r/w block size: 2048 bytes
Card type: SDv1
CSD:
00000000 00 0E 00 32 5B 5B 03 B6 1D B3 FF 80 0A C0 00 E9 ...2[[..........
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...

Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 20 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 25 80 00 00 00 00 00 .%......

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!


もちろんどちらの初期化手順でも得られる使用可能総容量はCSDレジスタの値自体が
アジャストされ変化するためSDv2,SDv1のどちらの初期化手順でもまったく
同一の容量となり、さらにバイト/ブロックアドレッシング両方の読み書きも
すべて正しく行えております。
しかもご丁寧にSCRのSDSecurityのバージョンまでちゃんとアジャストして
SDv1で初期化したらちゃんとSDSCとして認識されるという充実ぶりです!!



ついでですがその他の"4GBのSDカード"も調べてみました。これはTOPRAM製の
カードです。結果から言うと同じく初期化手順の違いでSDSCにもSDHCにも化ける
タイプでした。



こちらは規格外カードの本家ともいえるTranscendの4GBカードです・・・がUSEDで
しか手に入らなかったのでなんか茶色いのがいっぱいこびりついててきちゃない・・・

中華からかった中古なので何がついてる分からずIPAでよごれをこすって落とし
まくって2時間後にようやく動作確認・・・


こいつこそホントに単なるSDHCでした!!!!!F**K!

20160512追:
後でさらに調べて分かりましたが"SD Compatible"とパッケージにはっきり
書かれたものでない限りはSDHCの表記が無くてもただのSDHCでSDv1の
初期化は一切通らないそうですF++K!!!



というわけで規格外な"4GBのSDカード"は規格外ながらも今日もどこかの
ちょっと古い機材で活躍しているかもしれません。


●秋月の006Pリチウム電池
テスタの電池用に秋月さんの006P型リチウム電池を購入してみました。


一般の006Pと比べるとやたら軽くちょっと大きく見えて不安になります・・・


一応無理なく収納できました★


動作も問題ありません♥
実はもう4ヶ月近く使用していますが今のところ電圧が出なくなったり爆発
したりとかはなく、至って問題なく使用できています。このリチウム電池は一
般的な006P型乾電池と比べると電流容量はかなり低いですがテスタのような
消費電力が低い機器で使用する分にはまったく問題は無いのでオススメです♥

いろいろ試す22

30日は〆のトレランに行くので年末恒例の奴を今やらせていただきます・・・


●フェライトビーズの使いどころ
ねむいさんはおきぱでSTM32のFatFs移植サンプルを公開してることから「FatFsが動き
ません><」という漠然とし過ぎる困った質問を今でもコンスタントに頂くのですが、
もはやその原因の99.99%が単純な結線ミスとか接触不良が起こりやすいブレッド
ボードで配線30cmくらい引き伸ばしまくって通電してたとかそんなモン動くわけ無い
でしょ的内容だったのですがまた新たに別のクリティカルヘンテコな報告を頂きました。

最短の配線でSTM32F407ZGT6の基板を起こしたにもかかわらず昨今のUHS-1のカード
ではSDIOで認識すらしない、クロックの速度を落としてもダメで昔のUHS表記が無い
Class6とかのカードならOKというこれまた奇怪な不具合だったのです。

STM32のSDIOは1.8VのUHS-1の高速クロックモードには対応しておらず、早くても
HSモード(3.3V/52MHz)ですがHSどころかNSモード(25MHz Max)でもダメとのこと。
ダメなカードも型番を教えてもらったのでPCOnes'sで購入して私も試して見ました。
TranscendのmicroSDHCカード Class 10 UHS-I 600x (Ultimate) なるものです。

謎のMLCアピール・・・。


私が持ってるSTM32F407ZG系の基板は紅牛に無理やりF4を乗っけた基板です。配線長も
なるべく質問を頂いた方と合わせるようにmicroSDソケットを無理糞つけてました。

で、こいつで試すと確かにHSどころかNSモードのクロックでも全く認識しなかった!
念のため別の会社のUHS-1のカードも複数枚試しましたが結構な確率で認識できない
ものが存在していました・・・!UHS無しのClass10表記の奴やねむいさん愛用のATPの
Class6の4GBの奴
はエラッタもちのF407系のいんちきHSモードでもバッチリ認識できて
るのですが・・・ひとまず信号の測定に掛かります。


これがATPのmicrosdhcのクロックの波形(NSモード/24MHz)です。


んでもってこっちがTranscendのほうの波形(NSモード/24MHz)。
ATPのよりも信号のふり幅が狭くなおかつリンギングも激しくなってる感がしますね。


波形の測定に関してはGNDリードの影響を抑えるために当然最短にして測定しています。
あとPCオシロのトリガはETSモードにして等価サンプリングレートを10GHzとしています。
STM32のSDIOのクロックはパワーセーブにしない限りは常に出っ放しになるので繰り
返し信号として測定でき、精確な波形測定ができるわけです。

話を戻しますが二つの波形の違い、なぜこんなに違うかですがこれはUHS-1のカードは
100MHz以上で動作できるUHSモードで転送する際はNSモードやHSモードよりも高速な
立ち上がり/立ち下がりを当然要求されるわけでそれに合わせてI/Oをこしらえていますが、
悪い条件が重なったときに信号の反射によってオーバーシュートやリンギングが激しく
出ることになります。
過去のClass表記のみのカードでは高々50MHzまで動けたら良かったので高速なI/Oを
必要とせず、オーバーシュートやリンギングは同条件でもそこまで大きくはならない
・・・と想定できます。

さて、状態は観測できたので後は対策です。こういうケースの場合はフェライトビー
ズを各信号ラインに直列に入れてやると効果が出るはずです。


いろいろ試してねむいさんの手持ちのフェライトビーズの中ではBLM18BB121SN1D
かなり効果があることが分かりました。この対策で認識できなかったUHS-1のカードも
無事見ることができました(NS/HSモード共)。


これが対策後のTranscendのCLKの波形です(NSモード/24MHz)。
リンギングがしっかり抑えられてるのが分かりますね〜。

こんな感じに無理糞つけけております。
念のためTranscendのとは別の認識できなかったUHS-1のカードも試してみましたが
すべて無事認識できるようになりました。ちゃんと対策として効いているようです♥

これより大きい抵抗値の奴ではHSモードでクロックが大きく崩されすぎてダメになって
しまいます。やっぱり程々が大事です。
また、秋月さんのとこで購入できるタイプのフェライトビーズでは特性が少しなだらか
なため余り効果が出ませんでした。とはいえねむいさんが選んだ奴もかなりピーキー
なのでそのまま真似しても多分効果は出ないと思います。

こういった信号の反射の影響度合いは設計するボードごとに大きく変わってくるので
オシロとにらめっこしながらカットアンドトライをしなければならない領域です。
GNSSモジュールの時も言いましたがむやみやたらにフェライトビーズを突っ込み
まくっても逆にノイズやリンギングをパワーアップさせてしまうことになりかねません。
また、オシロのプローブも見たい信号を正しく測定できるようにGNDリードを超最短
にするなどの配慮も必要で開発者としての様々なセンスが問われることになります。

と、ここまで苦労してSDIOの信号波形整て認識できるところまで持ってきましたが、
GPIOが速度面で強化されたSTM32F43x/42x系とかF7系を最初から使っとけば
上記のめんどくさいことをなーんにもやらなくても安定してSDカードを読み書き出来
たりします・・・酷いオチだ・・・。




全然関係ないですが大阪日本橋のPCOne'sでSDカードのついでに買ったスマホ置き台が
STM32F7Discoveryとぴったりフィットできる形状なので重宝してます♥



●GCC ARM Embedded in Launchpadの2015年Q4版が出る!

一年に4回リリースされるLaunchpad GCCの最新版がリリースされています。
今回はついにGCCバージョンが5になりました!

早速新旧比較をしてみたいと思います。まずは同じ条件でビルドした際のバイナリ
サイズ比較です。条件は以下のとおり。

F7のいつものの20151224版
・SDMMCのクロックはNomalSpeed(24MHz)
・-Ofast,HardFP
・AXIMからフラッシュ実行/SDRAM有効/フォントは内蔵フラッシュに格納
・使用SDカードはAF4GUD、SDFormatter4.0でフォーマット

旧:2015q3版(GCC4.9.3)

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 602096 0 602096 92ff0 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
599808 2288 821392 1423488 15b880 main.elf


新:2015q4版(GCC5.2.1)
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 612272 0 612272 957b0 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
609984 2288 821392 1433664 15e040 main.elf


バイナリサイズは2015q3版より10kByteほど増えてますね・・・
今度は実行処理速度比較です。SDRAMの時と同じようにlibjpegの展開時間の比較を
行ってみました。


旧:2015q3版(GCC4.9.3)


新:2015q4版(GCC5.2.1)

・・・イケてるじゃないですか・・・(セルピコ顔で)
なんか去年もモズグス編のセルピコさんになった気がしますが、最適化の悪影響が及んでる
かもしれないのでもうすこし様子見して安全性を確かめたいとおもいます。丁度明日は今年
最後のトレランに行くので屈作のSTM32Primer2GPSTr@ckerに2015q4版でビルドした
バイナリを書き込んで試してみるつもりです★



●Firefox版赤福が署名に対応する
虹裏関連のお話ですがFirefox版赤福spが署名チェックに対応することになりそうです

FirefoxはVersion44から拡張の署名が強制になり署名が無い拡張は撥ねられて動作不
可能になるとアナウンスされており署名が無い赤福spが使えなくなると言われていましたが・・・
作者の方ももう気付かれて対処されるようなので等分の間は安泰でいられると思います♥

この調子で合間合間にも対応してくだち・・・



●年末恒例のねむいさんFAQ

Q:わたしは(何らかの下らない他人の自慢話なので省略)
 なぜOpenOCDにこのバグが組み込まれてしまったか考えてみてください。
 ↑(原文ママ)

A:ねむいさんこの質問風八つ当たりにうっかりクソ真面目に答えてしまいました。
 ウブなねむいさんはこのバグの部分とは無関係だったにもかかわらずソースコードの
 更新履歴を丹念に調べエンバグされた経緯と対策まで連絡してあげました。もちろん
 質問されたクソ野郎方からその後どうなったか返事なぞまったくいただいておりませんが、
 実はkinetis.cにある致命的な"このバグ"はまだ修正されておりませんが、次に同じような
 こと聞かれたら適切な返事を返してあげようと思います。

 バカめと。

 ↑20160212追:
 kinetisドライバに真っ当にご助言いただいた方々にこれは俺の事かとお叱りの
 メールを幾つもいただいてしまいました。誤解を招きまことに申し訳ございません。

 致命的なバグはとあるぱちもんデバッガ使ったときに発動するのですが、
 ねむいさんに対してそういう情報隠して正規品使ってると秒速でバレる嘘ついて
 "動くようにしろ""対処してください"とかいって情報聞き出してくる奴は絶対に
 許さないのでそういった御仁たちは拙者尽く伊達にして返すでござる。

Q:ねむいさんってツイッターとかしてないんですか?
 所詮は批判を恐れ安全な場所から一方的に意見を言い放つことしか出来ない
 ティキンなのですか?
A:それはイエスでもありノーでもありますのだわ・・・(第五ドール風に)
 ねむいさんはいろいろあってツイッターやめた代わりにこのねむいさんのぶろぐ
 立ち上げました。かれこれ7年位前のはなs・・・グハッ!!!!


Q:ねむいさんってLINEとかしてないんですか?
A:ま だ ガ ラ ケ ー 使 っ て ま す

Q:スマホでピッ!簡単電子工作★
A:ま だ ガ ラ ケ ー 使 っ て ま す
 っ て 言 っ て る で し ょ コンチクショー




(以下ほぼ実際にあったやり取りですだいぶ前の話ですがもう時効だから書きます)
Qr:鶴岡工場(旧NECエレ系列工場)閉鎖ね
A:あっそ良かったねおめでたうございまs・・確かここって旧NECの・・・
Qr:ついで(?)にあんたのところのASIC生産中止だね
A:何ですって・・・!?
Qr:この前のが最終ロットね。今までご利用いただきありがとうございますを
A:あ”!?(CV柴田理恵)
Qr:代わりに弊社のSmar●tAnalogをご採用願います(営業スマイル)
A:カエレヤ!!
 (ここでルネサスと完全に手が切れPSoC5を採用しかけたが・・・)

Qp:gff...ねむいさんねむいさんそのセミカスタムのASIC、こちらでも
 起こせますよ・・・(はげたかのような目で)
A:オゥこれはありがたい・・・

Qrohm:ルネサスさんからのディスクリートデバイスの置き換え表ありますよ・・・
   ・・・gff(はげたかのような目で)
A:オゥこれはありがたい・・・

ディスクリートデバイスは旧NECエレでがっちり固めてたからヤバかったです。
R○HMさん(○は伏字)ありがたう!!!
今は東芝半導体がチャレンジ()の成果もあってRenesasに合体しそうでやばそうですね・・・
東芝さんのもかなり使ってるんですけぉ・・・


さぁそれはおいといて明日も早いから寝ましょう・・・Zzz・・・

↓としあきくんからのリクエスト↓
Q:カレン金剛の声の区別が付かないデース
A:ネムイサンも区別付かないデース(CV:柴田理恵)
 ・・・と言うのはおいといておすぎさん(悪堕ち)とピーコさん(純粋悪)に同時に襲われたら
 ピーコさんと間違えて悪堕ちした無罪のおすぎさんをうっかり攻撃してしまうくらい
 "うつけ"です・・・

Q:ねむいさんって雑誌に投稿したりしないの?
A:どのジャンルのこといってるのか分かりかねますができたらとっくにやってます。
 そいえば2014年初夏にC9出版のドメインのメアドで「記事作成を手伝ってみませんか?
 という何か目的をぼかした内容のしかも文語体と口語体が混じっておまけに芝まで生や
 したメールを頂いたのですがちょっと怪しかったのでCQ出版のお問い合わせにメールで
 (差出人の方の名)さんはそちらに在籍されていますか?とたずねたのですが問い合わせを
 してからはや約1年と8ヶ月、何の音沙汰もありません。
 問い合わせついでにトラ技の誤植を指摘したのがいけなかったのでしょうか・・・
 やっぱし本当にフィッシング目的の偽装メールだったかも。

Q:ブラギガスを検索したら諸星きらりが何故かサジェストに出てきました。
 虹裏メイドのねむいさんはなにか知ってそうな顔してますが・・・洗いざらい吐け
A:にょわー(野太い無理やりな高い声で)
 ↑もし隣からこんな絶叫きらり語聞こえたら速攻警察屋さん呼びますよぅ!!

JTAGKey2互換回路をもっと使ってみる3 -決着をつけてやる!-

●モロ!
2010年に始まり2013年に一応の決着を見たはずのJTAGKey2互換回路製作ですが・・・
ねむいさんは未だモロにこだわっていた。尤もここでいうモロ未加工の紳士画像
虹裏に張り付けせしめる野蛮な行為ではなく、FT2232HのLVTTLの出力を電圧レベル
トランスレーター74LVCE1G125の5V動作時のCMOS入力に直接モロに入力せしめる
乱暴な行為を指します。


JTAGKey2互換回路において、モロで何が悪いかというとターゲットの電圧が5V系で
動作してるケースです。このとき74LVCE1G125のVIHは3.5V以上となり、FT2232Hの
LVTTLの3.3Vの出力では規格を満たすことができません。
逆に74AHCT541等の高速なバッファを挟んで正規に5VCMOSレベルまで上げてみまし
たが今度はAHCTバッファの大きな伝搬遅延が影響してFT2232Hの特徴である30MHz
動作が出来なくなってしまいました。

そんなわけで私は5V系で電圧・動作温度にマージンをかなり取ってモロった時の動作に
問題が無いことを確認し
、規格は満たしてないけど私の回路図と指定した部品使えば5V系
でも実力値で問題なく使えます!…とお茶を濁していました。
しかし心の奥底でルールに反した事をしているとわだかまりを残したまま、TTLレベル
入力でなおかつ1.4〜5.5Vの電圧範囲で動き、それでいて伝播遅延も少ない夢のような
デバイスの到来を期待しておりました…。


●アチャモ・・・
時は流れ、半導体製造プロセスも進化したおかげか5V動作時にTTLレベルの入力電圧
範囲を持ち、それでいて速度もそこそこ早く動作電圧範囲もそこそこ広いまさに待ち望
んでいたバッファICがリリースされておりました!TIから2014年秋口にリリースされた
LV系レベルシフタSN74LV4T125です!


以前からワンゲートロジックのSN74LV1T125は既に出ていたましたがSN74LV4T125は
4回路ぶんコミコミでなおかつ出力電流と伝搬遅延特性が改善されています。
電圧範囲は1.60~5.5Vとちょっと電圧下限の保証が低いけどこれなら勝てる!!
しかし…


遅延で1ビットずつずれてやがる…orz

ちなみに正常に認識した時はこのような感じになるはずでした。

なんか包帯ぐるぐる巻きの猪狩さんに気を取られているうちに佐山聡似の不気味な飴玉
レスラーに不意打ちを受けてさらにチョビ髭ノッポなキックボクサー崩れのレスラー(?)
に追い打ち喰らって「あちゃ〜〜もろ・・・・」とか言われたような気分です。
やはりTTL入力を実現するため追加されているはずの内部ゲートの遅延がかなり
足を引っ張り結局74AHCT541を経由させたのと同じになっちゃいました。


そんなわけで安きに逃げるのは止めて既存のFT2232Hを使用している+5V動作を
保障しているJTAGアダプタたちは実際にどのようにして電圧レベルの変換を行い、
かつ速度も保証しているのかじっくり調査をしてみることにしました…。


●あくまでもモロにこだわる
夜逃げしたAmontecの過去の資料を穴の開くほど調べてみるとオリジナルJTAGKey2
のサポート"電圧"は確かに1.4V〜5.5Vでした。
この"電圧"と言うのはターゲット電圧(Vtgt)そのものを指します。JTAGインターフェース
のI/Oの電圧レベルではありません。AmontecJTAGKey2の紹介文をよく読んでみると、
"5V"ではなくわざわざ"5VTTL"と明記されています。5VTTLの出力は5VCMOSの
入力を満たすことができませんのでオリジナルのJTAGKey2はVtgtが5Vであっても5V
フルスイングのCMOSレベルの出力を出せていなかった可能性があります。

ほんとにそうなのかは販売元のAmontec及びAmontecの中の人にI/Oの電圧特性に
ついて詳細を聞けばよいのですが残念ながら夜逃げして早数年経った今はそれはかない
ません。しかもいくつかMLに残された中の人の軌跡を手繰ってみると中の人はサポート
下限は1.4Vのはずなのに1.2Vとのたまって
いたり5VCMOSサポート!とおもいくそ
のたまっていたり議論中に突然Amontecの製品の宣伝をしだしたり挙句の果てに"問題は
モニタとイスの間にある!(=お前もう出てけ!)
"と言われたり夜逃げしてからは"あいつ
もう死んだんじゃねーの?
"とか言われたりボロクソです。最早あまりのクソコテっぷりに
Switzer版ぴるすにしか見えないんですけぉ…
ねむいさんも彼を墓から引きずり出して殴る蹴るの残虐行為はしたくはないのですが、
オリジナルのJTAGKey2の電圧/速度スペックについてはほんとに額面通りであるのか?
懐疑的にならざるを得ませんでした。


とにもかくにもI/O電圧のレベルの上限は5VCMOSではなく、5VTTLレベルであること
は明確となりましたので一歩前進です。5VTTLレベルの出力規格2.4V以上をみたし、
なおかつFT2232Hの出力(3.3V-LVTTL)と74LVCE1G125たちのVIH(0.75VDD)を満たす
ためにはVtgtから何らかの形で電圧を落とし74LVCE1G125に掛かる電圧(Vrefとします)
の上限値を4.0V付近にクランプしてやれば解決です。

また乱暴なことを…と言いたい方もいらっしゃいますかと思いますが実はこの技、5V系
なVtgtで受けつつTTLレベルの電圧をやり取りするために実際に商業向けの商品にも
使用されているれっきとしたものです。それが使われている例をご紹介します。


xilinx platformcable データシートより引用
xilinxのプラットフォームケーブルUSBI/IIはデータシートに入出力バッファについて
の極めて有用な解説が記載されています(ここまで細かい資料って昔あったっけ????)



xilinx platformcable データシートより引用
プラットフォームケーブルはJTAGの出力にはUHSBufferなるNC7SZ125が使用され、TDO等の
入力には3.3V動作の超高速コンパレータで約1V前後のスレッショルドで取り込まれています。
(※プラットフォームケーブルIIは単なるロジックで受けているようです)


xilinx platformcableII データシートより引用
さらにVrefを生成するための回路は至って原始的で3.9Vのツェナーダイオードと抵抗で
Vtgtを強制的に3.9V付近にクランプさせUHSBuffer等に供給するVref上限を3.9Vまで
としていました!もちろん5Vをぶち込むとそこで80mA以上消費され、ダイオードと
抵抗にかなりの発熱を伴うのは容易に分かりますがなんて男らしい実装だ…!

さらにUHSBufferたるNC7SZ125は2000年代初頭にすでに存在している高速ロジックIC
なのですが、こいつの推奨動作電圧範囲の下限は1.65Vとなります。つまりプラット
フォームケーブルが保証しているはずの1.5VLVTTL/CMOSはこのロジックICの推奨範囲
から逸脱して使用されているわけで勿論設計された当初は74LVCEシリーズなんて存在
しなかったので結構ルールから外れた(でも最大定格範囲内の動作を守っている)結構
苦しい使い方されていたのが判明しました。

オリジナルJTAGKey2でも中の人が言っていた"UHSBuffer"とやらのスペックを見ると
当時の状況からはこのNC7SZ125以外に選択肢は考えられないので"最大定格範囲を
超えない"ようにしつつ推奨動作定格を破って動かしていた可能性が極めて高いと推定
しました。おそらくVtgtも何らかの形で4.0V付近にクランプしてVrefを作っていた
はずです。さすがにツェナーダイオード+抵抗の超乱暴実装ではないはずですが…。
まさか…。

また、CMOSの特性上VDDが低下すると伝搬遅延時間も大幅に増加していきます。

xilinx platformcableII データシートより引用
プラットフォームケーブルのデータシートではそれについての注意事項がありますが、
オリジナルJTAGKey2にはそんな記述すらないのですがTCK=30MHzの最大スピードで
動作せしめられるようなものは3.3V系のごく限られたターゲットのみでそれ以下の
電圧や速く動くデバイスがそもそも存在しない5V系では結局は良くても最大10MHz
くらいしか出せなかったのではないかと推測します。


●私はもうティキンじゃない
そんなわけでだいぶ実態が分かってきました。ねむいさんが取れる選択肢は究極
の二択になります。

一つ、冒頭のSN74LV4T125を使用して30MHz動作と1.65V以下の保証を捨てる。
->1.5VCMOS/LVTTLを使用する場面や30MHz動作できるターゲットがほとんどないので
 そいつらをあきらめてSN74LV4T125で組むと自作のハードルがかなり下がります。
 5VCMOSでも規格を満たします。初めてFT2232Hを使ったドングルを作る人向けです。

一つ、オリジナルのJTAGKey2のロジックレベル保証を忠実に守る。
->1.5VLVCMOS/LVTTLから5VTTLに至るまでの電圧範囲をサポートせしめる!!!
 2015年現在存在する新しい超高速ロジックICなら低電圧領域でも速度がある程度
 保証されます。その代り回路は複雑になり、使い方にも注意が必要です。


ねむいさんはもちろんオリジナルJTAGKey2の電圧範囲を忠実に守ります!!!
そんなわけでJTAGKey2Compatibleのキモにあたる部分の解説をおさらいを
兼ねて改めてしていきましょう。


TCK,TDI,TMS,SRST,TRSTはDIODES-Zetex社の74LVCE1G125です。1.4Vから動作するので
1.5V系も正式にサポートです★

TDO,RTCK,SRST_inはNxP社の74LVC2T45です。こいつは1.2Vから動作するすごい
奴です。この図だけ見るとパスコン乗せてないように見えますがPDFにはちゃんと
乗せてますのでご安心ください。


オプション扱いだった74AHCT541は廃して今回新たに4V出力のレギュレータを追加し
ました。これで5V系のシステム相手でも5VTTLの電圧レベルをサポートできます!
4V以下ではLDOの特性上内部消費電流が増加しますがこの東芝のTCR2EF40は内部
消費はmA以下のオーダーなので発熱も全くなく電圧クランプとしての役割を十分に
果たしてくれます。さらに最低動作電圧は約1V付近と一般的なLDO比べて十分低い
ので1.5V系の時の動作でも電圧が暴れず安定して使用できます♥
勿論全てのLDOがこのような使い方ができるとは限りません!しっかりとデータシート
の特性グラフとにらめっこして目的に最適なものを選んでいきましょう!


●ありがとうV戦士モロ

2年前作ったJTAGKey2CompatibleRev.4にレギュレータを追加しただけですので
見た目はまったく変わってません。74AHCT541乗っかったままですが
どこにも繋がっておらずもはやただのオブジェと化しています。

レギュレータは赤丸でかこった箇所につけました。現在は1608サイズで10uFで
しかも温度特性もそこそこのよいMLCCが売られている
ので早速使っています★


3.3Vの挙動については回路構成はRev.4以前とまったく同じですので5V系と1.5V系
のきわきわの動作を見ていきます。

前回と同じ条件でATMEGA1284Pをターゲットデバイスに選び検証します。今回は電圧
レベルの問題で引っかかるのはJTAGKey2内部ではなくJTAGKey2の出力バッファと
AVR間です。AVRを選んだ理由は前回と同じものを使ったから条件があわせやすいのと
VIHが通常のCMOS(0.7~0.75VDD)よりも大きい0.8VDDを要求しているからです。
VDD=5.65Vの厳しい条件で温度を振って書き込みや消去が正常にできたらねむいさんの
勝利です!!!
(注:1.5Vの時はAVRの動作補償範囲からはずれ、JTAGのTCK周波数許容値が
  下がってしまうので今回は一律10MHzではなく4500kHzで検証しています。)


勝った・・・!


手抜きではないのですがATMEGA1284Pの動作保証下限1.8Vを割って1.5Vでも問題なく
動作可能です♥これで1.5VLVCMOS~5VTTLレベルの電圧レベルでは完全に動作する
ことが確認できてさらに5VCMOSレベルも問題なく動作する実力があるのもわかりました♥

ちなみにATMEGA1284Pの内部CR発振器は結構根性があって一度発振できたら1.35V
くらいまで下げても余裕で動作するのがわかりました。電池一本で動きますよ。
さすがにJTAGのTCKの周波数は大幅に下がって1MHzくらいじゃないと駄目ですが。


動作可能なI/O電圧レベルを表にするとこんな感じです。最もパフォーマンスが
出るのは3.3VLVCMOS/LVTTLの時です。5VCMOSでは上述のとおり規格を一部
満たしていませんが動作する実力が確認されたので×ではなく△印つけています。
尤も相手がCMOSならば入力電流もMAX10uA位しかないでしょうから3.8V以上は
余裕で保てるので+5VCMOSでも問題ないですね。




そんなわけで長きに渡る戦いに終止符を打たせていただきます。ですがこれから先、
技術革新が進みTTL入力コンパチでなおかつ伝播遅延が3.3Vでも3nSec以下のすごい
バッファICが出たらまたJTAGKey2Compatibleの改良に取り組みたいと思います!



JTAGKey2Compatible Revision5
↑OpenOCDでSWDしたいときの追加回路もついでに追加しています。

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

                お詫び

私ネムイ・トリノミアスは国土地理院とgooglearthの規約を思いくそぶっちして地図
画像をぶち上げておりました。ここにお詫び申しあげますm( _ _ )m



何がダメだったかというと国土地理院の場合はカシミール3Dを使用して表示した画面を、
googleearthは同プログラムを使用してGPS軌跡を表示した画面をキャプチャーしたもの
をブログ上にそのまま上げてしまったことです。

国土地理院のほうは問答無用の完全アウツでgoogleearthのほうは以前はgoogleのロゴが
画面中に出ていればOKだったのですが
今はそれが完全に禁止され、使いづらいAPI経由
の地図表示でないと許されなくなっていました。
20160729追:
googleの方はくそ使いづらいAPIに苦情がありまくったらしく著作権帰属表記
がなされていれば問題なくなりました
。よかったよかった♥

というわけで11月くらいからせこせこと過去の東海自然歩道やGPS/GNSS関連の記事は
それらの問題に引っかからないように修正を今もし続けておりますすみません。

とはいえ国土地理院に関しては承認をもらえば逆に参照し放題となるのでこの際なので
正式に地図の使用承認をもらうことにしました。


●国土地理院の地図の複製承認をもらう
以前は手続きが恐ろしく難解かつ面倒で敬遠されていたそうですが今はある程度易しく
なっているそうです。しかしながら相変わらずのお役所処理なのでそこらへんのことは
しっかり理解して挑まないといけませんでした。

ねむいさんの場合、ブログ上でカシミール3Dで地理院地図を表示しさらにGPSデータと
高度データを追加で記載した画像、具体例をあげるとこんな画像をブログ記事上にて表示する
ための許可が必要ですが、これが法第29条「測量成果の複製承認申請」に相当します。

兎にも角にもこの"複製"が大前提です。では実際の手続きに入ります。

現在ではワンストップサービスなるもので申請が可能です。

このサイトの申請ボタンを押してスタート!…の前にユーザーを登録しなければ
なりません。なぜか先に進めてしまうのですが申請段階でログインしてないとエラーで
はじかれてしまいます######

右上のログイン画面へのところで新規登録ができるので先に必ずしておき、ログインも
済ませておきましょう。


申請に関しては「基本測量の測量成果」を選択し、次への矢印をクリックします

すると目的を聞かれますので「地図の作成」を選択て次へ。

最初で述べた「複製」を行いますのでここは「紙地図・空中写真をスキャン(コピー)
し、あるいはラスタデータ型の数値地図(地図画像など)をコピーして基図とする」を
選択してください。

複製目的は「インターネット等により情報を提供する」を選択。


ここから複雑になります。ねむいさんの使い方では上記のようにする必要がありました。

そして使用する地図ではカシミール3D上では電子地形図(タイル)を表示します。
電子地形図(タイル)チェックを入れさらにツリー下のすべてにチェックを入れてください。

「複製する測量成果の交付年月日又は地図の発行年次」は「すべて最新版」、
「複製の範囲又は区域」についてはねむいさんは日本全国を股にかけるので「日本全国」、
「複製の期間」は「一年間(※これを選ぶと承認日より一年分の包括申請となります)」、
「複製品の利用方法」は「Webサイト等での公開」、
「有償無償の別」はもちろん「無償」、
「複製品の部数」に関してはねむいさんはDropboxにファイルを置くので、「サーバー」に
チェックし、「1部」と記入します。


残りの項目は個人なら「不備があった時の対応者」以外は空欄で。
備考欄に「確認のやり取りはメールでお願いします」とすると電話連絡ではなくメール
のみで迅速に済ませられることができます。

これで申請ボタンを押して申請開始です。早ければ1週間ほどで承認番号を付与した
PDFファイルが登録したメールアドレスに送信されるでしょう。PDFに記載された指示に
従って作成した「成果物」を速やかに返信してください。webサイトの場合はその画像が
あるURL
を指定してください。
また、ねむいさんのようにやらかしてしまった人もかなり多く居るらしく、その場合は
速やかに指示に則ったフォーマットで画像を作成し差し替えるべしと指導を受けました。

また、審査状況は申請処理を行った後に現れる審査状況タブからも参照できます。


そんなわけでねむいさんも国土地理院の地図を堂々と使用することができるように
なりましためでたしめでたし♥あとカシミール3Dから地理院地図を表示しているので
ちゃんと"Powered by Kashmir3D"と使用ソフト表記も追加しております。




GCC ARM Embedded in Launchpadがアップデート
このぶろぐではデフォルトとなったLaunchpadのARM-GCCが予定よりちょっと早めにバー
ジョンアップしておりました。前回の更新は従来のGCC4.8.4からCortex-M7が追加された
だけだったのですが、今回はGCC4.9.3に上がっています。去年と同じくいつものを使って
さっそくlibjpegとlibpngのデコード速度の性能比較をしてみました!


libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
PNG : INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte

LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]
@1201_7z SDIO_NSMODE_LIBPNG1.6.15
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 492036 0 492036 78204 main.hex
***libjpeg
174817uSec
***libpng
157300uSec

LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]
@1201_7z SDIO_NSMODE_LIBPNG1.6.15
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 491948 0 491948 781ac main.hex
***libjpeg
181474uSec
***libpng
167060uSec

…イケてるじゃないですか(セルピコ顔で)

バイナリサイズは若干増加しましたがそれが気にならないくらいパフォーマンスが上ってます!
GCC4.8.4のSDIOのハイスピードモードでも勝つくらいの速さです。これはすごいです。


…と言いたいところですが!

なんと最適化が効きすぎてメモリマップドI/Oのアクセスがごっそり削除されてしまう
ケースが存在しましたorzこちらのディスカッションでも話題に上がっていますが、
プリプロセッサを経由したちょっとトリッキーなアクセスになる場合、すべて固定値として
処理されてしまいますorz

身近な例ではSTM32F1系の旧USBライブラリ(STM32_USB-FS-Device_Driver)が過剰な
最適化の影響を受けます。ここでUSBのレジスタの読み書きの部分がGCC4.9.3系で
ごっそり削除してくれやがるため、USB機能が一切機能しなくなってしまいますorz
たぶん新しいCube系ライブラリではマクロを多用した抽象化が極めて激しいためもっと
ヤバい事態になると思います。まぁそっちは使わないからどうでもいいですけど回避策
として"usb_regs.c"の全体を-O0オプションでコンパイルするようにpragmaをぶち込んで
事を収めました。

現在F1系のUSB機能使っている作例で公開しているのはSTM32Primer2 GPS/GNSS Tracker
のみなので、旧F1系USBライブラリをご使用の方はそちらを参考にしてください。
ついでなので関数ポインタの怪しい部分も明示的にvolatile化しています。




●年末恒例ねむいさんFAQ
ねむいさんのぶろぐを運営するうえでメールやコメント欄(業者対策で全く機能しなく
なってしまいましたが)、はたまた私が虹裏メイドとしてまっとうに本業をこなしてる時の
スレ上において、そして副業時などで頂いたさまざまなとんちんかんなご質問に対して
わたしがとんちんかんに返答させていただきます…


Q:いままで問題なく動いてたのに急に(ry
Q:OpenOCDが動きません。
A:私もOpenOCDがうまく動かないので困ってググってみたのですがこいつのサイト
 ばっかりヒットして非常に鬱陶しいです。なんとかしてくだち。

Q:(捨てメアドで)私は(日本語風の意味不明の文字列なので途中は割愛)
 したがってあなたは開発者なのだから使い方をわかりやすくまとめる義務がある。
A:ここを100000000回声に出して読んでください。
 なんですぐれたシステムとやらを納入してる実績をお持ちの割にはOpenOCDの使い方
 すら理解しようと努力せず丸投げしてくるのか理解に苦しみますがそもそもOpenOCDを
 業務で使用するほうが大間違いですがそれをやんわりたしなめたとたんに仕事じゃなくて
 趣味の遊びですから
とか言って逃げるのマジやめてくだち!

Q:ねむいさんのぶろぐをtwitterで薦めたらいきなりブロックされてしまいました(ニヤニヤ)
A:私のぶろぐを他者を攻撃する武器として使うのマジやめて。
 ルネサス系のマイコン、とりわけ旧日立系の産廃H8,SHをドヤ顔で使ってたくせに今更
 STM32にドヤ顔で乗り換えてきたようなハナクソみたいな周回遅れの意識他界系な方々の
 プライド最安値を刺激するのかほんとにヒット率高いです…でもそんなねむいさんも職業
 訓練のマイコン演習の際に生まれて初めて触れたマイコンはH8とイエローソフトのCコン
 パイラで、孫にあげるのはもちろんSTM32。なぜなら彼もまた、特別な存在だからです。

Q:ねむいさんルネサスのこと嫌ってるくせにルネサスのデジトラ愛用してますよね?
 い い え
 唯一使用していたFB1A4MはROHMのDTD123YKT146に置き換えました。そもそも
 NEC時代のFB1A4Mなのでノーカンですよぅノーカンうふふふ。
 これは独り言ですがルネサスの半導体のうち置き換えがきくディスクリートデバイス
 は早急に他社のものに置き換えたほうがいいです。旧NECエレの営業さんもROHM製品
 を進めてましたしねむいさんの好き嫌いの話ではなく突然使えなくなる事態が迫って
 いるので今からでも遅くはないですから急げ1!!!!!
 さて問題は置き換えが効かないV850とかのCPUですが、こちらも徐々にARMに変えて
 いこうと上司や社長に働きかけてます。すでにASICの代替でpsoc5採用になりましたし。
 正確に言うとルネサスが嫌いなのではなくルネサスの中にいる旧日立系の残党が大大大嫌いなのです。


Q:(回路図・コード・てにをは)が間違ってます。
A:すみません教えていただいてありがとうございます。直しました。

Q:何故がた老さんにあなた作の描画ライブラリのバグだしをさせているのですか?
A:ごめんなさいごめんなさい!!!!
 ちゃんとこちらでバグの箇所を見つけ修正しました。がた老さんいつもすみません。

Q:こんなバカな質問投げたのどう見てもあんたでしょ
Q:去年は年上にモーションかけてたくせに今年は年下かよ!
A:それわたしじゃありません!でも微妙に歳ごまかしてるように見えて他人のはず
 なのになんか自分のことみたいですごいヤですね…副業先でも話題になってしまった。
 突っ込みどころが多すぎて言葉に困りますがねむいさん
 じゅうよんさいからそっちの33歳の厄年なねむいさんに一言だけアドバイス送ります。

 自分のことばっか話すな。ちゃんと人の話を聞け###

Q:FETが焼けました。
A:焼いたFETの数だけ強くなれるはずです。
 わざと焼くと逆に弱くなります。

Q:(ハルロックの)ハルちゃんいいよね…
A:いい…
Q:そっちじゃないだろ
A:ハルちゃんいいよね…
Q:ケモナー↓キ↑モいんだよ(C.V.置鮎)
A:気づかれたくなかったのでな…(C.V.麦人)
A:マジレスすると表紙に気合入りすぎて表紙詐欺の同人真っ先に思い出しtウソウソ
 ハルちゃん可愛いよ。マンガ読んだことないけど。
 
Q:↑をぶろぐに乗っけるといろんな意味でヤバいんじゃないの
A:線画だけだととびぃぶろくんにバレなくてセーフなのに気付きました。
 たぶん肌色が見えたらアウトですね〜。
 来年は虹メらしく手描きを強化していこうと思います
 ↑後で知ったのですが作中でSTM32F4を使う描写があったそうで、
  ハルちゃんはSTM32を知っていることになり、この手描きは的外れでした。

Q:ねむいさんのぶろぐが会社/学校から閲覧禁止にされてしまいました。
A:おそらくあなたの上司のケモホモ嫌いが原因ではないかと
 至極まっとうな会社や学校だと思います。
 ねむいさんの副業先でも閲覧禁止されて自分のぶろぐ休み時間ですら見れませんから
 おあいこですよHAHA!
 …ウウッ!

Q:ねむいさんのスレにたまに現れなぞの呪文を唱えるこれは何ですか?
A:そんなのこっちがききたいです…"「」はお前を監視している"ということでしょうか…
 それはさておきKOUSHIROUさん主演のNHKのドラマがひどすぎて腹筋の筋肉痛が
 いまだに直りません…

Q:「ねむいさん」って名前の人ってBL好きな人がやたら多いのですが貴女も…?
A:twitterで一押ししてた方のマンガ買って読んでみたんですけど単なる"やおい"に
 ならず結構読ませる内容でしたよ…新たな世界が見えた…
 ってわけでわたくし虹裏メイドねむいさんは朝田ねむいさんを応援しています♥
 ねむいさんつながりですし♥


さて、そろそろ年越しそば作る時間になったのでこの辺で勘弁してあげましょう…
2014年も最後までドタバタ続きでまったく年が納まっていない感じですが
それでは皆様、よいお年を〜Zzz…

WVGAな解像度のTFT-LCDモジュールを動かす

私が最初にTFT-LCDに手を染めてからはや4年…もう4年も経っtグハッ


すみませんいきなり自爆しそうになりましたが時代の趨勢は大解像度化の一途を辿って
おります。電子工作で使用されるTFT-LCDも例外ではなくSTM32F4等の高速・大規模な
マイコンではもはや320x480(HVGA)な解像度は当たり前となっていますね。

それ以上の解像度の物は配線や駆動が面倒なRGBインターフェースの物しかなかったの
ですが2013年代後半からまた状況が変わります。なんと480x800(WVGA)なTFT-LCDモジ
ュールでも従来のi8080バス形式で使用出来るものが一般にも出回り始め、私も幾つか
入手したのでまとめて動かしてみることにしました。


●TFT-LCDのバックライト用LEDの話
かつて大解像度/大型のTFT-LCDモジュールにはバックライトに冷陰極管が用いられて
いました。しかし白色LEDの高性能化により冷陰極管にとって代わり、モジュール全体の
大幅な薄型化に貢献しております。また、点灯に必要な電圧も冷陰極管と比べて極めて
低いので感電の危険も無く安全に工作が行える利点もあります。


とはいえ大きな範囲を均一に照らすためにはLEDを複数個配置しなければならず、ムラ
なくLEDを点灯せしめるためには各LEDになるべく均一に電流を流してやる必要が生じます。
そういった点から大型/大解像度のTFT-LCDモジュールではLEDが直列に配置されている
(=全てのLEDに等しい電流を流すことができる)物がほとんどでこの場合はLED駆動用の
昇圧回路を組む必要があります。


私が選んだ昇圧ICはオン・セミコンダクターのCAT4240という品種です。
これは4〜8個の直列LEDを点灯させるのに最適で、回路構成次第で大電流駆動可能です。
後で紹介するWVGAなTFT-LCDたちに使用されているLEDは、6〜8個直列でLED全体の
Ifも20mAもあればいいので昇圧用コイルは電流容量の低い小さいものが使えます。



ほぼデータシートに即して回路図を作成し、LED駆動用昇圧ユニットを組んでみました。
+3.3VからMAX+28Vまで昇圧可能なのでLED8連でも余裕で対応できます♥
回路中で使用されているパーツは昇圧IC以外は同スペックの物が秋月で購入可能です。


●さぁ動かそう

先ずはこちらの5インチのTFT-LCDモジュールです。コントローラICはNovatechのNT35510
という品種です。インターフェースはi8080-16bitバスなので私のいつものと同じように
動作できるはずです。バックライトLEDは8連直列なので上で組んだ昇圧ユニットを接続
していざ電源投入!


…ぁぁ・・・
あああああああああああああああああああ!

保管の仕方が悪かったようで薄さも災いしてLCDを割ってしまったようですorzorz

↑かろうじて映る部分で動作を確認しました…さぁ次です次!!!



お次は4.3インチなドライバICがOTM8009Aという品種のものです。
24bitインターフェースですがレジスタの設定は16bitかつRGB565の設定も可能で従来
どおりの16bitバスに極めて近いため特に苦労はありません。こちらもLEDが直列の6個
使いです。

※これはいないさんです。
WVGAになると表示できる範囲も大幅に増えて大きい画像表示するのに便利ですね♥
・・・あり?どしたのですかそんな顔して?

けなげに+3.3Vから+18V近くまで昇圧を続けるCAT4240さん。コイルもCAT4240もまったく熱く
なっていないのでまだ余裕がありますね。ただし昇圧に使用する+3.3Vの供給源は1A程度
ひり出せられるくらいの余裕は持たせておいてください。



最後に4.3インチでIPSなTFTです。ドライバICはHX8369-Aです。こちらは解像度以外は
従来のHX8357系とまったく変わらず。一番使いやすく感じました(動かしてしまえば
あとはどれもほとんど変わりませんが)。Aliexpressでも購入できます。

※これはほむらちゃんではなくいないさんです。

※こ(ry
IPSなのでデジカメでとっても青っぽくならず発色がかなりよいですね〜




幾つか動かして思い知りましたがさすがにバラックでLED用昇圧回路込のボード組むのは
辛いので最初は面倒でも専用の基板起こした方がいいかもしれませんね。

言い忘れていましたが今回のWVGAなTFT-LCDモジュールの駆動に用いたのはおなじみ
STM32F4のいつものです。すでにソースコードに反映していますのでこれらのモジュール
を手に入れていても攻めあぐねている方の参考になるかと思います。今後もよさそうなのが
入手できたらラインナップにどんどん加えていくつもりです。

2.5元だったはずがいつの間にか5元に値上げしたかと思ったらさらに8元になり仕舞に日本で300円で売られているi2c液晶を動かす


約2年前、ねむいさんはtaobaoでピン配置以外詳細不明のi2c液晶を超破格値の2.5元で
購入しておりました
。その後なぜか急に8元に値上げしやがっておりましたが私は破格
かつ円安だったのを活用して30個くらいガメて以来殆ど動作させずそのままで放置。

が、

2014年の春、aitendoさんもこの液晶に漸く目をつけたようで一つ当たり300円で販売
しています。
さすが大陸店、阿漕っスね
このまま腐らせるのもなんなので誰かがこれを使って面白い物を作ってもらえるように
との願いを込めて込めて私の当時の解析結果を公開したいと思います。




●これはなんだ

これは今となってはごく一般的なドットマトリクス形式のモノクロ液晶です。インター
フェースはI2Cのみとなっています。プラ製の外枠はLEDをつけるくぼみのような
意味深なものも見受けられますがあまり気にしてません。

●だからこれはなんだ

なんなんでしょうねこれ…粘着テープ等でべったりつけられてるわけではないので簡単
に取り去ることができます。中華液晶は謎が多いです。


●マイコンとどうつなげればいいのか?
データシートに提示されているのはピン配置のみ…ほんっとこれだけです。
しかしその情報だけでも十分解析が可能です。


ここで閑話休題、I2Cというインターフェースについてですが…
ひとまず、I2Cの規格はNxPのサイトにPDFにて公開されていますのでしっかり確認し
ておきましょう。後述しますが最初はGPIOのエミュレーションの方が動作の把握が
しやすいかと思います。いずれの動作においてもオープンドレインで動作させるのは
変わらないため、SDA,SDLの各信号線にはプルアップ抵抗は絶対に必要です。

プルアップ抵抗算出式は Rp(kohm)>(Vdd-0.4)/3(mA) なので一般的な+3.3V系では
Rp > (3.3-0.4)/3 = 0.967(kohm)となります が、
100pFの容量で400kBps通信時の所要立ち上がり時間300nSecを考慮すると
Rp < 300(nSec)/100(pF) = 3(kohm)

計算上は0.967kohm~3kohmが適切な抵抗値なはずですが、1kohm付近ではドライブ能力が
低いF**KなI2C液晶だとACKがLowに引いてくれないことがあるので結局実測(オシロス
コープの波形)を元に安全値を求める羽目になります…めどい
BolyminのキャラクタI2C液晶を動かした際の実測は以下のようになりました。

(MAX400kbps通信時)
  1kohm ×
  1.5kohm ○
  2.2kohm ○
  2.7kohm ○
  3.3kohm ○

というわけで400kBpsでI2Cデバイスを動作させる際はプルアップ抵抗は2.7kohmが最も
適しているかと思われます。

ですが速度的に潰しの効く100kbpsまで落とすなら4.7kohmで吊っとけば大抵は問題は
ありません。…て言うわけで今回4.7kohmで行きます。



先ずは液晶と意識せず一つのI2Cデバイスと思い込んでI2CのACKが返ってくるアドレスを
サーチしてやりましょう。ほとんどのデバイスは8bit変数で示される範囲内なので捜索数も
少なくそんな時間がかかりません。
で、ヒットしたアドレスは0111_101xと0111_100xでした。ヒットしたアドレスを元にいろいろ
ググってみるとI2Cで64x96のドットマトリクスに適合したドライバICはUC1602Sが最も
近いのではないかと推測しました。データシートを見るとデータとコマンドのレジスタが
上記アドレスのとおり二つに分かれており推測が正しかったと分かります。


ここで改めてこのI2C液晶、"GG0906186FWNNC"を動かしせしめるための準備を行います。
ドットマトリクス液晶に必須のバイアス電圧を作り出すための電圧ドライバもUC1602S
には入っているので後はデータシートを参考にVLCD用のキャパシタを外付けしてやれば
おしまいです。具体的には上記回路図の要領でVLCDに0.33uFぶら下げればよいです。



●動かす!



使用するマイコン/基板は今流行りのSTM32-Nucleoボードを使用します。
初めて動作させる際は低速ですがデバッグがしやすいGPIOによるI2Cバスのエミュレー
ション(ソフトI2C)が良いです。上でも注意しましたが制御はすべてODです!あと裏ワ
ザになりますが、STM32の場合はGPIOを出力に設定をしていてもODで制御してREADの
際はポートをHI(=疑似トライステート)にしておけばターゲットデバイスから吐かれる
信号レベルがわかりますので入出力を切り替える手間が省けてオトクです★


…ていうかハードウエアI2C制御版のほうはF1/F4系と全く違ってて動かし方を見つけ
てる最中なので今しばらくお待ちください。


UC1602Sのイニシャライズのための呪文もねむいさんが既に調査済ですのでご安心く
ださい。ご覧の通りに無事表示が出来ました。
TFT-LCDで使用したFONTX2ドライバを使用しております。


これだけでは使いどころが分かりづらいので同じI2C接続のデジタル温度計STTS751
つなげて簡易の温度計をサクっと作成してみました。


特に危なげなく温度を表示することが出来ました♥
やっけつ配線ですがこういう出来合いボードは本当に便利ですね〜



今回のF0版Nucleo向けのソースコードはおきぱに置いておきます。圧縮ファイル内のlibフォルダにxMSTNというフォルダがあり、ドットマトリクス液晶の制御のためのコードが集中しています。
今回制御したUC1602SはxMSTN/driversフォルダにuc1602.cとして抽象化してありますので
別のマイコンやmbedに移植される方はご参考に。移植は容易にできるはずです。

デフォルトではSTTS751の制御はIF文で切っていますのでSTTS751をお持ちでない方も
aitendoさんから購入したi2c液晶単体でも動作確認が可能です。この液晶は動作電流が
かなり小さく、低消費電力な工作にもかなり使えるアイテムとなるでしょう。

I2Cネタは書きたいことが沢山有りすぎてまとまりがつかない状態です。特に怪しい中華製
I2Cキャラクタ液晶の電源投入時の変な動作とか回避のためのバスリカバリとかキリがない
です。ですが今回みたいなひょんなことをチャンスにして公開していきたいと思います。

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

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

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



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

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

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


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

いわれるものです。ARM本家のこちらこちらもご参照のこと。


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

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



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

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


libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
PNG : INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte

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

@@L1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496760 0 496760 79478 main.hex
***libjpeg
182341uSec
***libpng
168305uSec

@@L2222
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489144 0 489144 776b8 main.hex
***libjpeg
181903uSec
***libpng
168485uSec

@@L2222 (nano-lib)
(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 470620 0 470620 72e5c main.hex
***libjpeg
194318uSec
***libpng
234706uSec

@@L3333
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496752 0 496752 79470 main.hex
***libjpeg
182345uSec
***libpng
168311uSec

@@L4444
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489136 0 489136 776b0 main.hex
***libjpeg
181925uSec
***libpng
168588uSec

@@L5555
(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496152 0 496152 79218 main.hex
***libjpeg
186999uSec
***libpng
168740uSec

@@L6666
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 488592 0 488592 77490 main.hex
***libjpeg
187095uSec
***libpng
168490uSec







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

@@B1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555460 0 555460 879c4 main.hex
***libjpeg
183801uSec
***libpng
170161uSec

@@B2222
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555436 0 555436 879ac main.hex
***libjpeg
183797uSec
***libpng
170156uSec

@@B3333
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 553492 0 553492 87214 main.hex
***libjpeg
187582uSec
***libpng
170098uSec






SOURCERY CODEBENCH
arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.11-24) 4.8.1
@@S1111
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 504568 0 504568 7b2f8 main.hex
***libjpeg
184072uSec
***libpng
203915uSec

@@L2222
(Using newlib) -Ofast -msoft-float
=== Total Binary Size ===
text data bss dec hex filename
0 504040 0 504040 879c4 main.hex
***libjpeg
186811uSec
***libpng
203920uSec


かなり条件が入り乱れているので要点をかいつまんで紹介しますと、
まず"-mslow-flash-data"有だと、無しのものより逆にlibjpegのデコード速度が若干
下がるといった結果になりました。libpngはちゃんと速くなったのですが…全体的に
スピードアップすると思っていたのでちょっと微妙な結果です。
おきぱにて公開してるいつものはつぶしが聞くように"-mslow-flash-data"オプションは
デフォルトではコメントアウトにしてます。
↑2014年が明けて一週間たったころにようやくlibpngとlibjpegの評価をあべこべに書いて
 たの気づきましたすみませんorzちゃんと修正しました。
 "-mslow-flash-data"オプションを付与するとlibjpegでは逆効果になってしまいます。

またLaunchpad特有のnewlibをシュリンクしたnano-libを使用した場合、全体的なパフォー
マンスが低下することが分かりました。libjpegもlibpngもmallocを使用するので、そこに
パフォーマンスの違いが現れていると思われます。作成するアプリケーションの目的に
応じて使い分けるのがよいでしょう。

次に各コンパイラ比較ですが同条件(-Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16)
の場合、LaunchpadのGCCがサイズの小ささ/速度ともにトップになりました。さらに
Launchpadのは"-mfloat-abi=hard"も選択できる(Sourceryのはsoftしかない)ので、
もはやわざわざ登録してまでSourceryCodebenchを利用する意味が全くなくなりました。
皆様も早急にLaunchpadに乗り換えられることをお勧めいたします。

すぐにだっ!




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


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

Q:USB3.0でLibUSBが(ry
A:こちらをご覧ください
 USB3.0のホストのほうもファームやドライバの最新化は必須ですよぅ!

Q:いままで問題なく動いてたのに急にOpenOC(ry
A:変なことやらかした人に限って口をそろえたように"問題なく動いていたのに急に
 何ちゃら"は何らかのシンクロニシティなのでしょうか…???

Q:(ブラジルポルトガル語と思われるFatFsに関する質問)
A:Sorry,I cannot understand your language,at least in English.

Q:(簡体字中国語と思われるSTM32(←中国で人気のマイコンだそうです)に関する
  何らかの質問)
A:Sorry,I cannot understand your language,at least in English.

Q:(日本語と思われる文字列だが日本語としてまったく解読不能の何らかの質問)
A:Sorry,I cannot understand your language,at least in English.

Q:ねむいさんとか言うサイトみたけど役立つ情報が全くない上に何が
 言いたいのかよくわからないので
A:私もそう思う。特に今日の前半のとことか。意識他界方がこんなトコ来ちゃ駄目ですよ…

Q:OpenOCDのWindowsバイナリは配布されておらず
A:ここが見えないのですかここが!!

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

Q:ルネサA:帰れや!

Q:ギンギンに勃○してるのですが
A:ヤダモウ///

Q:ギンギンに○起してるのですが
A:ヤダモウ///
 これデザインしたの私と同性の方でしょうか…?
 本来のとは逆向きに付いてますし///

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

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

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

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

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







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

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

いろいろ試す19

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


●夏休みの工作・LPC4088

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

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

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

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

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




●Kinetis K20/K10シリーズを触る
わざわざ独立の記事にするほどでもない超小ネタなのでここでさらっと紹介します。
少し前にFRDM-K20なるボードが販売されましたがこのシリーズの一番小規模のチップで
あるMK20DX32VLF5MK10DX32VLF5をちょっと触りました。写真はK10のほうです。

K20はUSBと内蔵3.3Vレギュレータが付いてて本当にこれひとつで完結した基板も作れ
ます。実際に安価に製作されている方もいるようです。

ねむいさんがこれを単品で購入した理由はOpenOCDの書き込み/デバッグ確認のため
だけに過ぎません・・・が、このチップ特有の機能にちょっとはまってしまいました。

以前、私はKL25やKL05を触りOpenOCDへの書き込み/デバッグを可能にしてきましたが、
K10/K20もコアがCortex-M4(F無し)違いでKLシリーズと同じように楽勝だろうと高を
くくってました。しかしPOR後のウォッチドッグタイマの挙動が違っていてブート直後に
即効ウォッチドッグの機能を殺しにいかないとせっかく書き込んだのにセキュリティ状態に
突入してしまい、mass-eraseして解除してからGDBからイメージをもう一回ロードしないと
デバッグできない事態になることが判明!

工場出荷時はセキュリティ状態は解除されてるらしいですがこのウォッチドッグリセットの
せいで実質セキュリティ状態になってる為STLink/V2などのMDM-APを直接叩くことが
不可能なデバッガハードウエアでは手詰まりになってしまいます・・・ぬぎゃー
(これFRDM-K20が国内販売されたらまたねむいさんのとこにプログラムが書けなくなった
 って質問飛んでくるんだろうなぁ・・・・)


●EFM32シリーズもおさわり
同じくOpenOCDの書き込み確認のために単品購入したチップです。EnergyMicroという
メーカのチップでしたが現在はSiliconLabs社に吸収されています。

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

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

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




というわけでOpenOCDのバイナリには上記3品種の書き込みcfgファイルを追加してます。
パッチも前回から不備が見つかったものをさらに改修してますので私と同じ環境をお
持ちの方は試してみてくださいね〜
・・・すっかりOpenOCDありきのマイコンいじりになってしまいましたが実務ではルネサ
(日記はここで途切れている)

いろいろ試す18

GW中は副業(本業は虹裏メイド)が糞ほど忙しかったのですがおかげで給料も貯ま…
るわけがなく円安を迎えた今はひたすら安価な小物や以前に買った物をただひたすらに
消化していきまっす!

●秋月さんとaitendoさんのi2c液晶キャラクタ液晶モジュール

ぇ?昔i2c液晶の記事書いてたやんだって?さぁ?何のことですか?
これのこと?これはキャラクタじゃなくてドットマトリクスですから別物です別物!

…さて、ホビー用途では配線の手軽さから不動の地位を確立したi2c液晶ですが秋月
さんから安価でスリムなAQM0802A-RN-GBW
が発売され私もi2c液晶でびぅです♥

コントローラはST7032iというi2cインターフェースに特化したものだそうです。
BOLIMYINの提供していたサンプルのおかげで危なげなく表示出来ました!


お次はaitendoさんから販売されているバックライト付きで破格のi2c液晶たちです!
もう基板に組み込んでますが、秋月さんのと同じくST7032iのコントローラICで
簡・単・表・示…
…と思いきやO-Familyさんも遭遇したF**Kな不具合にねむいさんも遭遇し,"i2cバス
リカバリ"の重要さを思い知らされる羽目になったのでした…
(※STM32F4のFatFs実装例ではすでにi2cバスリカバリのルーチンを実装しております)

これについてはいずれ解説するであろう"i2c液晶を使ってみる"でみっちりと…


●OZSSとGLONASS対応のGPSモジュール Gms-g9


去年の冬,Gms-g6aというMT3333が乗ったモデルを使用していましたが、チップアンテナ
を使用しているため、せっかくの新モデルなのに初回補足時間/感度はあまりよろしく
ありませんでした。4月末に某送料が安い方の欧州店でパッチアンテナモデルのGms-g9
がようやく販売され、遅ればせながら私もゲッツした次第です。

既に使用されている方のレポートによれば消費電流もPA6Cよりはちょっと多い(GLONASS
の処理があるから)ものの十分控えめなのでSTM32Primer2のロガーと組み合わせても
私のトレラン用途には全く問題ないようです。私はすでにGms-g6aで予習していたので
ロガー側もGN系センテンス対応済みでそのままPA6Cと差し替えて試せそうです。

というわけでいつものユニット化してみました。いちばん右の黒いのがGms-g9です。
PA6Cよりもパッチアンテナの面積が広いので感度はさらに上がっているでしょう。
あいにく今週から梅雨に入ったのでPA6Cとの比較試験は来週以降、トレランでの実践
投入は6月末を実施予定としています。


●ILI934x Mystery
SPIモードでDeviceCodeの読み出しができるようになるまでのお話。
Seeedstudioの中の人がいかにしてデータシートに記載されていない複雑なコマンド
体系を見つけだしたのかはいまだに謎
それとねむいさんの英語力に突っ込みを入れないように!!!




●LPCLink2


LPCXpressoに密着していたLPCLinkはirukaさんの解析によると変更不可能なOTPによっ
て機能が限定されており外部から全くhackすることが出来ずどっかのSTM32では出来た
DiscoveryでVersaloonが出来ないじゃない!と判明しごくごく一部の解析大好きな
好事家からはったくNxPはセコイな!とスル―してゲフンされておりました‥

が、

今回デバッガハードウエア単体として販売されたLPCLink2は回路図全公開、さらに
ファームウエア変え放題でしかもCMSIS-DAPやJlinkファームウエアまで用意している
という超太っ腹なボードとなっておりました!

ねむいさんも秒速で入手しその威力を早速試してみました…

電圧変換は前回紹介した74LVCxTx45系が使用されています。LPCLink2ではDIRを入力
に切り替え疑似的にOD化し、1.2〜5.5Vの非常に幅広い電圧範囲をカバーしているようです。


…LPC4370…?


ねむいさんの目的はJ-Linkです。ほかは一切視界に入れません。THE・シカトです。
そっこう中身のファームをDFUでJ-Linkにしようとしましたがホントの最初はドライバ
不要のHIDローダーで認識されDFUをさらに読み込むようです。この時にDFU用のWinUSB
ドライバ
を読み込ませていないとJ-Linkへのアップデートに失敗するのでご注意を。

WinUSBドライバを読み込ませてこれでJlink化完了!



…ぇっとOpenOCDとかで使ってみましたが‥JTAGKey2と比べるとワンテンポほど反応が
遅くてちょっと微妙な感じです。無理にOSSで使うよりSegger提供のツール使った方が
いいかもしれません。ファームウエア(spifiに格納される)はいくらでも書き換え出来る
のでいろいろやってみましょう。…そう自分で作成したプログラムも…
20130603追:
やっぱりJlinkエミュレーションのファームヤバかったようで
修正版が2013.05.31にUpしてます…。


で、LPCLink2にはTargetのJTAG端子のほかにLPCLink2の心臓部のLPC4370からもJTAGが
引き出されています。LPC4370って検索しても2013年5月末現在は詳しい資料全く出て
いないしLPC4350系のメモリ多い版かしらと思って何気なくUrJTAGで引っ掛けてみると…


なんとコアが3つありました…
CortexM4とCortexM0が2つの合計3コア…
トリプルコアなの!?



次回に続く!!

Amontec夜逃げ記念☆JTAGKey2互換回路をもっと使ってみる2

20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。

20150514追:



数年前、FT2232Hを利用したJTAGkey2Cloneの紹介をしました。しかしちょっと自分で
も回路上で疑問を感じる点が多く、かねてから再製作の構想は考えておりました。
昨今のロジックICの性能向上も相まって2013年の今、再び満を持しての再製作となり
ました…最初に書いたのもう3年前か…もう3年も経ったの…さんねんも……


ゲフン失礼、前回は単に回路図と実に抽象的な使用例を紹介しただけでしたが今回は
どうしてそういう部品選定or回路に至ったかのねむいさん的ポリシーも述べます!

●肝心な回路図は…
実は少し前から公開していたのですが…以下のリンク先"JTAGKey2"のディレクトリ内
にあるpdfファイルが新しいJTAGKey2互換回路の回路図となります。
FT2232Dを使ったJTAGKey無印の互換回路も2009年当初のままですが下記リンク先の
"JTAGKey"のディレクトリに収録していますので同じくご参考までに。
JTAGKey or JTAGKey2Compatible Circuits

神木さんのJTAGKey2互換を参考にして作ったねむいさんのJTAGKey2互換を参考に
して作ったjujurouさんのJTAGKey2互換を参考にした最終形です!

そして以前使用していた"Clone"という単語は以下の理由でそぐわないのでもう使わ
ないようにしました。これからは"互換(Compatible)"で統一といたします。

●オリジナルのJTAGKey2との差異
夜逃げしたAmontecから販売されていたJTAGKey2純正品とは機能面で差異があります。

1.暗号化EEPROM(DS2432)の有無
 これはオリジナルではFT2232のB側のバスのどれかに接続され、Amontec社が提供し
 ているamthal.dllはここから書き込まれた情報を読み出し正規品判定を行っていま
 す。digilentの"JTAG HS-1"もそれと似た仕組みで判定を行っているようです。

2. LEDインジケーターの設定
 ねむいさんのJTAGKey2CompatibleのLEDの設定はJTAGKey無印をベースにしています。
 JTAGKey2で変更になったLED表示とは全く合っていません。

3. Lattice-ISPVMの使用可否(OE強制制御)
 Lattice"さん"提供のISPVMは数年前にFT2232系デバイスからでも書き込みができる
 ように神対応をして下さいました!!しかし純正のJTAGKey2からはOEの手動コント
 ロールが不可能(MPSSEを強制直結状態にできない)のため蓋をこじ開けてジャンパを
 飛ばさない限り使用不可能です。

OpenOCDやUrJTAG等のフリーなツールでは純正/互換品に関わらず同じ"JTAGKEY"と
して扱われるのでまったく問題なく使用が可能です♥


●回路解説
いくつかのブロックに分けて主要部の解説をします。

 1.FT2232H周辺
  JTAGKey2互換初号機と同じくDLPDesignのDLP-USB1232Hを使用しています。
  面倒なUSB-HS周辺やFT2232系で必須なEEPROM等の周辺部品を搭載しモジュール
  化されており非常に簡単に扱うことができます。
  今だとUM-232H等のFT232Hを使ったモジュールなども使用可能と思われます。
  ただTx/RxバッファがFT2232Hよりも少なく処理速度に影響しますので、その点は
  ご留意ください。

 2.電圧変換(電圧レベルトランスレータ&バッファ)
  JTAGKey2互換回路の心臓部です。ここで+1.4V〜+5.5Vまでの幅広いターゲット電圧
  に対応します。前回は+1.65Vからでしたが昨今のロジックICの性能向上に伴いサポー
  トされる電圧範囲の保証される下限がさらに下がりました。それ故に型番どころか
  製造メーカ指定まで必須となります。ねむいさんのぶろぐ見てる人は同じ74シリーズ
  の同型番でも製造メーカー間で性能が微妙に違うという昔からよく知られている事実は
  常識中の常識のはずなので理解していただけるかと思います。
  "DIODES Inc. Semiconductor” の74LVCE1G125"、NxPの"74LVC2T45DC"を
  指定して使ってください。他のメーカーの同機能品は駄目です!

  また、各バッファICに繋がりFT2232Hから制御されるOEの制御線は必ず+5V(回路図
  中ではVbus)で攣ってください。JTAGKey2をPCと接続したときのこれらは入力/Lo出力
  の疑似的なOD扱いで制御するPC側アプリが多く、+5V系で攣っていないと+2.5V付近
  の中間電圧が掛かってしまい動作不良の原因を作ってしまいます。

  jujurouさんが指摘していた+5V系の動作の考察についてはさらに掘り下げて別枠で
  考察させていただきます。


 3.ターゲット電圧検知
  こちらに関してはJTAGKey互換のころと同じく元NEC現ルネサス製のデジトラ
  使用しています(ねむいさん的定番部品です)。

  ↑Rev.4でルネサスを排除しました。使い勝手良かったのですが…さらばFB1A4M。
   代替としてROHMのデジトラDTD123YKT146を指定しております。
  ↑Rev.5に回路が変わりました!

 4.OE強制制御
  切り替えスイッチで無理やりバッファのOEをGNDに落としてMPSSEで使用される
  ポートをターゲットと常に直結状態にします。これは上述のとおりLatticeのISPVM
  やデバッグ用途で活躍します。3Pの少信号用SWならなんでも使用可能です。


●実際に組んでみよう


今回はアイテムラボさんのパワーメッシュユニバーサル基板を採用しました。
本来ならVCCに使うべきレーンもすべてGNDに割り当て高速信号の扱いを意識して
配線を行いました…行 っ た つ も り で す ! !


前回はFT2232Hのモジュール上部が吹きさらしで打撃を喰らいやすい危険な構造でした。
今回からアクリル板を加工して屋根を設けました。いい感じですね♥


10MHz越えの高速信号を外に引き出すので信号線とGNDが交互に来るフラットケーブル
は必須です。さらにSEIWA製コの字型フェライトコアを設けて外来/輻射ノイズを殺す
ようにしています。

もともとチップバリスタも基板上に実装するつもりでしたがフェライトコアだけで100V/1uSec
のインパルスノイズ耐量試験を余裕でpassしてしまったのでチップバリスタは未実装の
オプション扱いにしました。

一からJTAGKey2Compatibleを作る場合は初めにPCと接続したときにVID/PIDがFTDI
の素のFT2232Hとして認識されます。FT2232Hモジュール上のEEPROMにデータを書き
込むために先ずはFTDIのドライバを認識させてください。JTAGKey/JTAGkey2製作用に
特別にinfに書き加えたもの
を用意しましたので必ずこちらを使用してドライバを読み込ま
せてください。2じゃない方のJTAGKeyを作りたい方もこのドライバを使用可能です。


JTAGKey2Compatibleとして動かすためにはEEPROMのデータを書き込んで化かさな
ければなりません。従来はMProgを使用してデータを書き込むようにしていましたが、
現在はFT_Progに統一されましたのでこちらを使用してEEPROMにJTAGKey2になる
ためのデータ(xml)を書き込みます。上のドライバにはJTAGKey/JTAGKey2用のxml
データもJTAGKey_XML.7zとして収録していますのでこれを使用し書き込みを行って
ください。FT_Progの使用法についてはFTDI公式のマニュアルを参照のこと。

業務連絡:
野田様、FTDIドライバをWin8対応に更新しURLも変更しましたので直リンク先を
このページに変更願います。


書き込みが終わったらUSBケーブルPC一度抜いてさし直してください。成功したら今度
は"Amontec JTAGKey2"として認識されます。

その後はlibusb系を使いたい場合はおなじみZadigでインストールを、FTDIのドライバを
使いたい場合はそのままとしてください。

注:LibUSBKはドライバの入れ替え無しに0.1系と1.0系APIが同時使用可能な便利な
  ドライバですがWindowsXP下ではあらかじめ0.1系のドライバをインストールし
  ていないと動作が不安定になるようです。一度0.1系でインストールしすぐに
  LibUSBKに戻せば問題なく使用可能です。この操作もZadigを使うと楽ちんです



製作したJTAGKey2の動作確認を簡単にしたい場合はOpenOCDよりもUrJTAGが便利です。
ターゲットデバイスに接続して"cable jtagkey"->"detect"のたった二つのコマンドで
JTAGチェインが見えればチェック完了となります。さらにpodコマンドでSRST,TRSTを含めた
JTAGの信号線単体の個別コントロールも可能なのでトラブルシュートにも役立ちます♥


●ちょっとしたデザインレビュー
20150512追:
以下の検証はRev.4以前のモロが問題だった頃の回路の内容です。
Rev.5にてオリジナルJTAGKey2のサポート電圧範囲に忠実になりましたので現在は
モロで問題有りません。
20150512追:







さて、実際に信用に足るJTAG用デバッガとして使うためにはいくつかクリティカルな
条件を設け試験する必要があります。JTAGkey2互換回路では大きく分けで2つの考慮
すべき点があり、どちらも回路図中の電圧レベル変換ブロックに集中しています。


1.電圧入力レベルに関する点
FT2232HのI/Oの電圧はMAX30Mbpsの高速信号を扱うため+3.3V系のLVTTLと呼ばれる
電圧レベルで固定化されています。(FT2232D系だと3.3V〜5Vで可変だったのですが)
これを考慮してかFT2232Hは+5VI/Oトレラントとなっており+5V系の入出力に対して耐性を
持っています。ですのでFT2232Hの+3.3V出力に10kohmで+5Vにプルアップする程度
の衝突ならびくともしません(この荒業は疑似的なOD制御の時に役に立ちます)。
また、SRST,TRST,JTAG各信号線のゲーティングをしているバッファICのOE端子は
FT2232H側が疑似的にOD出力の形で操作しているため、常に+5Vで吊るのが正しい
です。(FT2232H,74LVCE1G125,74LVC2T45のいずれも+5Vの入力トレラントを持つ)


本回路中で使用されている74LVC2T45DCは+1.2〜+5.5V,74LVCE1G125は+1.4〜+5.5V
までカバーしており、何れも+5V入力トレラントも保証しています。つまり+1.4〜+3.3Vまで
の回路の場合は電圧入出力とも全く問題はありません、しかしターゲットが+5V系のケース
では74LVCE1G125のHレベル入力下限(3.5V)を満たしません。
こちらについてはjujurouさんの情報をもとに74AHCT541(※)を挟み、LVTTLから+5VCMOS
の電圧変換を行うことによって電圧レベルの問題は一旦は解消としました。
…しかし…

(※…NxP製の物は74AHCT541と74VHCT541の特性は全く同じ)


2.信号の伝達遅延に関する点

74AHCT541を挟んだことによって同素子内部のゲートを通過する際の遅延が余分に追加され
ることになりますが、最初に組んだときは204MHz動作のLPC4330とTCK=15MHzで接続し、
周囲温度も十分振って安定して書き込みデバッグできたので問題なし!としていました。


ですが純正JTAGkey2がサポートしてるのが30Mbpsだったのを思い出し"本当に30Mbpsで
通信できるのか?"と感じ、購入後放置していた公証80MHzまで使用可能なSPI-ROM
SST25VF032B-80-4I-S2AFFlashROMを使ってTCK=30MHzで読み出し試験してみました
が、リードしたデータがすべて1bitずれた状態となってしまい玉砕orz
…というわけで真面目に伝達遅延の影響について考察を開始しました。


ターゲット電圧3.3VでTCK=30MHzで通信した際に一クロックサイクルは33.33nSecであり、
FT2232HのTCKからでたクロックがターゲットのTCKに届き、それに準じてターゲットMISO
からの出力とFT2232HのTDO(SI)に届くまでの時間の合計が33.33nSecを超えてしまうと
ビットシフトした状態でデータが取り込まれアウトになってしまいます。

データシート記載の使用温度環境-40~+125度で動作させた場合(データシート上で明記されて
ないものは一番条件が絞れてる温度範囲)のパラメータを抽出して計算すると上図のよう
に33.33nSecを余裕で超える遅延が発生することになり74AHCT541を挟むと30Mbpsの
通信が理論上ですら不可能なのが判明orz


74AHCT541を省くと7.0nSec分遅延がなくなるため30MHzでもビットシフトは起こらない
計算になり、実際に74AHCT541を省いたモロにするとSST25VF032Bと通信(DeviceID
の取得,書き込み,ベリファイ)が問題なくできることを確認しましたorz
やはりモロでなければだめだったのですorz

それと配線の引き回しも非常に重要です。10cmを超えるような引き回しをすると上記
のモロでも駄目でした。また、FT2232Hモジュールからレベル変換ICを何も挟まない
ガチの直結も試しましたが10cm以上を超えるとやっぱりだめです。30Mbpsで安定して
通信を行うためには高速クロックで動作する回路を意識しないといけませんね。

PicoScope3206AでTCKの波形取得してみましたが74AHCT541付きの波形は
見るからにちょっときつくなってますね…。

↑15MHzの時のSPI-ROMのTCK波形(74AHCT541付)

↑15MHzの時のSPI-ROMのTCK波形(モロ)


↑30MHzの時のSPI-ROMのTCK波形(74AHCT541付)

↑30MHzの時のSPI-ROMのTCK波形(モロ)


ここでちょっと疑問に思ったのですが市販のFT2232H系のJTAGハードウェアは本当に
30Mbpsで動かせられるのか?という点です。10MHz以下までTCK速度を落とさないと
OlimexのARM-USB-OCD-Hでは安定して書き込みできないという報告
もあり、もしかして
それらはレベル変換にFT2232D系で使用されていた低速なLV系バッファが使われ続けて
いるのではないのかと訝しんでしまいます。純正のJTAGKey2ではどうなんでしょ??
さすがにできるはずですが…???


3.モロへの誘い
で、ここで74AHCT541外したら3年前作ったのと全く同じじゃん!とお思いの方が多い筈です。
それは引っ込みがつかなくなったねむいさん本人が一番強く感じています。

というわけで癪なのでモロで動かしたときに+5V系で本当に問題がないのかの実力
検証を行いました。

使用MCU:
 ->ATMEGA1284P
動作電圧:
 ->+5.65V(安定化電源にてAVRの推奨上限+5.5Vにさらに+0.15Vのマージンを加える)
試験環境温度:
 ->-15度~+70度
  (-15度はコールドスプレーでJTAGKey2互換回路基板上をくまなく冷却,
   +70度はドライヤーで同基板上をくまなく加熱)
試験内容:
 ->試験環境温度下でATMEGA1284pにOpenOCDを試用しJTAGモード(TCK=10MHz)
  で100kByte程のプログラムの書き込み動作を行いその動作中にJTAGの
  通信エラーやフラッシュの書き損じが一切出ないことの確認。

  JTAGモードにした理由はAVRの場合はコア電圧/クロックに関わらず10MHzの
  高クロックでAVR内のOCDブロックとの通信が可能なためです。

結果:
 ->全く問題なし。
  現行のAVRドライバはread動作を行うとOpenOCDごと落ちるステキ仕様なので上記環境下で
  JTAGKey2をISP端子につなぎ変えたうえでAVRDUDEにてISPモードで読み出しを行い、
  さらに読みだしたhexをOpenOCDでJTAGモードでフラッシュの全領域消去->書き込み。
  そこから再びAVRDUDEでISPモードで読み出しを行いhexファイルの完全一致の確認を
  もって問題無しと判断しました。


てわけで電圧/温度/TCK速度とも一番厳しい状況を作り試しましたが全く問題は
ありませんでした!試験で使用したOpenOCDはatmega1284pのフラッシュ書き込みに
対応させた奴
使ってます。ログは↓こんな感じです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/atmegaxxx4p_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00011-g70a2ffa-dirty (2013-05-11-14:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10000 kHz
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
verify Capture-IR is disabled
Info : max TCK change to: 30000 kHz
Info : clock speed 10000 kHz
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
auto erase enabled
Info : device id = 0x1970503f
Info : target device is atmega1284p
wrote 113408 bytes from file main.elf in 4.453210s (24.870 KiB/s)
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
shutdown command invoked

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


同じくAVRDUDEはFT2232系MPSSEに正式対応した6.0RC1をビルドして使用しておりま
す。JTAGKey2があれば難しい設定もワークアラウンドも必要なくARMもAVRも余裕で
書き込みできるようになっていい時代となりました♥


+5V系でAHCTバッファ挟まなくても問題なかった理由は、74LVCE1G125のVthが実際は
中間電位の+2.5Vで切られていてそれさえ跨げばちゃんとレベルが遷移できていたから
と推測します。データシート上の規約におもいくそ違反してますが実力/マージン共に十分
あることが確認でき自分が理解して使用する範囲ならモロでも全く問題なしと判断しました。
(↑売り物の製品の設計の時はちゃんとデータシートに記載された指示/定格をすべて
  守ったうえでみっっっちり動作テストを行うのが大前提です!)


もちろん保証の範囲外なので、他のメーカの同種型番のIC等では入力にヒステリシス
が設けられて全く動かないかもしれません。真似して製作される方は回路図中でねむい
さんが指定したICを必ず選定してください。「違うメーカのレベル変換ICをどうしても
使うんだーぃ!」という方はご自身で動作検証を念入りにした上で使用してください。
念入りというのは回数だけ無意味に重ねるだけではなく温度と電圧くらいは最低限振れ
という意味です。ベストな環境だけで満足すると後で絶対にしっぺ返しがきますから…。

ということで74AHCT541はオプション扱いにとどめ、TCK=15MHz以下でしか使用しなく
て電圧的に心配な人だけ付けてね!ていう風にして冒頭の回路図に最終的に落ち着く
運びとなりました。めでたしめでたし。


20150210追:
+5V系の時の74LVCE1G125の挙動をもう少しガン掘るトしてみました。

VCC=+5.5Vにして入力をわざとゆっくりと上げ下げした時に実際に何Vで出力信号
が遷移するかという実験をしました。

先ずは立ち上がり。2.5Vできっちり信号が変化しだしているのが分かりますね。
2.5V以降の途中で波形が乱れている件は後で解説します。

お次は立下り。こちらも2.5Vで信号が変化しだしています。

本来ならばCMOSロジックの場合はVthはVCCの中点で本実験の+5V系上限値+5.5V
の場合は2.75ボルトになるはずですがLoレベル寄りの2.5Vとなっていました。
実際に使われる+5.0Vで換算すると74LVCE1G125の真のVthは2.27V付近となる
ことが容易に分かります。FT2232Hの+3.3V出力直結モロでもドライブ能力を十分に
強化して電圧降下を起こさなければVthをまたいで1V近くのマージンを確保できるので
電気的には全く問題がないことが分かります(※FT2232HのI/Oドライブ能力を最弱の
4mA設定にしても30MHzでぶん回しても問題ありませんでした)。

そんな訳でホビー用途ならAHCTバッファ無しのモロで十分であるという結論とさせて
いただきます。逆に売り物にする場合は今回のロジックICに限らずデータシートに記載
されている事項をすべて守った上で周囲環境条件を十分に振ってみっっっっちりテスト
しまくって最終的にどういう仕様に落とし込むかを慎重に決めてください。
大切な事なので二度言いました。
「ねむいさんのぶろぐに書いてある通りに作ったおれはしらん」とかいう奴にエンジニアの
資格は無いです。

また両者の波形とも遷移直後に大きく出力波形が乱れていますがこれは入力スルーレート
の規約(5V時5ns/V)に違反しているからで、遅すぎる速度の入力によって発振が起こ
っています。上記の測定結果は入力をオープン(殆どのケースで中間電位になる)にして
いると出力が発振を起こして予期せぬ誤動作に繋がるという重要な事柄も示しています。
CMOSの入力は吊るか落とすかどっちかはっきりと!


最後にスルーレート規約も守ったうえでVCC=5Vで3.3Vドライブした時の波形の例を。
VersaloonのSWCLK波形を入力にしています。ご覧のとおり問題なく電圧の遷移が出来て
いることが分かりますね。

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

●LPC812Xpressoを試す


Cortex-M0+コアが搭載されたLPC800シリーズ。この評価基板ではLPC812が使用されて
おります。またLPC1114系にはないファンクションマルチプレクス機能などがあり、柔軟
なプログラミングが可能です(と言ってもSTM32の第二世代以降はかなり柔軟なリマップ
が出来るので物珍しいことでもありませんが‥)


さて、裏返すと見てはならない物が視界に入ってしまいましたが気を取り直して
即分離してSWD接続のVersaloon+OpenOCDしてみました。…しかし…


ぐは…だめだ2番目のセクタ以降が書けてない…
OpenOCDのソースコード中にあるlpc2000.cにLPC800系のドライバ追加しましたが
フラッシュメモリの構成がLPC1000系と全く違うのでやっけつじゃむりですね…
年明けにでも本腰入れてOepnOCDのソース掘ってみますかー!


aitendoさんのANUXを試す

ねむいさんもご多忙にももれず買ってしまった…
え?この前のあれはどうしたって?
通電しっぱなしで放っておいたらDCDCと思われる部分が死んだので捨てました‥



さぁ通電だ!
>ANUX基板の電源スイッチ(SW1)を3秒ほど押して、1秒ほど画面が表示されます。
だそうですが早速出ましたね★

おおっ!Androidが起動しました♥


無事起動を確認したので他の人柱の報告待ちと行きましょうか1!1!!
さぁ次です次!!


●STM32EvoPrimterのその後

↑こうなりましたorz
リチウム電池を通電状態でうっかり放置してしまったため
放電終止電圧を大幅に下回って液漏れを起こしてしまった模様ですorz
漏れ出た電解液が基板に浸出してビアや部品の足を浸蝕していましたorz

てわけでかろうじて生きていたLCDだけ回収して荼毘に付して次です次!!1




●よくいただく質問とか
去年と同じく尺が余ったのでメールやコメントよくいただく質問に対する回答を
していきたいと思います。

Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:あのさぁ…イワナかった?
 ねむいさんのOpenOCDのバイナリは上記の対策済みなのでこちらをお使いください。
 
 また、どこぞの与太者がビルドしたものなんて使いたくない!!
 なんて人は帰れよこちらの方法を試してみるのもいいと思います。
 …でも面倒ですよねぇ…FPレジスタのサポートなんてまだまだ先ですし…
 諦めてねむいさんがビルドしたバイナリ使いましょうよ…
 ちゃんとNOD32とAVASTでウイルスチェックしてますから♥(←しつこい)


Q:いままで問題なく動いてたのに急にOpenOCDが繋がらなくなってフラッシュ書き込みが
 できなくなった!!1!!なんとかしろ!!!!
A:分かりましたから落ち着いてください。たぶんJTAG(若しくはDAP)へのクロックが
 WFI命令等で供給を断たれてOpenOCDから繋がらなくなっただけです。
 現在のARMマイコンにはほぼ必ずシステムメモリからのブートローダが内蔵されてい
 ます。そちらから起動してメーカ提供のUARTブートローダ等でフラッシュを全消去
 して電源をOFF->ONしたら回復します。


Q:ねむいさんのステッピングモータドライバの回路図でFETのドレイン-ソース間に
 保護素子が付いていませんがほんとに設計の仕事してるんですか?
A:アバランシェ耐量でぐぐりなさい!1!!


Q:動力線の接点不良が心配なので丸端(丸型圧着端子)を圧着せずに半田つけで接続
 しました(^^)これで大丈夫!
A:やめれ!
Q:なんでですか?半田つけなら確実じゃないですか!
A:熱サイクルで半田の接合部が徐々に劣化してそこの部分で発熱し出すから駄!目!
Q:先生は信頼性の高い半田つけの方が‥
A:あの…学校の授業で圧接の仕組みとかハーネス設計とかもやるべきだと思いますよー
↑つうかこれマジでヤバいのでちゃんとかしめ工具で圧着しましょうね。


Q:AWG22だと300Vで8A流せますね。てことは24Vだともっと流せますね!
A:なわけないでしょ…300Vってのは絶縁耐圧でそのAWG22とやらは300V以下のどの
 電圧でも8A以下ですよぅ…てかUL番号何番の電線ですかそれ…


Q:XXのシステムを設計してくださいorXXをしたいのですがプログラムを提示
 してください。以上。
A:ねむいさんかいないさんの可愛いイラスツと等価交換ですね…!(ニーサン風に)
 えろすな奴だとサポートつきです♥


Q:twitterで参考になるサイトとして"ねむいさんのぶろぐ"をすすめたら
 相手にいきなりブロックされました…
A:ねむいさんは素のEclipseが存在しない世界に生きているので素のEclipseで攻撃
 されると反物質世界の住人のテレサさんのごとく爆発して死ぬ体です。Eclipseが
 好きな方から見ると仏敵に見える可能性があります。気を付けてください。とくに
 ARMマイコン使い慣れている方ににコメントを行う際は言葉を選び注意を払いましょう。
 ちなみにメーカお仕着せなEclipseベースのIDE等はちゃんとチューンされているので、
 ねむいさんは爆発しません…。


Q:虹裏メイドってなんですか?
A:お笑いの集団です。
Q:某同性愛者向けAVに登場する人物がねむいさんと言うことになっていますが?
A:ララバいさんはそんなこと言わない




…はぁはぁ…だいぶ疲れてきましたので今年はこのへんで勘弁しときますよぅ‥
それでは皆様、よいお年を〜
Zzz…

いろいろ試す14

●余ったAT90USBKeyをPDI接続のXMEGAライタとして使う
AT90USBKeyは(元)主人の遺品の一つでしたが引き継いだ私がSTM32をはじめとした
32bitマイコンに完全移行した今、もう必要ないかと捨てるつもりでした。
しかしLUFAの成果物の一つにAVRISPmk2の実装があったことを今更知り、XMEGA専用の
フラッシュロムライタとして再生することにしました。

XMEGAにあるPDIインターフェースはCortex-M系のマイコンにあるSWDとよく似ていて
2線式で書き込み・デバッグを行うことができます。しかもXMEGAの場合はJTAG接続よ
りも書き込みスピードが速い(ATMEL曰く)のです!!


ATUSBKey上のAVRISPmk2の実装はPD2&PD3(PDIDATA),PD5(PDICLK)として引き出
されます。AT90USBKey上では上記図の様に配線します。またポートの出力バッファの
破損を防ぐためPDIDATA・PDICLKとも各自100〜220ohmの抵抗を直列に付けるべきです。
本当は電圧トランスレータをかます必要がありますが、私は3.3V使いしかするつもりが
ないのでこれで十分です。

PDIインターフェースはXmegaのReset信号を通信に使用します。外部リセット用の
メカニカルスイッチを実装している際にチャタリング防止のキャパシタをぶら下げてる
場合は必ず外してください。


ドライバはおなじみのLibUSBを使い、書き込みはAVRDudeから行います。メッセージは
こんな感じです↓
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
avrdude -p atxmega128a1 -P usb -c avrisp2 -U flash:w:main.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e974c
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (118286 bytes):

Writing | ################################################## | 100% 9.27s

avrdude: 118286 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 118286 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 7.77s

avrdude: verifying ...
avrdude: 118286 bytes of flash verified

avrdude done. Thank you.


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



ついでなのでXMEGAのFatFs+TFTLCDの実装サンプルも新しくしました。
しかしこのXMEGA、A1シリーズの384kByte版や4bit-EBIの完全版とかがATMEL本家
からことごとく無かったことにされ、素直にARM使った方が良い昨今は存在意義がほんと
にわかりません…まさに好き者物好きなあなたへ。
※もともと所持していた図体がでかいAVR-JTAGICEmk2は副業先に提供しました。

●ついでですがWinAVRからAVRToolchainに乗り換えるときの諸注意など
さすがにWinAVR使う人激減してますが、ねむいさんのようなコマンドラインビルド
主体の人がAVRToolchainに乗り換えるためのtipsを紹介します。

PROGMEMの定義
 これもう海外ではavr-gcc4.7系が出てすぐにFAQと化した事柄ですがたまに質問
 もらいますので日本でも既に他の方々が言及してますが私もお伝えします。
 
 prog_****系の(prog_char)等の宣言が4.7系で廃止になったのでテーブル等の定数
 をフラッシュメモリ置くときは以下のように定義し直せばOKです。

 旧 :const prog_char unk[] ="inachang!";
 新 :const char unk PROGMEM[] = "inachang!";

 私が公開してるXMEGAのサンプルはすでに修正入れています。

utilsが無い!
 AVRToolchainはAVRStudio6で使用するのが大前提なのでunixライクツールがあった
 utilsフォルダが存在しません。ですがAVR-GCCのバイナリがあるフォルダに同等の物が
 一緒にほぼ全部ぶち込まれてるので大抵は困りません。(sh.exeだけは無いです)
 シェル(sh.exe)に依存するmakeの書き方をしてるとエラーで止まるのでご注意ください。
 …LUFAっていまだWinAVR20101110が前提なんですよね…めどい…。
 因みに私が公開してるXMEGAのサンプルはもちろんこのビルド手順準拠です。
 ARM-GCCの代わりにAVRToolchainをGCCコンパイラとして指定するだけです♥

●デジカメ買い換えました

2010年の8月に購入後数日で比叡山の登山道の石の上におっとこして以来だましだまし
使用していたねむいさんのIXYDIGITAL220Fちゃんが湯の山温泉のバトルで力尽きとうとう
縦向きでしか撮影できなくなりE32エラーも連発するようになったので最新のIXY3に
買い換える運びとなりました…

2年たつと全然性能が違いますね…まぢて…マクロ撮影が1cmまでできるのでTFT-LCDの
COGの解析に役立つかもしれません!



●今まで普通に使えてたSDカードが急に書き込み禁止になったんですけぉ!!1!!
物がよくつぶれる(人も)ようになりました。ねむいさんが使ってるPCも上記の症状が
出るようになってしまいました…。SDカードは認識するがライトプロテクトが解除
出来ず書き込み禁止になるパターンはいくつかの原因が考えられます。

SDカード本体のライトプロテクトキーがLOCKになっている
 ->SDカードについているLOCKキーは物理的なものでSDカード内部と
  電気的なつながりはありません。もしこれがLOCKの位置になってたら
  ずらすと直ります。しかし大抵は…い紡海

SDカードリーダ・ライタのドライバ側がライトプロテクト設定にしてある
 ->ちょっとインテリジェンスなカードリーダ・ライタはたまにソフトウエアで
  プロテクト設定可能な機能があります。違うカードリーダ・ライタだと普通に
  読み書きができる手合いの奴ですね。マニュアルを見て解除してください。

Windowsを使ってる場合限定でレジストリの設定でライトプロテクトにしている
->google先生に聞いてください…

SDカードリーダ・ライトのソケットに問題があり、常にLOCK状態になっている
 ->使い込んだリーダライタやノートPC付属の奴ではよくありがちです。
  ではなんでこんなことになるのかを説明します。


SDカードの挿入検知(INS)とライトプロテクト(WP)検知はメカニカルスイッチで行われ、
カードリーダ側でその電圧レベルを読み取って状態を判断します。INSとWPのポートは
大抵は3.3Vでプルアップされています。


カード未挿入状態ではINSは解放されているので3.3Vになり、なおかつWPも上写真
ように解放されているので3.3Vとなり、ロジックレベルではどちらもHIになります。


このときSDカードのLOCKスイッチをLOCKにしないで挿入するとINSはSDカードリーダ
側のソケットと電気的に接触し信号レベルがGNDに落ちます。

同じくWPも挿入するとSDカード側のLOCKスイッチに物理的に押されてGNDに落ちます。
この状態ではカードリーダ側は読み書き可能と判断します。


一方SDカードのLOCKスイッチをLOCKの位置にスライドして挿入した場合、同じくWPの
接点とソケットのGNDが一時的に押されるわけですが深くまで挿すと位置的に再び解放
されてロジックレベルがHIに戻ります。
この状態ではカードリーダ側は書き込みのみ可能と判断します。

まとめると3つの状態があることがわかります。

・カード未挿入
 INS :HI(3.3V)
 WP  :HI(3.3v)
・カード挿入(LOCKの位置ではない)
 INS :LOW(0V)
 WP  :LOW(0v)
・カード挿入(LOCKの位置)
 INS :LOW(0V)
 WP  :HI(3.3v)


そしてWPの接点はINSよりも構造が脆弱で長期間使用で接点の弾性の劣化・酸化による
接触不良を非常に起こしやすく、ある日突然常にHIレベル(WP有効)と認識されるように
なってしまいライトプロテクト状態となってしまうわけです。

これについての対処方法ですが、つまりは接点を復活させればいいわけですが、USBの
カードリーダ使ってて起こった人は買い換えた方が手間暇も喰わず安上がりです。
しかしノートPC等で基板にソケットが備え付けられてるタイプの奴は一苦労です。大抵
修理保証期間を過ぎたころに上記の接触不良が発生するので上記の箇所の修理でも多額
のお金がかかるケースもあります。
ねむいさんの場合、購入後5年以上経過していたのとPCの裏蓋を外すとカードリーダー
のソケットが手の届く位置にあったので、WPの端子を導電性布テープで詰めて固定しGND
に強制的に落としてLOCKスイッチの位置にかかわらず常にWP解除状態としました。

接触不良の初期段階の書き込み禁止になったりならなかったりの時は接点復活王なども
有効かもしれません。いずれにしてもソケットが手が届く位置にある場合限定です。


●STM32F4DiscoveryでMP3プレーヤーを構築する

ククク…(by鍵最高)もうほぼ完成状態です…♥
こちらについては月末あたりに別枠でまたお知らせしますね〜

いろいろ試す13

DIPのLPC1114の話がここかしこで持ち上がっていますがSRAMの容量半分に削られてるし
ねむいさんはふつーにスルーさせていただきま…
と言いたいところでしたがなんと秋月さんからもリリースされましたので方針を360度変更
してこちらでも取り扱います!!!乞うご期待!!!

それと私が提供してるOpenOCDのバイナリとVersaloon使ってデバッグとか書き込
みでしようとして躓く人必ず出てくると思うので思うので一応注意を書いておきます。
下記の2点さえ抑えていれば大丈夫です。
1.SRAMが半分に削られてるのでlpc1114_swd_flash.cfgじゃなくてlpc11u14_swd_flash.cfg
 を使用するべし。
2.Windows使いの人以外でOpenOCDビルドする必要がある人はlpc2000.cにパッチを当
 てないと書き込みができません。詳しくはここ参考にするべし。

ちなみに2.のOpenOCDビルド手順はUbuntsuやマカーな方にとっては未だに需要がある
ので新たに整備が必要だと感じてきました。逆にWindows使いの方は9割がたEclipse環境
に行くので初見で私のぶろぐまでたどり着く人は実はものすごく少なくそもそも知ってても
みなかったことにさr

…さて、前ふりはこの辺にしといて小ネタが貯まってきたので消化していきます。





●LPC1788にMCIインターフェース版FatFsを移植する。

やっとこ安定化しました…。結局I/Oポートの初期化がおかしかっただけだったという
なんたるイージーミス…
LPCwareのサンプルも同じ間違いしてるから中の人に伝えておきました。

LPC2388ではメインSRAMに直接DMA出来ないため、ChaN氏はUSBRAMとリンクリストで
順繰りに効率的に転送するかたちを取っていました。私の場合もLPC1788ではAHBRAMを
使用して同じことやってます。AHBRAMとメインSRAMは独立しているので転送中別の処
理やってもフンつまりにならないのです。


MCIのクロックは定格内で20MHzまで設定できます。転送効率が良いのでリード速度は
理想値に近いですね♥ちなみに定格に外れますが30MHzも設定は可能です。

↓外人さんもよく来るので英文でメッセージ
Finally,FatFs for LPC1788 MCI interface turns stable by Nemuisan's works!
You can get sourcecode Here!



●SANDISKのUSBメモリ
ごく一部で話題沸騰だったSANDISKのUSBメモリを欧州のebay経由で購入しました!
2012年8月現在は日本国内の通販でも安価に購入可能です。

SDCZ80-032G-X46っていうUSB3.0対応のメモリなのですが、一般に安く売られている
USB3.0な奴と違って小さいサイズのファイルのランダムアクセス(特に書き込み)にも非常に
強く、私のようにレス用画像をUSBメモリに入れてる方にはもってこいのアイテムです♥


deflaggerで見るとSSDが検知されています。SSDをUSB3.0に変換してるタイプの奴な
のでチマチマ書き込みにも強いのですね。こちらの方はさらに詳しく調べられています。

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 195.029 MB/s
Sequential Write : 117.804 MB/s
Random Read 512KB : 144.212 MB/s
Random Write 512KB : 25.899 MB/s
Random Read 4KB (QD=1) : 13.372 MB/s [ 3264.8 IOPS]
Random Write 4KB (QD=1) : 9.992 MB/s [ 2439.5 IOPS]
Random Read 4KB (QD=32) : 11.232 MB/s [ 2742.2 IOPS]
Random Write 4KB (QD=32) : 3.699 MB/s [ 903.1 IOPS]

Test : 1000 MB [E: 0.2% (0.0/29.8 GB)] (x5)
Date : 2012/07/30 9:05:28
OS : Windows 7 SP1 [6.1 Build 7601] (x64)
SDCZ80-032G-X46 FAT32 Vostro3350_Win7x64_USB3.0Renesas_64kbclaster

↑買ったばかりの時のベンチ結果です(検証に使ったPCはDellのVostro3350です)。
 スクショ取り忘れたのでこぴぺで…
 中身がSSDなので64GB版はさらに早くなるようです。

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 131.462 MB/s
Sequential Write : 23.899 MB/s
Random Read 512KB : 121.063 MB/s
Random Write 512KB : 5.004 MB/s
Random Read 4KB (QD=1) : 10.935 MB/s [ 2669.8 IOPS]
Random Write 4KB (QD=1) : 0.240 MB/s [ 58.5 IOPS]
Random Read 4KB (QD=32) : 11.655 MB/s [ 2845.4 IOPS]
Random Write 4KB (QD=32) : 0.281 MB/s [ 68.5 IOPS]

Test : 100 MB [E: 0.0% (0.0/14.7 GB)] (x5)
Date : 2012/07/12 9:26:14
OS : Windows 7 SP1 [6.1 Build 7601] (x64)
USM16GQ/SC FAT32 Vostro_usb3.0_64kb

↑SONYのUSM16GQ/SCと比較。やはりSanDiskのほうが性能がダンチです。


↑約一か月使い込んだ後
 512kと4kのWriteかなり劣化してしまいましたorz


↑今日日のSSDならSecureEraseとかTrimとか使えるはずですがSanDiskから
 そういうツールも提供されていないので黎明期のSSDでよく使われていた
 空き領域のデフラグやってみました…ちょっとだけ性能回復♥



●中華MP3プレーヤー LYUMO M21
ヨドバシで安さにつられて買ってしまったこれは値段通りの性能でした…
めでたしめでたし。

…で終わるわけがないので捨てる前に分解してみました。


生意気にケースは金属製です。


…チャイナクオリティ…ショートしたらやばいですよぅこれ


操作した時に液晶の切り替えがやたら遅いので気になってましたがどうやら私のぶろ
ぐでは定番のMCUバスタイプの中華液晶モジュールが使用されているようです。


ねむいさんは中華液晶を何年も何種類もいじってきましたのでこの文字列見ただけでも
何を意味するか分かります。お尻の"OTM2201"がコントローラICの型番を示します。
そこからi8080接続タイプで176x220の解像度を持ったTFT液晶モジュールであることも
わかります。


液晶モジュールだけ取り外してSTM32F4でうごかしてみました。ピン配置の判定も過去
のデータベースから推定して一発で判明しました♥
ちなみにOTM2201のはずなのにDeviceIDを読んで判明した正式なコントローラICはS6D0164
でした…まぁ中華クオリティ(ry



●いつもの中華液晶たち
aitendoさんから出ると脊髄反射的に手に入れようとしてしまう性格を直さなければ
と思いつつまた動かしていた…

S95311
 
 まだデモコードが提供されていませんがコントローラIC(HX8340A)とピン配置が判明
 しています。QCIFサイズで8bitバスのモジュールではよくある配置なので楽勝です。
 初期化手順も中華サイトを巡ってさらにこの液晶用にガンマと表示方向を指定して
 あげれば余裕です。
 i8080な8bitバス専用です。
 
 8/27の雪子ちゃん誕生日記念の際に作ったコラ絵を映してみました。
 ※今年はえろす抜きです

S93610
 
 コントローラICはILI9163Bです。まだデモコードが(ry
 i8080な8bitバス専用です。
 
 コントローラICとしては何度も動かした実績があるので今回も楽勝です

S95417
 
 ピン配置はYHY024006Aと同じタイプの2.4inchのモジュールです。まだ(ry
 i8080な16bitバス専用です。8bitに切り替えができません。
 
 こちらのコントローラICはST7787でILI9340やR61526系統のコマンド体系となってい
 ます。しかしながらSTM32F2/F4のような高速でぶん回せるバスの速さに追従し切れ
 ないようなのでGPIOによるエミュレーションかXMEGA等の少し遅めのバスで動かす
 のが良いかと思われます。

S95461C
 
 WQVGAタイプのTFT液晶モジュールです。ま(ry
 i8080な16bitバス専用です。8bitに切り替えができません。(意味深)なチップ抵抗
 があることにはありますが載せ替えても16bitのままです。

 
 2年前にHX8352Aのものを動かしたことがあります。今回のはHX8352Bです。似通った
 コマンド体系ですが細かい部分の動かし方が微妙に違います。特にレクタングル指定
 では内部メモリアドレス指定のコマンドも追加する必要がありました。よって初期化時
 に双方のコントローラICを判定してそれぞれの初期化ルーチンの最後にレクタングル
 指定用の関数のポインタを割り振るようして条件分岐による速度低下の発生を抑える
 ように工夫しました。



 そしてChaN氏のFatFsも久々に更新されたので、いつものにも更新ついでに上記モジ
 ュール他に対応しておきました。いつものに収録されているTFT液晶ドライバ群は隠れた
 人気があるようです。特にHX8347Aについては検索で飛んでくる方も未だに多く、役に
 立ってると私は思(いこんで)います。


 


 ●おまけ
 本来はNuvotonのNUC120やM051をOpenOCD使ってデバッグするのも紹介するつもり
 でしたが、意外とボリュームあるので次回LPC1114DIP板の記事の時にご紹介します。
 代わりに…

 taobaoでSTM32の生基板大量に買ったついでにまた買ってしまったTFT液晶たちを。
 気が付いたら殆ど使いもしない液晶モジュールを150種類以上持っていた私…

 
 R61509V互換のILI9326をコントローラに持つWQVGAのモジュールです。

 
 H016IN61というH016IT01(H161T01は間違い)のパラレルバス版みたいなの
 LEDは2個直列なので6.2Vくらい必要です。

 
 QCIFサイズでSPI接続専用でしかもタッチパネル付きの液晶です。LEDは並列3つで
 3.3V単一電源でもOK。以前は3-wire,9bitシリアルの奴に苦しめられましたが、こいつは
 4-wire,8bitシリアルで非常に扱いやすいです♥aitendoさん!!これ国内で販売
 したら大ヒットまちがいなしですよぅ!
 
 
 とにかく動かすの優先だったので配線が全てやっけつなのは許してほしい。

OpenOCDの新MPSSEドライバを試す

20130403追追:
こちらのページにてOpenOCDとInsightを用いた効率的なデバッグ方法を紹介しております。
合わせてご参考願います。

20130403追:
私のおきぱで公開しているOpenOCDバイナリはWinUSB/LibUSB両対応となっております。
Zadigでインストールする際にLibUSBKを選択するとドライバの入れ変え無しに
どちらの方法からでもアクセス可能でさらに便利になっております。




MLを追いかけてる人ならご存知と思いますが少し前のOpenOCDのコミットで新MPSSEプ
ロトコルによるJTAGkey2をはじめとしたFTDI系デバイスでアクセス速度がさらに向上
するサポートが追加されました。
Windows環境下ではLPC17xx系でフラッシュ書き込みの速度不足を感じていたので私も
すぐに飛びつきました。

さて従来のものとどう違うかなのですが、新MPSSEは使用するドライバがLibUSB(libftdi)
やFTD2XX(libftd2xx)ではなくMicrosoftの汎用USBドライバであるWinUSBを使用する
(実際はlibusb-1.0 async API のバックエンド)ようになります。


ねむいさん今までWindows環境上ではかたくなにFTDI純正ドライバ使用してきましたが
速度的に大幅に優勢になったのとlibusbがWin7系でも十分安定したので今回の変更を
機にFTD2XXを捨てて乗り換えることにしました。


以下いくつかのMCUで実際に書き込みの比較を行います。
FT2232系デバイスとしてJTAGKey2を使用しています。

●RCLKを効かせたLPC2388の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
RCLK - adaptive
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
fast memory access is enabled
dcc downloads are enabled
target state: halted
target halted in Thumb state due to debug-request, current mode: User
cpsr: 0x00000070 pc: 0x0002b5ae
auto erase enabled
wrote 491520 bytes from file main.elf in 7.796974s (61.562 KiB/s)
verified 465140 bytes in 0.515632s (880.935 KiB/s)

requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
shutdown command invoked

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


*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
RCLK - adaptive
Info : RCLK (adaptive clock speed)
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
fast memory access is enabled
dcc downloads are enabled
target state: halted
target halted in Thumb state due to debug-request, current mode: User
cpsr: 0x00000070 pc: 0x0002b5a8
auto erase enabled
wrote 491520 bytes from file main.elf in 4.859437s (98.777 KiB/s)
verified 465140 bytes in 0.437505s (1038.247 KiB/s)

requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
shutdown command invoked

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



もう全然威力が違うのがわかりますね♥

●STM32F4の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080451a0 msp: 0x10010000
15000 kHz
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
stm32x mass erase complete
wrote 550968 bytes from file main.elf in 4.093803s (131.432 KiB/s)
verified 550968 bytes in 0.781260s (688.701 KiB/s)

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked

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


*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08045c28 msp: 0x10010000
21000 kHz
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
stm32x mass erase complete
wrote 550968 bytes from file main.elf in 3.937550s (136.647 KiB/s)
verified 550968 bytes in 0.546882s (983.859 KiB/s)

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked

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



残念ながらSTM32系はフラッシュの消去が遅いので(autoeraseだとさらに遅くなるので
"stm32f2x mass_erase 0"の使用を推奨)そっちに足が引っ張られます。実際のテンポは
あまりよろしくないです。それでも100kiB/Sec越え(どっちも越えてますがー!)
また同じスクリプトファイルでも新MPSSE版はJTAGのクロックが細かく設定できるよう
になり若干JTAGのクロックも早くなります♥
20130507追:
…と思いきや実際にオシロで波形を測定してみると15MHzのままでしたorz
FT2232Hの仕様上MPSSEの最高が30MHzでその一つ下は15MHzとづづきますからLibftdiの
時はOpenOCDの周波数の表示が計算上の値を正直に出してるだけで実際にFT2232Hに
設定されるTCKの周波数とは全く違うということですねorzorz


ちなみにSTM32F1系はもっと悲惨でフラッシュの書き込み速度も遅いため35~7kiB/Secで
一律頭打ちになってしまいます。
*FTD2XX
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802bb00 msp: 0x20010000
7500 kHz
Info : device id = 0x10016414
Info : flash size = 512kbytes
stm32x mass erase complete
wrote 434240 bytes from file main.elf in 11.765700s (36.042 KiB/s)
verified 434240 bytes in 1.015631s (417.536 KiB/s)

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
shutdown command invoked

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


*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0802bbe0 msp: 0x20010000
9000 kHz
Info : device id = 0x10016414
Info : flash size = 512kbytes
stm32x mass erase complete
wrote 434240 bytes from file main.elf in 11.640700s (36.429 KiB/s)
verified 434240 bytes in 0.765629s (553.875 KiB/s)

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
shutdown command invoked

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



●FM3の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
15000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 524288 bytes from file main.elf in 9.312559s (54.980 KiB/s)
verified 505904 bytes in 0.578129s (854.562 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked

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


*WinUSB
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
18000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 524288 bytes from file main.elf in 6.984419s (73.306 KiB/s)
verified 505904 bytes in 0.343753s (1437.215 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked

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



FM3の場合はフラッシュの読み書きが非常に速いためRCLKを効かせたLPC2388並みに速く
なっています!(でもCQ出版系の雑誌記事では大人の事情でわざわざこの性能を殺し、さらにわざわざめんどくさい使い方やデバッグ方法しか紹介してませんね…)

上記3つの検証ではねむいさん特製の各マイコンに合わせたOpenOCDのスクリプトであら
かじめCPUの最高速度まで叩き上げてこの数値を出しています。
(最高速にするために動作電圧も+3.3Vを想定しています)。



ということで今回の変更によって益々デバッグの回転力が上がることが期待されます。
また、付加的な利点としてFTD2XXを排したことによりプロプライエタリなライブラリが
なくなるのでOpenOCDのバイナリがおおっぴらに配布できるようになるという私のよう
な教える側の人にとってはARMマイコンのビルドデバッグ手順の整備が大幅に短縮・
簡略化されることにもなり非常に手間が省けます♥ こっこれで"ねむいさんとかいう人の
ページみたけどやり方がさっぱり"
って後ろ指挿されることなくなったんじゃあんちゃん






中途半端に尺が余ったので、今までにOpenOCDの操作に関していただいた問い合わせの
中で私が「初めて触った人が陥り易く、かつ致命的になる」と感じた問題たちについての
回避策やtipsをご紹介したいと思います。


●STLinkでOpenOCD使ってみたいのですがLibUSBやWinUSBのドライバのインストール
 方法が面倒そうででわかりません><;
->zadig


●あんたのところの記事をもとに基板作って自作のプログラム書き込んだらJTAGで
 一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
 てこさえた基板言い値で全部買い取れ。
 ->カエレや!!1!
->STM32ではWFI命令を含むプログラムを実行した後ペリフェラルのクロックが停止し
  ますが同時にコアにあるデバッグユニットに供給されるクロックも仲良く停止し
  てしまい、JTAG/SWD等で一切アクセスできなくなってしまいます。

  回避策はWFIが実行される前に速攻HALTをかけてフラッシュを全消去して電源再投
  入してやれば再びアクセスできるようになります。しかしこの方法はタイミングが
  シビアすぎるのでお勧めできません。
  
  確実な方法は、システムメモリからブートするモードにしておき、リセットかけ
  ても常にブートローダーに飛ぶようにしておくとJTAG/SWDでアクセスできるよう
  になってとにかくフラッシュを消去できるようになります。ブートローダーから
  そのままFlashLoader等のツールでUART経由で消去しても構いません。

  ここ最近で"元に戻せなくなった"と↑の質問をいただくケースが激増してます。
  戻す方法はちゃんとあるのであきらめないでください。

●LPCXpresso基板のLPCLinkの部分を分離してJTAGkey+OpenOCDをデバッガにして
 開発を始めてみました。でも何故かmbedやLPCXpresso(ねむいさん注:IDEの方)で動い
 ていたLチカのプログラムが全く動きません><;
->NxPの内蔵フラッシュ付きのARMマイコンは伝統的にCheckSumValidationを持って
  います。これはリセット直後にフラッシュのとある番地にあるリセットベクタのチェック
  サムの値を確認し正しくなければISPに飛んでいく機構です(ユーザーマニュアル参照)。
 
  mbedやLPCLinkのライタは書き込む際にリセットベクタのチェックサムを計算し、
  その番地の値だけ計算済みの値に改変して書き込むのでCheckSumValidation
  を通過しユーザープログラムを実行することができます。もちろんOpenOCDでも同じ
  ことが可能ですが、ベリファイの際は改変前のバイナリと比較してしまうため、
  必ずエラーになってしまいます(=ゆえにベリファイだけできない)。

  ベリファイまで通したい場合は、あらかじめ計算した値をリセットベクタの指定
  のアドレスに書き込んでおくことで可能となります。私が公開しているLPC系の
  マイコンのプロジェクトは、すべて計算済みの値を記してあるので参考にしてく
  ださい(スタートアップのアセンブラファイルに直値を記述)。


●フリーのEclipseを使った開発をしているのですが(ry
->(全身から血をふきだして死んだ)
  ※しかしねむいさんは有償のEclipseベースの開発環境では死にません。
   死ぬのはあくまでも設定が死ぬほど面倒な素のEclipseで攻撃された時です。
   あといないさんのおぱんつ画像でも一発で死にますので絶対に見せたりしな
   いでください絶対ですよ絶対!!1!1



●ねむいさんの手順の通りにしているけどOpenOCDがビルドできません><;
->ビルド済のバイナリを用意したのでこれからはおきのOpenOCDのバイナリを使っ
  てください。FTD2XXのライブラリは使用していないのでGPLに引っかからずバイ
  ナリを自由に利用できるようにしました!…あとご忠告ですが、最初のうちは変
  な自分流のアレンジをしたりせずにあくまでも手順に沿ってやりましょうね…。


●mt_flashとかいうのがよくわかりません&見つかりません><;
->大昔はtelnetでOpenOCDとコマンドのやり取りをし、マイコン内蔵のフラッシュに
  プログラムを書き込む方法しかありませんでした。現在はその方法はスマートでは
  無く、ARMコアなルーターのフラッシュ書き換えの際の動作確認程度にしか利用さ
  れていません。デバッグでカットアンドトライをしてる時はとても効率が悪いです。

  しかしながら上記のような"現在は不適切なor廃止された"とされる数年以上も前の
  OpenOCDに関する情報が「最新のOpenOCDを〜」という見出しで検索のトップを占め
  ているのが現状で、何も知らない人がこれらの情報をもとに"最新"のOpenOCDを使
  おうとしても当然うまくいくはずもなく、"使えない"、"敷居が高い"という印象を
  持って離れてしまっています。

  2012年7月現在"最新"の0.6.0ではWindowsはバッチファイルで、Linux系ならシェル
  スクリプトでJim-Tclのスクリプトをコマンドの引数として一括で呼び出すことに
  より簡単に書き込み動作ができるようになります。mt_flashってのはそのスクリプト
  の名前のことで、それが記述されているスクリプト(もしくはコンフィグファイル)
  がないと当然使用できません。私が公開しているOpenOCDのバイナリにはそれらが
  仕込まれたコンフィグファイルがありますので安心してお使いください。
  現在は以下のMCUのフラッシュ書き込みに対応しています。
   STM32F1,F2,F4,L,VL,F0
   LPC1114(/DIP版も),LPC11U14,LPC1343,LPC1227,LPC1768/69,LPC1788,LPC2388
   ADUC7026
   AT91SAM7S256
   LM3S9D92
   MB9BF618
   ATMEGA644P,ATMEGA1284P

  ちなみにmakeと組み合わせることによりさらに効率よく開発が可能です。長々と書
  きましたがここ見てくれれば間違いないのですがそうだね宣伝だね。


"Remote 'g' packet reply is too long"というエラーが(ry
->去年の年末に「次それ聞いたら頭にJTAGKeyぶっ挿して一ビットずつ対策方法焼き
  こんでくから
」…って私言いましたよね!?

いろいろ試す12

年度始めになるといろいろ忙しくなります。私がほしいもの(ハードウエア)は2011年
中にあらかた買いそろえていたのでわずかな時間を見つけて目下消化中な現在です。


●NokiaのLCDたち
またまた中華掲示板から引っ張ってきたネタなのですが、もうねむいさん一部のイカ
ス思想の方々からs**kと思われてるかもしれませんがNokiaのGSM用のLCDはebayで非常
に安価に購入できます。その中でも比較的ハードル低そうなのを試してみました。


これはNokia1202用のモノクロドットマトリクスLCDです。コントローラーはSTE2007という
ものだそうです。ハードウエア的な接続や初期化手順は違いますが基本としては幅広く
応用例があるドットマトリクスLCDの代表格であるNokia5110とほとんど変わりません。


バックライトもついてますが10mAだとちょっと明るすぎですね。もう少し電流絞れると
思います。接続はi2cではなく9bit3wireなシリアルのみです。


端子の部分を拡大。
半田付けになれてない人もこれなら何とかいけるでしょう。
ebayでは最安3$前半くらいから購入できます。


こちらはNokiaのC1-01という機種で使用されているTFT-LCDです。
128x160のQQVGAサイズです。


安価なTFT-LCDモジュールのうちホビイストにも手が届くものは数年前の型落ち品や
ユーズド品しか回ってこないものですがなんと2011年製のさらぴんでした。
端子の形状は先ほどのNokia1201とほぼ同じ感覚です。またLCDのバックライト電圧
は3.2Vなので非常に扱いやすいです。


動かしてみました。
光のムラはちょっと多いですが、さすが2011年製だけあってコントラストはよいですね
こちらも9bit3wireのシリアル固定です。LCDのコントローラはSPDF45124Bかもしくは
HX8353-Cと思われます(両者とも初期化手順・コマンドは同一)


ちなみにebayで買うときの注意ですがこの液晶、大体相場は8$前後で売られていますが
形がよく似ていてピン配置も同一のものが半額くらいで売られています。
これは別のNokiaの液晶でTFTではなくCSTNなのでご注意ください(SPDF45124Bの初期化
手順と全く同じものが使えます)。


●新たなARMマイコン基板
去年の秋くらいにLPC1788の載った中華基板を購入していました。現在主流になって
いるSTM32F4と比べると見劣りはしますが、それなりの性能は持っています。



外観はこんな感じです。


OpenOCDは既に対応しています。私の公開しているスクリプトファイル群はもちろん
書き込み・デバッグまでサポート済です!

さて、LPC1788はLPCXPressoの最高品種LPC1769版には存在しないMCIインターフェース
があります。LPC2388にある奴と同じですね。レジスタの構成もほぼ同一です。
LPCWAREのサイトにはLPC1788のMCI対応のFatFsのサンプルがあるにはあるのですが、
残念ながら全くと言っていいほど使い物にならなかったのでChaN氏のLPC2388用のMCI
ドライバを参考に移植にチャレンジしてみました。

Cortex-M3以降はアンアラインド転送が(速度低下しますが)許容されていてごく単純な
ブロック転送ルーチンで事足ります。DMAのバッファから4byte単位でメインメモリに
高速にコピーするアセンブラのルーチンをこしらえてみました。

LPC1788のMCIクロックはPCLKが支配的かつ24MHz以下を要求されるため120MHzだと設定
上許容されるクロックは20MHz(PCLK=120MHzの時)になります。MCUのクロックを少し下げ、
CCLK=PCLK=96MHzの時だとMCIクロックも24MHzが設定できます。


読み取りスピードはこんな感じです。LPCWAREの奴よりは安定しましたが、残念ながら
一部のカードはMCIクロックを大幅に落としても認識ができないものがありました。
中途半端ではありますが同じくLPC1788を触られている他の方たちが安定化してく
れる事を期待して…白旗

20120905追:
安定化しました。安心してお使いください!


●公開している記事とかプログラムの見直し
私の記事は"ねむいさんの方法だと全然うまくできなかったけど(他の人が公開してる)
方法だと一発で出来た!"というご意見が圧倒的に多いですorz

ねむいさんは事態を重く見て、書きっ放しで放置せずに他の方が試して引っかかった
点を調べて即座に反映するようにしています。正直いつまでも環境構築ネタなんかに
留まってるとほんとに進歩出来なくなってしまうんですが、MTMとかの展示系やロボット
等の競技系に参加するつもりは今後も無いので最初のとっかかりとなる情報・ノ
ウハウくらいはケチらずに公開していく所存でございます。
↑英語圏漁ればこの程度の情報いくらでも転がってるだろっていう突込みは無しで!

ついでにFatFsの移植した例がどこにあるのか分からないとご指摘いただきましたので
少し前から目立つ場所に日本語以外でもわかるようにリンクを明記してます!



●そういうこともあって
私も一か所にとどまらずに新たな一歩を進んでみました!

おきぱではすでに対応したコードを公開していますが、STM32F2/4系にlibpngの移植
を行いました!詳細は次回に!

いろいろ試す11

●STM32L-Discovery
少し前に秋月さんからSTM32L-Discoveryが販売されましたが、遅ればせながら私も
入手しました!


これでDiscovery系のボードもほとんど手に入れましたね。

さて、いつもなら即座にVersaloonに改造するのですが、2012年に入ってからOpenOCD
の0.6.0系のサポートにSTLink・STLink/V2が加わっています。しかもSWD対応です!
去年まではSWDでCorex-Mx系のマイコンに書き込みデバッグするまでがかなりしんどい
方法しかなく(一度コツつかんだら後はスクリプト組んじゃえば楽勝なんですが…)、
皆さん華麗にスルーされてきましたがメーカーやサードパーティの有償のツールを使う
ことなく使い慣れたOpenOCDを利用できるようになりました。



↑STM32L-Discovery(STM32L152RBT6)にOpenOCDを使って書き込みしてるところです。
 書き込み用のスクリプトはいつもの場所に最新の物をまとめてあります。現在動作確認
 してるのは今回のSTM32L-DiscoveryとSTM32F4-Discoveryです。
 STLinkやVersaloon(SWD接続)対応のOpenOCDビルド方法はこちらに。

↑デバッグも自由自在です♥OpenOCDはSTLinkのAPIを呼びだすことで通信を
 成立させているようです。MLを追っていくと対応に当たってOpenOCDのdevの人たち
 の苦心の様子がうかがわれます。

2013年現在はOpenOCDからSTLink/v2を動かすドライバとして、STマイクロ提供の
純正ドライバが利用できます
(といっても中身はWinUSBですが)。


●ほっぽらかしていたBeagleBoard達
去年争奪戦に勝利したにもかかわらず購入した時点で満足して箱に納めてしまってい
たねむいさんですが、aitendoさんの液晶キットを購入したことを皮切りに少しずつ
手をつけ始めています。


↑せっかく奮発してHDMIケーブル買ったのに一旦DVIコネクタ咬ませて変換しとかない
 とこの構成だとまともに写らんなんて考慮しとらんよ…orz
 副業先のPCのでかくて新しいモニタ使わせてもらいますか…無駄に2980円がががg
 ぁーでもS端子使うって手もありますね。


↑去年末にBeagleBoneなるさらに機能を絞ったBeagleBoardの仲間が誕生しました!
 今流行りのクラウド環境を意識したモノになっていてArduinoからの置き換えを狙った
 プロトタイピングに特化した作りとなっているようです。
 こちらの導入記は現在まとめていますのでまた次の機会に詳しく述べたいと思います。



●モノクロドットマトリクスSTN液晶
皆さんは去年さらっと紹介した2.5元I2C液晶を覚えているでしょうか?あの後詳細
が判明した途端に5元に跳ね上がりやがりましたが、ねむいさんは基本的な動作確認
を終えシンプルi2cライブラリに加えようと画策していました。

しかし、Nokia5110に代表されるドットマトリクス方式のモノクロ液晶は動かし方が
ほとんど同じことが分かったので、私がTFTでやってるのと同様に汎用のドットマトリ
クスモノクロSTN液晶向けのライブラリを現在作っています。aitendoさんで購入で
きる一部のOLEDも同じ動作方法の物があり、こちらに組み込んでます。

こちらもまとまり次第別記事で詳しくお伝えします。Nokia5110以外のマイナーな
モジュールに関する動作方法のテクニックも同時にお伝えしますね。


↑てわけで自作ライブラリで5元OLEDを駆動。
 …これ焼きつき激しすぎです!



●一個忘れてました
STM32系のOpenOCDのフラッシュ書き込みルーチンで現在テスト段階なのですが、
asynchronous algorithmと言うものに換えると書き込み速度がアップするそうです。

20120226追:
公式のコミットにも来たわよ



実際にこのパッチを取りこんで試してみました。
デバッガハードウエアはJtagkey2を使ってますが、ボトルネックがフラッシュ
書き込みにあるのでSWD接続のVersaloonでも変わりません。
*Normal
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00415-g338f5a1-dirty (2012-02-16-10:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 3750 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08031280 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 19.750000s (25.924 KiB/s)
verified 454868 bytes in 4.062500s (109.343 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked

*asynchronous algorithm
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00423-gd8b9127-dirty (2012-02-17-21:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 3750 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08031440 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 12.968750s (39.480 KiB/s)
verified 454868 bytes in 4.015625s (110.620 KiB/s)
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
shutdown command invoked


…てわけで25.924 KiB/sから39.480 KiB/sへの大幅アップです!なにこれすごい。
現時点で書き込み速度がRTCK使っても10KiB/s代しか出ないLPC1769系のフラッシュ
にも対応してほしいですね♥

いろいろ試す9

電子工作系のブログ記事はこれが今年で最後なので旅先から無理やり更新してやり
ます。明日(12/30)のAM6:30には犬山遊園に降り立ってる身です・・・!


さて、クリスマスは虹裏向けのネタの仕込みで死にそうになってたねむいさんでしたが
aitendoさんからよさげなTFT液晶モジュールが2点追加されていましたのを目ざとく見
つけ購入だけはしていました。今週に入ってやっとこ作業時間ができたので即効バラッ
クをくみ上げて動作させて見ました。

まずは320x480の解像度でなおかつタッチパネルが付いているTRULY製のTFT液晶モジュ
ールTFT1P2797-Eです。以前も同じコントローラIC(ILI9481)で解像度が同じものが売って
いましたが、これはタッチパネル付きで、この解像度ではtaobaoでもなかなかお目に掛か
らない一品です。

↑早速動かしてみました。
電源電圧は3.3V単一でまったく問題ありません。よく液晶モジュールのデータシートでは
慣習的に2.85VをtypとしていますがコントローラICのVioとVccが3.3Vを許容していれば
なんら問題はないです。F4用の液晶はこれで決まりです!
・・・といいたいところですが、この液晶は以前のものとは違ってノーマリホワイトのよう
なので初期化手順が微妙に違います。ご注意を。


お次はお値段500円と非常にリーズナブルな液晶モジュールS95591-AAAです。こういう2.2"で
QVGAでタッチパネルつきはなかなかtaobaoでもお目にかかりません。aitendoさんやりますね!


↑こっちも早速動かしてみました。
こちらはLEDのバックライト電圧が9Vとなっています。3.3Vから昇圧して定電流回路
組んでやりましょう。私はPowTech社のPT4101というLEDドライバICをよく使用して
いてこのバラックでも秋月さんの変換基板と組み合わせて使用しています。


最後にSTM32VL DiscoveryのVersaloon化について、最近のファームウェアはSWDとして
使うためのピン配置があべこべだったのが元の正しい形?に戻っています。
私のぶろぐを参考にSTM32VL DiscoveryをVersaloon化されてる方は注意してください。

↑私も久しぶりファーム変えて気づかないではまった・・・
以前と同じこと言ってる気がしますが春日井から戻ったら手順書も更新します。

てわけで去年とまったく同じことしかやらないまま今年の電子工作納めてしまいました。


・・・
さて、尺があまってしまったのでよくメールなどで頻繁に頂く質問、いわゆるFAQを
この場を借りて答えたいとおもいます。

>メカトロ(含むロボット関連の競技)で使うモータドライバを組むことになりました
 がお勧めのFETを教えてください
 ・・・など、モータ制御に関する質問
→これなぜか非常に良く聞かれるのですが副業の仕事内容的にモータドライバに関する
 質問は「私ぜんっぜんわかりません><」としか答えられません・・・
 なんせ私は1聞かれたら100答える人間でなおかつぶろぐのこと副業先の方々が
 皆知ってて変なこと書かないように監視されてますから・・・
 ちなみに本業の虹メに関してはやりたい放題に見えて実ははるかに恐ろしいくらい
 厳しいガイドラインがあって政治・経済・野球・サッカー・アニメ・漫画・特撮・絵師さん個人
 の話題そしてジャガイモの入ったカレーなど個人の嗜好が大きく分かれる事がらの
 話はタブーなっています。
 とくに「」の前ではジャガイモの入ったカレーの話題は絵師さんに絵を描くことを強要
 する行為と同じくらいタブー中のタブーにあたります。
 私的にはいないさんのぱんつのつぎにじゃがいも入りの野菜カレー大好物なんですけぉ・・・

 すみません話反れました・・・

>(任意のマイコン)からARMに乗り換えましたがGPIOを切り替えるスピードが遅いのですが
→「最適化」「吐かれたアセンブラリストを良く見直して無駄な分岐・ロード・ストアが出
 ないようにGPIOアクセスする部分のコードを組みなおす」
 それとCPUコアが100MHz以上で動いててもGPIOがそのスピードについてけるとは限り
 ませんからよくマニュアル(ARM本家の仕様書も)やデータシート穴の開くほど読んでください。
 それをマスターしたら君もGPIO高速パタパタで大空に羽ばたくことができる!!
 そしてもうこんなところに戻ってくんなよー!!!1!

>中華の電気電子系の掲示板からよくネタをパクってますよね
はい
 私の描いたJTAGKey2Cloneの回路図とかあっちで貼られてることがあったりして
 面白い発見も

>なんでトレイルランのはずなのに徒歩とあんまり早さが変わらないの?
途中から疲れて歩いてるからです

>GT-723Fを使っています。ちゃんとつないだはずなのに衛星を補足しません><
表出ろ(別にけんかするわけではない)。部屋の中では補足はほぼ不可能ですよ。
 特に最近のマンションは金属線が埋め込まれた窓のガラスなのでそれがシールドに
 なって外部からの電波がシャットアウトされてしまいます。(Bluetoothの電波とかもダメ・・・)

>GT-723FからUARTのメッセージがまったく吐かれなくなってしまいました
→お気の毒ですが壊れました
 LVTTLなI/OラインにCMOSな+5V系の信号ぶちかますと簡単に死んでしまうようです。
 +5Vで動かしてるAVR等と組み合わせるときは注意です。あと落下のショックにも
 弱いです。静電気にもメタクソ弱いです。
 ねむいさんは安価ゆえにとっかえが効いて性能の非常に高いPA6Cをお勧めします!
 ユーロ安の今がチャンス!!!


>Cortex-M3でOpenOCDデバッグしようとすると"Remote 'g' packet reply is too long"
 というメッセージが出て(ry
→もうねむいさん何十回も言ってるのですが・・・#
 次にこれ聞いて来たら頭にJTAGKey2ぶっ挿して1ビットずつ焼きこんでいきますからね!

ねむいさんってマミゾウのパクリだよね
→そうだね

STM32等のARMマイコンをInsightとOpenOCDを使ってデバッグする(2017年度前期版)

OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
 解説はこのバイナリを基にすすめますので4649!



この記事は前回からの続きです。前回のものよりちょっと内容が難しくなってます。
前回の内容を基に環境を構築していることが前提で話を進めさせていただきます。
今回はOpenOCDを使用し実際にARMマイコンにJTAG/SWD経由でフラッシュ
書き込みそしてデバッグを行うところまでいきます。
もちろん今回も軽量動作,NO-Eclipse,NO-Cygwinです。

※今回の記事も時代に合わせて適宜加筆修正していきます。


●必要なもの
 1.ARMマイコンが実装されたターゲットボード
  凡例として、STM32F4シリーズであるSTM32F407ZGT6が乗ったボードを使用します。
  私が配布しているSTM32F4向けのFatFs移植例は、デフォルトのターゲットボードが
  STM32F4Discovery、デバッガハードウエアがSTLink/V2となっていますのでご注意を。
  Nucleo系板や2015年以降発売のDiscovery系板はSTLink/V2-1に変ってます。
  
  
  先ずは上記の形になるようmakefile中の評価ボード/デバッガ設定を変更してください。
  また、FT2232系ドライバとしてWinUSB(libusb-1.x系)を使用します。"MPSSE = ftdi"の
  定義をコメントアウトするとLibUSB0.1系のAPIでアクセスするようになりますが、1.0系
  より低速になります。また、2017年現在のOpenOCDのバージョンでは"Deprecated"
  となりました。


 2.JTAG/SWDデバッガハードウエア
  上記のCortex-M4はデバッグユニットとしてJTAGとSWDという接続方式の両方をサ
  ポートしています。ARM7TDMIはJTAGインターフェースのみでした。

  現在、ホビーユーザーが手軽に利用できるものとしてFT2232系を使ったJTAGデバイスが
  主流です。以後の解説はそれを利用したJTAGKey2互換の"JTAGKey2 Compatible"
  を使用しJTAG接続にて解説していきます。
  JTAGKey2 Comatibleを自作される方はこちらの解説を参考に。

  SWD接続についてはCMSIS-DAPが現在の主流となっています。NxP系の評価ボード
  にはmbed版としてデフォルトで搭載されているのでおなじみだと思います。
  その他の品種ではVersaloonや上記のJTAGKey2CompatibleでもSWD接続可能
  なっています。
  STLink/V2.STLink/V2-1もSWDで使用可能ですがOpenOCDからの扱いが特殊です。
  こちらにつきましては追補の形でここに手順を記載しましたのでご参考に。


 3.OpenOCD
  OpenOCDはターゲットMCU(ARMマイコン)と後述するgdb/insightの仲介役を果たす
  プログラムです。自身がTCPのサーバーとなり、gdb/insightに接続されます。
  以前はWindows向けにインストーラ付のバイナリが配布されていましたが、FTDI純正の
  スタティックライブラリがOpenOCDのGPLライセンスに引っかかりてめえでビルドしろ
  的なものになってしまいました。
  …しかし…
  当ぶろぐ内ではWinUSB(LibUSB1.0系)をFT2232系のデバイスドライバとして使うように
  方針を変えたので、もうビルドする必要はありません♥
  OpenOCDのWindowsバイナリはこちらからダウンロードしてください。

  注意すべきはデバッガハードウエアに対するドライバで、上記リンクにある
  OpenOCDバイナリは下記のデバイスとドライバをサポートしています。
  (注:LibUSB->クラシックなLibUSB0.1系を指す
    WinUSB->バックエンドとなるLibUSB1.0系を指す)

  *JTAGKey2をはじめとしたFT2232系デバイス:(WinUSB or LibUSB)
  *Versaloon:(WinUSB)
  *STLink/v2:(STMicro純正/WinUSB)
  *TI-ICDI(Stellaris Launchpad):(TI純正/WinUSB)
  *J-Link(WinUSB)
  *J-Link On LPCLink2(WinUSB)
  *CMSIS-DAP(HIDとしてドライバレスだがmbed版はVCPドライバ必須)
  *STLink/V2-1(VCPドライバ必須)


  各ドライバのインストールは以前は、PID/VID調べてINFファイルを作って…と非常に
  めんどくさかったのですが、現在はWinUSB,LibUSB向けのGUIな汎用インストーラのzadig
  を使用することによりインストールが大幅に簡略化され、手軽になりましたのでこちらを
  使用してドライバのインストールを行ってください。
  公式のサイトにはインストール手順も英文で懇切丁寧に書かれていますが見る必要も
  無いくらい簡単にWinUSB/LibUSBが導入可能です。
  さらに、使用するドライバにLibUSBKを選択するとドライバの入れ替え無しに0.1系と
  1.0系のAPIが使用可能になります!…が2017年現在は全てLibUSB-1.0系に移行して
  いるのでLibUSBKを適用する強い理由はなくなりました。WinUSBのドライバを
  適用してください。


  注:このOpenOCDは32bit版ですが64bit版Windows環境でも問題なく動作します。
     64bit版OpenOCDと比べて速度的な面で大差はないです。


  どうやらJtagKey2を売ってた所が夜逃げしたらしく現在ではFT2232系を使用したデバッガ
  ハードウエアはOlimexのARM-USB-OCD-Hが主流になりつつあります。
  こいつのデバイスドライバのインストールで詰まってる方が極めて多いのでついでに
  こいつを使った時の導入方法もお伝えします。と言っても難しい操作は全くなく、おなじみ
  Zadigを使用して"ARM-USB-OCD-H (Interface 0)"のデバイスにWinUSBもしくは
  LibUSBKのドライバを適用するだけです。間違っても"Interface 1"に適用しないでください。
  そちらは仮想COMとしてFTDIのドライバを普通に適用させてください。

  ARMは新旧の情報がweb上のいたるところで倒錯しすぎて何が正しい組み合わせか
  分からないと思います。Windows環境でOpenOCDを使われる方は私のぶろぐをしっかり
  見ていただければとにかく途方に暮れることだけは避けられるかと思います。


 4.Insight(gdb-gui)
  InsightはgdbのGUI版です。また、純粋なフロントエンドではなく内部にGDBそのものが
  取り込まれているので別途gdb.exeを用意する必要はありません。当ぶろぐではこれを
  使用しソースコードレベルのデバッグを行います。
  これも詳細は後述しますがバイナリが配布されていますのでビルドする必要はありません。



●下準備
 1.ドライバ強制認証の回避措置(WindowsXPでは不要)
  今回は絶対に必要ということではありませんが開発を行う上で必ずぶち当たる
  問題なので紹介しておきます。

  64bit版のWindows7では、デバイスドライバはデジタル署名が必ず求められていて
  未署名のドライバを使用するときはOSの起動時にF8キーを押してドライバ署名の
  無効を強制を選択しなければなりません。毎 回。
  で、バリバリ開発する人は未署名のドライバなんかも使わざるを得ない場面がた
  くさん出てきますね。こんな糞かったるいことはやってられないのであらかじめ回
  避措置をしておきましょう。
  Driver Signature Enforcement Overriderというプログラムを使用し、使用したい
  未署名ドライバに強制的に署名を施しWindows7をTestModeとして走らせます。
  詳しい設定方法は上記URLを参考にしてください。
  また"TestMode"で動かしている時に画面右下に"TestMode"と表示されてしまって
  いますが気になる人はRemoveWatermarkX64.exeを使用して文字を消してください。


 2.OpenOCDのビルド
  以前はWindows環境にてMSYS/MinGWを用いた手順を公開しておりましたが、
  OpnOCD0.8.0以降はビルドするまでの手順が大幅に煩雑になり慣れてない人には
  ビルドがほぼ不可能になってしまいましたので公開を廃止しました。代わりとしまして
  ビルド済のWindowsバイナリを公開しております。ご利用ください。


 3.Insightの準備
  SourceForgeにあるNetXのページのかなり下のほうにある
  "arm-none-eabi-insight-7.4.50.20111222-cvs-mingw32-netx.0.7z"をダウンロード
  し、任意のフォルダに展開してください。


●ターゲットデバイスにプログラムをダウンロード
  前回の手順を参考にSTM32F407ZGT6用のmain.elfが生成できてるものとします。
  デバッグ時は最適化オプションを必ず"-O0"にしてビルドしてください。

 1.makeファイルの編集
  前回も解説しましたが、makefileにあるOpenOCDとInsightがインストールされて
  いるパスを指定してください。
  
  

 2.PN2の設定
  PN2の"TOOL"から呼び出すことが出来るように前回と同じ要領で引数つきで登録
  てください。登録するのは"program"と"debug"です。

 3.書き込み
  ターゲットデバイス(STM32F407ZGT6)が載っている基板にJtagKey2を取り付け、"TOOL"
  から"make program"を呼び出し、OpenOCDからSTM32のフラッシュ書き込みスクリプトを
  呼び出しターゲットデバイスに"main.elf"をダウンロードします。
  OpenOCDのcfgファイルのパスの指定が間違っているとエラーが出ますので各自の環
  境に合わせてパスを修正してください。
  

 4.書き込み用のコマンドについて補足
  makefile内では以下のように記述されています。
  1.OpenOCDをJTAG・SWDデバイスのcfgファイル・ターゲットMCUのcfgファイルを
   -fコマンドで指定して起動する。
  2.同時に-cのコマンドでターゲットMCUのcfgに記述されているproc(関数)を呼び出す。
  3.procに記載されている順にコマンドが実行され書き込みを行う。

  上記一連の動作にてgdbやtelnetからの回りくどい操作は一切要せず、簡単に
  書き込み動作が可能です。


●ターゲットデバイスをInsightを使用しデバッグ
 1.makeファイルの編集
  正しくプログラムが書き込まれたことを確認したら次はデバッグです。
  makeでinsightをcmdウインドウ(DOSプロンプト)なしで呼び出すために
  ちょっと回りくどいですが下記のようにして記述しています。
  

 2.OpenOCD・Insightの呼び出し
  "TOOL"から"make debug"を呼び出すと、OpenOCDをターゲットデバイスに接続、その後
  insightが起動します。
  

 3.Insightの接続設定
  デバッグ開始前にFile->Target Selectionに進み、以下のように設定を行います。
  原因は不明ですが"Set Breakpoint at 'main'"が効かない事がよくあるので
  "Command issue after attaching"に"tbreak main"と記述し確実にmain関数の
  最初の行で止まるようにしてください。ここでmainに設定したブレークポイントは
  自動的に消去されるのでリソースの無駄になりません。
  

  その後"Run" -> "Connect to Target"へ進み、接続を開始します。ダイアログがまた
  出ることもありますがそのままOKを押してください。
  
  OpenOCDとInsightの接続が成功すると"Successfuly Connected"とGDBのダイアログ
  が出ます。ここで"ok"をおすとプログラムがリセット直後にhaltした状態となります。
  
  このときCortex-M系のマイコンを使用時でなおかつGDBのバージョンが7.2以上の時に、
  "Remote 'g' packet reply is too long"というエラーメッセージを吐くことがあります。
   これは従来GDB側がARMv7-mコアに対して疑似的な浮動小数点レジスタを設けていて
  それに対応するためにOpenOCD側がレジスタの分だけパケットを余分に生成して送り
  込んでいたのに対してGDB7.x以降ではその浮動小数点レジスタの領域が完全に廃止
  されてしまったため、余分なパケットが送り込まれていたと判断し、上記のエラー
  を吐いて(="Remote 'g' packet reply is too long")止まったからです。

  ↑※OpenOCD0.8.0以降のVerではtdescを指定する方針で対策されました。

  さらに"Continue"を押すとmain関数の最初の行、一時的にmain()に張った
  ブレークポイント(main()の最初の行)に飛びます。
  
  
  ここまできたらあとはInsight上でステップインとかステップアウトとかブレークポイント
  張って停止させたりレジスタとかメモリとか(条件付で)I/Oレジスタの値読み出した
  り自由自在です!

  終了する時はTools->Stop Toolsで終了させたいところですがが、PN2ではひとつの
  プログラムしか終了できず、Insightだけが終了してOpenOCDが終了してくれません。
  私は下記の要領で強制的にタスクを殺すwindowsのtaskkillコマンドを使ったバッチ
  ファイルを作成してこれを呼び出して"確実に"終了させています。
  ↓呪文
  taskkill /F /IM openocd.exe
  taskkill /F /IM arm-none-eabi-insight.exe
  

  taskkillはXPPro版とVista以降しかサポートしてませんのでご注意ください。

STM32等のARMマイコンをGCCでビルドする(2017年度前期版)

OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
 解説はこのバイナリを基にすすめますので4649!


当記事はWindows環境下におけるARMマイコンの開発環境構築”入門”ではなく、
私が公開しているプロジェクトをビルド/デバッグするために必要な最小限の手順の
指南という位置づけです。
はっきり言いますが初学者向きの解説ではありません。専門的な語句の意味や
GNUMakeを駆使したコマンドラインビルドの方法を熟知している前提で話を進めます。
初めてSTM32等のARMマイコンやXMEGA等の大規模AVRマイコンに触れ、情報を
求めて迷い込んできたという方は私のぶろぐの事は忘れて回れです。

2017年現在は無料のEclipseベースの開発環境CoIDEGNUARMECLIPSE
無償版は機能は一部限定ですがAc6 System Workbench for STM32MDK-ARM
2品種、そしてオンラインコンパイラ+ライブラリ等の強力なサポートがあるmbedなどが充実して
おり、一般的な事柄を学びたい初学者の方にはそちらを強くお勧めいたします。


ちなみにねむいさんはメーカサポートが無い素のEclipseを使うと「あわびゅ!」と
叫びながら全身からを吹き出して死ぬ奇病に罹っていて、且つCygwinを使うと
バストサイズが強制的に20cm減のマイナス補正を喰らい(=フラットなB(Breasts)特性
を持ついないさん
と同レベルに堕ちてしまい)虹裏メイドねむいさんとしての
あいでんてぃてぃを完全に失ってしまうため、当ぶろぐでは絶対に扱いません。


 ※要注意※
   ツール群の盛衰や時勢により時々刻々と本記事の内容は変化していきます!



●必要なもの
 1.ARM用GCCコンパイラ
  とにもかくにもまずはこれです。
  現在はLaunchpad.netが提供し、ARM本家から配布されている
  GNU Tools for ARM Embedded Processors
  を強くお勧めします。主にCortex-Mx向けとなっておりますがLPC2388等のARM7TDMIも
  しっかりサポートしており古い品種でも問題なくビルドが可能です。

  今回の手順ではダウンロードした上記コンパイラをC:/Devz/ARM/launchpad直下に
  解凍するものとします。解凍後launchpadフォルダにはarm-none-eabi,bin,share,libの
  4つのフォルダがあるのが正解です。

  ほかにWindows環境下で動くARM用GCCコンパイラとして、Bleeding Edge Toolchain
  やdevkitARMなんかもあります。いずれもABIEABIで2017年現在流通している
  最新のコンパイラはもはやすべてEABIとなっています。


 2.サポートツール群
  ねむいさんが公開しているプログラムはコマンドラインビルドを想定しています。
  IDE全盛の昨今は古臭いものとなってしまいましたがmakeコマンドでビルドするという
  ベタベタなクラシックな手法を敢えてとっています。makeの他にunixコマンドのechoや
  rmなどを用いているので、これらのunixライクなコマンドをネイティブなWindows環境下
  で動かすことができるCoreutilsを使用します。

  a.Coreutils本体
   有志の方々が作成されたCoreutilsの"Binaries"のリンク先をダウンロードし、
   2バイト文字やスペースを含まない任意のフォルダに解凍してください。
  b.GNUMake3.81
   次にGNUMakeを同様にダウンロードしたあと解凍しCoreutilsを解凍した
   場所と同じフォルダに置いてください。
  c.サポートDLL群
   最後にmakeをダウンロードしたページの下にある"dependencies zip file
   (中身はlibintl3libiconv2)"をダウンロードしGNUMakeと同様の処置をしてください。

  今回の手順では上記3点がすべてC:/Devz/Coreutils/bin内にあるものとします。
  このbinフォルダ内にmake,echo,rm等のunixライクコマンドとdepedenciesの
  libintl3.dll,libiconv2.dllが存在していることを必ず確認して進めてください。
  ここで間違ってるとpn2からmakeを呼び出す段階でコケて失敗します。
  
  よくやる間違いが、最初のCoreutilsを解凍して出てくるbinフォルダの中に
  さらにmakeやdepedenciesの入ったbinフォルダを置いてしまうことです。

 

C:/Devz
   ├ARM
   |└launchpad
   | └bin (←GCCコンパイラのバイナリがある場所)
   ├Coreutils
   |└bin (←make他unixライクコマンド群のある場所)
   └ocd(←openocd.exeのある場所)
↑ねむいさんは上記のディレクトリ構造にしています。
  以下この構成で話を進めます。


  ちなみにAVRToolChainでもARMと同じような感じのディレクトリ構成にすると同じ
  感じでWinAVRの頃みたいにコマンドラインビルドが出来ますのでおすすめです。

  ※以前はWinAVRのutils配下にあった同様のファイル群の使用を推奨していましたが、
   WinAVRは開発が停止し数年経ち、フリーで利用できるAVRToolchainに主流が移行
   したのでもう一切使用しませんし使ってはいけません。


 2.5.sh.exeが見つかりません対策(必ずしも必要ではない)
  ネット上で手に入るARMマイコンのGCCプロジェクトの中ではWinAVRのmakefileを
  ベースにしたものがいくつか存在し、そこにはshell関数などのbashに依存した記述が
  数か所あります。この記述が含まれているとまともにビルドができません

  当ぶろぐで公開してるプロジェクトはmakefileからbash(/bin/sh)に依存して
  いる記述はすべて排しておりますが、他の方のプロジェクトをビルドする際の
  回避措置として紹介します。
  こちらからwin-bash.zipをダウンロードし、解凍して出てきたwin-bash.exeを
  Coreutilsのbinフォルダに突っ込んでください。次にmakefile ファイル中に
  記載されているはずのSHELLの設定を以下のように書き換えてください。
  SHELL = sh
  ↓
  SHELL = win-bash.exe
  bash.exeは自身のファイル名によって特殊な動きをするので横着してwin-bash.exeの
  方をsh.exeとリネームしてしまうと逆にビルドが通らなくなります。ご注意ください。



 3.エディタ
  メモ帳でせこせこ編集してコマンドプロンプトからmake実行してもいいですけど
  makeを引数つきで呼び出せられるエディタを使えばIDEのように使えます!
  ねむいさんのお勧めはProgrammers Notepad2(PN2)です。素のEclipseは(ry
  ビルド時の解説はこのPN2を使用して解説します。

  注:必ずStable2.3以降を使用してください。
    また、日本語入力に対応するために下記の要領で多バイト文字の設定を
    ”Shift-JIS”に変更しておいてください。
   

  

 4.デバッガソフトウエア&ハードウエア
  ARM用のデバッガはホビーユーザーご用達のGDBサーバであるOpenOCDを使用します。
  また、MCUとJTAGで通信するハードウエアはFTDIのFT2232系JTAG-I/Fを使用するのが
  スタンダードになっています。これらに関しては次回詳しく紹介します


●下準備とビルド
 ※以後はエディタとしてPN2をインストールして使うことを想定して解説します。

 1.ソースコードの展開
  今回の凡例として、STM32F4向けの液晶表示プログラムをダウンロードしてローカルに
  落としたzipファイルをローカルフォルダに展開します。
  このときディレクトリパス(アドレス)にスペースや2バイト文字が絶対に入らないよ
  うにしてください。
  

 2.makeファイルの編集
  PN2がインストールされている場合、拡張子pnprojのアイコンをダブルクリックす
  ると下のような画面になると思います。"makefile"をクリックして編集画面を
  出しましょう。
  

  下画像の要領でそれぞれの環境に合わせてARM用GCCコンパイラ、サポートツール群、
  デバッガのディレクトリパスを設定していきます。パスの区切りは"¥"ではなく"/"を
  使用してください。
  ディレクトリパスはスペースや2バイト文字が絶対に入らないようにしてください。
  大事なことなので二度言います!!

  
  

  ぇ?makefileの読み方書き方が分からないから教えろですって!?
  出直してきなさい!


 3.PN2の設定
  PN2をインストールしたての人は、makeコマンドをPN2の"TOOL"から呼び出すことが
  出来るように以下の要領でmakeコマンドを引数"all"つきで登録してください。
  その後、"build","clean"の引数についても同様に登録してください。
  
  
  

  重要:Windows環境変数のPATHはもはや設定する必要はありません!
     逆に下手に設定しているとビルドが通らなくなるので注意してください。


 4.ビルド開始
  
  ビルドの前に…デフォルトでは評価ボードの設定はSTM32F4Discovery向け
  になっています。これをSTM32F4系に汎用な形でビルド/デバッグしたい場合は
  上記画像のようにEVAL_BOARD = REDBULLにしてください。
  また、各評価ボード設定時の各ピン配置を知りたい場合は同梱のdoc/Boards.txtを
  参照してください。

  設定が終わったら"Tool"から"make all"を呼び出しビルド開始です。
  

  上記の液晶表示プログラムはデフォで下記のライブラリ/ドライバを有効にしてます。
    -libjpeg
    -libpng
    -giflib
    -FONTX2ドライバ
    -抵抗膜式/容量性タッチパネルドライバ(特定のボード限定)
    -HelixMP3デコーダ(特定のボード限定)
    -HelixHE-AACデコーダ(特定のボード限定)
  数分ほど時間がかかります。エラーが出てビルドが止まった場合は各種設定を
  見直しましょう。大抵パスの設定を誤っています。

  ちなみに"make all"はコンパイルしたオブジェクトを全部消してまっさらにしてから
  ビルド、"make build"はすでにオブジェクト吐かれたソースはスルーしてビルド(ソー
  スコードを一部書き換えてカット&トライしたいときに最適)です。
  "make clean"はその名のとおり生成されたelfやhexファイル含めてアセンブラリスト
  ファイルやオブジェクトをまるっと消去してしまいます。


お次はターゲットCPUへの書き込み&デバッグですが…長いので次回に続きます。

いろいろ試す8

国内は大変苦しい状況が現在進行形で続いていますが、今は新しい生活が始まる季節
でもあります。ねむいさんも二度とていどひくいといわれないように言われないように毎
年この時期に新たな決意をしながら勉強を重ねてきたつもりですが彼ははるかにていどた
かくなってしまってやっぱ資質も必要だよねと思いつつLED点滅で足踏みして茶を濁す
毎日を送っております…そうかあの悪たれも今春から阪大か〜…#




…てわけで前回に引き続き今回も小ネタをこなしていきます。

●キャラクタLCDを2線で制御する
元ネタは中華サイトのBBSより。2線と言ってももちろんi2c液晶ではないです。最低でも
データ4bit+制御2bit分合計6本のI/Oの接続が必要なHD44780互換タイプのLCDモジュ
ールを受動部品を駆使してたった2本のI/Oで制御を行うとこのとです。
コンセプトとしてはでんし研氏の鶏卵問題を解決するAVRライタに近いですね。
un
↑実際にATMEGA1284Pを使用してやってみました。久しぶりにAVR使った…
表示に使った超小型キャラクタLCDはtaobaoで一つ5元で購入したHD44780互換のもの。
これあと5個くらい持て余してるんですよね…(ボソ)ねむいさんは基礎研究しか興味
ないから面白い応用できる人が使ってくれるとうれしいなぁ(チラ

全部掃けました。ゲッツした方はweb上で面白い制作例を乗っけてくれると幸いです。


●LPC1114のI/Oトグルが…
> >>278
> main system clock48Mで、IOパタパタは約2Mだたよ。
とのことです。んなアホなと私も思いましたが、検証用のI/Oをトグルさせてる部分の
コード↓

while(1)
{
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
}

をGCC4.5.1の-O2でビルドして出てきた該当箇所のアセンブルリストが
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
390: 4a03 ldr r2, [pc, #12] ; (3a0 ) <-2cycle
392: 4b04 ldr r3, [pc, #16] ; (3a4 ) <-2cycle
394: 2100 movs r1, #0 <-1cycle
396: 50d1 str r1, [r2, r3] <-2cycle
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
398: 3101 adds r1, #1 <-1cycle
39a: 4249 negs r1, r1 <-1cycle
39c: 50d1 str r1, [r2, r3] <-2cycle
39e: e7f7 b.n 390 <-3cycle

でリファレンスマニュアル首っ引きで調べると合計14サイクル、理論上でもシステム
クロックが48MHzで約3.43MHzくらいでしかトグルすることが出来ない計算になってし
まうので最適化レベルにもよりますけどやっぱしこんなものですね…
ちなみにガチでLPC1114で理論上とりうる12MHzのトグルスピードを出したいのならば
STR命令の部分だけ延々と続くようにしてやればいいので、

while(1)
{
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
〜(出来る限り沢山並べる)
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
}
ってしてやるとよいです。
この場合実際のトグル波形は↓のようになります。
un
Cortex-M0のSTR命令は最短2サイクルのため、GPIOがAHBバスに繋がっているLPC1114では
48MHzの場合は最高I/Oトグル速度は理論上12MHzとなります。


話は変わりますが、audin氏が指摘しているMARY基板で公開しているソースのライセン
スが矛盾している件
ですが、ねむいさん的には金銭が絡まない限り、つまりソースコー
ド自身はタダで利用できる状態のうちは別に大きく騒がれないだろうと思われます(ぉぃ
などと偉そうに言ってるそういうお前はどうなんだと言われそうですが、私の公開し
ているもの
は該当するスタートアップのコードはSTM32のアセンブラのスタートアップ
コードを参考にしてarm-v6mでビルドが通すことのできる独自のものなので…
…ぇーとあのその…セ、セウト!

20111203追:
その後の顛末
あつ氏の見解

audin氏曰くMARYのライセンス形態が修正されたようです
i2c.h,i2c.cに関しては大本のNxPのKeil向けライブラリのライセンスに関する
文章を引用すると...
> Software that is described herein is for illustrative purposes only
> which provides customers with programming information regarding the
> products. This software is supplied "AS IS" without any warranties.
> NXP Semiconductors assumes no responsibility or liability for the
> use of the software, conveys no license or title under any patent,
> copyright, or mask work right to the product. NXP Semiconductors
> reserves the right to make changes in the software without
> notification. NXP Semiconductors also make no representation or
> warranty that such application will be suitable for the specified
> use without further testing or modification.
とのことです。
ざっと見たところ
"ここにあるソフトは製品(ここではLPC1xxx)のプログラムのしかたに関する情報
をカスタマーに提供する例示的な目的のためだけに書かれましたよ"

ってのと
"(あなたが)このソフト使うことに(NxPは)責任も負債も持ちませんし
特許・著作権・製品のマスクワークのもとにあるライセンスや商標も譲渡しません"

という点がミソですね。再配布(redistribution)の制限に関する記載が見当た
らないのですが、再配布たことによって面倒なことになっても俺(NxP)は
責任持たないよと解釈しておけばよいでしょうか。


おまけ
MARY基板でaitendoさんの格安OLEDボード動かして見ましたねむいさんはCheepにいくZE!
これは公開しているプログラムに反映されています。
un

●SUG○IHUBはSUG○Iのか
http://www.system-talks.co.jp/product/sgc-4X.htm
ねむいさんはシステムトー○ス製のSUH○IHUBを副業元のノートパソコンで愛用しています。
SUG○Iハブは独自の電力増強回路によりUSBデバイスを安定して動作させることができ
るという触れ込みです。確かにやっすいUSBハブではよく発生する「バスパワーのUSBデ
バイス挿しただけで突入電流で電圧ドロップして同じハブに刺さってるUSBデバイスも巻き
添えで認識外れる」現象が一切発生しません。しかし…

STM32のマイコン基板を一から組んででLDOの動作確認してる時に気づいたのですが、
このハブを使った時だけダウンストリーム側のVbusの波形がえらめっちゃ汚い…
un
※ねむいさんが持ってるSUG○Iハブはこっちの少し古い型なので現行のモデルでは改
 善されているかもしれません

恐らく独自の電力増強回路(=+5VDCDCコンバータ)のスイッチング時の出力波形がもろ
に出ちゃってる感じです。デジタル回路だけならあんまし問題無いですが、これアナ
ログ含む回路だとこんだけ揺れてるとちょっと都合が悪いです。
てわけでハブ側の改造でさらにSUG○くできるかしてみました。
un
基板はDC-DCコンバータとNEC製のUSBコントローラIC,そして2ポート分(PORT1とPORT2)
だけですがUSBパワースイッチャ(電源監視)ICまで積んであります。さらにダウンストリーム
側には100uFのアルミケミコンが1ポートずつ鎮座しています。市販のハブのほとんどが最
低限のパーツで寄せ集めたチープな作りなのを鑑みると値段にしては超豪華な作りだと思
います。で、こんだけ出力に電解乗ってて波形があれってことはESR不足かな?てことで
DCDCの出力部に低いESRのキャパシタ乗っけりゃ解決かなと判断してねむいさんのトラの子
NEC-TOKIN製NEOCAP(150uF/10V品)をぶち込んだ!
un
un
よし!
てわけでさらにSUGO○くなれたようです。前途のとおりデジタル回路用途のみなら未
改造でも問題無いので昨今のUSB機能付きのマイコンでバリバリ開発する人には多少の
おいたにはびくともしないこのハブお勧めです!


●某付録のRX62N基板
国産マイコンは諸般の事情で全く興味ないので去年と同じく電源周りの挙動だけ…
un
電源立ち上がり
un
電源立ち下がり

去年のSH2A基板はLDOの出力が入力が断たれた後も0.数V程ず〜っとチャージを保ったまま
になって次回の電源投入時に不具合が出ていました。しかし、今回は+3.3VLDOにSBDをか
まして素早くチャージを放電するようにしてあり、しっかり対策されているようですね。

いろいろ試す7

この度の大地震で被災された皆さまには心よりお見舞い申し上げるとともに一日も
早い復興を願っております。私も復興支援を私なりにできるかたちで行っていきます!



…てわけで電子工作野郎になる時間がなかなか取れなくなってしまったので今回はも
ともとタイトル通りいろいろやるつもりだった内容を大幅縮小変更してお送りいたします。


●AVRマイコンを使ったバックアップ機能つきRTC時計
un

前回軽く紹介していましたが実用レベルになれたので改めて紹介します。目玉はRTCの
バックアップをATMEGA644pのパワーセーブモードで行い、外付けのRTCのモジュールを
排したコストダウン仕様となっています。表示部は部品箱の肥やしになっていたNoritakeの
キャラクタVFDを使い視覚性も良好でLM60を使用した温度センサで気温も同時表示出来
るようにしました。
気になるパワーセーブモード時の消費電流ですが、ADVANTESTのnAオーダーで測定でき
るデジタルマルチメーターで測定したところMAX3uA,平均1uAでした。CR2032(約220mAh)
なボタン電池でも単純計算で3000日以上余裕でバックアップ可能なわけです♥
主人がATMEGA328で作ってたやつはバックアップ時にAVCCを断つというセコ技を駆使して
も80uA程喰っていたのでそれを鑑みると非常に満足のいく結果と感じています。

消費電力削減の為にはファームで省電力レジスタ群をいじったり割り込み時のステート
を考慮するのはもちろんのことですが、VCCまわりの回路構成も非常に重要です。AVRは
STM32等の今日びのARMマイコンのように独立したパワードメインは無いので、逆方向
漏れ電流の非常に小さいショットキバリアダイオードでしっかりと分けてやらないとせっ
かくファームで省電力化できても外部回路からダダ漏れとなってしまいます。こういうの
意識しながら作ることを経験しとくと他でも応用が効くと思います。

時計合わせはUARTのコマンドからのみという手抜…シンプルな仕様!mega328バージョ
ンでは回路に取り込んでいたAVR309を外に出して手抜…回路の簡素化を図りました!


●STM32マイコンを使ったUSB-CDCが…
※知ってる人もいるかもですがかなり以前の話です
iruka氏のSTM32を使ったUSB-CDCの考察の最後に出てくる魔の時間帯について。
ループバックして、氏のw32termのテストモードを走らせるとこの時間に高確率で引っか
かってフン詰まり状態になってしまいます。単純にダブルバッファリング化しても同じ結果
だったのでUARTのデータを受ける部分の処理がまずいのでしょう。てわけで魔の時
間帯でもデータを受け付けるように…
…しただけでフン詰まり現象は無くなりました!
un
UARTの通信込みでこんだけ叩きだせるなら恩の字じゃないかしら!?
でもやっぱし専用ICには到底かなわないので、遊び以外で使わない方がいいですよ(重文)
上記の成果はおきばにあります。
20110406追:
STM32のUSBライブラリがV3.3.0に上がりVCPのデモもこの問題が修正されたと見せか
けて修正されていないようです。ご注意を!

●STM32 ValueLine-Discovery
を秋月さんから購入しました。ねむいさんみたいに買ってすぐにバラすような人対策か、
ST-Linkの部分が切り離すことができません。しかしこのST-Link部もVersaloon化できる
ようになっているのでさっそくVersaloon化してみました。これについては後ほど別記事で
詳しく取り上げたいと思います。

un
↑お約束のTFT液晶モジュール。8bitバス繋げるのめどいのでSPI接続方式の液晶で…。
この評価ボードのセットはSTM32が二つも付いているので(部品取り基板として)とても
利用価値があると思います。機能限定で単品物作るなら新品でパーツ揃えるより安上
がりで最適でしょう。


●トラ技別冊LPC1114ボード
圓山宗智氏作のMARYと呼ばれるLPC1114と周辺のボード群にちょっと興味が魅かれた
ので購入してみました。最初はLPC1114基板とCP2104基板で2枚組かと思ったのですが、
本当に同じ基板が2枚(LPC1114+CP2104の基板が2つ)なのですね…
un
LPCXpressoと大きく違う部分はLPC1114のメイン発振器が内部オシレータ(LPCXpresso
は外部に12MHzの水晶がある)の使用を想定しているのでスタートアップ時のオシレータ
選択レジスタを内部オシレータにしとかないと動かないといったところくらいでしょうか。

CQ誌のサイトからダウンロードしてきたMARYのサンプルを参考に過去に作ったとっかか
り用のLPCXpressoのプログラム
と共用できるようにしてみました。
MARY上で動かす時はmakefile内のボードの定義をMARYに変えるだけでおkです。
un

つづく

いろいろ試す6

あけましておめでとうございました!

去年に"来年から本気だす"といったものの自分の誕生日の絵作ったりたぬたぬの置物
をはるばる信楽まで(次回詳しく解説)買いに行ったりしてブログの更新もままならな
いほど大忙しであっという間に1月中盤です。

更新はしてませんでしたがいろいろ手は動かしています。今は思うところあってAVRマ
イコンを使ったベタな時計を作っています。
un
と言っても私が一から作ったわけではなく、↑写真左のように以前に作られたATmega328
で作成された物をATmega644pへと移植するような感じです。5年前に残された資料をもと
主人の遺品をふんだんに使ってにあれやこれやしたり主人が作り込んだヘボい処理を
修正したりしてますがコンセプトとしてはO-family氏のATmega88pを使用したものとほぼ同じ
物になりそうです(最初「すん氏の〜」と誤って表記してまいました。双方にお詫びします)。
しっかしVFDは見やすくて良いものだ〜

また、去年汎用のTFT液晶モジュール表示プログラムのARM版を更新しましたが、XMEGA版
もやっとこ最新に更新しました。こちらです。ビルドは最新のAVR Toolchainを使用してください。WinAVR20100110とはSRAM・ProgramMemoryににおいて64kb以上の領域にアクセス
するためのマクロが公式に取り込まれた絡みで互換性は全くありません!
この件については次次回の記事にてみっちり解説します。



んでもって上のやつを早急に終わらせたら次はまたARMに戻っておべんきょ継続です!
un
↑川内康雄氏の著書をねむいさんも購入しました。仕事でやってる人も続々参入してレ
ヴェルが跳ね上がった今の電子工作シーンに対応するため、私も一から基礎をみっちり
やりなおすことにしました!それ言ったの何度目だよそれっていう突っ込みはスルーで!

試用するSTM32についてももうすぐ出るらしいが全く音沙汰がないF2系の大規模なMCUを
意識してSTM32F103ZET6と超高速SRAMが乗っかるボードをtaobao経由でチップと基板を
別々に買って必要なパーツだけ実装して使っています(日本で同じものをフルセット買うより
かなり安くなるため)。
un
↑STM32F103ZET+高速SRAM物で一番小規模な奴。
 セコく基板だけ買ったせいで回路図もらえなかったので解析からする羽目にorz
un
↑中華評価ボードでは比較的有名なPowerAVR製の基板たち。
 上がSTM32F103ZETのもので下がよく使ってるSTM32F107VCT6のもの。

STM32F107VCT6版は単に以前のものを移植だけで済みました。これはのすでに公開してる
プログラム
中で統合済みです。しかしながらSTM32F103ZETのは、はぢめて触るのでベースとなる環境から整えないといけませんね。先ずは基本的なFatFsと液晶表示の実装なわけですが
今回は外付けSRAMも絡むのでそちらも併せて取り入れていくことになるでしょうね〜。これができたら次はI2S!んでさらにそれをSTM32F107VCTにフィードバック!
(↑すぐなかったことにする人間なので一応宣言しときます…)


そしてARMに関してはもう一品、LPC1343を使ったライントレースロボットの学習教材
ビュートローバーも秋月さんから販売されていたので買ってみました。
un
↑コンパクトなパッケージ。
un
↑中身こんな感じです。

un
↑組んでみました。

un
↑…

電池買って無いや。続きはまた今度!

あばばばば

…はぁ、今年も終わりですね〜…
今年の〆として、
STM32F107VCT用とLPC2388用、そしてSTM32Primer2用の液晶表示プログラムを更新し
ました。
いつものおきにありますのでご自由に〜

そうそう、CodeSourceryの中のGCCが4.5.1になってLinkTimeOptmizationも実装されて
いますけどもちろんそれにも対応しています。-fltoを付けるだけですが、結構目に見えて
違いが出てきますので試してみてください。


今年の後半は高専等の学生さんからの質問をたくさんいただくようになりました。
私もわかりやすい記事を書くよう努めたいと思います。あと「」からいないさんのイラスト
云々のお問い合わせも時々いただきますが"びょういんいけ"と的確に対応しております。

…とりあえずもう液晶デバイスばっかいぢるのは卒業してねむいさん自身も新たなる
ステージに進む必要があると痛感しています(キッ
まぁそう気張らずにtaobao等で購入した怪しいデバイスとかを消化していくつもりで
す。やってるうちに新しいネタを思いつくと思います。


というわけでねむいさん来年から本気出す!!


中華TFT液晶モジュールを動かしてみる(概論)

※今回の記事は適宜追加・修正していきます。

Arduino等のプロトタイプボードを使ってaitendoさんで売ってるようなMCUバスで動
かすタイプのTFT液晶を専用基板起こさずに無理くそうごかそうとするとどうしても
ジャンパ線山盛り配線になってしましますがこれを8bitじゃなくて16bitバスでやって
みるとどういうことになるかというと…
un
こういう地獄絵図になるわけでしてもう二度と横着しないと心に誓う。
さて、上の画像表示に使ったのはコントローラICにILI9327をもつDST9901A-NHとい
う3.2インチ、WQVGA(240x400)の液晶モジュールです。データシートにはコントロー
ラICがHX8352Aとか書かれていますがブツはちゃんとILI9327です。aitendoさんでも
同じのを扱っていますが、私のはtaobaoで他の商品と一緒にまとめ買いした物です。
(ねむいさんはHX8352Aのものもちゃんと持っててこれはDST9901A-NHとくりそつなnです
が8月位に一度ぱ…動かしてるところをお見せしてますね〜…ぬふふ)

データシートや製品紹介に記載されてる内容が現物と全く違うとか言うのは中華液
晶だけでなく中華製品にはよくある話ですが、TFT液晶モジュールを使って何かを
作るのではなくてモジュールそのものを動作させ(ただけで満足して飽き)ることが
目的と化してしまったねむいさんが得た情報をtaobao経由の購入の事例にからめて
お伝えしますね。




基本的にTFT液晶(とOLED)モジュールは大きく分けてRGB,MCU,シリアルの3つの
接続方法があります。MCUバスとシリアルバスで接続できるモジュールはフレームバッ
ファを内蔵したコントローラICを必ず持っていて、AVR等のメモリ資産がほとんど無い小
規模のマイコンでも簡単に扱うことができます。
今回はそのMCUバスとシリアルバス接続方式のモジュールついて説明します。

●MCUバス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。
un
↑i8080タイプのMCUバスの場合
ほとんどのモジュールはi8080タイプの8bit若しくは16bitのMCUバスとして、アクセ
スを行います。一部のモジュールではM68kタイプのアクセス方式を選択できるものが
ありますが一般的にi8080タイプのアクセス方式の方が圧倒的多数となっています
(HD44780とかはM68kタイプですね)。中規模のマイコンが持っている外部バスで接続
したときは、マイコンからはアドレスが2つだけあるSRAMに見えることになります。

i8080タイプの方式はMIPI AllianceDBI(Display Bus Interface) Type Bに相当します。

また、データバス幅はコントローラICのデータバス幅選択ピン、ILI系列のICならIMx
に当たるピンをモジュールへのリセット信号入力時に信号レベルを確定しておくこと
によって選択されます。モジュールによっては外部まで出ておらず、FPC上のチップ
抵抗の配置によって決定しなければならない物や16bit幅に固定されてしまっている
ものがあります。
逆に低解像度でサイズが小さいものはFPCの面積的に8bitに固定されていたりします。

以下にaitendoさんでも購入できるモジュール達のビット幅変更箇所等を。
STM025QVT-001はソフトウエアからビット幅が変更可能な逸品なので割愛します。

un
YHY024006A
un
EGO028Q02
上二つはFPC上のジャンパ抵抗(0ohm)の配置でバス幅を決定。
un
un
WBX280V009
FPC上のジャンパ抵抗(0ohm)を画像の位置に移すとIM0ピンが外部に出る。
…と以前書きましたが最近出回ってるのは少し違う模様。
なんと写真に示すとおりFPC上のパタンで16bitバス固定になっていました。
8bitバスで使ってる方や、Ardunio使いの方は別のTFT液晶モジュールを
使用しましょう。
un
DST9901A-NH
ビット幅選択ピンは外部に出ている。FPC上に抵抗を実装できるパタンはあるが、
前途の理由でFPC上で作業は不要。

ちなみにFPC上の該当のピンにIMxが出ていなくて実質上NC(NoConnect)になって
るモジュールもありますが、UEW等の極細の線でジャンパを飛ばしてやれば無理やり
ですが外部から選択もできます。ていうかこうしておく方がなにかと便利ですよぅ



●シリアルバス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。
un
今日びの一般的なマイコンではほとんど有しているSPIインターフェースを用いて接続
することができます。基本的にMCUバス接続方式とアクセスの手順は変わらず、パラレ
ルのデータバスがシリアルになっただけです。
比較的小規模の解像度のTFT液晶/OLEDモジュールがシリアルバスの接続方式を有して
います。一部のモジュールでは外部ピンの設定によりMCUバスも選択できるものがあ
ります。このとき一部のコントローラICではシリアルバス接続だとREADができないも
のがあります(よってMISOが不要)。
ST7735は一つのラインがMOSI/MISOを兼ねていて制御は少々特殊です。
READもするのならSPIインターフェースよりGPIOのソフトSPIの方が使いやすいでしょう。

この方式はMIPI AllianceDBI(Display Bus Interface) Type Cに相当します。


QVGA以上の解像度ではコントローラICがサポートしているにもかかわらず設定用のピン
が外部に出ていないためシリアルバス接続方式が選択できないものがほとんどです。
逆に大きい解像度のRGBインターフェースをもつパネルにもSPI用のピンが出ている
ことがありますが、これはリフレッシュレートやガンマ値の設定専用というあくまで
RGB_IF(MIPI DPI(Digital Pixel Interface))の補助用です。


以下にシリアルバスで接続できるモジュールたちを。
un
aitendoさんのおなじみ小型OLEDモジュール。バス選択ピンの設定によりMCUバス
接続方式も可能です。このキャリーボードはSPI固定になっています。
コントローラICはSSD1332。少々癖があります。
・CSは8クロック目でD/Cの同期をとるため、下げっぱではだめ。
・GRAMに書き込むときはダミークロック1つ入れること。

un
同じくaitendoさんでも売ってるH161T01。これを使った「TFT-LCD Shield」がMTM06
でNetSynth.orgのブースにて販売されました!そうだね宣伝だね。
お問い合わせはshield.io若しくはねむいさんまで!!

un
taobao経由で購入したシリアルの他にRGB,MCUバスも選択できてQVGAな液晶。
しかし前途のとおりコントローラICがSUCKと言う罠

un
同じくtaobao経由で購入した、シリアルの他にRGB,MCUバスも選択できてQVGAな液晶。
これはコントローラICが馴染みのILI9325なのでさっきのと違って暴走とかしないで安定し
て動きます♥♥
…と思ったらdeviceIDを調べるとILI9325フルコンパチのILI9328であることが
分かりました…。まぁこの程度のチャイナリスクは想定済みです。

un
最近ebayを試用したときにego-chinaさんから購入したSPI接続専用タイプの
TFT液晶モジュールJD-T18003-T01。コントローラは皆さんおなじみのST7735です。
高速性は必要なくてちょっとした表示に使いたいなんて時に重宝します♥
un
そして小動物の足。
20110519追:
JD-T18003-T01には型番・外見はまったく同じですが、中のコントローラICが異なる品種(ST7735R)があります。
ST7735RのものはST7735と初期化手順が異なるのでST7735のコードでは一切
動きません!注意!

しかもご丁寧にデバイスIDまで一緒なので私のいつもののディスプレイドライバの
ソースはST7735とST7735Rは分けてあります。敢えてそうしてあります。




↑購入したばかりの状態だと保護シールのはがしタブの色の違いで
 見分けがつきます…


さて、これらのマイコンから簡単に扱える液晶/OLEDモジュールは少し前までは国内
向けのリユース液晶をボッタ価格で購入せざるを得なかったのですが、現在は大陸系の
電子部品屋であるaitendoさんがいわゆる中華TFT液晶モジュールを販売していて、
日本国内でも使いやすく安価な液晶を手に入れることができるようになりました。

通常の電子工作に使用するならば入手性・価格性・資料性・ユーザともにaitendoさん
で扱っている商品で十分なのですが、もっとマニアックなのを使いたいとかあやしい
液晶モジュールををあえて動かしたいとかいう奇特な人にはtaobaoで購入することを
お勧めします。こっからが今日の本題です!



●taobaoで売っている商品を買う
先ずtaobaoのメインサイトで欲しい商品を検索して探します。検索のときには当然
ひらがなカタカナはNGです。TFT液晶モジュールを探すなら"液晶屏"とかのキーワー
ドを絡めてみましょう。

めぼしいものを幾つか見つけたら買いたいものをいったんリストアップしましょう。
国を跨ぐので中国国内送料に加えて国際送料がかかります。小種類・少数だと効率
が悪いのでよく考えて買う物を決めましょう。

買いたいものが決まったら日本国内で購入代行をしてくれる業者さんに依頼します。
日本国内から業者挟まないで直接購入するのは日本住みでなおかつ故郷にも生きた
銀行口座を持ってる中国人くらいしか無理だと思います。
購入代行業者さんも業務形態・料金の計算方法などはさまざまですので説明をよく読
んだり質問した上で自分が購入する予定の物・値段・量・そして店舗数を考慮して
最適なところを選びましょう。料金の支払いは、落札作業前と日本に発送される前の
2回にわけて請求されることがほとんどです。

業者さんを選んだら購入依頼のやり取りを行いますが出来るだけ詳細を伝えるように
してください。こちらでは周知のことでも担当の人は基本的に部品知識は無いので
意図が伝わらないことが有ります。これこれこういう理由でこうしてくれ・こう伝え
てくれとお願いしましょう。また、購入は現地の落札担当の人が相手先店舗の人とや
りとりを行うことがほとんどです。その際に不明な点がある時は質問が返ってくると
きがあるので丁寧に分かりやすく返答しましょう。また価格が半導体部品で1元とか
異様に安い値段設定されているものもありますが、これはたいてい万個単位で購入し
た場合の価格のことで、**個なら一つ**元だがそれでもいいか?と返事がきます。
逆に他の店舗と比べて2/3くらいの微妙に安い値段で取り扱ってるのはリマーク品や
フェイク品がまぎれている可能性があるためよく吟味してください。


それと超重要な事柄ですが相手先店舗が製品紹介文に"資料は配布する"と明記され
てある時は落札時に必ずもらうようにお願いしましょう。言わないとブツだけが来て解析
に大幅に時間がかかります。もらえるものは全部もらってください!
20110404追:
taobao代行王さんで購入代行依頼した際に上記のお願いしても無視されます。
自力解析出来るor過去に動かした経験がある物じゃないとお勧めできません


しかしこれだけよく考えてやりとりしてもお国柄とんちんかんになりがちですが…

…っというわけで落札が終わりお目当ての商品が届きます…物や地域にもよりますが
2010.12現在だと購入代行依頼してから早くて3週間弱で手元につきます。たいていEMS
で届けられます。


●実際に解析して動かしてみる
un
↑2.2寸の液晶モジュール。
落札時にデータシートを送ってくれと何度も頼みましたが対応してくれませんでしたorz
こういうことは非常によくあります。仕方なく自分で解析を行います。
解析の流れは以下の手順で進めます。

 ピン配置の推定
    ↓
 コントローラICの推定
    ↓
 初期化手順の決定
    ↓
 基本動作確認


TFT液晶モジュールを数種類以上触られてる人はご存知かと思いますが、FPCのピン配置は
メーカーが違えどほぼ同様の"定番"なパタンのものがあります。
たとえばEGO028Q02とWBX280V009はピン配置が全く同じでキャリーボードが使い回しでき
たりします(YHY024006Aもピッチは違いますがピン配置は同じです)。そのことから同じ
ピクセルサイズ&インチ数の液晶モジュールの中でデータシートが手に入るものを調べ、
記載されているピン配置から詳細不明のモジュールのピン配置を推定することができます。

幸いにもこのモジュールは一目しただけでわかるレベルでパタンが別れていて容易に
ピン配置を推定することができました。
un

次に、液晶のコントローラICの推定を行います。ピン配置の推定した時と同じように
似たサイズモジュールのデータシートより候補とするコントローラICの型番を控えます。
2.2寸のものは176x220ピクセルの品種が多いようですね。176x220ピクセル対応の品種
をあらかじめ絞り込んでおきましょう。これをもとにコントローラ内のレジスタの値を読み
出し、コントローラICの決定を行います。大抵は00h番地のレジスタにコントローラ固有の
"device code"をもっています。ILITEK系列のものはほとんどこれでコントローラの種類を
判別できます。電源電圧はLED用電源を除いて3.3Vでほぼ事足りますが、LCDモジュ
ールでは標準的な2.85Vが作れたらそれに越したことは無いです。


しかしこの液晶モジュールは読みだしても0x00が帰って来るだけでした。違う番地の
レジスタに値を放り込んで読むと放り込んだ値が正しく返ってくることから読み書き
はきちんとできていることが分かります(これができていない時はピン配置の推定まで
戻って調査しなおしです)。

私は上の結果から、176x220ピクセル対応で特定のレジスタ番地にdevice codeが無い
品種のものとして"HX8340B"がこの液晶モジュールに使用されていると推定しました。
ここまで絞りこめたら後はネットでこの型番を検索して初期化手順を調べます。たい
てい中華サイトから見つかるでしょう。なんせ中華液晶モジュールですから…。


ところでコントローラICのレジスタの値を読み出すとか言ってるけど具体的にどうすれば
いいの?という話になりますが、私の場合は動作実績があるILI9325系列のプログラム
を使用し読み出しを行っています。これはChan氏が公開しているOLEDテスト用のプロ
グラムをベースに各液晶モジュールにも対応できるように構造化させたものです。
またchan氏のFatFsのテストプログラムも兼ねています。
おき
上のおきにあるコードで実践していますが、"汎用で使える抽象的なレベル"と"
デバイス固有のレベル"なコードとを分ける、プログラムのライブラリ化やモジュール化を
しておくようにすると、未知の液晶/OLEDモジュールを調査する時やトラブルシューティング
時の問題の切り分けにも役に立つかと思いますので、コードサイズや速度を気にしない方
に強くお勧めします。


話は脱線しましたが、HX8340Bの初期化手順を作り、確認用プログラムを走らせます。
un
おっし!
こんな感じで上手くいけたら目的達成です。画面が真っ白でうんともすんとも言わない
場合はピン配置やコントローラICの推定まで戻って解析を進めましょう。
この液晶、大きすぎず小さすぎずで手軽に扱える掘り出し物を引き当てたみたいで、
ねむいさん的にはとても気に入ってます♥
次構想してる基板に載せちゃおうかな見たいな
20110824追:
その後の調査で宇顺电子のS95329というS95215Aを改変したモジュールである
ことが確定しました。

20111110追:
さらにその後改訂版のデータシートを手に入れ"Read HIMAX Device ID"
コマンド(0x93)でDeviceIDを読み出すことに成功しました。


データシートや資料が手に入ればここまで苦労することは無いのですが、何せ相手は
大陸なので資料が手に入ったとしてもまだ安心はできません。ふつーに全く違うデバ
イスの資料付けてきたり素で勘違いしてたりなんて日常茶飯事で私が経験してるもの
だとコントローラICがILI9320ものを指定して購入したつもりが実際に動かしてみると
"ハズレ"のLGDP4531で、資料として送ってくれた"ILI9320"の初期化ルーチンとやらも
見比べるとLGDP4531のものだったとかあってもう勘弁してくだち…
もしLGDP4531のものを引いてしまったら奇声上げながら窓から投げ捨てる以外にない
とおもいますね…(←本気でやっちゃだめよ!)

というわけでオチが無い話をつらつらと書き殴ってしまいましたが、そこまでしてチ
ャイナリスク負いたくない人は中華液晶モジュールばっかいじってる奇特な人と仲良く
なって動作が保証されてるのを譲ってもらうのがいちばんだとおもいまし た!
それといつまでも液晶デバイスばっかいじってても進歩がないので次はまぢで新しい
別の試みに手を出していこうと思います。


ちなみにおきで今もメンテを行っているSTM32F4向けTFT液晶モジュール表示サンプル
以下のコントローラICに対応しています。いろんなサイト巡って集めてきましたが、すべて
動作確認を取っています。何気に当ぶろぐの一番人気のメインコンテンツです!
20161028追:
現在、液晶ブームはひと段落したのか今度はESP-WROOM-02関連の記事がぶっちぎりです。
次点はブラウザベンチマークとか日本の自然歩道です。

*ILITEK
ILI9160
ILI9163B/C
ILI9132
ILI9222
ILI9225/B/C/G
ILI9320
ILI9325/C
ILI9326
ILI9327
ILI9328
ILI9331
ILI9335
ILI9338B
ILI9340/C
ILI9341
ILI9342
ILI9481
ILI9486L
ILI9488
ILI9806H(HALF-RAMモデルのためMCUバスには向かない)
ILI9806G

*Renesas
HD66772
HD66773
R61514S
R61503U
R61505U/V/W
R61509/V
R61526
R61580
R61581/B0

*Himax
HX8309A
HX8310A
HX8312A
HX8340A
HX8340B(T)
HX8340B(N)
HX8345A(T)
HX8346A
HX8347A/D/G
HX8352A/B/C
HX8353C/D
HX8357A/B/C/D
HX8369A/-00/-01

*NEC
uPD161704A

*Solomon
SSD1332(OLED)
SSD1339(OLED)
SSD1351(OLED)
SSD1283A
SSD1286A
SSD1289
SSD1297
SSD1298
SSD2119
SSD1963(外付けタイプ)

*EPSON
S1D19122
S1D19105

*Sitronix
ST7735
ST7735R
ST7732
ST7781
ST7785(ST7787とまったく同じコードで動く/バスアクセスはかなり遅くすべし)
ST7787(バスアクセスはかなり遅くすべし)

*MagnaChip
MC2PA8201(Nokia6300 & NokiaE51)
D51E5TA7601(HALF-RAMモデルのためMCUバスには向かない)

*LG
LGDP4511
LGDP4531(←VCCの立ち上げを遅くしないと発熱して暴走します!!!)
LGDP4535
LGDP4522
LGDP4524
LG4538(LGDP4538の誤字ではない)
LGDP4525
LGDP4551

*Samsung
S6E63D6(OLED)
S6B33B6(CSTN)
S6D0117
S6D0128
S6D0129
S6D0144
S6D0151
S6D0154
S6D0164X1
S6D1121
S6D05A1
S6D02A1
S6D04D1

*瑞鼎科技股份有限公司
RM68050(ILI9325と全く同じ)
RM68070(ILI9335と全く同じ)
RM68042
RM68090
RM68110
RM68120

*旭曜科技
SPFD5420A
SPFD54124B
SPFD54126B
SPFD5408A
SPFD5408B
OTM3225(ILI9325とまったく同じ)
OTM8009A(STM32F769I-discoveryでDSIにも対応)
OTM8012A(HALF-RAMモデルのためMCUバスには向かない)
OTM4001A(R61509Vと全く同じ)

*統宝光電
C1L5-06
C1E2-04

*朋億股份有限公司(NOVA TECHNOLOGY)
NT3915
NT35510
NT35702
NT35582

*Tomato LSI Inc
TL1793
TL1771


*その他
SEPS525(OLED)
REL225L01
FT1505C


おまけ
駄目押しチャイナリスク
un
↑ワーィ USB3.0のExpressCardだ〜!
un
↑ウボァー!

いろいろ試す5

こんなんきました…これはありがたい…
un
un
以前購入したものの全く触れていなかったPSoC5を少し触りました。PSoC5は中のCPUコア
がMAX80MHzで動作するCortex-M3が採用されています。6月位にPSoC5の評価キット
PSoC 5 FirstTOUCHが安価で販売されたので、CypressからSRAMと一緒に購入しました。

un
統合開発環境のCPUコア(Cortex-M3)プログラムのビルドはGCCです。
CodeSourceryG++を呼び出すようになっています。

un
P.O.V.による文字表示がデモプログラムが出荷時に書き込まれています。電源を入れて
ぶんぶんふるとメッセージが順次表示されます。

今現在C言語ソースしかいじり方が分からないのでCypressのサイトのチュートリアルでも
みてツールの使用方法を覚えていきますか…。以上前フリ終わり!



さて、ゆっこちゃんの誕生日(だいぶ前ですが)も無事終わり、少し落ち着いたので
かねてから考案中だった複数のフォントに対応したFontX2ドライバ作りを行いました。
ProjectC3氏のページの内容を元に以下のような動かし方にしました。

1.半角・全角ごとにFontX2ファイルのヘッダー部の構造体をSRAM上に構成する。
2.各フォントを登録するごとにSRAM構造体の分だけをゴリゴリ消費。
 (というわけで比較的大規模のマイコン上での使用を想定してます)。
3.半角・全角ともにグローバルなFontX2の構造体ポインタを置き、文字描画する関数
 群は全てこれを参照するようにする。
 使いたいフォントで文字を描画する前に構造体ポインタに「1.」で登録した構造
 体のアドレスを渡すようにする。こうすることで使用したいフォントを簡単に切り
 換えることができる。
4.FontX2側のドライバは使用するFontX2ファイルの登録と、要求されたascii/sjis文字
 コードに対してフォントデータの実体があるアドレスのオフセットを返す。

決め打ちでやるのならばSRAMなぞ消費する必要はないのですが、汎用性を上げたかっ
たのでこんな感じにまとまりました。今はまだマイコンのフラッシュメモリ上にFontX2
のデータをそのままのっけています。こちらも追々と大容量のSPI-ROMに追い出すつ
もりです。

というわけでSTM32やLPC2388のTFT液晶表示プログラムにそれを組み込んでおきました。
タッチパネルの設定の際に使用しています。

un
当たり前ですがフォントそのものは同じなので以前のと見た目は変わりませんけどね。
表示に使用しているデバイスはSTM025QVT-001を使用しています。何気に使用可能な
MCUバス接続タイプのディスプレイモジュールの種類もどんどん増やしていってます。



あと、IJG JPEGライブラリを使用したjpegファイルのデコードの実験なんかも試みて
います。同ライブラリを使用したsirius506氏作成のmp3プレーヤーのフォトフレーム部を
そら氏がSH-2A向けに利用されたものをさらに参考にさせてもらいました。

いろいろ試行錯誤してようやくビルドが通ったのですがバイナリサイズが220kbyteも膨
れ上がってしまったのでフラッシュメモリ容量がMAX256kByteしかないSTM32F107系には
到底載りません。というわけでjpegデコード機能を乗っけるのはフラッシュ容量が豊富
なLPC2388やSTM32 Primer2向けのみ(将来的にはLPC1769も)になりそうです。

QVGAサイズの場合LPC2388ではjpegデコードに必要な最低限のRAMは1024*35=35840Byte
以上必要でした。RAMもそれなりに喰うようです。その際標準関数mallocがheap領域を
使用するのでスタートアップをいじりmakefile内で使用量を明示できるようにしました。


un
コツ
un
メカ
un
ワウソ
やっぱデコード->描画には多少時間かかりますね。他にもIJG JPEGライブラリはリサイズ
機能なんかもあってピクセルサイズが大きいものでも縮小してくれます。
今回使用した小動物たちの画像は大阪海遊館で撮影したコツメカワウソたちです。
まだ全く手を付けてませんが120MHzで動くLPC1769で同じことやるとどんだけ早くデコ
ードできるかちょっと楽しみです。



最後になりますが、少し前からTFT-LCDShield開発の折にtaobaoで液晶モジュールなどを
いろいろ購入していました。その中でひときわ目立ってた3.5inch、320x480の大解像度、
それでいて扱いやすいi8080インターフェースで接続できる液晶モジュールを紹介します。

un
un
デカイ!
un
で、デカイ!
un
72MHz駆動のSTM32F107VCT6だとSDカードから320x480,24bitの標準的なWindowsBMPファ
イルの一枚絵を読み取り表示するのに掛かる時間を測定したところ約360mSec掛かりました。
(全画面消去->SDカード読み出し->RGBデータ24bit->16bit変換->GPIO転送)
誰ですか900mSec以上掛かって遅くないかとか言いがかり付けてる人は(ビキビキ


普通これくらいの解像度になるとRGBインターフェースしかないのですがこのモジュールは
i8080のMCUバスで接続できるコントローラIC(ILI9481)が内蔵されていてAVR等のワンチ
ップマイコンでも手軽に扱えます(ただし16bitバス強制)。
まだタッチパネルが搭載されたモデルは一般に出回っていないものの、簡易でフォト
フレームを作成するのなら見栄えがあるものができると思います。



おや?aitendoにも似たようなものが…?(棒読み)
追:私のはFPCの形状・ピン間隔・外観が全く違う別物です!

JTAGKey2Cloneをもっと使ってみる

20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。

20150514追:






よし
やっと日記書く余裕ができた…MTM05に参加された皆様、本当にお疲れ様でした。
日記はぢめてもう1年たったことだし、ねむいさんもていどひくいと言われないような仕事を
したいものです。本業の虹メの方がスレの途中で寝落ちしまくっててていどひくいどころ
じゃない状態なのは置いといて。てかいつもスレに参加してくれてる人ごめんなさい…。


20130422追:
HJ-LINK/USB とispVMにも対応する JTAGKey2互換の回路図起こしました


さて本題、前回はJTAGkey2のクローンを作成し、LPC2388のフラッシュプログラミング
でRTCKの威力を確認しましたが、今回もう少し設定をなぶってみました。
CQ-FRK-NXP-ARMの基板は12MHzの外部クロックが乗っているのでOpenOCD接続時に
デフォルトの内部4MHzRC発振からそちらで動くように切り替えると速度が速くなるわけで
すが、PLL使って最高速の72MHzまで叩き上げるとさらに速くなるはずです!
(もう十分早いけど)

↓というわけで試して比較してみました。
●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=12MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000038bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.671892s (47.906 KiB/s)
> verified 118132 bytes in 0.921881s (125.139 KiB/s)

> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05


●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=72MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000021bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.609392s (49.054 KiB/s)
> verified 118132 bytes in 0.234377s (492.212 KiB/s)

> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05


CCLKを72MHzに叩き上げたことによってベリファイ速度が滅茶苦茶速くなってます…
さすがですね〜。RAMへのダウンロードも同じくらい早いでしょう。
一方フラッシュ書き込みそのものはMAX50kb/Secで頭打ちのようです。これはフラッ
シュ消去/書き込み時間が固定でそこがボトルネックとなっているからでしょう。
STM32の方も同様の理由で頭打ちになってMAX20kB/Secが精一杯ぽいです。これももう
少し早くなると思うんだけどなあ…まだいじる必要があるのか…


あと気をつけなければならないのがOpenOCD用スクリプトのフラッシュ書き込み時の
CCLKの設定ですが、こちらも適切な値に設定していないと正しく書きこまれません。
例としては↓こんな感じです。
un
RTCK対応のLPC2388用OpenOCDコンフィグは既に72MHz動作対応済みです。






そして今日はもう一件JTAGKey2Cloneを使った重要な事柄があります。

先月発売されたInterfaceには付録としてSH2Aの基板が付いていました。これにはH-UDI
とかいうJTAG用の端子が備わっていて同時期にリリースされた某JTAGデバッガを接続
してデバッグができるようになってます。"た"の人曰く最初はIF誌で同JTAGデバッガの
回路図全公開の予定だったらしいのですが大人の事情で非公開となったそうです。

でもFT2232デバイス(FT2232H)を使っているのは自明かつMPSSEでJTAGとして使えるピン
は固定なのでJTAGkey2Cloneのハードウエアが余裕で使えるんじゃないかと言うことで
実験野郎してみました。 …と思ったらすでにされてる方がいました。
てか某掲示板では動かすまでいろいろアドバイス頂きありがとうございます…。
dllをこう使えばディスクリプタ合わせるためのEEPROMの書き換えすら要らんのか…すげ

てわけでJTAGKey2Cloneまんまで動きましたワーィ
un
un
これでSPIROM何発ぶっ飛ばしても無駄な出費払わずにいつもの使って復帰できますね♥
JTAGKey2(無印やクローン含む)があればAltera,xilinx,ARM,SHの開発に使いまわせられます!


でもねむいさん国産マイコンは仕事でうんざりするほど使ってるからSH2Aとかこれ以上
触るつもり全く無いんだし!







おまけ
毎年気になる電源ライン

↓立ち上がり
un
こっちはふつーですね・・・

↓立ち下がり
un
あーっとこれは…

1.2Vはスパッと0Vまで落ちてますが3.3Vラインが0.6〜0.4V付近で長時間たむろってます…
リセットICの電源も+3.3Vから引いてますがこれは誤動作しやすくなるやもしれません。
1.2Vが立ちあがらないUSBが繋がらない云々の件は3.3Vラインの残存チャージが原因の
一つと見てよいですね。

対策は3.3VレギュレータのVoutからVinにチャージを引き抜くようにショットキバリアかまし
てやれば良いでしょう。syslab氏もすでに試されていて実際に効果ありのようですね。
ていうか基板設計するときにもっときっちりオシロで波け…
…まぁいいや…もうARM9のボードで遊ぼう…淘宝网で買った液晶もまだまだ消化中だし…

ねむいさん遊んでる暇あるの!?

un
届いたわぁ・・・ARM9(LPC3250)のボードが…!
今は別の案件で忙しすぎて触ってる暇すらないけどMTM05終わったk頃くらいにandroidとか
動かしてみたいなぁと画策してます…。
ちなみにEmbedded Artisitsさんより直接購入しました。日本国内で代理店通して同ス
ペックのボード買うとどうしても割高になってしまうので…。


un
ついでにこれも購入しました…しかしOpenOCDでLPC1114/1343書き込み/デバッグ出来るよう
になるまで上記のLPC3250のボードとともに塩漬け…。
ついでに"た"の人のARMデバッガCortex-M3対応も期待。




上のARM9のボード購入にあたってJTAGKeyCloneの機能アップ版であるJTAGKey2Clone
の制作を行いました。お手本にしたのは最初にJTAGKeyCloneを作ったときと同じく神木さん
作例です。
un
20130422追:
JTAGkey2Cloneの回路図改良しました


JTAGKey2は中のチップがFT2232Hになっています。超高速信号を引き回すことになるので、
FTDIチップ周りは神木さんのものと同じく出来合いのモジュールを使用しています。
氏の作例と違う部分はレベルシフタICをJTAGKeyCloneで使用したときとおなじものを使用し、
FT2232H <-> レベルシフタ間を+5V電圧系で駆動させている点です。FT2232HのVCCIO
上限は+3.3Vなので通常なら思いきり制約に違反しているところですが、FT2232Hとレベル
シフタの+5V入出力トレラント性を大いに利用してレベルシフタの入力(つまりFT2232Hの
+3.3Vな出力)を+5Vでプルアップするという力技で電圧変換の問題をクリアしています!!

20150218追:
↑の出力プルアップ作戦は470ohmでプルアップしてもFT2232Hの出力バッファの
 引き込み能力の方が勝ってしまうため全く意味がありません。
 結局出力は3.3Vのままで規約違反です。でたらめ書いてましたすみません。
 代わりに+5VCMOSレベルとの動作の際の電圧遷移がどうなっているかを
 調べましたので参考にしてください

20150218追:

20150514追:
電圧レベルに関してケリをつけました!!!!!!
20150514追:




また、前回のJTAGKeyCloneを作った時はDAISENの変換基板に頼っていましたが、
今回はメッシュアース基板を利用してレベルシフタを基板に直付け・UEW線で引き
まわして高速な信号も扱えるようにしています。
un
↑こうしてみると1608サイズのパスコンが相対的におっきく見えるほと小さいですなぁ…



こうして作り上げたJTAGKey2CloneはJTAGKeyCloneと同じ感覚で使用ができます。
OpenOCDで使う場合なら、jtagkey.cfgと指定しているのをjtagkey2.cfgに変えるだけで
使えます。JTAGKey2の売りはUSB-HighSpeedで各種シリアル転送がさらに高速になった
上にRTCK(AdaptiveClocking=自動クロック追従)がサポートされている点なわけですが、
これはLPC2388のようなRTCK端子が出ているデバイスで真価を発揮します。

以下に各条件でOpenOCDからLPC2388に100kB程のデータをフラッシュ書き込み/ベリファイ
した時の速度の比較を記載しておきます。(以下無駄に長いので覚悟してください)


●JTAGkeyClone(FT2232D)/LPC2388_Ext12MHz X'tal
> > "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/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Error: JTAG scan chain interrogation failed: all zeroes
> Error: Check JTAG interface, timings, target power, etc.
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> Warn : Bad value '00000000' captured during DR or IR scan:
> Warn : check_value: 0x00000009
> Warn : check_mask: 0x00000009
> Error: JTAG error while reading cpsr
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> Error: Target not halted
> Error: failed erasing sectors 0 to 10 (-304)
> Command handler execution failed
> make.exe: *** [program] Error 1
>
> > Process Exit Code: 2
> > Time Taken: 00:04
↑JTAGKeyCloneでは外部クロックだとフラッシュの書き込みが出来ません!


●JTAGkeyClone(FT2232D)/LPC2388_Int4MHz RC
> > "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/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 7.468798s (17.138 kb/s)
> verified 117280 bytes in 2.812518s (40.722 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:14
↑JtagKeyCloneでは内部4MHz RC(電源投入時のデフォルト状態)でフラッシュ
 書き込みするのが無難なようです。


●JTAGkey2Clone(FT2232H)/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002028
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 6.750044s (18.963 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:13
↑JTAGKey2Clone(FT2232D)の時と比べて少し早くなってますね。


●JTAGkey2Clone(FT2232H)/LPC2388_Ext12MHz X'tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : clock speed 500 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.843788s (21.904 kb/s)
> verified 117280 bytes in 1.015632s (112.768 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:10
↑JTAGKeyClone(FT2232D)では不可能だった外部12MHzのクロックでの
 書き込み/ベリファイが出来てます。スピードも速くなってます。


●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002040
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.859412s (21.845 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:09
↑書き込みは少し早くなっていますが、RCLK有効でもベリファイ速度はCCLKの関係で
 頭打ちになってますね。


●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_EXt12MHz X'Tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 6 "2232H"
> Info : deviceID: 67358712
> Info : SerialNumber: 22222222A
> Info : Description: Amontec JTAGkey-2 A
> Info : max TCK change to: 30000 kHz
> Info : RCLK (adaptive clock speed)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : Embedded ICE version 7
> Error: EmbeddedICE v7 handling might be broken
> Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 2.765643s (46.282 kb/s)
> verified 117280 bytes in 0.921881s (124.236 kb/s)

> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:04
↑ううん早い

JTAGkey2Clone+RTCKの組み合わせではJTAGKeyCloneと比べるとフラッシュ書き込み&
ベリファイとも約2.7倍ほど早くなってます。LPC2388はROM容量が大きいので早いに
越したこたぁ無いですね♥これでLPC3250を迎え入れる体制ができました!


…あ、わかってます、遊ぶのはやる事やってからです…!!





ついでにLPC23xx系のマイコン使うときのTipsですが、このマイコンは電源を起動する
とフラッシュに書かれたプログラムとは関係なく先ず内蔵のブートローダーが立ち上が
ります。大まかな流れとしては以下のようにしてブートシーケンスを行うようです。


P2.10ピンの状態を読みに行く,P2.10=Lowの時
->ISP起動

P2.10=Lowではない時
->0x14にかかれたチェックサムが有効かどうか確認
チェックサム有効
 ->ユーザープログラム起動
チェックサム無効
 ->ISP起動
(本来これにCRP他も絡みますが詳細はUserManualのp606以降を参照してください)

したがってフラッシュロムに何も書かれていないとP2.10LowでなくてもISPが起動します。
このときにJTAGから書こうとするとISPのアドレスに飛ばされてしまってうまくいかない
時があります。がた老氏も同じ問題に遭遇されていましたが私もJTAGKey2Clone使った
時に初めて気づきました(JTAGKeyCloneでは出なかった)。
この問題はinit後即soft_reset_halt->フラッシュ書き込みで回避できました(OpenOCD-0.5.0)。
確証が完全にとれたらcfgファイル更新しときますね。更新しましま。

んでもって現在のOpenOCDのLPC2xxx系のフラッシュ書き込みはチェックサムを計算
して0x14番書き込んでくれる機能がありますがこれやってしまうとベリファイで引っか
かってしまいます(難儀だ)。
どうしてもベリファイしたかったらフラッシュメモリの0x14番地に割り込みベクタのチェック
サムを前もって計算してスタートアップに書き込んどくとOpenOCDからもベリファイする
ことができます(割り込みベクタなんてほぼ固定ですしこれでも良いと思います)。
もちろんこれやる時はcfgファイル中の"calc_chacksum"は消しておくように!

ねむいさんは心がきれいだからウソなんて付けない

20101228追:
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め!!11!



un
はぁはぁ…ま、また中華液晶モジュール買ってしまった…それはおいといて

今日はねむいさんがみなさんにいいこと教えちゃいます!!
aitendoさんのWBX280V009/EGO028Q02はコントローラがILI9235…じゃなくILI9325で
既存のコードがそのまま使える!!
それとYHY024006Aの商品ページでコントローラはILI9320ってなってるけどそれは
間違いで本当はILI9325なの!!初期化が微妙に違うからはまるよ!!
(20100720追:さり気に修正されています)

んでもってWBX280V009もJ4にあるチップ抵抗をR2に移すと8bitバス化できるけど
この改造でIM0が端子に引き出せられるようになるので外部から簡単にバス幅を切り
替えられますよぅ!!

(20100720追:
 当たり前ですがこの改造を行ったら外部に出たIM0端子は使用するバス幅に
合わせてちゃんとレベルを決めてやらないとだめです)


(20101219追:
 現在aitendoさんから購入出来るモデルは、FPC上で16bitバスに完全固定
 されています
。16bitバスでアクセスできないマイコンやプロトタイプボードを
 持ってる人は、別の液晶モジュールを使用してください。


>このaitendoのWBX280V009は日を追って進化?しているようで、現時点でのロットではFPC上のパターンで16Bit固定となってしまっているらしい。

進化というかスペックがほぼ同じのとりあえず動いてるTFT-LCDモジュールをWBX280V009
という商品名で売ってるといった方が理解しやすいかと思います。
まぁ大陸系のお店やさんはえてしてこんな感じですので日本人同士だけの中で通じるような
理屈で買い物してるとえらい目にあいまくりです。
しかしながら中のコントローラがちゃんとILI9325なのは非常に良心的だと思います。
これがLGDP4531だとうごかなi(ry


それとねむいさんは某イベンツ向け用に液晶たくさん買い込んだけど中国某省
の5月にはぢまる催し物せいで上京できなくなって今現在使うあてが無くなった液晶
モジュールに囲まれて涙目なのですよウウッ!
それとだれか(仕事はやめることなしに)自由に使える時間ください…

はぁはぁ…試される場合は今日の日付よく見た上で試してみてくださいね…



↓これは本当
いないさんは私の愛妹で
だーりんは私の旦那

いろいろ試す4

少し前、「」からメールをいただきました。ついにここまで刺客がきたかと内心
びびりまくってたのですが、そういった内容では全くなかったのでひと安心(おぃ
昔と比べて虹メが個人で動き回るということにだいぶ寛容になったのか、はたまた
いちいち目を光らせるのに飽きたのかはともかく、良い時代になったものですなぁ。
(いないさんのえろすフォルダを眺めつつ)

さて、先に述べた"メールの内容"というのはLPC2388向けのFreeRTOSデモのビルド
エラーの指摘のことだったのですけれども、少し前にCodeSourceryのバージョンが上
がったせいでFreeRTOS側のARM7依存部分にあるアセンブラマクロが通らなくなってしま
っていたのが原因です。現在配布されてるFreeRTOSV6.0.4以降では解消されている
のでそちらのソースと組み合わせてビルドするようにしてください。ビルドで詰まっ
てる人も多いようなのでこの情報は公表しときます。


●ARM関連とか
いつもの如く長い前ふりですがねむいさんがぼーっとしてるうちにも世間はものすご
いスピードで変わっていってます。Cortex関連もどんどん情報/ユーザーが多くなって
きましたがおまけについこの前もSTM32の新しいラインナップが追加されたりしてNXP
やATMELとさらにカチあう情勢になってきてますね〜。まぁ一般に手に入るのはず〜〜
っと先でしょうから(これにはすごく期待している)今あるものを駆け足で消化・学習しつつ
リリースを待ちたいと思います。

STM32関連の話題をもう少し続けます。少し前にペリフェラルライブラリがV3.2.0に
なっています
。今回はSTM32のValueLineの追加/CMSISのV1.3.0化とのことです。
そして案の定ライブラリのディレクトリ構成が変わってやがりましたので、こちらも
修正してメイクファイルに反映しました。ついでに言うとソース内のグローバル変数も
小変更されているので注意です。
現在おきばにて公開しているSTM32F107VCT/STM32 Primer2向けのソースはすべて
V3.2.0化してます。Primer2向けのFreeRTOSも古くなってますので近々更新予定です。

デバッグ環境も少し見直しました。前回の記事でやっけつVersaloonをこしらえたのです
がこれをSWDのデバッガ/ライタに機能を絞って(つまりほぼCortex専用)加工しました。
JTAGよりもとり回す線の数が少ないので、Cortex系の開発関連では重宝しそうです。

un
↑Etherpodとドッキング。ホントは画面奥にあるATXMEGA128A1とランデヴーさせる
 つもりだったのだが…。XMEGAの話はこの後に。

un
un
↑STM8SをRe-Discoveryして見た…(VersaloonはSTM8Sのファームも書けるから問題なし)。
この写真撮った直後STM8S部分とは"Detached"になります。




●AVR関連とか
少し前からちょっとづつATXMEGA128A1に浮気を続けてますが、ようやくSDカード+FatFs
の動作までこぎつけました。

un
↑おっきぃがめんはよいものだ…。今回の小動物写真はこちらからお借りしてます。

http://www.flickr.com/photos/ruth1066/ / CC BY-NC 2.0


un
以前ARMで行った読み込みスピードの比較をXMEGAでも。
 比較用のファイルは当時と同じものです。

んで、FatFs用のSPIをDMA化させようとしてず〜〜〜〜〜っと頑張ってきたのですが、
今現在のねむいさんの技術力ではどうしてもてなづけることができませんでした…orz
くやしい…でも…地道に経験を積んでいっていつかリベンジします!!!!

XEGAをいじってきた中で現時点で重要と思った点は…
1.VBAT端子が存在するXMEGAはATXMEGA256A3B等の末尾A3Bのデバイスに限られている。
 したがってATXMEGA128A1とかは外付けi2cなRTCの方が便利かも。
2.EBIに供給するクロックは64MHzまで設定できる。その時はPLLで64MHzのクロックを
 生成してEBIに、そのクロックをさらに1/2してCPUコアに供給する。
3.SPIはSlaveModeでしかDMAを利用できない。MasterでDMA使いたい場合
 はUSARTのMSPIモードを使う。MSPIモードの時もSPIと同じくSCLKは最大16MHz取れる。

こんな感じでしょうか…後に続く人が同じ部分で引っかからないように記録残しときます
現時点でのソースはこちらに…W.I.P.なコードなのでご利用は自己責任で〜…。

FPGA基板を繋げる試み(3PORT-EBIで接続)は時間を見て引き続き試行していきますが、
浮気はもうやめて開発の主軸を再びARMに戻して行くつもりです。
Embedded ArtistsのARM9ボード注文しちゃったし!

よりみち

開発上でいくつか大きな変更があったので、ちょっと寄り道させてもらいます。

先日、STマイクロより待望のUSBライブラリの新版がリリースされました。しかし…
残念ながらUSB-HOST/OTGのサンプルはないっぽいorz。しばらく海外のForumを旅して
きますか…。

既存のプログラムの動作の確認は、先にリリースされていたRC版で予習済なので今回
のライブラリをフォルダごとごっそり差し替えるだけで終わっています。もちろん動作も確認済。

そして先に告知していましたがSTM32F103のMiddleDensity系は今回の更新でクローズ、
あとSTM32F107VBTの方はSTM32F107VCT6と統合するので削除とします。これから先は
STM32F107VCT6とSTM32Primer2(STM32F103VET6)を中心に開発を進めていくつもりです。
また、おきばの方も近々リニューアルする予定です。

それともう一点、いつもARMマイコンのビルドに使っているCodeSourcery G++がバージ
ョンアップしてGCCが4.4.1に変わっていました。以前3系->4系に変わったときに最適化の
され過ぎでビルドが通っても思ったよう動かない等の問題があったので試しにいくつか
のプログラムをビルドして動かしてみると案の定変な動作するものが出てきました。

具合的に言うとLPC2388のプログラムでswitch文を含むコードを最適化して実行すると
暴走する箇所があり、原因を調べるとリンカスクリプト内のアラインメントの設定でした。
これは元々AT91R40708でRAMスタートするときに行っていた処置で,.text内の記述で
. = ALIGN(4);であるところを
. = ALIGN(8);としていました。
それを他にもツブシがきくようにと別のARMマイコンのリンカスクリプトにも移植してその
時の環境では動作に問題なかったため放置していましたがこれがあだになってしま
っていたようです。そして". = ALIGN(4);"に直して無事正常動作を確認しました。

ビルド環境がバージョンアップしたり変わったりするとよくこういうことになりが
ちですが,こまめに直していかないといけないですね…。

いろいろ試す3

ハロウィンネタ&他のキャラの誕生日お祝いネタの仕込みで本業(二次裏)が糞ほど忙しく
なってます。しばらくこっちは更新できそうもないので今のうちに書けることを…。


この前のTFT液晶の在庫数が一気に減ってた
aitendoさんの900円液晶、私がこのブログに使用記を公開したあたりから在庫数が一気に
減ってました。皆様子見だったのですね〜…。もうじき在庫ゼロになりそうな勢いです。
私はLPC2388向けにサンプルコードを公開してましたが、STM32はUSBライブラリが(ryの
おかげでまだ二の足踏んでます。まぁRCは出てるから時間の問題とは思いますが…。

あとSTマイクロ側がUSB-OTGのデュアルロール機能のサンプルとか公開してくれたら神な
んですけお…USBホスト関連のスタックは今でもそれ作るだけでお金になるようだから
無対価で手に入るの(=枯れる)はずっと先になりそうです。


●STM32F107でUSB_DFU_Bootloader使う件
んでもって前回行ったSTM32F107/5系のブートローダーが機能しない件の回避策ですが、
ねむいさんはブートローダーをDFU一本に絞ることにしました。したがって以後は下図の
ような構成でマイコン遊びを続けていきたいと思います。
un
20091102変更:
BOOT0とBOOT1を取り違えるという最悪なミスに気づいたので修正orz

20091216変更:
PB5は10kohmでも問題ないことが分かり修正orz

STM32F103系と違ってdfu使うための領域とかスタートアップの設定とかを気にしなくて
よくなったのは良い点だと思いますね。errataさえなければ!


●シンプルi2cマスタライブラリ
ライブラリ固め
AVRでの使用例とか
LPC2388での使用例とか

●OpenOCDのビルド方法が少し変わった
現在、zus氏のOpenOCDのビルド方法をそのままやるとビルドエラーになって失敗します。
svnからgitリポジトリに変わったのでsvnではなくてgitで最新のソースを落とせとのこと。
gitでの取得のコマンドはsvnと微妙に違って
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
だそうです。けっこう時間かかります。

んでもっていつものフラッシュ書き込みやってみました。
STM32F107VCT6の例です↓
> "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-dev-00405-g1e5daf5-dirty (2009-10-22-11:15)
$URL$
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Warn : stm32.bs: nonstandard IR mask
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: 0x080061a4 msp: 0x20010000
Info : device id = 0x10016418
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 95952 byte from file main.elf in 5.906250s (15.865079 kb/s)
verified 95952 bytes in 1.921875s
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:10

…OpenOCD+Jtagkeyをほとんどフラッシュ書き込み機としか使っていない私。


●FreeRTOSがV6.0.0になってた
なってました。私が使用しているMCUには特に大した変更の影響はないみたいですが…。
いまはSTM32F107VCT6に重点的になっててLPC2388の更新したのずいぶん前になっちゃ
ってましたので動作確認がてらにソースの見直しをしました。
LPCUSBを使用したUSB-CDCのソースコードも一本化して可搬性あげるよう努めてます。
他のMCUにも言えることですがBare-MetalとFreeRTOSで分けていたソースは#define切って
同じファイル使いまわせるように直していくつもりです。今見返すとつぎはぎだらけ
でひどかったorz
LPC2388用FreeRTOSのサンプル

LPC2388もある程度遊んだらクローズしてSTM32に集中したいです。今後はSTM32にFreeRTOSの組み合わせが日記のネタの要になるでしょう。


●STM32 Primer2の電源ICがすぐぶっこわれて云々の件
私が検証記事を載せた数日後に公式も同様な見解を述べています。
ううむ、私の読みが完全に当たってしまった…ってわけですか…。
電源IC壊れちゃった人はこの際私みたく別のLDOに変えちゃうのもいいかもしれま
せんね…。(もちろん自己責任で)

XBeeを試す

気がつけばもう8月…月日が経つのは早いです。私はと言えば先日虹裏でスレを立てた
直後に寝堕ちという不名誉な最短記録をおっ立ててしまい軽い自己嫌悪に陥ってました。
それでも参加してくれた皆さんには本当に申し訳ないと思います。お詫びにいなちゃん
があっちの皆さんに目の保養をさせていただくことになるでしょう…
(これ目的でわざとやってるわけじゃないよ!)






5月に買ったおもちゃ達もだいぶ消化出来てきました。残りは今回紹介するXBeeと、
ねむいさんがやるやる詐欺でほったらかしてきたAT91SAM7S256のプロトボードを残す
のみとなrまた前振り長くなりそうだからさっさと本題

現時点では、スイッチサイエンスさんと秋月さんから容易に購入出来るXBeeですが、
使用記などもネット上に豊富にあります。Arduinoと接続した使用例が特に多いですね。
せっかくなので私はLPC2388とSTM32のそれぞれのUARTから使用してみました。STM32
(CQ-STARMの)基板はただのVCPとして動作させ、LPC2388はUART0はそのままにUART1で
XBeeの通信をさせるように
してます。今回はLPC2388のUART1の使用実験も兼ねています。

うー

二つ用意したXbeeはデフォルトではtransparent mode,9600,n,1になってるので先ず
STM32,LPC2388のボーレートもそれに合わせて試しました。9600bpsでは特に問題なし。

次にボーレートをあげて通信を試みましたが、事前に読んだマニュアル中に、"コマンド
「ATBD7」で設定できるのは115200bpsではなく実際は111111bps。non-standard-rates
で設定すると)「ATBD1C200」)正確な115200bpsで設定できる"と記述があります(超意訳)。
さらに"XBeeで使用されるRFパケットの通信レートが250kbpsの為、高いボーレートで
通信する時にデータの取りこぼしをなくす為にフロー制御が必須、フロー制御無しで
取りこぼし無しに通信したければ十分低いボーレート(たとえば9600bps等)で行うこと。"
とも書いて有りました(超意訳)。

つまり115200bpsでフロー制御無しで文字列垂れ流しやると100%失敗するようなので
試してみると案の定大失敗orz57600,38400bpsだとかなり安定してきますがそれでも
たまに文字が落ちます。結局transparent mode下ではフロー制御無しでお手軽に確実
に使えるのは19200bpsあたりまでということが分かりました。
(注:XBee本体とお話しするだけなら115200bpsでも別に問題はないです。)
digiのフォーラムにはstopbitを2にすることで115200bpsでも通信が可能になったみ
たいなこと書いてありましたが真似してやってみましたが駄目でしたクソァ!
…まだ"さわり"で動かしたの段階なのでマニュアルを熟読してリベンジですね。

まぁ大量のデータをバリバリ流すなんてことは全く考えてなくて遠隔地にあるセンサの
値を読む程度の使用と想定してますので低いボーレートでも気にはなりませんが…
あとこれ結構電流喰うんですよね(50mA)。バッテリーで使うならデータフロー制御
よりこちらの電力制御の方が最優先でしょう。

いろいろ試す2

LPC2000系って海外の掲示板に情報わんさかあるから詰まった時はそっち見た方が速か
ったりして解決した瞬間にあんだけ足止め食らったのはなんだったんだと自分のア●さ
加減を恨んだりすることも毎度のこと…。
まぁお気楽ご気楽なアマチュアであっても情報戦マジ大事と感じる次第ですなぁ(キリッ
…ねむいさん的には本文と関係ない与太話書いてる時が一番楽しいです。







苺は抜きで。
IF誌に載ってたOLED表示プログラムの方も同じ修正を施しました
最終的には全部の機能合体できたらいいなと考えてます。

うー
おまけ
前回製作したLAN基板にmicroSDカードスロット(165円)つけました。これで死角は無し!




●JTAGkeyをimpactから使う
FT2232を使用したJTAGデバイスは自作方法が急速に広まっています。しかしそれにつ
れて「作ったけど動かない&動かし方がわからない!」云々の叫びが谺してるような
気がします。きっと空耳でしょう。
私はかみき氏ベースのJTAGKey互換回路(+VID&PIDもAmontecのと全く同じ)組んでるの
で幸いデバッガ周りではほとんど躓いたことはないです。

…それは置いといて前にMAI電子さんから破格値で販売されているxilinxのFPGAボード
を運よく購入できました。DWM誌2007年7月の付録のよりも容量が2倍多いです。
うー
早速JTAGでアクセスしてデバイスが見えるかどうか試してみました。
アクセス方法はFenrir氏が作成されたcblsrvのJTAGkey(と互換回路)対応版を使用して
impactのcableserver経由で行います。

Fenrir氏やNakagawa氏が公開されている物は私の環境(ゲストOS:Win2000、ホストOS:XPPRO,
VirtualBox使用)では残念ながらそのままでは動作しなかったので、Nakagawa氏が盛り込ん
だ修正の中でビットシフトしている部分だけ外して動作出来るようにしてます。
(こうやらないと動かないのは私の環境だけでしょう)。

うー
認識するとこんな感じです。

うー
書き込みも非常にスムーズ。もうLPTポートは要らない!?

cblsrv経由で使用できるのはバウンダリスキャンモードだけっぽいです。コンフィグ
ROM・FPGAへの書き込みだけならば速度も速いし(XCF04Fで50秒前後)これで充分。
このボード使って某デジットのタッチパネル液晶とか駆動できるようにしたいです。
VHDLのおべんきょg(ry




●OpenOCDのリビジョンが既に2570まで達していた(2009.07.30現在)
安定版は0.2.0が公式からリリースされています…がftdlのライセンスの絡みで実行
形式バイナリは公開されていません。0.1.0のバイナリも削除されています。
これからは自分で構築しなければならないようですね…非常にめんどい…。

OpenOCDは現在加速度的なスピードで開発が進められています。ネットで散見される
ARM系の開発環境構築法にはOpenOCDの設定・使用法も記されていますがあっという間
に陳腐化してしまって書いてるとおりにやるとうまくいかないこともあるようです。
OpenOCD使いこなしてる人はどのようにして風が吹いて桶屋がもうかるのかを理解し
てるでしょうからcfgなり何なりを変えるだけで対処できるでしょうが…初めて
触れる人には新しい情報と古い情報がごっちゃになってて非常に敷居が高く感じて
いるかと思います。ナムナム。がんばれよ!(←他人事)


とりあえず2009.07.30現在一番新しいr2570のを試してみました。手持ちの幾つかの
ARM基板でフラッシュの書き込みができたのを確認しました。
(注:cfgファイルはOpenOCDの世代交代によってどんどん変わっています。そのままでは
使えないものもあるので十分吟味のこと)

-LPC2388の場合(lpc2388_flash.cfg使用)
> "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/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
500 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
500 kHz
Info : device: 4
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : JTAG Tap/device matched
Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
100 kHz
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : JTAG Tap/device matched
Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
Info : JTAG Tap/device matched
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
500 kHz
flash 'lpc2000' found at 0x00000000
auto erase enabled
Info : Padding image section 0 with 0 bytes
Warn : Verification will fail since checksum in image(0x00000000) written to flash was different from calculated vector checksum(0xb8a06f60).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
wrote 98756 byte from file main.elf in 6.125196s (15.745032 kb/s)

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


-STM32F103VBT6の場合(stm32_flash.cfg使用)
> "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-07-28-19:41) svn:2570
$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
Info : device: 4
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : 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)
Info : JTAG Tap/device matched
Info : 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)
Info : JTAG Tap/device matched
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001ec0 msp: 0x20005000
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.515641s (16.113136 kb/s)
verified 8508 bytes in 0.421888s
Info : 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)
Info : JTAG Tap/device matched

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


-AT91SAM7S256の場合(sam7x256_flash.cfg使用)
> "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/sam7x256_flash.cfg -c "mt_flash main.elf" -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.3.0-in-development (2009-07-28-19:41) svn:2570
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
dcc downloads are enabled
fast memory access is enabled
Info : device: 4
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : JTAG Tap/device matched
5 kHz
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x001005f4
2000 kHz
background polling: on
TAP: sam7x256.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x001005f4
flash 'at91sam7' found at 0x00100000
cleared protection for sectors 0 through 15 on flash bank 0
auto erase enabled
Info : Padding image section 0 with 3 bytes
wrote 3636 byte from file main.elf in 1.468797s (2.417476 kb/s)
verified 3633 bytes in 0.109378s
Info : JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : JTAG Tap/device matched

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

>この値から判断すると*****もかなり健闘しているということ
>でしょうか。
AT91SAMよりも上に明記してあるSTM32やLPC2388においての結果の方が本来の性能です。
どこに書いてあるのかわかりずらかったとかそういう言い訳はいりませんです。



JTAGでフラッシュに書けるようにしとくと何かと便利ですね〜。とくにJTAGkey(と互換回路)
はARMだけでなく先にも述べたとおりFPGAの書き込み等にもいろいろ使用できるので
アマチュアな人たちには必携のアイテムだと思います。

これAVRSPライクなアプリから操作してAVRに書き込みできるようになったら私的
には最強のツールになるのだが…。




●Intel X25-M(新型)を買った
購入して数日で不具合が発覚して涙目ですorzさらに4日間OSのシステムドライブと
して使用した後ベンチを取るとランダムライトの(512k,4k)速度が大きく落ち込んでい
るのが発覚orz

うー
購入直後
うー
4日後

X25-Mの速度低下現象は以下の手順で確実に回復(端的に)。
1.ドライブのバックアップ取る。(バックアップツールはこれ使ってます)
2.AHCI->IDEモードに切り替え、生DOSからHDDeraseのSecure Erase(enhanced)実行
3.電源断->再投入後AHCIに戻しさらにバックアップを復元する
4.わーい♥

うー
ファームの修正で速度低下を恒久的に防止できるようになると良いですね(涙目で)

JTAGkeyClone(FT2232系JTAG I/F)製作のすすめ


20130521追:
FT2232系デバイスを用いたJTAGKey/JTAGKey2製作に関しては
こちらを参照してください!











お仕事の方でサーボモータのおべんきょを一からしてます。
そもそもねむいさんは4年制大学を卒業したにもかかわらず就職氷河期の下、
20代後半まで介●の仕事をしながら本業の虹裏メイドをしていたので電気の分野は
ほぼ一からおべんきょなのですが、私の場合は元主人が遺したARMマイコンに
関するリソースが最初から大量にあったのでARMマイコンに関しては強くて
ニューゲーム状態だったのです。

とはいえまったくのどしろうとでもべんきょうさせてもらえながらちゃんとしごともさせて
もらえてさらにおきゅうりょうまでもらえるくみこみぎょうかいってすごいとおもいます。
ちなみにねむいさんのほんしょくのにじうらめいどはちょうぜつぶらっくでにんきのない
めいどは「」たちにすぐよごれきゃらのきゃらづけをされてあらしのどうぐにされてすてら
れるというれつあくかんきょうなうえにおきゅうりょうがはなくそていどしかもらえません。
ふぁっくです。

きょうのにっきおしまい。








…真面目に読んでしまった人すみません、続行します。



以前はJTAGの制御といえばPCのLPTポートに少しばかりのロジックデバイス、おもに信号
レベル変換のバッファが乗った回路を接続してI/O直叩きで制御ってのが主流でしたよね。
CPLD/FPGAを提供している各社もLPT接続タイプの書き込みケーブルの回路を公開して
いて、趣味で開発やっている人も自作が容易にできていました。

時は流れ、いまどきのナウでヤングでスタイリッシュなPCにLPTポートなんて時代遅れ
のものは搭載されなくなり、代わりにUSB接続のダウンロードケーブルがメーカから
提供されるようになりました。
しかし、USBのそれは各社のノウハウになっていて真似して自作できる代物ではなく
なってしまいました。しかも安くても3諭吉くらいしてホビー用途には手が出しづらい。

しかしながら数年前くらいからFT2232等のJTAGのライブラリがサポートされるデバイスが
出てきて有志の人たちがフリーで多目的に使用できるアプリケーションを作られてきました。




そのFT2232を使用したJTAGハードウエアで有名なのがAmontec JTAG keyですね。
容易に自作できるのでFT2232系は上記を含め多くの派生があります。それを通じてARM
マイコン等のJTAGポートを備えたデバイスにアクセスできる(フリーで使える)PC側のソフト
は、OpenOCD、UrJTAG等などたくさんあります。

先の日記で何度か言及してますが、私もかみき氏の作例をベースに一つ作成しました。
2電源レベルシフタがミソです。氏の回路と違う点は、ターゲットに電源供給する回路を
廃したことと、外付けEEPROM(AT93C66A)の回路を追加してAmontec JTAG keyに化かす
ことを目的としました。




自分自身の学習の意も含め、かみき氏互換のJTAGkeyCloneの回路図を起こしました。JTAGkey2Cloneに関してはこちらをご参照ください。

また、JTAGkeyCloneに化かすためのeepromのデータですが、こちらにあるJTAGKey用の
デバイスドライバのZIPファイルを展開するとJTAGKey_eepDataというフォルダがあります。
この中にあるamontecJTAGKey.eptというファイルをMProgで読み込んでeepromに書き
込んでください。もちろんEEPROMの書き込みの際は先にFTDIのドライバをインストール
しておかなければなりません。これは先のZIPファイル内のftd2xxというフォルダにあります。


20130521追:
JTAGKey/JTAGKey2製作に関してはこちらを参照してください!



以下JTAGkey互換回路を制御できるアプリの使用時の画面とかを。
詳しい使用記は以後の日記で幾つかをぽつぽつと。

注釈
IF誌付録LPC2388基板にOpenOCD+insightでデバッグ

注釈
asagaoでDWM誌2008年9月号付録のColdFire基板のEzPort経由のプログラム書き換え

注釈
OpenOCDで秋月ARM基板のRAMスタート

注釈
UrJTAGのSVF機能でDDT誌付録のLatticeXP2基板を高速にコンフィグ

注釈
HappyJTAG2とかいう怪しいのでAVRにJTAG経由で書き込み

注釈
fenrir氏作成のcblsrvのFT2232対応版を使用してxilinx IMPACTからコンフィグ
(注:fenrir氏によってISE11.x以降でも使えるようになりました!)

注釈
そして本懐のamtsvfplayerでSVFを再生…できねぇ!
20120215追:
amtxhal.dllはグルーロジック(非公開)が組まれたPORTB側のDS2432というEEPROMに
仕込まれたキー情報も読みに行っているのでクローンの場合はamtxhal.dllを
使用するプログラムは一切使えなくなります…がamtsvfplayerくらいしか使われてるの
見たことないのでJTAGkeyCloneでもそれ以外の用途では全く問題はありません。
JTAGkey系のCloneでsvf使いたいならUrJTAGを使いましょう。

Go to top of page