2011-11

2011-10　LPC1114

11月なのに夏並み・・・

この気候何？罰ゲームの一種？

↑

今ごろになってＭＡＲＹ基板アタック！


参考サイト： MARY-MB (LPC1114) 用プログラムの雛形（Makefile など）


workspace/以下のディレクトリの、

CMSISv1p30_LPC11xx    .... いわゆる共通らいぶらりぃ。CMSYSってヤツ。Cortex-M 用 verは1.30
PROG01_COLOR_LED      .... Ｌチカのサンプルソース。

これをちょっと配置換えして、

D:/MyProject/HW/CMSISv1p30_LPC11xx
D:/MyProject/PROG01_COLOR_LED/

みたいにする。


そして、Makefileを置く。

ダウンロード：Makefileなどなど



  • コツ： '-c3' オプションを lpcsp.ini に書いておくこと。これにより、DTR=RESRTやRTS=BOOTの制御をうまくやってくれる。書き込み後に即起動してくれる。言うことなし。



↑

だけど・・・ビルドしても動かない。何故だー？

落とし穴その１：

  • MARY基板は内蔵ＲＣ発振なので、CMSISv1p30_LPC11xx/ 内のheaderを一部書き換える必要がある。
    • これはCODE REDから落としてきたCMSISを使う場合であって、cq出版のサイトのMARYサンプルに 含まれているCMSISv1p30_LPC11xx/はすでに改造されているのであった。

落とし穴その２：

  • すごく詰まらない理由だった。
× -mcpu=cortex-m3 
○ -mcpu=cortex-m0
  • LPC1343のMakefileを使いまわしていたのでm3のままにしていた。
  • 一見、コンパイルもリンクも、出来たコードにも何の問題もないように見えて、
  • 全然動かないのであった ORZ!
  • Cortex-M0はM3の命令がいくつか抜けているらしい。ほんとか？（たぶん割り算とか・・・、いや割り算しないんだけど）ヒマな時に何故動かないか差分攻撃してみようっと。
↑

やってみた。

  • Cortex-m0 
    0000035c <NVIC_ClearPendingIRQ>:
    35c:	231f      	movs	r3, #31
    35e:	4018      	ands	r0, r3
    360:	2301      	movs	r3, #1
    362:	4083      	lsls	r3, r0
    364:	1c18      	adds	r0, r3, #0
    366:	4a02      	ldr	r2, [pc, #8]	; (370 <NVIC_ClearPendingIRQ+0x14>)
    368:	23c0      	movs	r3, #192	; 0xc0
    36a:	005b      	lsls	r3, r3, #1
    36c:	50d0      	str	r0, [r2, r3]
    36e:	4770      	bx	lr
    370:	e000e100 	.word	0xe000e100
  • Cortex-m3 
    00000358 <NVIC_ClearPendingIRQ>:
    358:	2301      	movs	r3, #1
    35a:	f000 001f 	and.w	r0, r0, #31
    35e:	fa13 f000 	lsls.w	r0, r3, r0
    362:	4b02      	ldr	r3, [pc, #8]	; (36c <NVIC_ClearPendingIRQ+0x14>)
    364:	f8c3 0180 	str.w	r0, [r3, #384]	; 0x180
    368:	4770      	bx	lr
    36a:	bf00      	nop
    36c:	e000e100 	.word	0xe000e100
  • cortex-m0系の命令コードはbranch系のみ2ワード(16bit x 2)で、それ以外はすべて1ワード(16bit) となっている。
  • cortex-m3系には、2ワード(16bit x 2)に拡張された命令がいろいろ存在している。 
        396:	e8bd 4070 	ldmia.w	sp!, {r4, r5, r6, lr}
  • こんなやつもそうだ。
  • また、cortex-m0ではレジスタは前半８つ(r0-r7)までしか使えない（レジスタフィールドが3bitしかない）が、 cortex-m3では、r8,r9なども使用できるようだ。

つまり、簡単にまとめると、

  • Cortex-M0は、ARM7TDMI(LPC2388等古いARM)などに実装されているThumbステートそのもの。ARMステート無しのコア。
  • Cortex-M3は、いわゆるThumb-2と呼ばれている拡張セット。

ということらしい。どうりで、まったく動かないはずだ。

  • m3のほうが、（誤差程度だが）短くなるようだ（１〜２％くらい？）




  • なんとなく、この基板HIDaspx互換とpic18spx互換基板になったような気がする。気がするだけだけど。
  • シリアルは実ボーレートを設定しないとちゃんと動作しない。（仮想COMで適当に9600とかやってたらマイコン側も9600にしないと動かない。これ当然なんだけど最後まで仮想COMなマイコンではボーレート関係ないからなぁ）
  • とりあえず230400bpsはＯＫ。460800bpsは字化けして使えない。少し増やして500000bpsだと逆にＯＫになった。
  • LPCXpressoの4.1を拾ってきたけれど、LPC2000の中身は29xxしかなかった。2388は放置かい。まあ、1769とI/O互換に近いという話はあるが。






↑

時期はずれのアイスクリームサンド。

Android 4.0 "Ice Cream Sandwich" ソースコード公開

■[android][ICS] ICSのミラー終わったのでビルドしてみた

  • ビルドするのに16GBのRAMが要るらしいけれど・・・。
  • どのマシンも4GBしか積んでないからなぁ・・・（2G SIMM x 2）
  • 昔はWindows上のVMWareでubuntu走らせて十分ビルドできていたのに。
  • ていうか、Linuxカーネルの部分だけなら、普通にカーネルビルド程度で済むはずなんだけど、何が重いのかな？
  • やっぱりJava開発環境のところ？

とりあえずRAM買ってくるか。(4GB x 2くらい。貧乏なので)


でも、だめだった。歯が立たない。なんかいろいろビルドエラーする。(ARM,x86ともにだめな感じ)

  • 奴ら(Google)はどのubuntuを使っているのだろう？
  • 次は、クリーンインストールしたubuntuでも用意するか。


えっ？やっぱビルド出来ないのが正しい（？）

  • 結局32bitのlibstdc++が要るってことが分かった。こうする 
    #!/bin/sh
sudo apt-get install git-core gnupg flex bison gperf build-essential \
 zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \
 x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \
 libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \
 libxml2-utils
  • ビルドは出来たんだけど、output/の system/とか system.imgしかなくって、ISOファイルが出来ていない。Orz


  • アイスクリームのバイナリー(ISO)は落ちてないけど、Honeycomb(3.2)のISOなら、ここにあるみたい。


  • そしてICS 4.0のISOもあるらしい。



↑

OpenOCD:USB-Blasterサポートが少し良くなっているような気がする。

  • 気のせいか？
  • ヒマなときに追試してみるか。
"Remote 'g' packet reply is too long"問題ってもはやFAQレベルだと思ったが…
知らん人多いのですか…
  • ええ、知りませんでしたとも。
  • ねむいさんのHPはとても参考になる。
  • OpenOCDはいまだにROMライターソフトだと思っている人＞ ./


↑

OpenOCD:高速化のヒントが大体分かった（つもり）

  • openocdは各ドライバーに対して、jtag_command という構造体を渡して、JTAGコマンドを逐次実行してもらう。 
    int bitbang_execute_queue(void)
{
	struct jtag_command *cmd = jtag_command_queue; /* currently processed command */
  • で、*cmd は実は１個のコマンドだけが渡ってくるのではなくて、単方向リストで繋げられた一連のJTAG コマンドの束を送りつけられる。
  • 各ドライバーのexecute_queue()は、 
    while(cmd) {
  switch(cmd->type) {
    case ... : 
      ... ; 
  }
  cmd=cmd->next;
}
  • のようにリストを全部実行して結果を返す。
  • そこで、JTAG_SCAN:のようなコマンドはUSBの先のデバイスにコマンドを送りつけて結果をもらってこないと いけない。
  • それを逐次的にやると、JTAG_SCAN１個に対してどうしてもUSBの１フレーム以上の時間を費やしてしまう。
  • なので、高速化したいのであれば、このwhileループの処理を遅延評価(Lazy Evaluation)する(USBから返答が帰ってくるまでほおっておいて、どんどん処理を進める)か、あるいは
  • ２パス処理にして、１パス目でコマンドを全部投げつつ、２パス目で戻ってきたUSBパケットを全部結果に書き戻すとかすれば良いことに気づく。
  • と、まるで分かったように書くのは簡単なんだけど、実際にコードを書くのは大変だ。
  • ---> 一応思いつく限りの遅延評価や遅延バッファを実装してみたんだけど、ちっとも速くならなかった。
  • ---- なんか、Win32 APIの ReadFileとWriteFileがRS232Cに対しておもいっきり腐ってるような気がする。
  • ---- ReadFileはたいていブロック処理されてしまうので、その前にClearCommStateするんだけど、なんかそこでUSBパケットが飛んでいるような気が・・・（気のせい？）
  • ---- ReadFileを非同期で処理すると、WriteFileが出来ない（ファイルハンドルが共通なのでいろいろ待たされる不思議）という本末転倒さはなんとかしてほしいけど、いまさらWin32APIが変わるとは思えない。
  • ドライバーのソースは読みづらいし、処理を追いかけにくいと来ている。おまけにlibftdiだのD2XXだの、未知のデバイスドライバーの仕様も良く分かっていない。




｜次の月＞