電子ボリュームの動作試験に進む予定でしたが、良く考えたら正負電源が必要なので電源回路を用意しないと進めませんでした。
電源回路を用意するためには必要な電圧が確定しないとならないので、先に表示パネルの選定をする必要があります。
続きを読む: 車載PC Player - 22 - OLEDパネル
2012年2月アーカイブ
FM-TEA5767-Mをブレッドボードで接続してPIC16F648Aからコントロールしてみました。
続きを読む: 車載PC Player - 21 - FMチューナ
勉強用のPIC16F648Aの使い方がだいぶわかってきました。
ただLEDを光らせるのは卒業してロータリーエンコーダの読み取りに進みました。
PICのカタログを眺めてPIC18F4550を使ってみる事にしました。
勉強用に使っているPIC16F648Aは18ピンの8ビットですが、PIC18F4550は40ピンの16ビットで規模がだいぶ違います。
表示パネルを有機ELパネルのDD-25664BE-3AにするとPICで制御しないとならないのですが、そうするとPCとPICを接続するシリアル通信の転送速度がネックになります。
PCとの接続にUSBが使えないか調べてみると、PIC18F2550やPIC18F4550を使うとUSBトランシーバが内蔵されていて、USBを操作するためのスタックも提供されていることがわかりました。
本体の表示パネルにはノリタケ電子産業のSCK256X64C-3100-Aを予定していましたが、これって結構なお値段なんですよね。
で、他に使えそうな物を探したところ有機ELディスプレイが見つかりました。
続きを読む: 車載PC Player - 17 - 表示パネルの検討
7個のボタンを3線で識別するようにダイオードを使って配線したのですが、まるで反応しません。
「あれ？ ダイオードの向きって逆だっけ？」とこのときに変だなと思ったのですが...
続きを読む: 車載PC Player - 16 - PIC消失
設計が終わって取り寄せていた部品が来ました。
ほとんどの部品は秋月の通販で仕入れ、ボタンとロータリーエンコーダはマルツパーツ館です。
続きを読む: 車載PC Player - 15 - 部品が来た
少しずつ進めていたハードの設計が大体完了しました。
どうも1DINサイズには収まりそうもありません。
続きを読む: 車載PC Player - 14 - ハードの設計
ハードウェア構成を現実的な線で考えてみます。
とりあえず以前のH/W構成で必要な部品と電源などを並べてみると、大きな問題となりそうな部分はありませんでしたが、PCとPICの通信方法と1DINに収まるのかがカギとなりそうです。
続きを読む: 車載PC Player - 13 - ハード構成再考
粘土が乾いたのでサンドペーパーで仕上げてみました。
微妙にゆがんでるような気がするけど、まあこれでいいや。
Voyageにはフォントがありませんし、VFDに描画するための便利な機能もありません。
で、とりあえずグラフィック処理プログラムを書いてみました。
続きを読む: 車載PC Player - 11 - グラフィック処理
とりあえず、面倒なスピーカーの型作りから。
CADで正確な図面を書き、断面図から立体化します。
続きを読む: 車載PC Player - 10 - マスター型(1)
どうせ車載PCオーディを作るならと、スピーカーもリフレッシュする事に。
大体、エリーゼの純正スピーカーは位置が悪いうえにショボ過ぎて、すぐに不満いっぱいになるに決まってますから。
これがメインSP。膝の先の奥まった位置に10cmフルレンジがあり、ほとんど聞こえません。
大体、エリーゼの純正スピーカーは位置が悪いうえにショボ過ぎて、すぐに不満いっぱいになるに決まってますから。
これがメインSP。膝の先の奥まった位置に10cmフルレンジがあり、ほとんど聞こえません。
続きを読む: 車載PC Player - 9 - スピーカー
Bluetoothが言う事を聞きません。
一応動作はしているようだし、ペアリングもできますし、Voyage側からAndroidにpingを打つと応答が帰ってきます。
これはWindowsXPに付けたBluetoothドングルに発信したとき
こっちはAndroidに発信したとき
Android側は受信バイト数が0なのでなんかおかしいようです。
Android側で見ると「Connected」と書いてあります。
でも、Android側から
のsock.connect()で例外「java.io.IOException: Service discovery failed」が起こって通信できません。
文面からすると、Voyage側のrfcommサービスが見つからないということみたいです。
BluetoothはTCP/IPのソケットよりも洗練されている仕様ですが、それだけに動作も複雑で今ひとつよくわかりません。
ネットを探しても、LinuxにBluetoothマウスなどの周辺機器を接続する例などは先人のレポートがいろいろありますが、Androidをつなぐというのはほとんど見つかりませんでした。少しだけGUIツールを使って接続する例が見つかりますが、VoyageにはGUIがないのであまり参考になりません。
それにAndroid2.2のBluetoothは、使える機能が少なく中途半端間が否めません。
LinuxのBluetoothスタックはBluezというパッケージを使用しますが、これも設定方法がバージョンでいろいろで何が正しいのやら。Bluezのソースを見るとD-BUSにかなり依存しているようで、なぞは深まるばかりです orz
一応動作はしているようだし、ペアリングもできますし、Voyage側からAndroidにpingを打つと応答が帰ってきます。
これはWindowsXPに付けたBluetoothドングルに発信したとき
root@voyage:~# l2ping 00:1B:DC:04:23:XX
Ping: 00:1B:DC:04:23:XX from 74:2F:68:E1:2F:XX (data size 44) ...
44 bytes from 00:1B:DC:04:23:XX id 0 time 9.77ms
44 bytes from 00:1B:DC:04:23:XX id 1 time 27.76ms
44 bytes from 00:1B:DC:04:23:XX id 2 time 19.77ms
3 sent, 3 received, 0% lossこっちはAndroidに発信したとき
root@voyage:~# l2ping 8C:71:F8:28:B3:XX
Ping: 8C:71:F8:28:B3:XX from 74:2F:68:E1:2F:XX (data size 44) ...
0 bytes from 8C:71:F8:28:B3:XX id 0 time 73.78ms
0 bytes from 8C:71:F8:28:B3:XX id 1 time 34.74ms
0 bytes from 8C:71:F8:28:B3:XX id 2 time 32.78ms
3 sent, 3 received, 0% lossAndroid側は受信バイト数が0なのでなんかおかしいようです。
Android側で見ると「Connected」と書いてあります。
でも、Android側から
try {
BluetoothSocket sock = device.createRfcommSocketToServiceRecord(RFCOMM_UUID);
sock.connect();
OutputStream os = sock.getOutputStream();
byte [] bytes = "Hello".getBytes("UTF-8");
os.write(bytes);
os.flush();
os.close();
sock.close();
}
catch(Exception e) {
Toast.makeText(this, "send error", Toast.LENGTH_LONG).show();
}のsock.connect()で例外「java.io.IOException: Service discovery failed」が起こって通信できません。
文面からすると、Voyage側のrfcommサービスが見つからないということみたいです。
BluetoothはTCP/IPのソケットよりも洗練されている仕様ですが、それだけに動作も複雑で今ひとつよくわかりません。
ネットを探しても、LinuxにBluetoothマウスなどの周辺機器を接続する例などは先人のレポートがいろいろありますが、Androidをつなぐというのはほとんど見つかりませんでした。少しだけGUIツールを使って接続する例が見つかりますが、VoyageにはGUIがないのであまり参考になりません。
それにAndroid2.2のBluetoothは、使える機能が少なく中途半端間が否めません。
LinuxのBluetoothスタックはBluezというパッケージを使用しますが、これも設定方法がバージョンでいろいろで何が正しいのやら。Bluezのソースを見るとD-BUSにかなり依存しているようで、なぞは深まるばかりです orz
ソフトの構成を考えてみました。
続きを読む: 車載PC Player - 7 - ソフト構成
