SONY S-BUSを解析する。
SONY S-BUSとは、ソニーのカーステに付いてるシステムバスのことです。通称「ブタ鼻」とか言われるらしいです。
ちなみにソニーは、相当昔に車載品からの撤退を発表しており、何を今更感がたっぷりですがそんなことは気にしない。
何故今更S-BUSかというと、「ヘッドユニットが手に入っちゃったから」です。
先日（といいつつ結構前）に車を買い換えた時、以前使ってた2DINのヘッドユニットが載せられなくなり、仕方なく適当なのを使ってたんですが、外部入力が無いという非常に不便でした。
基本、裕之は車にはたいしたこだわりを持たない人種なんで、やっすい車を適当に乗り潰してます。よって、そこそこ頻繁に車が変わったりします。
なんか、PCヲタ＝メカヲタ＝プラモヲタ＝車ヲタという世間一般的に成り立つ場合が多いっぽいですが、私の場合は機械系の属性は全く無しですねー。まあどうでもいいですけど。
で、そういうわけで車にはこだわりも愛着も特に有りませんが、生活はデジタル化されているので、そこに不便さを感じます。
つまりどういうことかと言うと、
(これまたジャンクのカーステで済ましてるので）家のストレージから音楽データを車に持ち出すのがめんどい、という訳です。CDしか再生できませんからね！USBメモリから再生とかそんな高度なヘッドユニット持ってませんから！
ではどうするか、というと、データ通信端末とPCを車に持ち込んでそこから再生する、となるわけです。WiMAXなら無圧縮Waveでもいけます。3Gだとギリギリ無理なくらい。
家のNASは、グローバルからもデータを取得できて、WMPとかのプレイリストも書き出せるようになってます。CDイメージを置くだけでwave+プレイリストで送信したり出来るように工夫してあるんでよ。
で、まあこういう使い方をする以上、ヘッドユニットには外部入力が必須なわけです。えぇ、最近のヘッドユニットはbluetoothとかに対応してて無線で音飛ばしたりできるらしいですけどね。
さて、そういう訳で困ってたところ、知り合いから「外部入力が付きそうなヘッドユニット余ったからあげる」という訳で貰ってきました。
「付いてる」ではなく「付きそう」なところがポイントなんですが。付きそうだから適当に何とかしろ、ということらしいです。
まあそんなわけで、S-BUSの情報収集と解析を始めたところ、既に同じことをしてる人は居るようで。
Welcome to GNUnilink (http://gnunilink.sourceforge.net/)
Michaels Electronic ProjectsのInside Unilink (http://www.mictronics.de/projects/inside-unilink/)
Sony UniLink (Sony Bus) (http://users.ntplx.net/~andrew/sony/unilink/)
あたりが非常に参考になりました。特に最初のGNUnilinkはかなり参考に（というかソース丸パクリレベル）させてもらいました。
今回入手したヘッドユニットは、CDX-C818というものです。
なぜかsonyサイトに情報が無いので、説明書とかも無いため、そもそもいつ頃の製品で、S-BUSには何が繋がるのかすらわかりません。
ですが、とりあえずMDチェンジャーが繋がりそうです(切り替えスイッチがあるため)。
S-BUSの詳しい動作は上記ページを参照してもらうとして（丸投げ）、とりあえずGNUnilinkの通りだとこのヘッドユニットでは動きませんでした。
ですので、その辺についての説明をします。
まず、CDX-C818は、ロングネームに対応してるらしいです。まあこれはdefineで定義されてるので特に問題は有りませんね。
問題なのは、SlaveBreak時の動作が違うらしい、というところでした。
ここで、ざっくりとS-BUSの動作を説明しますと、
・送受信共用の１本のデータ線
・送受信クロックは方向に寄らずマスター（ヘッドユニット）が作る
・マスターはスレーブ（この場合MDチェンジャ)に、定期的にpingの様な物を送って接続確認をする（アクセサリーＯＦＦ時も！）
・スレーブがマスターに何か伝えたいこと（たとえばディスプレイの更新＝時間表示など）がある場合、SlaveBreakという状態を発生させると、マスターがスレーブに問い合わせをする。
という様な感じで動いています。
で、このSlaveBreakは、マスターが通信していない期間を見計らってスレーブが発行するため、主導権はマスターにあります。言い換えると、マスターがバスを占拠している間は、SlaveBreakは発行できません。
ここでGNUnilinkの実装では、スレーブが何らかのきっかけでSlaveBreakを発行しようとしたとき、バスが空くまでずっと待ちます。その間何も応答はしません。ここが問題でした。
もっと具体的な話をすると、
・MDチェンジャー切り替えボタンを押す
・マスターはボタンが押されたことをスレーブに通知する
・スレーブはそれに応答し、SlaveBreakを発行する。
・マスターはSlaveBreakを受信したため、スレーブに対して問い合わせを行う。
・スレーブは、画面更新情報などを返答する。
という一連の動作を行うのですが、スレーブがSlaveBreakを発行したいタイミングから、実際にバスが空くまでに、マスターがPingを送信することがあり、そのPingに応答できないとマスターが異常動作としてリセットしてしまうようです。
なので、SlaveBreak発行待機中も、コマンド解析は行わないとだめなんですね。
というわけで、その辺の修正＆GNUnilinkはPCからの操作を前提としていたため、その辺を省いてコンパクト化し、16F84で動作するようにしました。
また、手持ちが秋月のライターだったので、それに合わせて記述も変更しています。
Unilink.zip
実際のハードウェア構成はソースを参考にしてください。16F84とクロック生成部(20MHz水晶＋コンデンサ)だけでいいです。特にレベルシフトなどは考慮する必要なく、PICとS-BUS直結で問題有りません。
これをヘッドユニット内に突っ込むことで、無事MDチェンジャモードに切り替わることができ、外部入力が増設できました。
また、数時間以上この状態で使ってますが、いきなりリセットかかったりすることもなく、無事動いています。
さて、このソース、実はもう一つ機能が組み込まれていまして、ここで「SEEK」ボタンを押すと、外部入力１と外部入力２を切り換えることができます。
とはいうものの、ヘッドユニットには入力端子は１系統しかありませんので、表示が変わるだけです。実際には何も変わりません。
ただ、１と２（ソースではDIGITALとanalogと記述)のどちらを選択してるかは、PICの端子から解りますので、外部にセレクターを持たせることで、入力を２系統に増やせますね。
で、何をしたかったのかというと、もちろんanalogは普通にアナログ入力なんですけども、digital入力として、I2S出力のあるUSBオーディオデバイスをヘッドユニットに搭載して、ヘッドユニットの(CDプレーヤー用の)DACを流用してデジタル入力（というかUSB入力)を付けてやろうと考えてました。
DACの入り口にセレクター付けて、内部のアナログセレクターを強制的にCDのDAC側に切り換えてやればいいだけだよなーということで。
がしかし、アナログセレクターがなんとシリアルでコントロールされているという、単純に切り換えるだけにしても面倒な仕様なので挫折。
これはPIC1個だけでやるのは困難だよなと。ならFPGA載せてSPDIFとか色々付けてやりたいよなと。
まあ今回は挫折しましたけど、別にソース上に残ってても困ることは無いのでそのまま放置してあります。
さて、そしてさらにもう一個問題点。
どうやらロングネームの処理にバグがあるくさく、名前の最後に変なゴミが付きます。
ここはGNUnilinkと同じ構成のはずなんだけどなあ。本物のMDチェンジャが無いので解析は手詰まりです。
まあこれも問題ないので気にしませんが。
ともあれ、とりあえず目標だった「車に外部入力付きのヘッドユニットを付ける」ということがあり合わせの材料だけでできました。
決して、「S-BUSを解析する」ことが目標だったわけではないですが、意外と大変でした。
まぁ、1dinで外部入力付きのヘッドユニットが手に入ったということは、車を変えても当分は使い回せるでしょうから、壊れるまではお世話になるのかな。
ちょっとベツバナ
移動体通信(つまりデータ通信端末ね)の設計開発をしている人の講演を聴くことがありました。
その人いわく、「移動体通信といっても、実際歩きながらパソコン使うわけじゃないですし、立ち止まって使うんですよね。だからハンドオーバーが問題になることはあまり無いんです」という事を言ってました。開発者ですよ？
ですが実際ここに、だいぶ前から、移動体通信をフルに使って（時速６０キロでハンドオーバーさせながら）ストリーミングで自宅サーバーから音楽を再生とかしてる人がいるんですよ。開発側にとっても想定外なんでしょうね。実際のところ問題なくできてますが。
ただ、グーグルがMusic betaという、似たようなサービスを行っています。
携帯を音楽プレーヤーに使ってる人も世の中に多数居ます。
音楽データはサーバーに保管し、聞くときはストリーミングで、という時代が来るでしょう。きっととても近い将来です。
むしろ、携帯で音楽を購入し、本体のストレージに保存し、それを再生するとか、なんて無駄な事でしょう。
決済情報はサーバーが持っていて、再ＤＬも可能（らしい）ですし、常にネットワークにも繋がっています。ローカルにデータを持つ必要なんて無いじゃないですか。
キャリアはさんざん帯域を使わせるような商売のしかたをしつつ、スマホが帯域圧迫してるとか言ってますが、もっともっと移動体通信は便利になって欲しい物です。
感想、要望、バグ報告、その他何かありましたら、メールもしくは掲示板にてご連絡ください。
裕之 
ホームに戻る