広いような、狭いような、32KB

MMlpc2368でTINET動かしました。今回は昨年末に出たTINET 1.5を使ってみました。TINET 1.5からはTOPPERS/ASPにも対応したので、ASP用とJSP用で別々の配布ファイルが用意されています。イーサネットのドライバはInterface誌の2009年6月号にあったコードを元にして作成。イーサネットのリンクダウンとアップは、PHYからの割り込みで検出するようにしてみました。



動作確認にはTINETに付属する機能豊富なサンプルであるnservを使いたいところなのですが、多数のタスクが動くnservはSRAM領域もたくさん必要となり、連続するSRAM領域が32KBしかないLPC2368では簡単には動かせそうもありません。手をかけて、TINETの使用するバッファや各タスクの使用するスタックをUSBやEthernet用RAMに割り当て直せばなんとかなるかもないのですが、それでもかなり苦しそうです。そこで、機能は少ないけどメモリは喰わないminsvを動かしてみました。ビルドしてみたサイズは次のとおり。EthernetドライバがEthernet RAMを使用していますが、直接アクセスしており配列をとったりしてはいないので、そのサイズはBSSには表れていません。連続SRAM空間使用量は16KB以下に収まっています。




nserv/minsv はWWWサーバ機能を持っており、index.html と stat.htmlの2つのURLに対応するページを表示することができます。次の画面は、minsvにおけるこれら2つのページの表示内容です。





実際に使ってみてわかったのは、minsvではstat.htmlの表示に時間がかかること。しかも、なんだかカクカクと何段階かに分けて表示される感じ。最初に示した実行ログ画面からは、index.htmlの出力には379msしか要していないのに対し、stat.htmlの出力には2555msも要していることが読み取れます。調べてみたところ、TINETのコンフィギュレーションと関係がありそうです。minsvは、メモリの消費量を極力抑えるようにTINETのパラメータを調整してコンフィグしてあります。その一例が USE_TCP_MSS_SEGの使用であり、これによりTCPのセグメントサイズが512オクテットに制約されるようです。使用するバッファメモリを小さくできますが、その代りに一定量のデータを送出するのに、何度もパケットを送受する必要が生じます。ACK待ち回数も増えて、その結果、時間がかかっているようです。

そこで、minsvのMakefieをちょっと修正。上述したUSE_TCP_MSS_SEGの指定を外してみました。すると、消費されるBSSサイズは20KBを超えました。



しかし、stat.htmlの送出時間は942msと、一気に倍以上の速度になりました。



このように、TINETにおいては消費メモリ量と、TCPの転送処理速度には密接な関係があることがわかります。性能を犠牲にすれば、32KBのメモリもそれなりに使いでがありますが、性能を求めてバッファを大きくするとすぐに使い切りそうなサイズという感じです。やっぱ、LPC2388の64KBは使いでがあるなぁ。

プロダクトガイド

ATMELのARM製品のプロダクトガイドが更新されていることに気が付きました。SAM9G46とSAM9M11が「開発中」として記載されているところが目新しいところでしょうか。一方で、SAM3N、SAM3X、SAM3Aについては全く記載なし。こりゃ、来年になるかも。。。

SAM3Sはサンプリング段階なので、まだDigikeyにも並んでいません。Production状態になったSAM3Uですら在庫なし状態。Mouserも確認してみたら、納期17週間。うーん、使ってみるにはまだ時間かかりそうです。

ATMELのCortex M3はこんな調子なんですが、NXPは順調にその存在感を示していますねぇ。ついに、秋月にmbedと LPCXpressoが登場したのには驚きました。

LPC2388とLPC2368の違い

LPC2368実験ボードを用意したので、ソフトの方の作業中。とりあえず、TOPPERS/JSPのsample1を動かしました。



LPC2368とLPC2388は、どちらも同じユーザマニュアルで説明されているくらいで、ピン数は違っても、基本的にレジスタのアドレスは同じようです。Keilのサイトにあるヘッダファイルもlpc23xx.hという名前になっていて、共通で使えるようです。このヘッダ、NXPの方で探してもどこにあるかわからなかったです。

さて、レジスタのアドレスは同じでも、ピン数やピン割り当てが違うデバイスを同じように操作できるわけではないので、レジスタの値の意味が異なるものがあることになります。その代表がPINSELxで、各ピンの機能割り当てを設定するレジスタです。しかし、とりあえずJSPとsample1を動かすのに必要なUSARTのRXD0/TXD0についてはPINSEL0の同じビット位置に割り当てられているので、設定は共通でかまわないことが判明。TIMERも必要ですが、こちらは外部端子を使う必要なないので、PINSELを意識する必要は無し。よって、こちらもLPC2388のコードをそのまま流用可能。結局、sample1を動かすには、メモリの配置をリンカ・スクリプトに反映することと、それにともなってスタックの初期値を変更する程度の作業で動かせました。

Willcomの会社更生手続き開始に思うこと

こうなることはわかっていたとはいえ、やはりさみしい。そしてなによりもPHSがいつまで残ることになるのかが心配です。Softbankが支援するとはいえ、彼らは自分たちの欲しいところだけを採るわけで、興味が無い部分は切り捨てるでしょうから。周波数帯はもちろんですが、既存基地局のロケーションだって、そうとうな財産ですから、Softbankが欲しがるのは当然ですよね。

こうなった原因としては、XGPサービスに関わる新規投資の負担の大きさがあげられていますが、サービス内容がXGPであろうがなかろうが、どのみち設備更新が必要な時期にさしかかっていたのではないでしょうか。PHSのデータ通信サービスが開始されたのは、確か97年だったと思います。それから10年以上が経過し、NTTパーソナル(ドコモ）とASTELが撤退した理由にはサービス加入者減はもちろんですが、設備の更新時期と重なってきたのが負担になったと聞いたことがあります。10年もたてば、基地局メーカの保守期限も切れるので、設備更新が必要となってきます。しかし、何万局もあるPHS基地局を設備更新していくには、時間もお金もかかることになります。

Willcomの場合とて同じでしょう。設備更新と合わせて新サービスであるXGPを展開するつもりだっただろうと推測します。これを従来サービスと、XGPとに分けて考えるということは、すなわち従来サービスの設備は更新されずに、切り捨てられることにならないかが心配です。すぐにサービスを止めるわけではないにしても、更新されない設備は次第に朽ちていくわけで、動かなくなったものは、もう誰も直さない/直せないわけです。なんか、近い将来、我が国の社会インフラの全て(道路、橋、水道とか)に共通しておこる事態のような気もして、気分が沈みます。

しかし、悪いことばかり想像していたって、何の役にもたちません。ここは、やはりダメ元で、思い切ったことをやって欲しいものです。わたしが希望するのは、値段よりも本来のW-SIMコンセプトの実現でしょうか。

• まず、W-SIM単体で普通に販売して欲しい。端末ジャケットと組みでしか販売しないなんてW-SIMコンセプトの意味がないですから。
• そして、技術情報の無償開示。コンソーシアム会員なんて、しょせん法人にしかなれません。技術情報を一般に無償開示して、ユーザと用途のすそ野を広げてほしいです。

開発に携わった各社の知財権がからむので、コンソーシアムとか組んで情報開示手順を踏む必要があったのだとは思いますが、そんなことしていても、もう誰の利益にもならないんじゃないでしょうか。調子の良かった時期には、Willcomは保有する技術を海外にもライセンスすることで、それなりの収入を得ていたようですが、もうそんなことで稼ごうなんて考えなくていいでしょうし。

技術開示されれば、すぐにでもW-SIMシールドと、それをサポートするライブラリとかが登場してきますよね。わたしも、買い置きのW-SIMソケットがまだいくつも残っているんで、今年も何かひとつくらいは作ろうと思います。

引っ越し準備

いままで、ずっ～と Fedora Core5をVMware Playerで走らせて、GCCも4.1.1を使っていました。自分でも何年前の環境だか覚えていないくらいです。年のせいか、新しいものを追っかけ続けることにさほど(いや、ほとんどか？)興味を覚えないのも一因ですかね。日々の作業に何も不自由感じませんし。気が付けば、VMware Playerすら 3.0に更新しないで 2.5のまま使っているような始末。

しかし今後 Cortex M3に手を出すことを考えれば、いいかげんにツールを新しくする必要ありです。そんなわけで、インストール作業で時間つぶしました。とりあえず、基本構成として入れたもの↓。

• VMware Player 3.0.0
• Ubuntu 9.10
• CodeSourcery　ARM 2009-q3

ようやく人並みの環境を入れたというところでしょうか。VMware Toolの導入がえらく簡単になっていたのでビックリ。以前は、Windowsとのファイル共有するのに Linuxのソースを拾ってきて、カーネル作り直したりしたような記憶があるのですが。。

これからしばらく、apt-get installの日々が続くかな。。

LPC2368実験ボード - その2

配線し忘れていたJTAG信号を追加して、MMlpc2368を載せました。



ジャンパは、裏側でPHYであるDP83848の割り込み要求端子へとつながっています。割り込み要求が回路図上ではどこにもつながっていないようなので、しょうがないのでジャンパすることに。割り込みは、P2[10]/EINT0 で受けることにしました。



JTAGつなげて、コネクトできることを確認。いつものことではありますが、とりあえず見えるようになるというのは安心できていいものです。



JTAGつなげる時にデバイス選択して気付いたのですが、LPC2368ってSRAM 32Kだったんですね。何かの資料で「RAM 58KB」とあったのが頭に焼きついていたのですが、この数字は SRAM 32KB + Ether RAM 16KB + USB RAM 8KB + Backup RAM 2KBの合計だったようです。たしかに58KB あることに違いはないのですが、不連続だとそれなりに意識して使わないと。改めてLPC2388はメモリたくさんあったなぁと感じた次第です。

LPC2368実験ボード

死蔵状態だったMMlpc2368を生かすべく、実験用親基板を作成。アイテムラボのパワーメッシュ基板を使って、VCC/GND配線の手間を省くことにしました。

つなげたのはリセット用SW, JTAGとUSB端子、そしてシリアルをつなぐための3P端子です。USBは当面は電源用端子ですね。このミニBコネクタのピッチ変換基板はSparkfunのもの。大きさ、お値段ともに手ごろで助かります。



裏側にはいまのところ、3.3Vのレギュレータだけです。



これだけ用意すれば、とりあえずはJTAGでコネクトできるかなと思ったのですが、まだつなぎ忘れの線がありました。続きはまた週末にでも。

MMlpc2368

先日もちょっと書きましたが、昨年買い込んだPropoxのMMlpc2368を少しは使ってみようということで、机の上を探して引っ張りだしました。

まずは、写真撮影。電池フォルダの下には、PHYであるDP83848が隠れています。



裏側にはクリスタルと、8MBのデータフラッシュが載っています。



3.3V電源と最低限のコネクタを付けてやれば使えるはずですので、ともかくも動作確認から始めようかと思っています。

そもそもこのボードを購入した動機は、インターフェースのLPC2388基板に自分でPHYをつなげるだけの気力がなかったからです。LAN&SD基板を買おうかとも思ったのですが、同じ値段でこのボードが買えるので、ついついこちらをポチッってしまいました。そんな経緯もあるので、ここはやはりイーサネットを使ってみるつもりです。

JTAG調子悪し

昨年末ころから兆候はあったのですが。。ここのところ、JTAGの調子が悪いです。どうも、フラットケーブルのコネクタの接触が悪くなったようです。起動するとCPU IDの検出に失敗することしばしば。ケーブルをコネクタに押し込み直すとなんとか、検出できるようになったりします。



これでちゃんと動き続けてくれればいいのですが、やはり接触が悪いのか、フラッシュの書き込み途中でハングしてしまう症状を見かけるようになりました。どうにも安心して使えないので、今週はもっぱらFlash Magicを使ってシリアルでLPC2388へ書き込んでいます。

今のJTAGはKrisTechで買ったものですが、すでに2世代前の製品です。現行の製品はFT2232Hを使ってハイスピード対応しているようです。だましだまし使い続けるのも面倒なので、そろそろ新しいものを買おうかと思案中です。