« 2009年8月 | トップページ | 2009年10月 »

2009年9月の記事

Ride7開発環境のデバック制限解除ライセンス

STM32 Primer2購入直後にアップした記事にて、32KBのデバック制限を解除するためにはSTM32 Primer2 Professional(129ユーロ)の購入が必要ではと書いたのですが、誤りでした。

STM32 Primer2 Upgrade for Unlimited Debuggingというソフトライセンスのみの製品があり、こちらは68ユーロです。Raisonance(発売元)のwebページは製品一覧がなく見づらいです。ただ、今見ると、自分が参照したSTM32 Primer2 Professionalのページからリンクが張ってありますねぇ。。。

68ユーロ(クレジットカード決済の為替レートだと9500円程度でしょうか)も決して安くはないですが、32KBの上限を超えるアプリを作る際は追加ライセンスを買ってしまうかも。CircleOS領域が24KBのため、ユーザーアプリは実質8KBが上限、かつデバッグビルドはリリースビルドに比べてHexファイルのサイズが2倍近くになるため、8KBにはすぐ到達しそうです。

追加ライセンスに引かれるもう一つの理由ですが、デバッグ機能をちょっと触ってみたところ、これがなかなかよい感じなのです。Cell SDKを使用したリモートデバック(PS3にデバック対象プログラムをロードしてPC上のEclipse IDEからデバックを実行)では、デバックプログラムのロード中にエラーで停止するような事象に結構遭遇しますが、Ride7では今のところこのような問題もありません。

IDEとしての機能を比べると、Eclipse + CDT + Cell SDKの方が上だと思いますが(定義済み変数の入力補完など)、デバックの安定性という点ではRide7の方がよいです。あくまで、Cell SDKを使用したデバッグとの比較ですので、Eclipse上でPCのネイティブコードをデバックする場合は問題ないです。

STM32 Primer2の電源回路とバッテリー駆動時間

STM32 Primer2の電源ONは、ジョイスティックの中央ボタン押下で行います。一方、電源OFFはCirculeOSのメニューからshutdonwを選択することによって行います。いわゆるソフト制御ですが、具体的にどのような動作になっているのか興味があったため調べてみました。ついでにバッテリー駆動時間の測定を行いました。

電源回路

回路図の抜粋を以下に示します。回路図全体は、ここにあります

Primer2_pwoercircuit

回路図から分かる動作イメージは以下の通りです:

  • VCC5_USB(USBバスパワー)とVBAT(バッテリー出力)がダイオードオアされ、MOS-FET(U6)のSourceにつながっている
  • MOS-FETのDrainがステップダウンレギュレーターに接続されており、ここでシステムに供給する2.8Vを生成する
    → NOR回路のみは常時給電されるが、その他はMOS-FETのON/OFFによって給電が制御される
  • 初期状態ではU12(NOR)の入力は両方ともプルダウンされているためHighを出力
    → そのためVEもHighとなりMOS-FET OFF(P-CH)→給電停止状態
  • Joystickの中央ボタンを押すとPBUTTON信号がHighになる
    → VEがLowになりMOS-FET ON →給電開始
  • 同時にU15の出力がHighになるため、スイッチを離した後もVEがHighに保持され、MOS-FETはON状態を継続
    → スイッチを離すとPBUTTONはOpen状態になります(Pull downなし)。そのため、GPIOをInput floatingに設定してあります
  • SHUTDOWN信号はMCUのGPIOにてソフト制御
    → Shutdown時このPinをLowに落とすことによってVEをHighに遷移させ、MOS-FETをOFF状態、即ち電源OFF状態にします

上記のように電源ONはメカ的に行えますが、電源OFFはソフト処理になります。アプリケーションをCircleOS配下で動かす場合、Shutdown処理はCircleOSが行いますが、CircleOSなしで直接アプリを動かす場合は、電源OFF処理の作り込みが必要です。

MCUの電源はON/OFF対象と書きましたが、RTCとバックアップレジスタに給電するためのVBATピンにはバッテリーの出力が直接つながっています。CircleOSではshutdown時にクロック設定・スピーカーボリュームなどをバックアップレジスタに退避して、次の起動時に以前の状態を復元しています。

バッテリ駆動時間の測定

STM32 Primer2のバッテリーは1セル, 400mAhのLi-Ion電池です。Webの製品紹介では、バッテリ駆動6時間以上とありますが、実際にどの程度かをテストプログラムを使って計ってみました。テストプロラム(CireleOSアプリ)の概要は以下です:

  • CircleOSからApplication_Handlerが呼び出される毎にLEDを点滅
  • バッテリー電圧と起動時間をLCDに表示(1s毎に表示を更新)

LCD表示、LED点滅、バッテリー電圧の読み取りはCircleOSのAPIを使用することで簡単に記述ができます。Arduinoもそうでしたが、基本的なI/O処理を行ってくれるOS・ライブラリがあるとやはり便利です。テストプログラムのソースをアップしておきます。
 「Toggle.zip」をダウンロード

起動時間は、Application_Handlerの呼び出し周期から積算しています。呼び出し周期15Hzの場合積算値を66msとしており、端数を切り捨てているため精度が悪いです。そのため、実際の動作時間はストップウォッチで計っています。

CircleOSでは、アプリケーションが動作中も周期的にバッテリー電圧の監視を行っています。バッテリー電圧の監視閾値は以下の通りです(マニュアルより):

  • FULL = 4200mV
  • LOW = 3750mV(Warningレベル)
  • EMPTY = 3500mV(Shutdownレベル)

試験プログラムを、クロック36Mhz、LCDバックライト輝度2(5段階の真ん中)で連続動作させました。動作中の写真を以下に示します。

Primer2_batterytest_2

バッテリ電圧が3500mVを下回ったところできっちりshutdownが動きました。動作時間は200分です。バックライトをこまめにOFFしたり、MCUのスリープモードを使うなどすればもっと駆動時間を延ばせるはずです。

STM32 Primer2が使用しているLi-Ionバッテリーは、定格電圧3.7V, 放電終止電圧2.75Vです(データーシートより)。せめて3.0Vあたりまでバッテリーを使えないものかと思うのですが。大きな電流は流れていないと思うので、スイッチ用のMOS-FETレギュレーター内で発生する電圧降下は僅かだと思うのですが。(ダイオードみたいな順方向電圧は、MOS-FETのソース・ドレイン間にはないですよね)

2009/10/25追記:
3.5Vでshutdownする理由がなんとなく分かりました。こちらをご覧ください。
バッテリーを860mAhのものに交換して、上記の連続ランを行ったところ、12時間動作後でもバッテリー電圧は3.77V残っていました。そのため、製品添付のバッテリーでも、カタログ値通りの6時間程度は動作しそうです。当初の試験で動作時間が短かった理由はバッテリーの使い方に問題があったためと思われます。

基板の写真

基板両面の写真を撮ってみました。結構部品点数があります。デバックやプログラム書き込み用USBポート制御のために8bitマイコン(ST72651)が乗っています(Joystickボタンの下)。

Stm32_primer2_board1

Stm32_primer2_board2

今後の予定

GPSレシーバーをつなぐために、シリアルポートの動作実験をしたいと思っています。シリアルポートは拡張コネクタに信号が出ています。CircleOSのAPIはありませんが、開発環境(Ride7)のライブラリフォルダーにUSARTドライバのファイルがあるためこいつを活用できそうです。

GPSレシーバーモジュールを拡張コネクタエリアに収めるのはスペース的には問題なさそうですが、以下の点が課題です:

1)電源

拡張コネクタに出ているのはレギュレーターを通した2.8Vのみです。スイッチサイエンス、秋月で売っているGPSレシーバーは5V動作のようで動作下限が3.3Vです。DC-DCコンバーターが必要ですが、一旦2.8Vに落とした電源を再度5Vにあげるのは効率が悪いです。とは言え、バッテリーから直接給電するとON/OFFが出来ないんですね。。。

2)2.8Vレギュレーターの容量、バッテリー容量

スイッチサイエンスさんのGPSレシーバーで50mA程度電気を喰います。DC-DCコンバーターの効率を考えると60~70mA程度の負荷増でしょうか。内蔵レギュレーターの容量は1.2Aなので大丈夫とは思いますが、forumの書き込みを見るとレギュレーターが破損したというケースが何件か報告されています。そのため、電源まわりはもう少しチェックが必要です。バッテリー駆動時間も減ってしまうため、バッテリーの容量アップ(換装)も行いたいところですが充電回路に影響がないかも確認する必要ありです。

STM32 Primer2

以前からARMを触ってみたいと思っていたのですが、STM32 Primer2を買ってしまいました。写真に示す通り携帯電話サイズで思ったより小型でした。

Stm32primer2

以下に示すデバイスを内蔵しており、自分が必要なハードはほぼそろっています。

  • STM32F103E(ARM Cortex M3コア、512KB flash ROM、64KB SRAM)
  • カラーLCDディスプレー(128 x 160) + タッチスクリーン
  • 4方向プラス押しボタンのジョイスティック
  • 三軸加速度センサー
  • Micro SDカードスロット
  • Li-Ionバッテリー駆動
  • USBインターフェース
  • 拡張ボード搭載エリア

これだけ入って秋月電子さんで6200円と価格的にもお得です。ハード的には完成しており自作の余地が少ない点が趣味的使用にはマイナスとも思えたのですが、パッケージングのよさに引かれて買ってしまいました。

この後の計画としては、GPSモジュール(こいつならケース内に入りそう)を追加してGPSロガー制作を考えています。妄想レベルですが、愛車のECUから信号を取り出せれば(メンテナンスコネクターに出ている信号をUSBに変換するアダプターがあるみたい)、燃費・速度・アクセル開度などの走行データーも一緒にロギングすることができそうです。

応用は今後の課題として、今日は開発環境のインストールを中心に気がついた点を記載します。

開発環境のインストール

製品添付のCD-ROMに開発環境が収録されていますが、バージョンが古いためコミュニティーWebサイトにある最新版のインストールを試みました。開発環境は、Ride7(IDE)とRKit-ARM(GNU Toolchain、ライブラリ類)に分かれているのですが、Ride7のインストール後半にエラーが発生して中断してしまいます。再度インストーラーを起動してRKit-ARMをインストールすると一通りのファイルは展開されるようです。この状態ではUSBドライバーがインストールされていないのですが、"[インストールdir]\Ride\Driver\RLinkDrv\RLinkUSBInstall.exe"を起動することでインストールができました。

上記のインストールにて、IDEを使用したプログラムのビルド・Flash ROMへの書き込み・デバッグは正常に動作しました。GUIツール(RFlasher7)を使用したFlash ROM書き込みはうまく動作しませんでしたが、コマンドライン(batファイル)を使用した書き込みはできているためよしとします。デバックイメージの書き込みはIDEのGUI操作からできています。

コミュニティーWebサイトからダウンロードできる一つ前のCD-ROMイメージは正常にインストールできますが、最新版の方が動作が若干軽快なこと、後で書きますがLPC2xxxのサポートが追加されたことから最新版(Ride 7.24.09, RKit-ARM 1.22.09)を使っています。

インストール問題解決(2009/9/21):
Forumに問題をアップしたところ、この件はVista環境でInstallerがJScriptを起動できないことに起因するとの解答がありました。リンクに示す対策にてインストールが正常動作するようになりました。RFlasherは依然としてうまく動作しません(操作が間違っているような気がするのですが、マニュアルがいまいちでよく分からず)。

一つ前のCD_STM32-Primer_BN14.zipをインストールした場合、flashプログラマーにバグがあるため要注意です。BN14を使用する場合、Primer2_Upgrade v3.71をダウンロードし、以下のファイルを"[インストールdir]\Ride\bin"ディレクトリにコピーします。

  • circle_mgr.exe
  • cortex_pgm.exe
  • cortexdrv.dll
  • monitortools.dll
  • RLink_WinUSB.dll

Ride7を使ったデバッグ

以下の画面に示すようにソースコードレベルのデバッグが出来ます。デバックの制御はJTAGではなく、Cortex M3でサポートされたSW-DP(Serial Wire Debug Port)をUSB経由で制御しているようです。

Ride7_ide_20090920

無償版のIDEでは、デバッグできるコードサイズが最大32KBという制限があります(コンパイル・リンクは無制限)。この点は購入前から認識していたのですが、ユーザーアプリ32KBが全てデバック対象だと思っていました。マニュアル(STM32-Primer2 User Manual)をよく見ると、32KBにはCircleOSと呼ばれるファームの24KBを含むため、ユーザーアプリとしてデバック可能なサイズは8KBのみになることが分かりました。この点はがっかりです。

追加ライセンスを購入することでコード制限なしのデバッグが可能となりますが、STM32 Primer2 Upgrade for Unlimited Debugging(68ユーロ)の追加購入が必要です。

LPC2xxxサポート

Ride7の新規プロジェクト作成ダイアログを見ると、以下のように"LPC2x"のエントリがあります。

Ride724_newproject

LPC2xはARM7TDMIベースのMCUで、トラ技2009年5月号付録のLPC2388もメニューに現れます。ひょっとして、LPC2388の開発も可能か? JTAGが使えないためデバッグは無理だと思いますが、一度試してみようかと思います。

CircleOS

CircleOSとは、STM32 Primer2のI/O制御・プログラム起動制御を行ってくれるファームェアです。最新のV3.80はサイズが128KBあり結構大きいですが、LCD表示・加速度センサーの情報取得などの基本的なI/O処理ルーチンを提供してくれるため便利と言えば便利です。I/O制御に加えて、MCUのクロック速度変更(リセットなしに反映可能)、バックライト輝度調整、アプリケーション起動などの機能があります。

製品出荷時に書き込んであるCircleOSはバージョンが古いため最新版に更新しました。Ride 7.24.09をインストールした場合は、"[インストールdir]\Ride\lib\ARM\CircleOS"フォルダにある以下のbatファイルを実行することで、最新のV3.80に更新できます。

  • Update_Primer2_Circle_OS.bat: CircleOSのみを更新
  • Restore_Primer2_Circle_Factory.bat: CircleOSの更新に加えて、サンプルアプリをインストール(MP3プレーヤーやゲーム類が多数)

CircleOSを使用した開発

CircleOSを使用した場合、Ride7 IDEで「Primer → STM32_Primer2_CircleOS」を選択すると自動的にCソースコードのフレームワークが生成されます。フレームワーク内の以下の関数にコードを追加することでアプリケーションを作成できます:

1)Application_Ini ( void ):
起動時に一回だけ実行される →初期化コードを実装

2)Application_Handler ( void ):
  周期的に起動される →アプリケーションの処理本体を実装

上記はArduinoのsetup(), loop()関数に相当します。スタートアップルーチンやI/O処理を全部自前でコーディングすればCircleOSなしでも動作が可能です。

Application_HandlerはSystick割り込み周期で呼び出されます。マニュアルによると、72MHz動作時のsystic割り込み周期は3KHzです(0.33ms 間隔)。ただ、実際にApplication_Handlerが呼び出される周期は3KHzより遥かに長いように思えます。Application_Handlerが呼び出される毎にLEDをON/OFFする簡単なコード実行すると、点滅が目に見えます。LEDの点滅周期からは、数百ms周期でしか呼び出しが発生していない感じです。これではリアルタイム性が高い処理ができないため、この点はもう少し調べたいと思います。

STM32 Primer2やCircleOSは回路図やソースコードは公開されていますが、内部構造のハッキング系ドキュメントはほとんどなく、上記のApplication_Handlerの呼び出し周期が遅い点などは自分でソースを読んだりして調べるしかなさそうです。この点はお楽しみということでぼちぼち進めていこうと思います。

Application_Handlerの呼び出し周期(2009/8/21):
Forumで答えを発見しました。Application_Handler call周期 = Systick周期は過去の仕様で、現在は以下のようにsystick / 100になっているとのこと。(マニュアルの修正漏れということなんですね)

設定 Clcok Systic周期 Application handler周期
0 18 MHz 750 Hz 7.5Hz   133 ms
1 24 MHz 1000 Hz 10 Hz   100 ms
2 36 MHz 1500 Hz 15 Hz   66 ms
3 48 MHz 2000 Hz 20 Hz   50 ms
4 72 MHz 3000 Hz 30 Hz   33 ms

systick周期 = clock / 24000
Application handler周期 = systick /100

もう少し調べてからブログに書かねば、、

2009/9/24追記:
デバック制限解除ライセンス(STM32 Primer2 Upgrade for Unlimited Debugging)の記載を修正。

Fedora 11にCellクロス開発環境(SDK 3.1)をインストール

超久々にLinux & Cellの記事を書きます。記事数的には、Cell/LinuxよりArduinoの記事数が多くなっているのですが依然としてベスト3はCell系の記事です。PS3 Linux, Arduinoともニッチな世界だと思うのですが、PS3 Linuxの方がユーザー数が多いのでしょうか。

少し古い数字ですが、2008/12時点でPS3の総出荷台数は2130万台です(日本経済新聞出版の「任天堂”驚き"を生む方程式」より)。国内向けの出荷台数は266万台です。その中で、Linuxをインストールする方は1%以下だと思いますので、国内のPS3 Linuxユーザーは1万人以下といったことろでしょうか。

一方、Arduinoの出荷台数は、2008/12時点で6万ユニットとあります。クローン込みの総出荷台数が10万ユニット、日本のユーザー比率が8%とすると(PS3の日本向け比率と同じと仮定)、日本向けの出荷が8千、ユーザー数で4~6千程度と思われます(一人当たり複数台所有と仮定)。

Fedora 11のインストール

前置きが長くなってしまいました。これまで、Fedora 9を使っていたのですが、PC LinuxをFedora 11に更新しました。Linux上でARMの開発環境を試してみたいと思っており、Linux自体を最新化しようと思ったのがことの始まりです。最終的にはWindowsベースになりそうな気もしますが、GNU/gccやmake toolなどはLinuxの方が親和性が高いように思うためです。

Fedora 11のインストールはいろんなところに解説がありますので説明するまでもないと思います。ただ、1点だけハマった箇所がありました。Nvidia proprietary driverのインストールです。

Fedora 11ではオープンソースのnouveauドライバがデフォルトになっています。別にゲームをするわけではないのですが、nvidia proprietaryドライバに比べるとウインドウの移動など通常の操作でももたついてしまうことがありました。そのため、nvidia proprietaryドライバのインストールをいつもの手順で実行しました。 RPM Fusion のリポジトリを設定して、
# yum install akmod-nvidia
で必要なパッケージをインストールして再起動すると、立ち上がりません、、、
(Ferora 9の時代はkmod-nvidiaを使っていましたが、最近はakmod-nvidiaの方がよいことを今回知りました)

ログを見ると,カーネルは起動しており、X Windowのドライバ初期化のところで止まっています。lsmodすると、nouveauとnvidiaドライバの両方がロードされており、後からロードされたnvidiaドライバがGPUを初期化できずにX Windowが立ち上がらない模様。さらに調べると、以下の設定を追加することでnouveauドライバのロードを抑止できるとあります。

1) /etc/modprobe.confに以下を追加
alias nouveau off

2) /etc/modprobe.d/blacklist.confに以下を追加
   blacklist nouveau

上記の設定を加えても、nouveauがロードされnvidiaドライバと競合してしまいます。他の方のインストール例ではこの設定で動作しているため、最新のドライバ or カーネルで何か変更があったのか? 諦めかけたのですが、initrdを再構築すると問題が解消するというforum discussionを見つけ、こちらを試したところ、ビンゴでした。以下の手順でinitrdを再構築します。

# cd /boot
# mv initrd-2.6.30.5-43.fc11.i586.img  initrd-2.6.30.5-43.fc11.i586.img.bak
# mkinitrd /boot/initrd-2.6.30.5-43.fc11.i586.img 2.6.30.5-43.fc11.i586

initrd-2.6.30.5-43では、initrdの起動イメージの中でnouveauを組み込んでしまうため、blacklist.confを書いても意味がなかったということのようです。1)2)の修正を行ってmkinitrdを行うと、再構築したinitrdからはnouveauが削除され問題が解決します。

2009/11/2追記:
kernelを2.6.30.9-90にアップデートしました。この版数では、nvidiaドライバとnouveauドライバの競合は発生しませんでした。最新版では、問題が解消しているようです。

Cell SDK 3.1のインストール

こちらは、「Cell SDK 3.1のインストール」に示した手順通りで問題なくインストールができました。

Fedoraのリポジトリから以下のspu-binutilsが配信されています。(執筆時点)
spu-binutils          i586          2.19.50.0.1-3.fc11

yum updateで上記パッケージに更新を行うとspeプログラムのコンパイルができなくなりました。そのため、以下の設定を追加して、自動更新を抑止しています。
/etc/yum.conf に以下を追加
exclude=spu-*

EclipseのCell SDK IDEが動くかが懸念点でした。Eclipse/CDTはFedora 11収録パッケージのEclipse 3.4.2とCDT 5.0.2をyumでインストール。JREも同時にインストールされるOpen JDK 1.6を使用。SDK 3.1指定のFerora 9ではCDT4.0を使用しているため互換性の問題が考えられしたが、こちらもOKです。以前最新のCDTを使った際に、新規プロジェクト作成画面にCellプロジェクトが現れない現象があったように記憶しているのですが、下のキャプチャー画面にあるようにOthersの中に隠れていました。

Eclipsecell31

ビルドを行う際に以下のワーニングが出ますが問題なくビルドができています。
****  WARNING: The "ppu-gnu32-debug" Configuration may not build  ****
****  because it uses the "PPU GNU 32 bit Debug Tool Chain"  ****
****  tool-chain that is unsupported on this system.  ****

****  Attempting to build...  ****

「使用するtool-chainが未サポートである」云々を言っていますが、プラットフォームがFedora 9であることをチェックしているだけなのかもしれません。今のところ動作に問題はありません。

Cellプログラムのデバッグ」に示したPS3実機を使ったリモートデバッグも動作しています。

おわりに

Cell SDKはFedora 11であっけなく動作しました。

Nvidiaドライバのトラブルに関しては、Ubuntuのように、nvidia GPUを検出した場合は、積極的にnvidiaドライバをインストールしてくれた方が私にはメリットが高いです。UbuntuだとSunのJava VMもaptパッケージとしてインストールができ便利です。Fedoraはオープンソースしか収録しないというポリシーにこだわりすぎているのではと思うのですが。

実は、Fedora 11をインストールする前に、一度Ubuntu 9.04をインストールしています。Cell SDKもrpmパッケージをdebパッケージに変換することでインストールが出来、サンプルソースのコンパイルやEclipse IDEでのコンパイルは通っていました。唯一PS3を使ったリモートデバッグが動作せず、Fedora 11をインストールした次第です。今思うにPS3側がFedora 9であったためリモートデバッグができなかった可能性があります。短時間の使用でしたがUbuntuの方が使い勝手に好感が持てたため、PS3側とセットで再度Ubuntuに更新してみようかと思っています。

Arduino RSSリーダー

これまでに準備した、GLCDへの漢字表示やRSSサイトのXML解析などのパーツをまとめてRSSリーダーを作りました。最低限の機能しか実装してありませんが、Yahoo天気情報を読み込んで1週間分の天気予報を表示するリーダーです。

ハード構成

自作のGLCDシールドをベースに、RSSの記事選択等に使うタクトスイッチを加えて、以下のハード構成としました。

Glcd_shield3v2_2

スケッチ

ArduinoでXMLを解析する」で使用したNunniMCAX XMLパーサーを使用しました。このライブラリはXMLパーサーとしては非常にシンプル・コンパクトですが、Arduino向けとしてはメモリー使用量が多くATMega328ではSRAM容量が不足してしまい、Arduino Megaが必要となります。今回は、ハードリソース的にもディジタルピンの必要本数が328では足りず、Arduino Megaが必要となっているためよしとしました。

スケッチのソースを以下に示します。
  Weather11pub.zip」をダウンロード

スケッチが起動すると、Yahoo天気情報のRSSサイトにアクセスして今日の天気をGLCDに表示します。対象地域は神奈川県東部(私のすみか)固定です、、

Rssreader

RSS情報の解析

Yahoo天気情報は、以下のソース情報抜粋に示すように、RSS 2.0の形式で配信されます。RSS 2.0はXML文書の一種です。

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
  <channel>
    <title>Yahoo!天気情報 - 東部(横浜)の天気</title>
    <link>http://rd.yahoo.co.jp/rss...............</link>
    <description>Yahoo! JAPANの天気情報に掲載されている最新の情報を提供しています。</description>
    <language>ja</language>
    <copyright>Copyright (C) 2009 Yahoo Japan Corporation. All Rights Reserved.</copyright>
    <lastBuildDate>Sun, 06 Sep 2009 09:51:29 +0900</lastBuildDate>
    <item>
      <title>【 6日(日) 東部(横浜) 】 晴時々曇 - 27℃/22℃ - Yahoo!天気情報</title>
      <link>http://rd.yahoo.co.jp/rss..............</link>
      <description>晴時々曇 - 27℃/22℃</description>
      <pubDate>Sun, 06 Sep 2009 05:00:00 +0900</pubDate>
    </item>
    <item>
      <title>【 7日(月) 東部(横浜) 】 曇時々晴 - 26℃/22℃ - Yahoo!天気情報</title>
      <link>http://rd.yahoo.co.jp/rss..............</link>
      <description>曇時々晴 - 26℃/22℃</description>
      <pubDate>Sun, 06 Sep 2009 05:00:00 +0900</pubDate>
     </item>

       ~ 中略 ~

   </channel>
</rss>

XML情報解析のプログラム部分は、「ArduinoでXMLを解析する」に示したサンプルスケッチと同様です。<item>~</item>タグに囲まれた部分(以後"item"要素と呼びます)が、日毎の天気情報(記事)になります。そのため、"item"要素の開始を見つけた時点で、ItemCount変数をインクリメントし、n番目のitem(デフォルトは1)内にある、"title"要素と"pubDate"要素を抜き取ってGLCDへの表示情報とします。

タクトスイッチを操作することで、翌日・前日の予報に移動します。表示対象日を切り替えた場合はページ全体をリロードして新たな対象日の予報を表示します。item毎の情報をメモリーに保持した方がレスポンスが上がるのですが、現状は手抜きをしています。

RSS 2.0を使用したサイトなら、この方法で記事のタイトル・概要(description)を取り出すことができると思います。RSSには1.0という別の形式がありこちらはフォーマットが全く異なります(RSS 1.0の方が複雑です)。今回は使用していませんが、NunniMCAXにはアトリビュート情報を取り出す機能もあるため、rssタグ(<rss version="2.0">)からversionアトリビュートを取り出して2.0 or 1.0の判定を行うことによって、RSS 2.0と1.0の両方に対応したRSSリーダーを作ることも可能です。

使用したライブラリ

XML解析パーサーとして使用したNunniMCAXとSPI Flash memory(AT45DB161D)ライブラリ以外は、Arduino - Librariesから入手できます。今回のプロジェクト用に変更を行った箇所は以下です:

1) ks0108 GLCD Library
最新のV2をベースに、「Arduinoで漢字表示(4)」で示した漢字表示のコードを追加しています。今回さらに、画面幅を超える長い文字列を表示する際に、自動的に改行を行う機能を追加しました。また、画面の最終行(12ドットフォントの場合、Y座標52~63にかけて)に表示ができない問題を見つけたため修正を盛り込みました。

2) Ethernet Library
WIZ812MJ(W5100搭載モジュール)とAT45DB161D(SPIフラシュメモリー)を同時使用するための変更を実施。

3) String Library
このライブラリも結構メモリーを喰いますが、文字列操作が楽ちんなので使用。メモリーリークバグの修正を盛り込んでいます。

今回使用したライブラリ一式(Arduinoサイトから入手できるライブラリは変更を行ったファイルのみ)を以下に示します。
 「LibraryForWeather11.zip」をダウンロード

余談

ks0108ライブラリの最終行が表示できない問題の解決には結構時間を取られました。GLCD制御レジスタ(ピクセル位置の指定)の操作、書き込むフォントデーターのビット操作が少々複雑で、私の頭の中ではプログラムの動作がイメージし切れませんでした。だいぶ前に、優秀なプログラマーは、部屋数が20位あるお屋敷の総模様替えを頭の中で出来る人、即ちプログラムの実行ステップに従って刻々と変化する変数やハードの状態を頭の中で追える人だとありましたが、その通りだと思いました。

EclipseやVisualStudioではビジュアルなデバック機能に助けられるのですが(上記の状態変化を追いかける仕事の多くを実行・補助してくれる)、Arduinoのデバック環境が貧弱な点も苦戦要素の一つでした(言い訳ですが)。 昔ならもう少し脳内トレースもできたと思うのですが、歳のせいもありそうです。

今回見つけたks0108の問題の修正イメージをArduino Forumにアップしたところ、ライブラリの作者さんから速攻でより美しい修正イメージが提示されました。悩むよりさっさとバグレポートした方が早かったような、、

2010/3/28更新:
WIZ812MJのSCKピン番号を誤記修正

« 2009年8月 | トップページ | 2009年10月 »

2018年10月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
無料ブログはココログ