はじめに

最近、MCUの周辺回路としてEthernetコントローラを搭載するものが増え、 MCUを容易にネットワークに接続できるようになりつつあります。 ネットワークにMCUを接続することでさまざまな応用が可能になります。 MCUが搭載するRAMの量はPCなどの世界から見るととても小さく、 ネットワーク通信やデータの処理においてメモリ不足に陥ることがあります。 そこで、以前、ネットワークを利用したアプリケーションのための、 大容量のRAMを搭載したMCUボード(以後、LPC2468ボードと記します)を設計しました。

今回はLPC2468ボードにマイナーチェンジを施し、MCUを最新のものに置き換えたボードを設計することにしました。 LPC2468ボードでは接続できる液晶モジュールが白黒で128x64の解像度しかありませんでしたが、 今回は安価に入手できるようになったカラーのQVGA液晶モジュールを接続できるように設計しました。

主に、別ページに記述したNetwork Appliance 3の製作に使用しています。

デモビデオ

• 2011年5月14日版
  

Windows Live ムービーメーカーで作成しました。WMV形式です。Firefox ではプラグインが必要かもしれません。 長さは約6分で、最後からの2分くらいのところから音が出ます。

ハードウエア

LPC2468ボードを設計する際にMCUの候補に挙がりつつも入手できなかったTexas Instruments(TI)のStellarisシリーズのLM3S9B96チップが入手できたので、 改めてLM3S9B96で設計しました。

Features

• MCU： Texas Instruments LM3S9B96
• Processor core: ARM Cortex-M3
• RAM: 96 KBytes
• Flash: 256 KBytes
• Clock: 80MHz
• 内蔵周辺回路: Ethernet MAC/PHY, External Peripheral Interface, USB 2.0 OTG/Host/Device, SafeRTOS kernel ROM等
• 外部RAM： SDRAM 16MBytes 16bit接続 (Qimonda HYI39S128160FE)
• 外部ROM： シリアルフラッシュメモリ 4MBytes (Numonyx M25P32-VMW6G)
• 電源： DC 5V (ACアダプタより供給)
• MP3デコーダ搭載(VLSI Solution Oy VS1053b)
• MACアドレス格納済みEEPROM搭載 (Microchip 24AA02E48)
• USBホスト機能
• 押しボタンスイッチx3

設計の見直しをしたり、MCUがEthernet PHY機能も内蔵していることもあってLPC2468ボードと比較して部品が大幅に減りました。 LPC2468ボードでは1台の製作に1日かかっていたものが、今回は半日程度になりました。

マイナーチェンジなのでボードサイズはLPC2468ボードと同じになっています(3900mil x 2800mil(大体 100mm x 70mm)のサイズ)。

基板の表面。MCUのピンはほとんど全て使用しているので配線が難しいです。 回路図と基板の設計には EAGLE Layout Editor を用いました。 EAGLE Layout Editorの自動配線ではうまく配線できないので全て手配線しています(シルバーウィークを全て投入して配線しました...)。 配線は電源配線を除いて基本的には 7mil で引いています。 LPC2468ボードでは10milだったのでかなり細くなっています。

中央にあるのがSDRAM。比較的安価で、写真のチップはひとつ大体250円で購入できました。 かつてはPCのメインメモリに使用されていたので、古いPCのメモリモジュールによくついています。

ボードに乗り切らなかった機能を実現するために、拡張ボードを作成して接続しています。 プロトタイプなのでまだケースへの格納は考えていない形状です。 拡張ボードにはST Microelectronics社のSTM32マイコン(STM32F103C8T6)や気圧センサ(Bosch Sensortec社のBMP085)が載っていて、これらとLM3S9B96とはI2Cバスで接続しています。 さらに、拡張ボードのマイコンにはXBee無線モジュール、赤外線リモコン受信モジュール、赤外線LED等が接続されており、拡張ボードのマイコンを経由して、 XBee無線モジュールを制御したり、リモコンの赤外線の受信や送信ができます。

ハードウエアの設計メモ

カラー液晶はコントローラが付いたモジュールタイプを使用しています。 モジュールのインタフェースは8ビット/16ビットを選択可能なパラレルインタフェースになっています。 今回はAHB経由でGPIOポートを叩いて制御しています。 MCUのピンが不足したので、8ビット幅でつないでいます。 高速にGPIOを制御できるようで、ロジアナで計測したところでは、 16bitカラーでの1画面の描画時間(画面データを液晶モジュールに転送する時間)は17.5msでした。 データさえ整っていれば、30 フレーム/秒には余裕があります。 1画面150KBytesなので、3秒間分、90フレームをSDRAMに読み込んで再生してみました。 30フレーム/秒で動画を再生して、同時にMP3形式の音楽を再生（VS1053bチップがデコードするので、必要な処理はUSBメモリの読み出しとチップへの書き出しだけ）してもまだ余裕があるようでした。

電子工作ではストレージデバイスとしてはSDメモリカードがよく使われますが、 MCUのピンの余りがほとんど無く、また、MCUにSDメモリカード用の専用インタフェース回路がないこともあり、 ストレージデバイスとしてLPC2468ボードと同様にUSBメモリを使用しています。 同程度の規模のMCUを用いたこれまでの報告(例えば、NXPのLPC2368を使用したelm氏の例や STのSTM32を使用したねむいさんの例)によると、 MCUの専用インタフェースを用いてSDメモリカードを制御すると読み出しで5MBytes/sから10MBytes/s程度は出るようです。 今回の設計だとUSBメモリの読み出しで1MBytes/sまで行かない感触なので (少なくともFTP経由でアクセスすると数百KBytes/s程度しか出ない)、高速なストレージアクセスが必要であればSDメモリカード用のインタフェースのあるMCUで SDメモリカードを使うのがいいと思います。

LPC2468で使用していたMP3デコーダチップVS1011eに代わり、新しいVS1053bチップを使用しました。 再生できるフォーマットが増えている点もうれしいですが、あくまで個人的で主観的な感想ですが、VS1011eより音が良くなっているように感じます。

ARM の Cortex-M3コアはARMのページを見るとTSMC 90nm Gプロセスで 0.047mm²から0.0837mm²程度のサイズということでとても小さいです。 90nmプロセスでは6トランジスタSRAMのメモリセルのサイズが大体1.0μm²から1.2μm²前後という話なので(注1)、この前提でざっくり計算して 5K-10KBytes(40K-80Kbit)分のメモリセルと同等の面積という計算になります。 メモリセルとロジック回路が同程度にスケールするなら、130nmプロセスのLM3S9B96においてもCortex-M3コアは5K-10KBytes分のSRAMメモリセルと同程度の面積になるはずです。 LM3S9B96だと92KBytesのSRAMが載っているので、この時点でCortex-M3コアがチップ全体に占める割合が1割未満であることが想像できます。確証はないですが...。 最近になって浮動小数点演算ユニットをMCUのプロセッサコアに搭載するようになったのは、 このクラスのMCUだとプロセッサコア面積を大きくしてもチップ面積に与える影響が小さいというのもあると思います。

注1) 例えば、甲斐 ら, 「90nm CMOSテクノロジの概要」,雑誌FUJITSU, vol. 55, no. 3, pp. 187-192, 2004. [Web]

消費電力

別ページで紹介したネットワークUSB電源を用いて消費電流を計測した値を 表にしました。 測定精度など確認していないので参考程度の値と考えてください。

表中の「Ethernetブートローダ」とある行はStellarisWare添付の Ethernetブートローダを動かした際の値です。 EthernetブートローダではSDRAMを使用しません。 ブートローダについての説明は "Stellaris Boot Loader User's Guide (SW-BOOTLDR-UG)"にあります。

ハードウエアの実装メモ

• QVGAの液晶モジュールは縦長で使うことが前提のものが多くあるようです。写真を見ていただくと分かりますがここで使用したモジュールも縦長で使うことが前提です。 今回のモジュールの場合、データシートの記載から想像がついていたのですが、横長で使うと 色によっては液晶画面を左側面から見たときと、正面から同じ程度の角度で右側面から見たときとで見え方が随分と違います。 白黒の表示ではあまり気にならないのですが、色の見え方が大事なアプリケーションではデータシートの指示通り使うのがいいのかもしれません。


• TIのStellaris シリーズの第4世代(Tempest class、LM3S9B96も含まれる)のチップは 内蔵Flashメモリ関連の問題で苦戦している様子です。 初めに使用したC1リビジョンのチップでは電源投入時にFlashメモリの中身が稀に消える問題があるうえに、Flashの先頭に不具合回避のためのコードが格納されているという有様でした。 最近の C5リビジョンでも書き換え回数100回までの保障になるという不具合が残っています (参考: TI E2E Community: 100 cycle flash endurance (C5 and A2))。 C1リビジョンのチップで何枚か製作したのですが、突然Flashメモリの内容が消えるのも嫌なので、全てC5リビジョンのチップに張り替えました。
  Flashの容量を増やしたLM3S9D96もありますが、 プロセスがLM3S9B96と同じであるため、書き込み回数の不具合を引き継いでいます。

ソフトウエア

現在は、Network Appliance 3 のシステムをつくるのに利用しています。 インターネットラジオやMIDIやMP3の再生、WebサーバとWikiのシステム、 FTPサーバ、XMLのパーサ、JPEGのデコーダ、などの要素機能が実現できています。

左の写真がインターネットラジオを再生中の様子。Webブラウザを介してネットワーク越しに再生の制御ができます。写真右下はiPod touchを利用して遠隔で制御している様子です。 無線LANに接続できる携帯デバイスが増えたので赤外線リモコンの代わりにそういった携帯デバイスを使います。

左が開発途中のRSSリーダの画面。UIはまだ作りかけで投げやりです。 他のサーバなどの助けを借りずにボードのソフトウエアだけでRSSをダウンロードし、パースし、表示しています。

ボード上のWebサーバでいろいろなサービスを実現できています。

PCからのみだけではなくて、タブレット型端末からの利用ができるように設計を進めつつあります。 左図ではiPad2を端末として利用しています。 2011年12月の時点で作りかけの段階です。 iPadでネイティブアプリを作るのは(技術以外の要因で)お手軽とはいえないため、 アプリケーションはHTMLとJavascriptで製作しています。 jQuery Mobile を利用しています。

iPad を使う場合(タブレット端末全体にも言えるかもしれませんが)、textareaのようなスクロール可能な要素をいれると 操作に違和感が出ることがあるなど、PC用のデザインとは違ったところで注意が必要になります。 マウスのドラッグを使う上の図のPC用のウェブシステムはタブレット端末ではうまく扱えません (ウインドウの移動を意図してタッチすると、スクロールとして認識される)。

サイバー-フィジカル・システム(CPS)構築のためのプログラミング環境をボード上のWebサービスに組み込んでいます。 ブラウザ上でプログラムを記述し、ボード上のMCUでプログラムを実行します。プログラムはブラウザ上でコンパイルされ、仮想マシン用のアセンブリコードに変換されます。 コンパイラはJavascriptで記述されています。 ボードではアセンブリコードを読み出し、MCU上の仮想マシンの上で実行します。

言語仕様も仮想マシンの仕様もいい加減ですが、現時点では言語はC言語風で、 仮想マシンの命令セットはうろ覚えのMIPSとAVRの命令セットを基に設計しています。

XBee無線モジュールを遠隔操作するプログラム例を表示した様子です。 この例では無線モジュールを扱っていますが、ページ冒頭のデモ動画にあるように、赤外線信号の送信などの操作も可能となっています。 プログラムの実行はボード上で行うので、一旦実行を開始してしまえばブラウザを閉じても実行が継続します。

XBee無線モジュールの一覧表示もできるようになっています。 (図ではモジュールのアドレス部分をぼかしています)

ブラウザからボードへの通信だけでなく、ブラウザからネットワーク上のさまざまなデバイスと通信してさまざまな機能を実現していこうと考えています。 図ではボード上のWebサーバが提供するNetwork Appliance 3 のウェブシステムから、ネットワーク上のプリンタに印刷にしています。 このプリンタの製作についてはこちらのページにまとめています。

ソフトウエアの設計メモ

さまざまな機能を協調して同時に動かすためにRTOSをつかいます。 今回はLM3S9B96内部のROMに格納されているSafeRTOSを利用しています。 現状でも分かるだけで10個から15個くらいはタスクが動いています。

内蔵のSRAMは特別な用途のため(たとえば後述のuDMAのため)にとっておいて、基本的には外部RAM(SDRAM)を data, bss領域や各タスクのスタック領域として使います。 ついでに、プログラムコード格納用のメモリがMCU内蔵Flashメモリの256KBytesでは不足するので、 サイズが大きいけれど使用頻度はそれほど高くないプログラム(JPEGデコーダや漢字コード変換等のプログラム)は 外部のシリアルフラッシュメモリに書き込んでおき、 起動時に外部RAMに読み込むようにしています。

チップが高機能になるとソフトウエア作成の負担が重くなるため、 MCUクラスのチップでもソフトウエアをチップメーカーである程度用意して労力を軽減させる方向に進んでいるようです。 今回使用したStellarisシリーズのMCUでは、StellarisWareというパッケージが配布されています。 StellarisWareにはペリフェラル用のミドルウエア(Driver library)、 USBやグラフィック用のライブラリ(USB library, graphics library)、Stellarisシリーズ向けに移植したフリーのミドルウエア(FatFs, libjpegなど)などが含まれています。 さらに、LM3S9B96はDriver libraryと SafeRTOS (FreeRTOSベースの商用RTOS)を含んだROMを内蔵しています。 この製作例では、StellarisWareに含まれていた Driver library, USB library, libjpeg, lwipに手を加えつつ使っています。

StellarisのDriver libraryを使うと、GPIOの制御はたとえば次のように書けます

	ROM_GPIOPinWrite(GPIO_PORTH_BASE, GPIO_PIN_7, GPIO_PIN_7);

この例ではポートHのピン7を操作しています。他の周辺回路を使う場合でもレジスタを意識せずに制御できます。UARTの設定だとこんな感じです

	ROM_UARTConfigSetExpClk(UART0_BASE, ROM_SysCtlClockGet(), 38400,
			(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE) );

Driver libraryのAPIドキュメントを見ながらプログラムを書く開発スタイルになるのでレジスタを直接触る機会は少なくなり、 スピード的に問題がある場合などに限られてきます。 上に示したシステムの場合、レジスタを直叩きしているのはプログラム全体でも10行程度です。 MCUは周辺機能などの分かりやすいハードの機能だけではなく、提供されるライブラリの量と質、プログラム開発環境も大事だと思います。

TCP/IPのプロトコルスタックとしては、組み込み機器向きの TCP/IP プロトコルスイート であるlwIPを使用しています。 LPC2468ボードと同じようにBSDソケットまで使えるように設定しています。 LPC2468ボードのときは lwIPとMCU、RTOSの間のインタフェース部分を自分で用意しないといけませんでしたが、 StellarisWareにはStellarisとSafeRTOSの組み合わせでlwIPを使うためのコードが用意されているので 自分でコードを書かなくてもほとんどそのまま利用できます。

ストレージデバイスとしてUSBメモリを使っています。 MCUのUSBコントローラをHostモードにして動作させて、USBメモリを制御します。 USBメモリのドライバ部分はStellarisWareに含まれるUSB libraryを利用しています。 USB libraryではUSBハブを扱えないようなので、現状では複数のデバイスを同時につなげることはできないようです。 USBメモリのためのファイルシステムミドルウェアとしてchan氏のFatFsを使っています。

EthernetコントローラをDMA無しで使い(StellarisWareのそのままのコード)、Network Appliance 3のコードを動かした場合、 FTPでのファイル転送速度(読み書きの対象はUSBメモリ)は 手持ちのUSBメモリ(pqi製)で、put が 82.5 KBytes/s、get が375.9 KBytes/sでした。 以前設計したLPC2468を使ったボードで同じUSBメモリを使用した場合も同程度のスピードでした。 感覚的にはUSBまわりがボトルネックになっているように感じます。

プログラムの開発では、ツールチェインとしてCodeSourcery の Sourcery G++ Lite Edition (GNU Toolchain) を用い、 JTAGデバッガとの接続に OpenOCD、プログラムの記述とデバッグには Eclipse に Zylin Embedded CDT をいれたものを使用しました。 JTAGデバッガとしては、安価なJ-Link互換(?)の製品を使用しました。 最近は、プログラムの書き込みにStellarisWareに付属するブートローダを用いてEthernet経由で行っています。 手持ちのJTAGデバッガより書き込みが速いです。

ソフトウエアの実装メモ

以下、実装上でのポイント・躓いた点をまとめます。

• lwIPを使うにあたって、StellarisWare付属のlwIPのコードのメモリの取得と開放の部分などで、若干微調整を入れています。 基本的には、オプションの設定とパラメータの調整("lwipopts.h"の定義)をがんばれば良いです。 ただ、パラメータの設定で通信スピードが大幅に変わるのですが、 項目が多く、項目によってはトレードオフがあるため適切なパラメータにするのはかなり大変です。 負荷をかけたりWireSharkでパケットを観察しながらパラメータを調整しました。 Ethernetコントローラの受信FIFOが2KBytesと小さいので、受信完了してデータをすぐに取り出さないと取りこぼします。 SafeRTOSと組み合わせる場合、StellarisWareに含まれる lwiplib.c の xTaskCreate(lwIPInterruptTask, ...) の行で 受信待ちタスクを生成していますが、タスクの優先度を十分に高くしないとパケットを取りこぼすようです。


• USBメモリのアクセスに用いたStellarisWare付属のUSB libraryではデータ転送にuDMAコントローラを使います。 困ったことに外部のSDRAMの領域をスタックとして使うタスク(この製作例ではほとんどすべてのタスクが該当)が このUSB libraryを用いてUSBにアクセスするとuDMAを動かした辺りの行で必ずプロセッサが止まりました。 理由は判然としないですが(プログラムのミスもありうる...)、USB libraryのコードを書き換えるのは避けたいので、 内蔵SRAMしか使わないUSBを操作するだけのタスクを作り、 ランデブを実装してそこに操作を投げるようにしました。


• LM3S9B96のuDMAコントローラはプロセッサがバスを必要としないときだけバスを使用できるようです。 LM3S9B96にはペリフェラル用にAHBとAPBのバスがそれぞれ1つずつあります。 SSI(SPIバスのコントローラ)とEthernetコントローラが同じAPBのバスにつながっているためか、 Ethernetの処理をしながら DMAを使ってSPIデバイスからのデータの受信を行うと(注2)、極稀にデータを取りこぼしているように見えます。 競合するチップ(たとえばNXPのLPC1769)と 比較するとバスが簡素にみえます。
  注2) SPIクロックの生成のための送出DMAと、受信DMAを対にして動かした場合です。 受信バッファからメモリへのDMA転送が滞ってもお構い無しにクロックを生成するため、受信バッファがオーバーフローすると予想しています。


• StellarisWareにJPEGライブラリ(libjpeg)を移植したものが含まれています。 サンプルプログラムがあるので参考にしながら、 メモリアロケータなどの環境をあわせるだけで利用できたと思います。


• 新しいチップでDriver libraryがこなれていないこともあって、 ROM内のDriver libraryに不具合があることがあります。たとえば、ROM内のUSBHostMode()には不具合があり、 最新のStellarisWareではROM_USBHostMode()の定義がなくなっています (ROM内の関数はStellarisWareの中のヘッダファイル(driverlib/rom.h)で呼び出しマクロが定義されている)。 この手の情報もErrataに載るのでプログラムを書くときもErrataを熟読します。


• 割り込み処理ルーチン内でSafeRTOSのAPIを使用する場合、この割り込みの割り込み優先度を portSYSCALL_INTERRUPT_PRIORITY より高くすると (言い換えると、数値が小さいほど優先度が高いので、優先度が数値として小さいと)クラッシュすることがあります。 脈略無くクラッシュして原因が特定しにくいので注意が必要です。

まとめと今後の課題

以前製作したLPC2468ボードにかわる低コストのボードを設計し、製作しました。 モノクロ液晶に代わり、解像度の高いカラー液晶を搭載したことで表現力が向上しました。 大容量のメモリを搭載したことで、グラフィックスを容易に扱うことができました。 Webサーバ、FTPサーバ等のアプリケーションも問題なく動作しました。

ここ数年でのMCU業界の競争が激化や、アプリケーションの複雑化もあってか、 プロセスの微細化が進み、新製品の発表が相次いでいます。 現時点(2011年10月現在)では、90nmから65nmプロセスのMCUが出始めているようです。 しばらくは、チップ性能にあまり依存しない陳腐化しにくい制作目標をたてたほうがよいのかもしれません (ちなみに今回のLM3S9B96は130nmプロセスなので、MCUのプロセスはすでに1,2世代引き離されている)。 電子工作関連も人多すぎになりつつある気がしなくもないですが、 エネルギーハーベスティング、UI系(AR、タンジブル)、フィジカルコンピューティング系やモバイル系の小物、 機械(ロボットetc)などがこれから暫く流行るような気がします。

(2010/10/20)
(2010/10/27)
(2010/12/4)
(2010/12/12)
(2010/12/30)
(2011/1/1)
(2011/1/22-1/23 写真・説明を追加)
(2011/2/12 写真・説明を追加)
(2011/3/7 Webベースのプログラミング環境について説明を追加、移転先記述)
(2011/5/15-23 デモビデオ追加、説明の追加)
(2011/7/12 拡張ボードについて記述の追加)
(2011/11/5 ページの構成を変更、プリンタについての記述を追加)
(2011/12/12 タブレット型端末からの利用について図と記述を追加)

参考文献