最近は、第三世代の電話機として開発される方が増えてきてQuad社のチップ以外に色々とMMなチップを付加されるケースが出てきている。こうしたセカンドプロセッサを取りつけると相互に通信するインタフェースが必要になる。Quad社のモデムチップとしての使われ方として通信プロトコルのみに利用するという考え方でアプリケーションソフトを別チップで動作させるという構成もあれば、特定の専用アプリケーションのみが動作する専用チップに対してデータのやり取りのみをさせるという構成もある。最近の流行りは画像処理プロセッサの搭載である。

データ通信をモデムとして捉えている限りにおいては、シリアルケーブルでPCと接続するという形での利用がQuad社で評価しているモデルでもある。日本のi-MODEやEz-Webという形で端末自身がWebBrowserを持ったりMail-Clientを搭載したりというモデルとは全く事例が違うように映るかもしれない。アプリケーションとのインタフェースが同一CPUとの共有メモリなのか外部プロセッサとのインタフェースなのかという違いでしかない。アプリケーションが必要とするCPU処理量などのバランスとを考えていくのはシステム設計の問題である。

携帯機器のシステム設計ではこうした外部機器との伝送の為に短絡的にDMAを望む声が多いようだ。アプリケーションが重いということからだろうか。かつての8ビットマイコンの雄であったZ80の普及にはDMAが有ったことが考えられている。二十年ほど前にデータベースの照会端末システムを開発した際に、分散処理する端末とデータベースエンジンをシリアルネットワークで接続するという構成をとった。イーサネット以前の時代でもありネットワークの核はIEEE488である。複数のCPUボードで分散処理を実施してトランザクションベースでデータ照会や印字業務、無線システムへの電文制御などを行っていた。今でいうPCのような端末をZ80ベースにカラーグラフィックスチップを接続して漢字画面を作り出すという暴挙を実施していたのだが・・・。

まだ漢字の扱えるPCなどが登場し始めたばかりの頃であり、専用端末として利用できるような物はなかった。カラー漢字表示・ソフトメニューキーというコンセプトで開発した端末照会システム自体はアセンブラで開発されて電子交換機開発で得ていたノウハウなどを集約して市販品として使える様々なチップセットを利用して構成していた。高速処理の為には、シリアル伝送のインタフェースであるRS-232Cの規格自体がネックになり代わりに光ファイバーを利用してチップセットで捌けそうな76.8kbpsのシリアル速度にして利用するという変な仕様になっていた。当時のRS232Cのドライバの伝送速度は19.2Kbpsまでしか対応出来ないという時代であったのだ。

IEEE488の分散ネットバスに接続された４回線収容のシリアルコントローラは電文ネットワークをポーリングによるプロトコルでラウンドロビン制御で行うことにしていた。しかし、アプリケーションデバッグに導入したスーパーカーよりも高い最新鋭のプロトコルアナライザは72Kbpsまでしか対応出来なかったのである。デバッグ途上では38.4Kbpsで行いシステムテスト段階くらいから76.8Kbpsに切り替えていくという選択が必要だった。実際に開発が完了してNECの中型マシンからZ80分散システムへのリプレースに成功した。しかし、納入案件が進んでいくと光トランシーバーが1Mbps程度を対象にしていたのに反してあまりにも低速な使い方だったために不安定になるという不具合や実際に導入したお客様の利用環境の手荒さなどからファイバーが切れてしまうという問題が起こってしまったのである。無論コストダウン要請もあったのは言うまでもない。

こうした問題やコストダウンを考えていくとシリアルインタフェースをRS232Cベースにして、グラフィックスではなく漢字ベースのキャラクタ表示端末にするという追加の開発を進めた。４回線収容基板のソフト変更をしていくと高速ポーリング制御によるレスポンス時間のばらつきよりもいつも同等な反応が得られる平行同時処理制御に代えたほうが良いという判断になり色々試行錯誤したがZ80の2MHzベースの環境では4800bpsの４回線制御がアセンブラベースでも限界であるということが判ってきた。76.8kbpsの光接続から銅線ベースの38.4Kbpsにしたのだが結局4800bpsの割り込み制御だけにしてしまった。無論IEEE488バスにはDMAが利用されているのだが・・・。お客様の評判は平均処理時間が遅くなった物の安定した反応時間が評判となり却って好評を博したのである。

さて、現在の携帯電話チップとマルチメディアチップとの接続にはH324などのデータ通信を行うためには、64kbps程度のデータ通信を行うことが必要とされる。スループットを保証するということが同期アプリケーションでは必要になりQuad社の携帯チップに接続されるさまざまなアプリケーションチップには工夫が凝らされているようだ。こうしたチップとの接続にはバス接続で割り込みハンドシェークとFIFOあるいは共有メモリという姿が見受けられる。特定アプリケーション専用のチップもあれば、「何でも出来ます」というチップだけでは何にも出来ないチップもあったりする。携帯ビジネスモデルという構成で期待される端末コストから考えていくとソフト開発コストが一番の要因であり新規要素を出来るだけ取り去るという判断が多いように見える。現実の開発現場での実情から見ると、正しくはないと思うのだが・・・。

別プロセッサとして新規にシステムソフトウェアを起こすようなシステム構成が選択されないのはそうした背景が強いようだ。無論別プロセッサでメモリが２系統必要になることを超量産を信じている経営者や技術リーダーが厳しくなる経営状況から選択できていないのも事実なのだろう。Quad社で数年前に発表した別プロセッサ構成のアーキテクチャ構成などは、時代から浮いていたのかもしれないが、自分たちで手が出せそうなそうした領域まで嫌いなQuad社と付き合いたくはないというのが本音だったかも知れない。技術コンセプトとマーケティングのコンビネーションがうまく回れば良い成果にも繋がったのかもしれなかったのだが。取り組みたいテーマを楽しく取り組んでしまっているQuad社が妬ましく映ったのかも知れない。

そうした背景となってきた組み込み端末機器の繁栄を信じている経営トップと実践している現場の間に乖離があるのも、また事実だろう。経営トップはITRONで設計できれば完璧に短期日に開発が終えられると信じ込まされている人の何と多いことだろうか。システム設計が出来れば、適用するOSや環境に応じた実装設計で解決できることをしない素人な会社集団が多いのは何故だろうか。自分たちの理解のみでシステム設計を行い実装設計に失敗している姿が日本メーカーに増えてきたように見える。同一時期に提供できる同一のソリューションを適用して完成できる日本以外のメーカーと、出来上がらないことを「APIがアプリケーションに合わないから」と自分たちだけで結論付けて、その話のみを変更要望として訴えてくる事例もある。

UMTSのCS通信でビデオ会議を実現するのは、期待されてきた当たり前の機能の一つでもある。通信機能の安定提供と性能向上を念頭に置いてシステム設計をしてCS性能の評価をUARTでPCと接続するという形で実装し評価している。CSでの64KbpsあるいはPSでの高速な要求を満たしていくためにはUSBということになる。Bluetoothでは伝送速度が不足するだろう。深い段数のFIFOバッファを持ち、USBやSIOのデバイスドライバで工夫したバッファ管理を行いUMTSのL1との親和性を取ろうとするのは当然の成り行きである。余分なデータの複写をしていては処理能力の負担がかかるからである。これは別に周辺装置がSIOで接続されようともバスで接続されようとも同じことである。

さて、ソースコードで提供されている、そうしたSIOやUSBのドライバーを見て戴ければお客様が選択した方法で接続されるアプリケーションプロセッサとの接続ドライバの開発も実は大した負担なく開発出来るのは言うまでもないことだ。開発リーダーがそうしたソースコードやシステム設計のツボを押さえていればとんでもないドライバーを開発することはないのだが・・・。さて同じソースコードを提供して、結果として同じアプリケーションプロセッサを選んだとしても開発成果に差異が出来てしまうという実情をどうみるのでしょうか。システム設計のポイントを指示せずに闇雲に高速のプロセッサを通信プロトコルの複雑さを理由に要求している我が儘なソフトウェア開発の実情が見え隠れしているようです。

64kbps以上の負担が掛からないはずの専用アプリケーションプロセッサから通信ユニット単位のデータを単にバッファリングする構造のデバイスドライバーを書いてから、通信処理の為のバッファ管理にわざわざ依頼しなおしているという姿では成功はおぼつかないでしょう。L1での通信処理を考慮したバッファ構成を取っていることを理解せずに、「このバッファサイズが通信ユニット時間のデータ量よりも小さいから大きくしてくれないか」という要請のみを繰り返す人達が、かつて本当に自分たちのみでL1を設計していたのだろうかと懐疑的になってしまう。「そんなこと当たり前じゃないですか」と云いたくもなるのだが、コンサルティングに耳を貸そうとせずに自分たちの設計方針を押しつけて仕様変更の要請のみをしているそのお客様のリーダーの姿がある。

通信プロトコルスタックの構造を理解せずに、だらだらとバッファ間のコピーとペーストを続ける姿が周辺機器との間のDMAを要求しているのだからこれは笑止千万である。「ARM7でUMTSのチップセットなんか出来るわけがない」と云われてしまう人達に向けて逆に問い掛けたいのは「設計方針が低消費電力あるいは処理効率を考えられていないのでは?」という一言である。鈍重なドライバーのコーディングに慣れきってしまった人達がコンパイラのコード効率を考えられないという実情を知り、アプリケーション性能を実現するはずの構成部品を唯々「実績がある伝統のコードです」と保全している姿が日本の開発力を駄目にしてしまっているとしかいえない。こうした事を理解しているエンジニアを異端視扱いするのであれば、もう時代は韓国・中国・インドに移っているという認識に立つべきである。中国人技術者達が日本語を学び日本では異端視されている技術者達のノウハウを自分たちの物にしたいと考えてきた世紀末から、新世紀ではバトンは渡されてしまい彼らが日本語を学ぶ必要は無くなってきたと云えるのかもしれない。

カメラを搭載して、ビデオテレフォニーを実現するというのが第三世代携帯電話の唯一のアプリケーションであると信じて疑わない人達が居るのと、明らかな機能上の差異をつけて需要を喚起したいという考えの人達がいるからだろう。動画メールは楽しいかもしれないが、二人の世界に浸って話をしたいもの同志がテレビ電話を始めたら、ますます電車内でのモラルが低下するのは必定である。彼氏や彼女の顔を覗きたいという輩もいるだろうし、周囲の声が入る程度、端末を前に出さないと通信出来ない現状を混んだ電車のなかで展開しまいかねない現状から、結果として繰り広げられる死闘について考えたくは無いのである。

使われ方を特定の程度の人達に限ってしまうと否定的になってしまうかもしれない、しかし英会話のレッスンや社内同志のビジネスでの通信には、良いかもしれない。互いに言葉を交わさずに黙々と電子メールを確認している風景は、一面静かだがカチカチというキー操作音に電波を感じて医療安全を危惧する人達は、声をあらげて注意する方もおおいようだ。この双方の組み合わせによっては三軒茶屋の悲劇などが繰り返される姿を容易に想像できる。横浜駅の夕方の風景ではそうした喧嘩が普通に見られたりもするものだ。

まあ、使う方の感性や常識が益々求められる第三世代携帯を使えるだけの社会にはなっていないようにも思うのだが、子供を躾けることも出来ない母親から逆に騒いでいる子供を叱ると怒られたりするのが現実なのだから致し方ないだろう。端末が開発され、エンドユーザーに品良く正しく多彩な使われ方をして世の中の為になっていくと信じて仕事をしていくしかないだろう。自分の仕事のみに邁進している感性の大人たちが、サボってきた社会人としての責任範囲の行動のツケが巡り巡って自分たちに降りかかっている。

果たして第三世代携帯電話というバブルを生み出してきた世紀末を越えてきた訳だが、開発する能力もなく、またでき上がった先進のアプリケーションを使うに値しない堕落した精神文化の上で転げ落ちていく日本の実情を哀れに思う。閉じこもった島国文化というスタイルをまた繰り広げている限りには、技術鎖国という状況で崩壊している実情を認識して精神としての鎖国を解き放っていく為にも肥大した世紀末のまま過ごしている政治の状況からは何も産み出せないのかもしれないと感じる。この日本に第三世代携帯を論じる資格はないのでは無いだろうか。鎖国を続けるのであれば、簡単な解決策として余っているバンドをPDCに解放するという事があるのだが、それも出来ないのだから・・・。