震災から1年が経った。もう1年かという思いが強い。

なんだかんだ言ってもうちは被害は少なく済んだし、仕事は先延ばしになって資金的にも大変だったりもしたものの、それでも家に困ることもなければ家族に問題もなく。比較するものではないけれど運良く過ごしているということを実感している。

現地の復興は未だに進みが遅いけれど、そこに私が打てる手はあまりないし、起こってしまった事故を糾弾しても起こったことが無かったことになるわけではない。辛い災害と事故であることは間違いないし、当事者が嘆き悲しむのは当然だけれど、悲観しつづけて将来が明るくなった試しはない。だから人はなるべくポジティブに生きた方がいい。特に災害の影響が少なかった人はポジティブに生きなければならないといってもいい。だから私はポジティブに生きるべく、まずはどうやって放射性物質と共存出来るのかということに注目して色々とトライしていこうと手を動かし続ける。不安がないわけではないが、そもそも不安無く動物が生きていられること自体が僥倖のようなもの。いかに不安を制御していくかが生き抜くコツなのだ。

しかし、戦争やら大空襲の焼け野原から復活した日本人の根性は今もまだある程度は生き残っているとは思うけれど、あれは行動経済成長というタイミングだとか、日本的社会主義が強く生きていたタイミングだとか、そういうバックグラウンドあってのものだったのではないかとも思っていて。将来はどうなるかわからない。まったくもって興味深い感じになってきた。

自分の頭で考えて、自分の勘で判断して、自分を賭けて選択すればいい。それだけ。

mbedを買ってその便利さに感動したものの、それが非常にmbedという枠に閉じ込められていているという気がしてしまい、結局LPCXpressoを買い足してきた。すでに持っているLPC1769版とLPC1343版もあるのだが、ちょっと目的もあるのでCortex-M0なLPC1114版。半ば意地でOSX環境で開発したいので、買ってきておもむろに真ん中で切り離した。

そしてノリノリでUSBで繋ぐべく、MiniUSBのコネクタを付け、プルアップ抵抗を付け、USBの配線をしてLDOを付けて。ここまでやってから大きなミスに気づいた。シルクスクリーンにUSB_DP, USB_DMという記載があったのでろくに調べずUSBでMass Storageでの書き込みが出来るだろう、と思っていたら、実はそれは出来なかったのだ。だからMARYもわざわざUSB-Serial変換チップが載っていたわけで。よくよくLPCXpressoのデータシートを見てみたら、

なるほど。もちろんLPC1114のデータシートにもUSBなんて文字はなく、思い切りウッカリしていた形になった。

ということでこれじゃUSBが使えないのだが、それでは色々進まないので、ホットエアを持ち出してチップの張り替えをしてしまった。ちょうど石はちょっと前にdigikeyから仕入れておいたLPC11U24で、ピンアサインもほぼ一緒(細かいところは違うが肝心なピンは同じ)なので、そのまま剥がして付け替えただけ。

さて、付け替えたはいいが、今度はどうやって中身を書くか。まずtoolchainだが、MacPortsだけでなんとかしようと試行錯誤したのだがどうしても駄目(これはさらに追って調査するつもりだが、newlibの新しい版の都合でarm-none-eabi-gccがちゃんとビルド出来ない)で、とりあえずはYAGARTO toolchainを使うことにした。頂いてきて展開してパスを通す。

次、ソースコードを書く方。CMSISなんていう胡散臭いものに手を出すのは結局mbedからエクスポートしてくるのと殆ど同じでブラックボックスが残って気持ち悪いし、とはいえ世の中には何故か「まずはどこそこからライブラリをコピーしてきて展開して」だとか「LPCXpressoを使って」ばかりでこれも落ち着かない。32kしかフラッシュがないM0クラスごとき、本当ならアセンブラで書いたって良いはず。とおもって調べていたら、同じような意図でChaNさんが32bitへの誘いというコンテンツで余計なライブラリに触れないで済む生っぽいコードを公開してくれているのを見付けた。これ幸いとこれを頂いてきてビルド、ビルドは通るけれどうまくいかない。なんでだ。

追って調べていくと、メモリアドレス先頭の0×0000 001c(割り込みベクタの頭から8つめ)にチェックサムがないとユーザプログラムがvalidとされないらしい。gccさんにここら辺やってもらう方法もあるのかもしれないが、これも調べていたらmicrobuilderさんのlpc1343codebaseをgoogle codeからチェックアウトしてきて、tools/lpcrc/以下でMakeしてlpcrcツールを入手。ちなみにこのときに

gcc -Wall -O4 -std=c99 -o lpcrc lpcrc.c
ld: lto: could not merge in /var/folders/6f/j0df6rz90jxbpfgg053_k0l80000gn/T//cc6uDMQK.o because Invalid ALLOCA record for architecture x86_64
collect2: ld returned 1 exit status
make: *** [lpcrc] Error 1

みたいなエラーがでたら、Makefileをいじって-O4を-O3にすれば回避できる。

ここまでやって、生成されたbinファイルをlpcrcに食わせることでその辺まで正しいバイナリを作れるようになったんじゃないかと思うのだけど、、、まだ動かないので結局まだ調査中。無念。調べて何かわかったら随時反映の予定で。

2012/2/20 うごいたー！

ポイントはいくつか。

• ファームを動かすときはPORT0_1/FTOGGLEを解放するだけでなく、VBUSも解放してあげないと駄目
• LPC11xxとLPC11UxxはGPIOレジスタがてんで違う。ばらっばら。
• ChaNさんの公開してくださっているstartup.c最強。ちょっとだけいじったので後ほどコピーライト無し権利主張無しライセンス無しで公開予定。ありがたやありがたや・・・

複合要因すぎる。

次の調査は、CRP(Code Read Protection)を設定したときの隙間埋め。CRPは0x2fcにあるのだが、LPC11Uxxの割り込みベクタは0x00c0まで。普通に書いたらその間は00で埋めるしかなくて、572bytesほど無駄がでてしまう。0x2fcに入るのがマジックワード(32bit値4つ)でなければ良いとはいえ気持ち悪いし、そもそもCRPを使いたいときにそれでは使えない。どうもLPCXpressoなんかは頭から0x2fcまでの間に初期化コードを突っ込んだりして使ってるみたいなのだけど、そちらも調べなければわからない。これは追って別のポストに。ひとまずこの話完結。何かの参考になれば幸い。

先の投稿で書いたが、mbedは大変すばらしいものの、それが無くなったことを考えると些か不安でもある。そのため、エクスポートしたプロジェクトをローカルでビルドする方法をきちんと確立しておきたかった。

で、ひとまずさんざん試行錯誤した結果、さくっとビルドする方法がわかったのでメモしておく。ちなみに、OSX Lion(10.7.3)にmacports環境なので、WindowsやLinuxユーザの方には適用できないかもしれない。

用意

• codesourcery gcc用としてエクスポートしたソース
• YAGARTO(http://www.yagarto.de/)から拾ってきたYAGARTO GNU ARM toolchainの最新版

展開

• 適当なところ(うちは/opt/local/)にyagarto(最新版).appをおいて実行
  • 中身が実行したディレクトリ/yagarto(バージョン)/に展開される
  • 趣味で/opt/local/yagarto -> /opt/local/yagarto(バージョン) にsymlinkしておく
• ~/.zshrcなり~/.bashrcなり~/.tcshrcなりにpathを追加
• エクスポートしたソースを展開してmake
• できあがり！

・・・あれー。これで終わるはずじゃなかったのだが。macportsのarm-none-eabi-gccでビルドすべくやってみたら、newlibの改変でエラーぼこぼこ出て、調べたら–disable-newlib-supplied-syscallsを付けろとかいうからPortfileに付けてみたらビルド出来ず、–enable-languages=c,c++付けたらarm-none-eabi-gccはビルド出来たけどcrt0.oが無くて結局ダウンロードした奴がビルド出来なくて、ついにはcodeRedのred suite 4 fullの試用版まで落としてきて試したにも関わらず駄目だったのに。

ひとまず大変シンプルなコードでしかテストしてないのでどこまでちゃんと使えるかは不明だがざくっとしたコードは問題なく動いていて、ライブラリ等も一式使えてる模様。ただ、mbed interfaceの支援がないからか、最適化オプションの都合か、バイナリは相当デカくなってしまった。mbedのサイトでビルドすると4,356bytes、エクスポートしてローカルでビルドすると56,736bytes。何かに騙されてる気がするくらいのサイズ差がある。恐らく不要なモノが大量にリンクされてるだけだろうし、この辺放置するとエラいことになりそうなので、追って調査。それと、このままだとmbedからエクスポートしてきたソースのビルドは出来る(ライブラリ類一式がアーカイブに入っている)が、一からソースを書き始めるには諸々準備がいる。その辺もそのうち時間が取れたら調べて書く。

2012/2/20追記：

上のnewlib云々の問題、がた老氏がSTM32で遭遇された問題にそっくりのような気がする。Stub書けば良いだけなら話は早い。追って調査としたい。