大きすぎるハム音

きょうは、しばらく間のあいたSAM3ジャケットでの実験。ADCにつなげたシリコンマイクは充分口元に近づければ、外付けアンプ無しでも充分使い物になる音量がとれることがわかりました。半田不良のため動作が不安定だったマイクをつけ直し。そして震えてノイズばかりだったスピーカも交換してみました。

W-SIM無しでの動作試験はADC/DACともにうまくいったので、いよいよW-SIMと連携しての実際の通話でのADC/DAC動作確認をしてみました。こんどは8000Hzのフレーム同期信号(WSIMのPCMSYNC)に同期して、ADC/DACにトリガをかけてやる必要があります。この方法には、いくつかの方式が考えられます。

1. ADTRG/DATRG信号を使う
   外部トリガ信号であるADTRG/DATRGにPCMSYNCを与えてやる。ハードウェア的にトリガがかかってADC/DACが動いてくれるので、ソフトは楽チン。DMAも使いやすい。ADTRG端子が32Kクリスタルの端子とだぶっているので、RTCクロックとして外部水晶が使えなくなってしまうのが痛い。
2. PCMCLKをTC0で分周して外部トリガとして用いる
   ADTRG端子を使わずに済む方法として考えたのが、この方法。PCMCLKは384KHzのようなので、これを分周して8000Hzを作り、TIOA0をトグルさせる。TIOA0はADC/DACの外部トリガといて使えるという仕掛け。端子を使わずに済むのでうれしい方法。PCMCLKとPCMSYNCは同期しているものの、PCMSYNCがアクティブとなる位置はその時々によって変化することがこれまでの経験でわかっています。そのため、PCM信号の送受のタイミングとADC/DACの送受のタイミングにはずれが生じることになり、これを吸収するためのバッファが必要となる。
3. PCMSYNCのタイミングでADC/DACにソフトウェアでトリガをかける
   もっとも単純な方法。PCM信号はPCMSYNCに同期して送受がおこなわれるので、送受信の完了割り込みのハンドラーにおいてADC/DACの動作開始をソフトウェアで指示する方法。8000Hzの周期で割り込み処理が必要となるため、CPUの割り込み負荷が大きくなる。DMAは使わないことになるが、バッファは不要だし遅延も最低限に抑えられる。外部トリガ端子も使用しない。

それぞれ一長一短がありますが、ゆくゆくは待ち受け画面の時刻表示のためにRTCを使いたいので、ADTRGは使いたくありません。まずは単純な方法で動作確認をしておきたいので、３の方法をとることにしました。割り込み負荷は高くなりますが、タイマもバッファも使わないので周辺機能資源の観点からは経済的ですね。ハードウェアの変更も不要なので、ソフトを作って実験。

ところが、W-SIMを動かしてみてビックリ!!

W-SIMが通信状態になり、同期信号が出始めるとものすごいハム音がのってしまいます。まるでブザーが鳴っているかのような大きさのハム音です。マイクからの音声は問題なく相手側に伝わるので、受信側だけの問題のようです。PCM信号とDAC出力の配線が重なっていたので、PCM信号をつなげ直してみても変化無し。悩んだあげくに、もしやと思ってDACからアンプへの配線をはずしてみたら、やっぱりハム音が出ます。アンプ基板あるいはその先の配線がノイズを拾っているようです。まいったなぁ。どうすりゃいいんでしょ？アンプの位置を変えてみたりするしかないのでしょうかねぇ。

M4の仲間入り

ATMELがSAM4Sのサンプルを出荷開始したことを発表しました。量産は来年のQ2の予定とのことですから、実際に入手できるまでにはまだまだ時間かかりそうです。

他社ではCortex-M4量産品の販売が始まっているところですので、周回遅れでの参戦という感じはしますけどね。ざっと見たところではSAM3Sとピン互換を保っているので速度とDSP命令を必要とする用途には有効なようですが、周辺機能には目新しいところは無さそうに見受けられます。SAM4S以前に、SAM3X/SAM3Aが発表/発売になると思っていたのですが、これらはどうしちゃったんでしょうかねぇ。何しろSAM3ですらいまだにDigikeyでは買えてもMouserにはちっとも在庫されないような状態です。個人的には、SAM4SよりもSAM3シリーズの拡充と、安価に流通することを希望したいところです。

24のツメで12パルス

C&Kのホイール・スイッチを使えるように作業中。このスイッチに魅了されてしまうのは、ホイールと方向キーが一体化されており、iPodを連想させる点でしょう。やっぱり、グリグリとホイールを回したくなります。もっとも実際には機械式で接点が動作するため「グリグリ」ではなくて「カチカチ」なのですが、そこもまた楽しいところです。



このスイッチですが、下図⬇のように７つのスイッチによって構成されています。S1がセンターのボタン、S2～S5が方向キー、そしてA/Bが回転検出用です。



A/Bスイッチの出力するパルスは図のように位相がずれているため、例えばA側の立ち上がりを検出した時点でのB側の状態がON/OFFのどちらであるかを見れば、ホイールの回転方向を知ることができます。この要領で、当初はA側の変化だけで割り込みをかけて、その時のB側の状態で左右方向のイベントを生成してみました。ところが、この方式だとホイールを１段階「カチ」と回しただけではイベントが生成されず、２段階「カチ、カチ」と回さないとイベントが出ません。

改めて上図をよくよく見てみると、「カチカチ」の刻み音を生じさせるツメ(detent)は24あり、１回転で生じるパルス数は12パルスと書いてありました。そのために２刻みで、イベントがひとつしか生じていないのでした。やはりこれでは操作上違和感を感じるので、再検討。A側の立ち上がりだけでなく、立ち下がりでも検出すれば良いかと考えて、実際に試してみるとイベントが発生されないこともあり動きがおかしい。A側のたちあがりとB側の立ち下がりの両方のタイミングで互いの状態を判別するようにすることで、一刻み毎にイベントが生成できるようになりました。

ようやく点灯

プリント基板を作ったものの、パターンミスのため凹んだきり手をつけていなかったLCD基板。早くも２ヶ月ほど経過してしまいましたが、ようやくとジャンパ飛ばして修正、そして点灯までこぎつけました。いずれは基板を作り直すつもりですが、もう少し作業を進めて、他に修正すべき箇所が無いかどうかを調べておきたいですし。




ここまではこれまでのソフトをほぼ修正無しでこれたのですが、今度はスイッチ部分が大きく変わったので、操作関係の処理コードに修正を加えねばなりません。でも、このホイール・スイッチを使ってみたかったというのが、基板を製作したそもそもの動機ですので、スイッチの操作方法を考えながらコードを修正していきたいと思います。やはり、iPodを真似てUpキーを押すとメニューを出すことにしましょうかね。

似て非なるもの(MacOS X LionでのAVRCPサポート -- その2)

このあいだMac OS XのBluetooth機能の動作確認をしたばかりですが、iOS5と時を同じくしてMac OS Xのバージョン10.7.2が出たのでこちらもアップデートしてみました。もちろんiTunesも10.5に上げたのですが、どうやらAVRCP 1.3の動作に関係する修正はなかった模様。やっぱり、日本語文字列が化けてしまいます。

このようなわけで、同時にアップデートのあったiOSとMac OS Xなのですが、Bluetooth AVRCPのサポートに関する限りは振る舞いが異なってしまっていることが確認できた次第です。iOS5ではプロファイルバージョンが1.4になりターゲットとコントローラの両方の機能がサポートされていましたが、Lion 10.7.2では1.3でターゲット側だけです。

iOS5とのAVRCP接続 -- その2

きのうの記事でiWRAP 4.0.0を載せたWT32とiOS5とをAVRCP接続すると、問題が発生することを報告しました。わたしとしては、iPadがAVRCPで曲情報を出せるようになるのを楽しみにしていたので、この機能を活かせないのが残念なことはもちろん、トラ技の記事でiPadやiPhoneとも接続できることを紹介しているので、WCA-009を購入していただいた方にご迷惑をおかけしかねない大問題です。早速、Bluegigaのサポートに問いあわせたところ、昨夜返答がありました。

iOS5は正式リリース以前にβの期間もあったようですから、Bluegigaでは以前からこの問題を把握していたものと思われます。返答ではこの問題に対処した最新のβ版ファームを知らせてくれました。現行の正式リリースは iWRAP 4.0.0 build 317ですが、提供されたのは次のように4.1.0 build 440でした。



このファームを使うことで、メデタクiPadからの曲情報をBlueSAM上で表示できるようになりました。iPadで手軽にデモできるようになるので、個人的には非常に便利で嬉しいです。



きょうは、この機会にWT32のファームウェア更新手順について簡単に説明しておこうと思います。詳細については、Bluegigaから「Firmware Updates User Guide」という資料が出ています。以後の説明は、この資料に基づく簡単なまとめです。

接続方法
ファームのアップデートをおこなうには、ホストとなるマシン(通常Windows)と接続する必要があります。WT32側のピンとしては、SPIあるいはUARTを用いることができます。SPIを使うのが最も安定的であるとされていますが、これをWindowsマシンと直接つなぐことはできませんのでLPTポートとの接続できる変換ボードを介して接続する必要が生じます。このボードを買ったり自作したりするのも面倒なので、アマチュアとしてはUARTの方を使うことになるでしょう。本ブログで紹介したようなボードをひとつ用意しておけば、USBでPCと接続できるのでファームウェア更新にも利用できます。

更新ツール
ファーム更新ツールとしては、CSRからBlueFlashやDFUWizardが提供されていますが、BluegigaがファームウェアとともにSerialDFUというツールを提供しておりUART経由での更新に利用することができますので、これを使うのがオススメです。今回も提供されたβファームの中にこのツールが含まれていましたので、このツールの使い方を簡単に紹介しておきます。

1. Serial DFUのフォルダの中にあるDFUToolGUIを実行して、WT32のつながっているCOMポートを指定します。BCSP settingsはファームの更新時に使う通信条件の設定ですが、通常は設定を変更しなくてもいいはずです。iWRAP settingsの方も提示される値がディフォルトですが、SET CONTROL BAUDコマンドを使って変更した場合には、その速度を指定します。Command iWRAPはチェックしておきます。これにより、ツールがiWRAPコマンドを出して実際にダウンロードで使用するBCSPのモードに自動的に遷移してくれます。
2. WT32をつなげた状態で、Get Device typeボタンを押すと、接続を確認することができます。
   
   
3. 接続が確認できたら、更新するファームウェアのファイルを指定します。dfuの拡張子がついたファイルがダウンロードに使うファイルです。
4. Updateボタンを押すと、ダウンロードが始まります。
5. 無事に更新が完了すると、次のような表示が現れます。WT32をリセットすれば、新しいファームが立ち上がります。
   

WCA-009を購入していただいた方には、紹介したファームをメールで送付するなり、ダウンロードURLを連絡するなりの対応が可能です。β版であることを承知でご利用になりたい方は、ご面倒ですが一度メールにて連絡いただけませんでしょうか？

iOS5とのAVRCP接続

iOS5が出たので、自宅のiPadをアップデートしてWT32との接続確認。ところが問題発生です!! WT32からiPadに対してAVRCPコネクションを張ろうとするとWT32が再起動してしまいます。iOS5ではAVRCPのプロファイルバージョンがあがったので、再生中の曲情報が拾えるようになるはずだったのですが。。。

ちょっと調べてみると、iOS5ではAVRCPのターゲット側とコントローラ側の両方がサポートされているようです。

Service Name: AVRCP Device
Service Description: Remote Control Device
Service RecHandle: 0x4f49110e
Service Class ID List:
  "AV Remote" (0x110e)
  "Video Conferencing" (0x110f)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x103
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
  code_ISO639: 0x6672
  encoding:    0x6a
  base_offset: 0x110
  code_ISO639: 0x6465
  encoding:    0x6a
  base_offset: 0x120
  code_ISO639: 0x6a61
  encoding:    0x6a
  base_offset: 0x130
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0104

Service Name: AVRCP Device
Service Description: Remote Control Device
Service RecHandle: 0x4f49110c
Service Class ID List:
  "AV Remote Target" (0x110c)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x103
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
  code_ISO639: 0x6672
  encoding:    0x6a
  base_offset: 0x110
  code_ISO639: 0x6465
  encoding:    0x6a
  base_offset: 0x120
  code_ISO639: 0x6a61
  encoding:    0x6a
  base_offset: 0x130
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0104

このように両方サポートされていることでiPadからヘッドセットの音量制御もできるようになるという利点があります。WM600のようなデバイスでも,ちゃんと両方がサポートされているので、このようなデバイスを接続すると双方の機能がフルに生かされることになります。試しにWT32をtarget側に設定してみると、ちゃんとiOSとAVRCP接続することができるのですが、これではリモコンとして機能できません。理屈としては、WT32側もtargetとcontrollerの両方をサポートする様にProfile設定できるのが一番良いのですが、現行のiWRAP4.0ではこの機能はサポートされておらず、どちらか片方しかサポートできません。iWRAP5.0になれば、両方サポートされるのかなぁ？

上記のsdptool出力からは、AVRCPのプロファイルバージョンが1.04になっていることもわかります。

WT32がリセットしてしまう問題については、Bluegigaに問い合わせ中です。

追記: 本問題、修正ファームを入れることで解決できました。詳しくは、あした記事書きます。

ADCのトリガではまる

シリコンマイクの配線ができてから、実験のためのソフトウェアを作成して音声入力を試みていたのですが、まったく動かずに悩んでいました。まずは、回路ですが、こんな感じ⬇



マイク入力のデジタル化は、ADCに外部トリガ(ADTRG)をかけてサンプリングとAD変換を実行させます。W-SIMをつないだ時にはこれを8000Hzの周期でおこなうのですが、実験のためにADTRGはタイマ0の出力である TIOA0とつないであります。タイマを8000Hzの周期で走らせてTIOA0からパルスを出力することでW-SIMを使わずに試験できるようにしています。この出力はDACのトリガとしても使っており、DACの試験もおこなえるようにしています。

これで定期的にADCが走るので、その変換結果をDMAで拾おうとしたのですが、全然受信完了しません。調べると、そもそもADTRGがかかっていないようです。ADTRGはGPIOのPA8に割当てられているので、ポートの設定を確認したり、配線を確認したりしましたがトリガがかかりません。さんざん悩んで、もう一度マニュアル見直して、ようやくと原因に気づきました。

I/O Line	Periheral A	Periheral B	System Function
PA8	CTS0	ADTRG	XOUT32

ADTRGはPA8を周辺機器のモードBに設定することで機能選択されますが、PA8にはシステム機能として32KHzクリスタルの接続用端子としての機能もあります。自分の書いたコードでは周辺機器Bを選択していたのですが。それ以前に CrossWorksが用意してくれているスタートアップコードがPA8をシステム機能用に初期化していたのでした。この場合、クリスタル用の設定の方が優先されてしまい、後から実施したADTRGとしての割当設定が無効となってしまうようです。自分の書いたコードを何度見直しても悪いところが見つからずに、ずいぶんと時間を無駄にしてしまいました。

ついでに気がついたのですが、DACやADCのトリガとしてはTIOA0出力を選択することができました。上の回路図のようにわざわざTIOA0端子をトリガ端子と接続せずとも内部的に接続してトリガとして利用することができるようになっています。SAM7の時には、このような機能は無く、SAM3で新たに追加された機能です。ADTRG端子を使わなくても済みますので、代わりに32KクリスタルをつないでRTCのクロックとすることができます。

読者プレゼントへのご応募ありがとうございました

トランジスタ技術９月号の読者プレゼントとして提供したWCA-009 ２台の抽選が終わり、当選者の方に発送されました。抽選と発送はトランジスタ技術編集部がおこない、個人情報保護の観点からわたしには当選者は連絡されないことになっていたのですが、当選されたお二方からメールにてご連絡をいただきました。当選おめでとうございました、そしてメールにて応用計画を聞かせていただきありがとうございます。わたしにとっても参考/刺激になります。

残念ながら当選からもれってしまった方、まだまだ在庫は豊富にあります。ありすぎて困っていますので、ご希望の方は是非ともご連絡ください!!

MacOS X LionでのAVRCPサポート

MTM07に出展することにしたので、久しぶりにBlueSAMを取り出してMac Book Airとの接続確認。これまでMacではツールの動作確認ばかりをやっていて、Bluetoothでの接続確認は全くの手付かずでした。さて、実際につなげてみると意外なことが判明。iTunesで再生してみると、BlueSAMの画面上に曲名が表示されるではありませんか!! iPadではこの機能は動作しないので、Mac OS X Lionでもダメだろうと考え、全く期待していなかったんですけど。

一応確認しておこうと考え、MBA上でubuntuの仮想マシンを立ち上げ。BluetoothのUSBドングルを挿して調査開始。このドングルを使って、本体内蔵のBluetoothの動作を確認しようというわけです。こういう時は、sdptoolコマンドを使うと簡単にサービスを調べられます。Profile Descriptorを読んでみると0x0103になっていますから、確かにAVRCP 1.03に対応していることが確認できました。



しかしながら、この予想外の喜びも長続きはしませんでした。日本語のタイトルのある楽曲を試しに再生してみるとちゃんと表示されません。なんだか、文字列が途中で途切れてしまいます。



おまけに、そのあとAVRCPがちゃんと動かなくなるようです。いったんBluetoothの接続を切断してから、再度接続すると再びちゃんと動くようになるのですが、日本語表示をしようとするとおかしくなってしまいます。

iTunesから送られる日本語曲情報データがおかしいのか、あるいはBlueSAMでのプログラム処理が間違っているのか、はたまたWT32のファームがおかしいのか、この３つのいずれかが原因であろうと思われます。Windows環境下では、こんな現象に出会ったことはなかったので、iTunes/Mac OS が怪しいと推測されますが、根拠も無しに決めつけるわけにもいきません。そこで、問題点の切り分け作業に着手。

まずは、WT32から出力されるメッセージを確認⬇。おやおや、やはりおかしいですね。夏川りみの「島唄」なんですけど。文字列内容の16進数表示も入れていましたが、やはり途中で文字列が切れてしまっています。BlueSAMはこの出力を素直に表示していただけでしたので、これで問題はWT32あるいはiTunes/MacOS Xのいずれかにあると考えられます。



続いてこんどは、WT32の代わりにソニエリのMW600をペアリングしてみました⬇。



曲名の「島唄」を表示してくれるはずだったのですが、やっぱりダメですね。そういうわけで、残念ながらMac OS X LionあるいはiTunesに問題があるようです。