To enable the goals of the Ara modular platform, a set of generic class drivers will be specified in the Greybus specification and implemented in the Greybus subsystem. The set of generic class drivers will span a broad range of module devices typically found on smartphones. The current plan includes the the following device classes: audio, batteries and chargers, Bluetooth devices, cameras, consumer IR devices, displays, GPS, input devices, lights, NFC, sensors, vibrators, WiFi, baseband, and other network devices, and storage devices. Future versions of the MDK and Greybus specification will include details for each device class.
見事な誰得プロジェクト (スコア:0)
散々時間かけてこれだもんなぁ
Re: (スコア:0)
時間をかけて、完全に後退してしまった。
期待通りの「CPUや通信機能を自由にアップグレードできるスマホ」が無理なのは予想できたけど、
結果は折衷案どころかやらないほうがマシなレベルになってしまった。
> モジュール交換で・・・リアカメラやスピーカーぐらいになりそう
カメラを外した状態を固定し追加できないタイプならビジネス用に売れるかもしれないが、
それじゃもはやアップグレードでもなんでもないな。
Re: (スコア:0)
今時のスマホはSoCとしてCPUとGPU、メモリコントローラ、モデム、センサー処理用DSPがセットになっているわけです。
つまりCPUを選ぶと自動的にGPUと適切なメモリ、アンテナ、センサー類も決まってしまいます。
だからこの辺りを不可分のユニットにするのは必然。
分離できそうなのはディスプレイとバッテリーくらいですね。
Re: (スコア:0)
センサーに関しては、センサー自体はチップセットに含まれているわけでは無し、
技術的には分離可能じゃないの?
センサーが変わるとソフトウェアも変えなきゃならないからというなら、それはディスプレイでも同じ話。
センサーが不可分なら、同様な理由でディスプレイも不可分というものだろう。
加速度センサーやジャイロセンサー、明度センサーなどをアップグレード可能にしたところで、
そんなに違いやメリットがあるとも思えないという話で切り分けられていないだけだと思う。
プロト
Re: (スコア:0)
センサーは、CPU(SoC)とは技術的には分離可能ですが、フレームと分離するのが難しいです。
物理現象を検出するため、フレームの強度とか振動、磁気特性、取り付け位置の影響を強く受けます。
CPUとの分離にしても、できるのはできますが、現実問題難しい。
メインのCPU上でドライバを動かすのは誰でも出来ますが、最近のスマホでは省電力化のためにサブのマイコン上で動かすことが多いです。
これらのマイコン上で動くドライバは、センサーメーカーが大手顧客向けにはカスタムで製作してます。
しかし、弱小スマホメーカーだと数量を出せないので、ドライバを作ってもらえない。
そこでCPUもセンサーもQualcommとかMediaTekのリファレンスデザインを利用します。
自由に組み合わせるとしたら、自分でセンサーの種類*マイコンの種類の組み合わせの数のドライバを作らないといけない。
Re: (スコア:0)
少なくともGoogleは弱小スマホメーカーじゃないんだから、Googleがモジュール化したセンサーを作るのに困難は無いだろう。
コンパスへの筐体磁界の影響は、結局キャリブレーションするんだから問題ないんじゃないの?
Re: (スコア:0)
マイコンが3種類、センサーが3種類あるだけで、組み合わせの数は9。
組み合わせのそれぞれについて、大手メーカー並の数を出すなんて無理。
Re: (スコア:0)
一気に同じジャンルのモジュールを何種類も出す必要は無いだろう。
アップグレードなんだから、性能が向上した部品が出てきたときに、次のモジュールを作ればよい。
Googleは今回1種類のプロセッサしか出さないんだから、とりあえずはそれように作ればよい。
新しいプロセッサのフレームを出すにしろ、新しいセンサーモジュールを出すにしろ、
その時点になったら開発すればいいだろう。
Re: (スコア:0)
1種類しか出さないって…
このプロジェクトの意義全否定ですか。
まぁそのように現実を見つめ直したから、今回の仕様なんでしょうね。
Re: (スコア:0)
「今回は」って言ってるのに。アップグレードなんだから、他のプロセッサを使ったものは、
さらに性能がいい製品が出てきた時に出せばいいだろう。
「このプロジェクトの意義全否定ですか。」というなら、君の言った
組み合わせのそれぞれについて、大手メーカー並の数を出すなんて無理。
というコメントで既に全否定していると思うが。
Re: (スコア:0)
>「今回は」って言ってるのに。アップグレードなんだから、他のプロセッサを使ったものは、
さらに性能がいい製品が出てきた時に出せばいいだろう。
「アップグレード」って認識自体が、元々のコンセプトからの思いっきりの退化だよ。
元々は自分に最適なコンフィギュレーションが出来、それがTPOで変更できるって話だったんだから。
Re: (スコア:0)
そうはいっても実際に最初は1機種しか出ないんだから、組み合わせ爆発が起きることもない。
センサーをモジュール化したところで困難はないだろう。
Re: (スコア:0)
1機種しか出さないなら初めだけ組み合わせは少ないね。
でも、それって、後からモジュールを増やしたら、結局組み合わせは増えるよね。
それとも、新しいモジュールは新しいモジュール同士しかサポートしないのかな?
Re: (スコア:0)
ARAはモジュールで接続されるメジャーなデバイスは抽象化されている。
例えばUSBで様々なスペックのWebカメラが標準のUSB video device classのドライバで動くように、
各々のモジュールメーカーはモジュールをその定義されたデバイスクラスに合わせて通信するように
作りこむ手間をかけるだけでよくて、その先のことは気にしなくていい。
Ara software stack: Greybus kernel, Android platform. [modularphonesforum.com]
To enable the goals of the Ara modular platform, a set of generic class drivers will be specified in the Greybus specification and implemented in the Greybus subsystem. The set of generic class drivers will span a broad range of module devices typically found on smartphones. The current plan includes the the following device classes: audio, batteries and chargers, Bluetooth devices, cameras, consumer IR devices, displays, GPS, input devices, lights, NFC, sensors, vibrators, WiFi, baseband, and other network devices, and storage devices. Future versions of the MDK and Greybus specification will include details for each device class.
プロ
Re: (スコア:0)
スレッドの初めの方で書いてありますが、センサーの問題はCPUで動くドライバではありません。
CPU上のドライバは、書かれているとおりAndroid上で抽象化が出来るので、特に問題ない。
問題なのは、コンパニオンマイコン上で動く、専用のドライバ。
センサ---マイコン---CPU
のように接続されており、センサーが常時動作してもCPUをスリープに入れられるように、センサーのキャリブレーション等のハードに直結した機能は常時動作する低電力マイコン上にあります。
これらのマイコンは、低電力化のため内蔵SRAMで動いてます。
たくさんのセンサーを管理する必要があるので、センサー1個あたりに割り当てられるメモリが数kBオーダー。
ここで動くドライバは、センサーメーカーが昔ながらの職人芸で1品毎に作ってます。
Re: (スコア:0)
だから、そのマイコンのプログラムがARAで抽象化されたセンサーとやり取りするように書かれるという事。
従来ならセンサーがI2Cなどで直接マイコンにつながっていたところを、間にUniProブリッジICが噛んで、
モジュール間はUniProのプロトコルで通信が行われる。間にAPUが入る必要はない。
Re: (スコア:0)
これまで低電力マイコン1個で済んだところを、センサ毎にブリッジICを追加して、しかも抽象化が出来るレベルのドライバを動かすって?
そんなばかな。現実を見ようよ。
Re: (スコア:0)
それがARAプロジェクトなんだから、そこを蒸し返されても、いまさら何を言ってるのやらという話。
いくらかの無駄を承知の上で、モジュール化することでの利点を得るというものだ。
実際にARAの各モジュールはすべてそういう方法でモジュール化されているんだから。
無駄が多いというのは、どこでも(ここでも)さんざん指摘されていたこと。
それが面白くないという人は、普通のスマホをこれまで通りつかうだけ。
今ここで話してるのは、センサーをモジュールとして分離するのは、別に技術的に実現困難な話じゃないよ
ということだろう?
Re:見事な誰得プロジェクト (スコア:0)
>それがARAプロジェクトなんだから、そこを蒸し返されても、いまさら何を言ってるのやらという話。
今回センサーのモジュール化を止めたというのに、何を言ってるのやら。
Re: (スコア:0)
だからそれは「いくらかの無駄を承知の上で、モジュール化することでの利点を得る」のうちの
「モジュール化することでの利点」が無いからだろう、少なくとも技術的な問題じゃない、
と#3017052 [it.srad.jp]書いただろう。
話を全然追えてないのか?