PC用の新たなインターフェースとしても Kinect をプッシュするマイクロソフトが、
PC用の新Kinect ハードウェアを発売することを明らかにしました。
新 Kinect はハードウェアおよびファームウェアをPCでの使用に最適化した製品。
奥行きセンサーから40cmの近距離から認識でき、50cmならば
高精度の読みとりが可能な ” Near Mode ” を備え、デスク上などで使う
「クロースアップ」アプリに対応します。

これをタブレットにつなげて使えれば、エアキーボードが可能になる！かも！
前後の入力文字を賢く判断してくれれば、物理キーボードよりもむしろ入力早くなったりして。

マウスジェスチャーのようにジェスチャーと組み合わせて使用すれば、あんなことやこんなことも・・・
なぜか入力インターフェース系には異常に夢が広がります！！

Windows 8とMac OS Lion、時代は「マウス」を遺物とする?!
個人的には「マウスは死んだ」と思っている。むろん、まだ死に絶えてはいない。しかし歴史は既に動き出していると思うのだ。

 
新インターフェースとして、マウスからタッチへと移行が本格化しつつあります。
以前「（1） PC3.0を予想してみた：キーボードとマウスに変わるもの」でも書いたように、キーボード＆マウスというオジサン世代（数十年後にはおじいさん世代）のツールは少しずつ無くなっていくのではないでしょうか。

上の記事を書いたときには、まだ自分でタッチパネルを使っていなかったのですが、いざEee Topを購入してタッチ操作を楽しんでみて分かったのは、据え置き型コンピュータのパネルをタッチするのは疲れるということです。
腕を常に上げ続けないといけない！

2009年当時欲しかったのはまさにiPadそのもの（タッチパネル式のタブレット）で、iSlateという名前で出る出ると噂され続けながらも結局Appleが出してくれず、仕方なくEee Topを買っちゃったという経緯があります。

その体験がchromeTouchというソフトウェアを作るきっかけにもなったのですが、タブレットではない据え置き型パソコンでは、Appleのマジックマウスのようなマウス＋タッチが最良解のようです。

今後はタッチパネル式のタブレットか、据え置き型コンピュータ＋マジックマウスの2択という流れになりそうですが、いずれの場合にも2つの問題が残っています。

それは、

1. 指がマウスカーソルほど尖っていないので、細かい部分をピンポイントでクリックできない
2. マウスオーバー（クリックしていないけどカーソルは動かしている）が表現出来ていない

という2点です。

問題1に関しては、iPhoneやiPadを使っている人は、ズーム機能によって解決できているのでしょうが、どうもそれが面倒に感じてしまうのです。
そもそも操作に時間がかかるし、操作している姿も何だか艶かしすぎるといいますか・・・

指に専用のキャップみたいのをつけるのも実はあり？

あほかと言われそうですが、意外にアスクルのカタログなんかにもいつか登場するかもですよ。
ネーミングは「Digit Cap」とか。

問題2は、MicrosoftのKinectの小型版みたいのをタブレットかマジックマウス様のものに搭載して、指を近づけるとカーソルっぽいのが画面に出現して、マウスオーバーを再現してくれる・・・というのが私の理想です。
指を触れないと操作できないという壁は、2012年くらいにはさっさととっぱらって欲しい！

とにもかくにも、Windows8とMac OS Lionによってぐいっと一歩その未来に近づいたわけですので、次のステップは本当にもう間近に迫っていると感じています。

なんだこれ、と思いこれまでのバックアップファイルを確認してみたら、突然ファイルサイズが倍になっているタイミングが何度かありました。

ぐぐってみると、「高速保存のチェックを外す（→もともとチェックされていなかった）」、「版の管理でバックアップが残っているのを消す（→何もバックアップされてない）」などありましたが、解消できませんでした。

そこで、

1. Wordファイルを新規に開き、
2. 問題のWordファイルを「全て選択（Ctrl-A）」してコピー、
3. それを新規Wordに貼りつけすると、

文書の縦横やマージンを含めてきちんと元の文書を保っています。
で、それを保存すると、360KB・・・。20分の一以下になってしまいましたことよ。
インデントなどがずれるところもありましたが、そこは手で修正しました。

というわけで、Wordファイルが重くなったら、新規ドキュメントに貼り付けましょう。

• このドキュメントについて
• Webプログラミング史
  • 黎明期（～1999年）
  • 検索エンジンシステム大流行の巻（2000年～2002年）
  • サーバーサイド・プログラミング大流行の巻（2003年～2004年）
  • サーバーサイド・プログラミング洗練期（2004年～2005年）
  • Ajaxの台頭（2005年～2006年）
  • Webの進化が止まった？（2007年～2008年）
  • つぶやきを中心に世界が回る（2009年～2011年）
• 過去Webの歩き方
  • 発行・更新年を意識した検索方法
  • Q&Aサイトは比較参考程度に
• 著者略歴

このドキュメントについて ↑

Webプログラミングの歴史はせいぜい10数年と浅く、古くはPerlを使ったCGIやJavaアプレット、最近ではHTML5やスマートフォン向けのアプリ開発などに話題が集まっています。
Webの進化の歴史は、2000年ごろに検索サービスを開始したGoogle検索の歴史とも重なるため、キーワード検索を使って過去の文献を探すこともできますが、時系列に沿ってWebの進化をまとめた資料というものは意外に多くありません。
そこで、1999年ごろからWeb開発に興味を持ち続けている当事者の観点からWeb開発の歴史を残しておくことは、多少なりとも意味のある試みと思い、この度「Webプログラミング史」としてまとめることにしました。

Webプログラミング史 ↑

黎明期（～1999年） ↑

私自身がWebプログラミングをはじめた1999年より以前については、正直多くを語ることができませんが、Perlを使ったCGI（アクセスカウンタ、掲示板）や、JavaScriptを使ったページのにぎやかし程度だったように思います。

当時はWebプログラミングよりは、OSインストール型のソフトウェアがほとんどで、お気に入りのソフトをインストールしては、ローカルPC上で利用するという考え方が一般的でした。

開発環境や実行環境も整備されていなかったため、数多くのバッドノウハウが生まれ、Perl職人、JavaScript職人といったある種の特殊技能として見られることが多い時期でした。

検索エンジンシステム大流行の巻（2000年～2002年） ↑

Google以前はどうやって情報を検索していたのでしょうか。

コンピュータを2000年以降に使い始めた方には考えられないかもしれませんが、Google登場以前は、「キーワード検索」という概念が実質ありませんでした。
現在でいうアルファブロガーのような方たちが、有用なサイトのURLを集めて、リンク集を作成し、そこからツリー上にたどっていく方法が一般的でした。
Yahoo!はそこに商機を見出し、各Webサイトオーナーに有料でリンクを販売し、カテゴリ別にあらゆるサイトへのリンク集を用意することで、一大ポータルサイトの座を獲得するにいたりました

キーワード検索機能を提供するWebサービスもあるにはありましたが、精度は低く、対象サイトも少なく、一回の検索に5～10秒近くかかるような代物だったため、一般的なサービスとしては認識されていませんでした。

Googleが登場したのは、まさにそんな状況だったのです。
あらゆる情報をコンマ数秒で表示してくれるGoogleに世界は熱狂し、検索エンジンブームが到来。猫も杓子も検索エンジンを作成する時期が続きます。
コンピュータ雑誌では検索エンジンの作り方を特集し、特に日本ではNamazu（当時最先端の日本語全文検索システム）を使えないとモグリ的な風潮が広まりました。

サーバーサイド・プログラミング大流行の巻（2003年～2004年） ↑

このころには、動的なコンテンツを表示するためのWeb用言語として、PHP、Perl、Java Servletが出揃い、それぞれが猛烈な勢いで進化していきました。

PerlではCPANサイトの利用が活発化し、PHPはユーザープログラマの要望にこたえてありとあらゆる機能が組み込み関数化され、Java Servletではデザインパターンを駆使した開発スタイルが大流行しました。

それらの開発言語とは別に、データ構造としてのXMLや、分析・設計言語のUML、HTMLにデザインを適用するCSSなど、関連技術が毎月のように登場し、発展し続けたため、開発関係者はとにかく勉強しまくって、エンジニア30代限界説などがまことしやかにささやかされ始めたのもこのころです。

サーバーサイド・プログラミング洗練期（2004年～2005年） ↑

開発言語としてRuby on Railsの採用が増え始め、PHPはPearやZend Frameworkといったフレームワークの利用が一般的になり、データベースへのアクセスはO/Rマッピングで行うといった、一から全部を作らず、これまで培われてきた技術や方法論を集約し、誰でも同じようにコーディングするような開発スタイルが定着してきました。

Javaの開発においても、アスペクト指向やDI（依存性の注入）という画期的な「発明」により、これまでに蓄積されたServlet開発の問題点を一掃することに成功しました。

Web開発の未来としては、プログラミングの自動化やメタ言語・メタメタ言語による設計など、より抽象的な方向に進むかのように思われていました。

Ajaxの台頭（2005年～2006年） ↑

2000年にWebの世界を一変させたGoogleが、今度はWebの進化の方向を、誰も考えていなかった分野へ切り替えてしまいました。
それが、Googleマップのリリースです。

Googleマップのリリース日以降、開発者たちは新種の珍獣でも見つけたかのように、GoogleマップのHTMLソースを調べまくりました。
そこにFlashのswfファイルが読み込まれておらず、JavaScriptによって作られていることを発見してからは、オンライン・オフラインを問わずいたるところでGoogleマップ勉強会が催され、「Ajax」という用語が作られてからはすさまじい勢いで関連サービスが生まれました。

JavaScriptは90年代からJavaScript職人によって利用されていたものの、ブラウザ間の仕様の不統一がたたって、ほとんど黙殺され続けてきた不遇の言語ですが、Googleマップ以降は2011年現在にいたるまで、重要言語としての地位を保ち続けています。
ただ、ブラウザ間のJavaScriptエンジンの実装の差異は大きく、統一的にコーディングを行うためのフレームワークの登場が望まれ続け、この時期開発されたPrototype.jsが最初のデファクトスタンダードとなりました。

Web2.0という用語が新聞に載り始めたのもこのころで、新たな商機を見出した企業が作って作って作りまくりました。

Webの進化が止まった？（2007年～2008年） ↑

Web2.0という用語が大衆化し、サーバーサイド・プログラムの画期的な進化も現れず、クライアント・プログラム用のライブラリとしてはPrototype.jsに代わってjQueryの一人勝ちが見え始めてきたこのころ、「もう新しいWebサービスは生まれないのではないか」という問いかけがちらほらと聞かれるようになりました。

ゼロベースから新サービスを立ち上げるのではなく、GoogleやAmazonなどが提供するAPIを呼び出して、それらのAPIから受け取った情報を組み合わせたマッシュアップサービスこそが新しいWeb開発のスタイルかのように喧伝されました。
Web開発者も、APIが生まれるたびに使い方を学ぶ羽目になるという状況が続きました。

クラウドという用語が生まれたのもこの時期で、Web開発そのものがブラックボックス化している様子をうまく表していると感じられました。

つぶやきを中心に世界が回る（2009年～2011年） ↑

2006年にサービスが開始したTwitterの可能性を、マッシュアップに明け暮れていた企業は見逃し続けていましたが、「ツイート」の魔力は2009年ごろにはもう抵抗できないくらいの勢いになっていました。

世界中のありとあらゆる情報が140文字のトークンとなり、すべてTwitterというブラックホールに吸い込まれていきました。
その影響もあってか、ブログなどでのまとまった形のコンテンツが相対的に減少したように、個人的には感じています。

さらに、TwitterやiPhoneの登場に呼応して、Webアプリという市場が形成され始めました。
Apple社のApp Storeという名称には、商標登録無効を訴える騒ぎが持ち上がるほどに、「アプリ」というキーワードがWeb開発のトレンドになっています。

これまではスケーラビリティー（拡張性、発展性）というキーワードの元に拡大・発展を続けてきたWebが、Twitterやアプリなどのように縮小を始めてきているのは何を示しているのでしょう。
これは未来になってみないと誰にも分からない問いなのかもしれません。

to be continued..

過去Webの歩き方 ↑

発行・更新年を意識した検索方法 ↑

この文書で見てきたように、Webの開発は二順も三順もしています。
2005年くらいまではキーワードだけによる検索も有効でしたが、サーバーサイド開発が盛り上がった2005年以前の情報は玉石混淆で、本当に現在使うべき方法を見つけることはなかなか難しいものです（クライアントサイド開発に関しては現在がその状況です）。

たとえば、Javaのプログラムでユーザーが入力した文字列の空白チェックをしたいと思います。
検索キーワード「java 空白 チェック」でGoogle検索すると、検索結果の1ページ目に出てくるのは、現在では不適切な情報ばかりだったりします。

代わりに、「java 空白 チェック 2011」と西暦を指定して検索すると、1ページ目の最初の10件のうち、3～4件は有用な情報を見つけることができるようになります。

西暦指定をしても、過去の情報が出てくる場合がありますので、かならずいつ書かれたドキュメントなのかを意識して参考にすることが肝心です。

Q&Aサイトは比較参考程度に ↑

こと開発に関する情報ソースとして、Q&Aサイトで解決できることは稀です。
プロフェッショナルの回答者は少なく、「ググってコピペ」タイプの方が多いため、古い情報を転載していることが非常に多いためです。

アメリカでは専門家がアンサーしてくれるQuoraというWebサービスが2010年にに開始しましたが、上記のような問題を解決しうるのか注目されています。

著者略歴 ↑

smilkobuta
プログラミング大好きな九州男児。

最初に作ったプログラムは時間計算プログラム。自作音楽テープを作る際、A面・B面に無駄なく曲を詰め込むために作成した。
開発環境は、父のワープロにおまけでついていた表計算ソフト。

幼いころからの夢であったフランス料理のコックを目指して、調理師専門学校卒業後に渡仏。
その後、製菓の勉強のため上京するも、PCの楽しさに目覚めてSEに転身。

いろいろあって今にいたる。

—-
Error in query [select u.* from users u where u.alias='guest' and (u.userid div 100000000000000) in (0) ] [You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'div 100000000000000) in (0)' at line 1]
—-

こんな感じ。
うんざりしながらもパッチを作りましたので、ログインできなくてうんざりしている人はお試しください。

—-
$ diff -ubB /usr/share/zabbix/include/db.inc.php.20110218 /usr/share/zabbix/include/db.inc.php
— /usr/share/zabbix/include/db.inc.php.20110218 2011-01-04 01:11:03.000000000 +0900
+++ /usr/share/zabbix/include/db.inc.php 2011-02-18 17:41:16.590757194 +0900
@@ -518,7 +518,7 @@
switch($DB_TYPE)
{
case “MYSQL”:
- $result = ‘(‘.$id_name.’ div 100000000000000)’;
+ $result = ’round(‘.$id_name.’ / 100000000000000)’;
break;
case “ORACLE”:
$result = ’round(‘.$id_name.’/100000000000000)’;
—-

先日購入したケースをパートナーに見せびらかしていたら、丸い窓ではなく後ろの四角い窓を正面にしたほうがいいのではないかと言われました。

こっちが丸窓

これが四角い窓。購入したLCD（WBX280V009）にぴったしサイズ。

うーん。確かに四角いほうがLCDを無駄なく使えるんだけどなあ。
でもドラゴンレーダーのあの形が頭にあるものだから、やっぱり丸窓がいいんだよなあ。

「丸い窓から基板とか見えているとかっこいいじゃない。」
な、なるほど。
確かにこの丸いところからArduino Duemilanoveの例の青基板が見えていたら、知らない人が見たら感心してくれるかも・・・
ということで、丸窓ではなく四角い窓を正面にすることにしました。

完成イメージ

（***）13.2 必要パーツの購入

というわけで、配線をきれいにするためのパーツを購入しました。

L字型のピンヘッダーの存在をたまたま知ったのですが、これがあればArduinoの勇姿を基板で隠すことなく見せつけられそうだ！と思い購入しました。
それで、秋月電子さんから即効で送られてきたので、居ても立ってもいられずにハンダ作業開始！
完成イメージは次のとおりです。

ある意味この図が設計書

（***）13.3 いざハンダゴテ

要となるユニバーサル基板と短く切ったビニール線との死闘が始まったわけですが、LCDとArduinoを背中合わせにしたせいか、8ピンの順番が逆になってしまい、さらにL字ソケットをつなげているため何がどうつながらないといけないのか大混乱してしまいました。

ようやく出来上がったのがこれ↓

ジャーン

これ動きそうにないだろ・・・だって？？
ふふっ、あんたいい勘してるぜ・・・

LCDにつなげるまでもなく、テスターで導通確認をしたところ12本中4本しかつながっていませんでした（T T）。
つながっていたかと思ったらショートしている（つながってはいけないところが接触してしまっている）箇所もあったりして・・・

半日かけてこの有様ですが、買ったはいいけど使い方が分からなかったテスターの使い方がわかったので、それで良しとしよう。

デジタルマルチメータ ＭＡＳ－８３０Ｌ　マニュアルレンジ

以前購入したのがこのテスターです（デジタルマルチメータ ＭＡＳ－８３０Ｌ　マニュアルレンジ）。
アナログのテスターが使いやすいと本で見ていたのですが、購入時にあいにく品切れだったため、安かったこいつを買いました（1,000円）。
届いてみたら超かわいい！
真っ黄色のラバーケースに包まれていて、これだけでおもちゃみたいです。案の定2歳の息子がおもちゃ替わりにしていたりします。

上の写真のレバー位置が導通確認のポジションで、この状態でつながっているかどうか確認したい部分の両端をテスターに接続した赤／青の測定リードでつつくと、導通時には「ピー」という音がします（画面には抵抗値も表示されます）。
他のポジションは今のところ理解していませんが、この導通ポジションに関しては完全に理解しましたよ！

さて作り直しなわけですが、ピンソケット（黒い穴が開いているやつ）はべったりハンダ付けしてしまったし、ビニール線も扱いにくいし、一からつくり直そうと近所のパーツショップに自転車を飛ばします。
・・・と付いてみたらなぜか休み∑（゜ε゜！！坂道きついのに・・・
仕方ないのでうちに帰って、失敗作からハンダを吸い取り線で一個ずつ吸い取って再チャレンジすることにしました。

基板作成ver.2。LCD側です。

・・・どう思われるかはわかりませんが、自分の中では最高最善の出来です。
作り上げたあとはうっとりと眺めこんでしまいました。

こっちがArduino接続側

基板のLCD側にピン接続するケーブルを這わせ、Arduino側に3.3V（プラス極。赤いリード線につながっているの）とGND（マイナス極。基板上の錫メッキ線）を這わせました。
ああ、うっとり・・・

自分で基板上のホールの穴の数を数えたり、糸ノコで基板を小さく加工したり、ホールの位置とピンヘッダーの位置を検討したりと、初めて機械いじりらしいことができて、かつ完成できたことがこんなに嬉しいとは・・・

LCDにつなげたところ

さらにArduinoにつなげたところ

そしてケースに入れたところ・・・！

パートナーのイメージ通り、後ろの丸窓からArduinoのかわいい姿が。

この後、接触不良を直したり、つけ忘れていたプルダウン用の抵抗を付けたりしたのですが、概ねスムーズに作業が完了しました。
それもこれも全てテスターのおかげです。
基盤づくりをこれから始める人は、絶対にテスターが必須ですので、ハンダごてと一緒に買い揃えましょう！

そしてこれが、実際に動かしたところです。

ケースに全部収まって、チャックの間からUSBケーブルをちょろっと出すことができるので、すごく取り回しがいいです。
出来たぞー！！

LCDを自由自在（？）に使いこなせることが分かったので、早速画面のデザインをしようと思ったのですが、LCDでの色表現ってHTMLでいう「#FFFFFF（白色）」みたいな表記ではないことに改めて気づきました。

FFFFFFはすなわち24ビットカラーですが、ILI9325などのLCDで色を指定する場合は16bitで指定する必要があります。
白色は0xffffですし、青色は0x001fといった感じです。

そういう色見本みたいのがどこかに転がってるんだろうと、軽～く考えて検索してみたのですが、なぜか見つからない！？
拾ったライブラリなどでは「#define ORANGE 0xFC00」みたいに定数定義していたりします。

それじゃあということで、色見本ページを作りました。
カラーピッカーも作りましたので、欲しい色の16bitカラーが確認できると思います。

16bit Color Picker & Color List

・・・それとも、本当はみんな違う方法で色指定しているんでしょうか？？
う～ん、不明だ。

LCD操作の目処が立ったので、あとはGPSとコンパスモジュール・・・と思っていたのですが、そういえば今回買ったLCDってタッチパネルが付いてるんですよね。
せっかく付いているんだから試してみたい！

・・・と思ったのですが、Arduinoのピン数が足りなくなりそう。

LCD接続のためにすでに12本のピンが使用済みで、残るピン数は8本。
改めてタッチパネルの使用ピン数を確認してみたところ、なんと5本（x1, x2, y1, y2, タッチ状態チェック）。
ということは、LCDとタッチパネルをつなげただけで17本のピンを消費してしまい、残るピンはたったの3本だけになってしまうぅ。。

ドラゴンレーダーには、少なくともコンパスモジュールとGPSモジュールが必要なのですが、これらには何本必要なんだろ。

まずコンパスモジュールはこれ、HMC6352搭載デジタルコンパスモジュール
マニュアルによると・・・2本必要。

GPSモジュールはこれ、SparkFun Electronicsの32 Channel LS20031 GPS 5Hz Receiver。
これも2本必要だと・・

てことは、ピンが1本足りない！！
どれかいらなそうなの無いかなあと本気で探してみましたが、もちろんそんな無駄ピンは使ってない。

（***） 11.2 タッチパネル諦めてボタンにするか、もしくは・・・

そもそもタッチパネルを何に使うのかといいますと、ドラゴンレーダーのユーザー機能としては、縮尺を変えることができないといけないし、管理機能（ドラゴンボール＝お宝の位置座標を登録する）にも色々画面操作できないといけないので、そういったユーザーインターフェースで使おうと思っていたのです。

これが使えないとなると、ボタン？みたいのでやるしか無いかあ。。
まあボタンも機械っぽくていいかなあ。

それとも、3軸加速度センサーをつけて、Wiiみたいなインターフェースを実現するとか！
う～ん・・技術力がついていけなさそうだ・・
でも、傾けるとカーソルが動くようなインターフェースも面白いかもなあ・・・。

とにかく！残る8本－GPSの2本－コンパスの2本＝残る4本でユーザーインターフェースをつくんないと。
ああ・・・タッチパネルが4本でよかったらなあ・・・（←しつこい）

前回の記事からさらに一ヶ月経ってしまいました。
その間何をしていたかと言いますと、来る10月31日にサービス終了してしまうBloglinesの代替サービスを作っていました。
それについてはまた後ほどアナウンスするとして、ようやくその代替サービスの開発が一段落したので、まだドラゴンレーダー作りを再開です。

前回、ようやくLCDとArduinoがつながったところまで進めていたので、もう少しLCDの使い込みをすることにします。
ここから先はソフトウェアの領域なので、ハンダゴテを握らなくて済むのが楽だー。

画像出力のサンプルコードを以前拾っていたので、それを動かしてみました。

楽勝楽勝♪
これまでのハードウェアで難儀したのが嘘のように、あっさり動作しました。

（***） 10.2 描画速度が3倍に！

画像の出力は出来ましたが、何だか描画が遅いかなあ・・・
テケテケ～と表示されるのは、作った本人は楽しいものですが、人が見たら遅いと思うだろうなあ。

サンプルコードとは別のライブラリコードを見ていたところ、何だか電子工作室 – 2.4/2.8インチ QVGA液晶表示器の制御で公開されているライブラリコードのほうがすっきり書かれていることに気がつきました。

ということで、電子工作室のライブラリを頑張って移植してみました！

例えば↓これ。

変更前
void LCD_Writ_Bus(char VH,char VL)  
{  
  unsigned char i,temp,data;
  data=VH;
  for(i=0;i<8;i++)
  {
    temp=(data&0x01);
    if(temp)
      digitalWrite(i,HIGH);
    else
      digitalWrite(i,LOW);
    data=data>>1;
  }
  digitalWrite(LCD_WR,LOW);
  digitalWrite(LCD_WR,HIGH);
  data=VL;
  for(i=0;i<8;i++)
  {
    temp=(data&0x01);
    if(temp)
      digitalWrite(i,HIGH);
    else
      digitalWrite(i,LOW);
    data=data>>1;
  }
  digitalWrite(LCD_WR,LOW);
  digitalWrite(LCD_WR,HIGH);
}

変更後。こんなにすっきり
void LCD_Write_Bus(char VH,char VL)
{
    // 上位バイト出力
    PORTD = (VH & 0xFF);
    digitalWrite(LCD_WR,LOW);
    digitalWrite(LCD_WR,HIGH);

    // 下位バイト出力
    PORTD = (VL & 0xFF);
    digitalWrite(LCD_WR,LOW);
    digitalWrite(LCD_WR,HIGH);
}

データの出力を行うD0～D7の8ピンに対して、元のソースでは何度もdigitalWrite関数を呼び出していたのですが、新コードではPORTD（Arduinoのポート操作用のキーワード）を使ってすっきり簡潔になりました。

この変更により、ものすごく描画速度が早くなった！
これぞ8bitアクセスの醍醐味！（？）

この移植作業を行ったおかげで、Arduinoのコーディング方法がだいぶ理解できてきた～。

（***） 10.3 文字も表示できた！

移植した電子工作室のライブラリには文字表示の関数も用意されていたので、それを使って文字表示できることを確認しました。

↑ちょっと見えづらいですが、カタカナや一部の漢字もきれいに表示出来ています。
ありがたや～

それと、改めてLCD（ILI9325）のリファレンスを読み直していると、縦表示と横表示の切り替えができることがわかりました。
今回作るドラゴンレーダーでは横表示の方が都合が良いので、横表示に変えてみました。

変更したのはLCD_Init関数の中の下記の箇所です。

LCD_Out(0×0003, 0×1028); → LCD_Out(0×0003, 0×1018);

リファレンスに詳しく（英語で）書かれていますので、必要な方はリファレンスのp.55～56（8.2.5. LCD Driving Wave Control (R02h）をご参照ください。

（***） 10.4 ケース発見！

そして、今日一番の出来事ですが、ドラゴンレーダーを収めるのにぴったりなケースをGeogesで見つけてしまいました！

ドラゴンレーダー用のケース。本当は写真入れです。

以前から「惜しい」ケースをGeogesで見つけていたのですが、こんなにぴったりのが売られているなんて・・・・
写真ケースにはむしろ微妙なデザインですが（おい）、ドラゴンレーダーを収めるには本当にサイズぴったりで、見つけたときは自分のために作ってくれたとしか思えませんでした。
ありがとうGeoges！！

周りがチャックになっていて、ぱかっと開く。しかも中はふわふわ。

丸い穴部分が少し大きいので、ボール紙でマスキング。改良の余地あり。

後ろにも窓が付いていて、これがなんとILI9325と超ぴったり！もはやILI9325のために作ったとしか思えない。

今は配線をブレッドボードで行っているのでごちゃごちゃしていますが、ユニバーサル基盤できれいに作り直したら早速はめてみます。
楽しみだ～

（***） 10.5 本日までの報告書

本日版の最終ソースです。
移植した電子工作室のライブラリも含まれていますので、良かったら使ってください。

あと、PORTDを使うために少し配線も見直しました。

前回のエントリーからなんと1ヶ月くらい経ってしまいました。
その間帰省をしていたり、仕事が忙しくなったということもあるのですが、なんといってもLCDが動かないのでブログも書きようがないという状況です。

この1ヶ月間何をしていたかというと、とにかく知識をつけるために電子工作の本を読みまくっていました。
図書館に行って理解できそうな本を取り上げてはざっと読んでみて、ためになりそうな本は借りてきて・・・を繰り返し、その都度分かったことをドラゴンレーダーに適用しては失敗してという感じです。

その中でも一番勉強になったのは次の本です。

★ 作る・できる/基礎入門 電子工作の素 [単行本]

各ページの横に電子工作についての基礎知識がふんだんに書かれており、これまでどの本を読んでも書いていなかった電子工作の「常識」が少しずつ理解できるようになってきました。
もう図書館に返却してしまいましたが、この本は自分でも一冊買おうと思っています。

↑に挙げた本やその他の本で知った、今回のLCDトラブルに関係ありそうな知識として、次のようなものがありました。

以上の知識を踏まえて色々と模索した結果、前回Arduinoを3.3V化したつもりが、どうもこれが上手くいっていないのではないかと。
購入したLCDの動作電圧は「2.6～3.5V」となっており、Arduino Duemilanoveそのままの5Vでは動いてくれません。

LCDと悪戦苦闘しているときにLCDから突然「ブーン」という小さな唸り音が聞こえてきたことがありました。
何をやってもうんともすんとも言ってくれなかったので、ちょっとでも反応があって喜んでいたのですが（バカ）、後から得た知識からするとどうも5Vを流してしまって規定の動作電圧を超えた電圧を流していたのではないかと思われます。

その後妥協の電子工作：4線式抵抗膜方式タッチパネル付きLCDパネルの試用に書かれてあった

ちなみに「WBX280V009」でも同様の方法で8ビット化できますが、この場合は、11番端子をVCC（6番)に接続しないと8ビットモードでは動作しません。

妥協の電子工作に書かれていた8bit化のための処置

を行い、プルダウン抵抗を取り付けた後、3.3VにしたときだけArduino本体についているLEDが点滅しなくなったことに気がつきました。
5Vに設定したときだけLEDが点滅するので、3.3V化に失敗しているのかなと。

前回行ったのは次の写真の作業。

だめだめ3.3V化

それで今回行ったのはパターンカットのやり直しと（ちゃんと切れていなかったようなので、もう一回やり直してみたら、明らかに線が残っていた・・・）、次の写真の箇所のはんだ付け。
一つ前の写真で「ここはどこともつながっていない」と書かれているところ。

3端子レギュレータの「IN」とおぼしき場所をつなげた

もともと三端子レギュレータの「OUT」しかつなげてなかったので、電流が流れるはずがない。。とは思っていたものの、どう見てもこの場所は無関係な出っ張りだろうと思い、無視していました。
反対側の「IN」とつながっているのかなあというのが今の理解。

（***） 9.2 LCDの現状

たった今さっき三端子レギュレータのハンダ付けを行ったところで、物は試しとPCとUSB接続したところ、なっなんと、LCDが光った！！光ったよ～っっっ！！！

LCDとごちゃごちゃ配線

LCD側についていた「LEDA」というソケットとArduinoの5Vをつなげていたのですが、「LEDK1」～「LEDK4」をGNDにつなげるようにしたところ、突然LCDが真っ白く輝いてくれました！！！
ふぎゃーーっっ

LCDもArduinoも壊れていなかったんだ～。
心底ほっとしましたよ！

（***） 9.3 ・・・と思ったら、今LCDが動いた！色が出た！！

ここまでブログを書いてきてあれっと思ったのですが、なぜかLEDAを5Vにつなげていました。
なんでだっけと思いだしていたところ、ITDB02-2.4 8Bit Mode Demoに書かれている接続方法を真似たことを思い出しました。

それでもう一度このページを見なおしたところ、なんと！LEDAは3.3Vって書いてあるぞ？色々やっているうちに接続を間違えてしまっていたようです。
でも動いていたしなあと思いながらも、LEDAを3.3Vにつなげ直したところ、さっきよりも明るさが減ったような感じ・・・
と見ていたら、夢にまで見た綺麗なブルーが我がLCDに写っているではありませんか！
ま、マジですか？！

勢いでYoutubeに動画をアップしてしまった。

一番の難関をやっとこさ越えたぞ～～～～～っっっっっ！！！

（***） 9.4 ここまでのまとめ！

ということで、いったん現在のドラゴンレーダーの配線についてまとめて置きます。

それでこっちがスケッチ（Arduinoのソース）。
あちこちのサンプルソースをツギハギしているので、元ソースがどこだったのか思い出せませんが・・・

（***） 9.5 今日までの報告書

ブックマークしたページ

次は文字表示だ！