オマケ基板

来年もInterface5月号にCPU基板がつくようですね。トラ技、Interface, DWMともオマケ基板が定着したということでしょうか。基板がつく度に買っていると、結構溜まっていくものですね。DWMにARM基板が付いた時には、つられて3枚(3冊？)買ってしまいましたが、結局2枚しか使っていません。幸いにも、どちらも修正なしでも問題なく動きました。その後V850は使いましたが、SH2, MSP430, dsPICはいずれも開封すらしていません。自分で基板作ることを想像すると、1700円とか2500円とかの特別定価も安く感じてしまうので、ついつい買わされてしまっています。昨年のSH2の号は、すぐに売り切れになってしまったようですが、皆さんほんとにSH2を使われているのでしょうか？対称的に今年のV850の号は、秋葉の書泉ブックタワーではまだ平積みされているようです。

来年のFR60も、ほんとに使うかどうか自分でも疑問ですが、USBホスト機能もあると聞くと、いちおう買っておこうかと思ってしまいます。

計画挫折

今度はCODECチップを使ってジャケットを作ろうと決意したばかりなのに早くも挫折です。DigikeyでMaster clockとPCMCLKを独立して入力できるPCM CODECを探してTLV320AIC1103というのを見つけました。こいつは2.7V動作だったので、3.3Vでも使えるTLV320AIC1110を買っておきました。さて、実際にこいつを使おうと思ってデータシートを読み直してみると、PCMCLKは128Kまたは2.048Mとなっています。Master clockが2.048MHzであれば、PCMCLKは独立して違う周波数で入れられるものと思っていたのですが、そうではありませんでした。PCMCLKとMaster clockは同じ周波数でも同期している必要は無いというだけのことだったようです。あぁ、大きな勘違い。

いちおう実験ボードでW-SIMのPCMCLKをテスターで測ってみると384KHzです。64Kの6倍ですか、あぁ、やっぱダメじゃん。AT91SAM7X256を購入する際に、ついでにと思って慌ててCODECを探したのが敗因でした。もう一度探し直さねば。やっぱ、OKIとかを探した方がいいんでしょうか。

TLV320AIC1110は、I2Cで音量制御もできて8オームのスピーカも駆動できるしで、外付け部品も少なく使えそうなので、ちょっと実験してみるには簡単に使えそうではあります。サンプリング周波数はPCMSYNCからの8KHzで動くようだし、PCMCLKが2MHzでなくたって、いいじゃんと言ってみたくなります。ダメなのは承知で試しにつないで遊んでみることにします。

次なる計画 - その２

次はW-SIMジャケット制作ということで作業開始しました。ある程度、基本的実験や動作確認ができるところまで進んだら報告することにします。CODECチップを使ってみます。昨日も書いたように、この方法だとSSCやA/Dを使わないのが残念です。というか、SAM7Sを使うほどのこともなく、ATMEGA程度でも充分できそうな事ですね。わたしは、ハードとソフトを最初から組み直すのが面倒なので、SAM7-H256を使いまわしていくことにします。

休み中に並行してSAM7X256の方もちょっと作業してみるかもしれません。実験ボードRev.2は、ハードウェア的にはSAM7-H256にソケットを付けただけというシンプルさが自分では気に入っているので、いつかLinuxとつなげてみるつもりではいます。

次なる計画

さて、W-SIM実験ボードRev.2を使ってのUSBオーディオ接続も基本はできたので、次のステップで何をしようか思案中です。現在の案としては、

1. 引き続きAudioの機能追加。じつは、Feature control機能は何も実装していないので、ミュートも音量調節もできない。これを改善する。
   
2. SAM7S256だとUSB EPが足りないので、CDCとAudioを両方サポートした複合デバイスをサポートできないのが不満。そこでAT91SAM7X256に挑戦する。
   
3. USBホスト側の電話クライアントソフトを作成する。
   
4. いやいや、SAM7S256側にスピーカとマイクを付けてW-SIMジャケットを作る。
   

と、いったところです。

案2については、手持ちのOLIMEX SAM7-EX256を使うことも検討したのですが、RKとRF信号を持つPA25/PA26端子がUSB制御に使われてしまっているので断念。SAM7X256を使うべくダイセンのQFP128ピン変換基板を試しに買ってみたのですが、そのデカサにためらっているところ。パスコンが載せられるようになっているのはいいんですけどねぇ。

案3は、イノテックのLX700ボードをベースにTTL 6bit VGA液晶とタッチパネルをつなげた自作Linuxマシンをもっているので、これにつなげようかというもの。ALSAのサウンドライブラリを使えば音声パスはつなげられるし、GUIはWideStudioでタッチパネル操作にできます。でも、これだとSAM7からは、はずれちゃうな。

そういうわけで、案4に魅力を感じているのですが、PWMで音声がきれいに出るかが心配です。以前、SAM7-EX256でPWM音声出力の実験をした時には、ずいぶんとノイズが載ってしまっていたので、自作のハードでどの程度できるか自信ありません。いっそのこと、アンプ内蔵のCODECチップをつなげることも検討中。でも、この方法を採ると、せっかく使いこなしたSSCの経験が役にたたないので、ちょっと残念なんです。

開発環境 - GCC

AT91SAM7Sのソフト開発は、Windows XP上のVMWare+FedoraにGCC 4.1.2を入れて使っています。Interfaceの記事なんかでは 3.4系を使ったりしているようですが、別段問題に遭遇したこともないので、以前インストールした4.1.2をそのまま使い続けています。

何も考えずにツールチェインをインストールしたので、newlib がThumb interwork対応になっていません。全部ARMモードで動かしてもAT91SAM7S256では、フラッシュが大きいので気になりません。コードサイズだけでなく、メモリアクセスの観点からもThumbを使った方が効率がいいのでしょうね。今度、ツールチェインを入れ替える際には、Thumb対応環境を整えたいと考えています。

W-SIM発信用のコマンドまで入れたところでのサイズはこんなかんじ。テキストセグメントの半分は、音声データとmu-Law変換用のテーブルが占めています。

$ size simusb.elf
   text    data     bss     dec     hex filename
  68160    1032    9580   78772   133b4 simusb.elf
$

Thumbモードで作り直せば、AT91SAM7S64でも収まりますね。

DTEモードでのRI信号

なんとかDTEモードで発呼するための方法も見出せたので、発呼時の動作ログを採ってみました。発呼するためには、consoleコマンドとして発呼のコマンドを用意して、それを起動しています。この例では、携帯電話に対して発呼していますが、着呼の時にも増してRI信号が何度もバタバタとしていることがわかりました。



EV_RIは、RI信号が変化する毎に表示されるようにしていますので、２つで１組と解釈するとパルス状の信号として何度も出ていることがわかります。何となく、網からQ.931メッセージを受信する度にRI信号が出力されているような気がします。着呼だけの時は、RI信号とCDC信号の状態から、呼の状態遷移を考えて応答(ata), 切断(ath)の処理をおこなっていましたが、着呼ではRI信号が何度も変化するのでこの方法は適切ではないことがわかりました。そこで、モデムからの応答メッセージを元に、状態を判断し応答、切断をするように変更しました。

QFPのハンダ付け

ひさしぶりに0.5mm QFPパッケージのハンダ付けをしました。年のせいか以前にも増して目が霞む気がする。おまけにコテを持つ手が震える。

アイテムラボのピッチ変換基板を使っているのですが、0.5mmハンダ付けを終えてからがまた一苦労。連結ピンを立てた変換基板をユニバーサル基板に挿すのが大変です。ピンを立てるときに曲げを入れているので、ラジペンやピンセットで姿勢修正しないと基板の穴に合いません。QFPだと4方にピンが2重に立っているので、全部のピン位置を合わせるのに結構時間を取られます。今回は32ピンだったので、ピンセットでつまみながらの作業で比較的容易に終わらせることができました。100ピンとかあったら、基板にさせる自信ありません。なにかコツでもあるのでしょうか？推奨ポストを使わずに、値段は高いけど細身の連結ピンを探して使った方がいいように思えてなりません。

DTEモードでのCTS信号

W-SIMにはアダプタモードとDTEモードの2つの動作モードがあります。アダプタモードの時には音声の発着信がおこなえません。DDのようにデータ通信をおこなう場合には、アダプタモードで使うようです。DTEモードという名前の由来が不明なので、とっても不思議な名前に感じられますね。W-SIMはモデムとして動く装置なので、DTEモードにしたところで、マイコン側から見ればDTEはマイコンの方で、W-SIMはDCEですから。W-SIMコンソーシアムの会員になって正式な技術資料が入手できれば、こんな疑問も解ける解説があるのでしょう、きっと。しかし、推測しながら動きを調べているからこそ、こうやって報告できるというものです。正式資料を入手してしまったら、守秘義務が発生して、知っている事は他人に伝えられなくなってしまうでしょうから。

W-SIMが起動されると当初はアダプタモードになっています。そこで、音声発着信ができるようにat*i2:1を打って、DTEモードに遷移させます。ところが、このコマンドを打ってから3秒ほど経過すると、なぜか自動的にCTS信号がHになってしまうようです。そのため、DTEであるマイコンからは新たなATコマンドが投入できない状態になってしまいます。この状態でも着信は受けることができ、ひとたび着信があるとCTSがLになって、応答のためのataコマンドを受け付けるようです。

このままでは着信はできるものの、発信ができないことになってしまいます。しばらく試行錯誤したところ、どうやらしばらくDTRを "H" にしてから"L" に戻してやるとCTSが変化するようです。しかしながら、やはり3秒ほどするとCTSが"H"に戻ってしまい、ATコマンドを受け付けなくなってしまいます。DTRのトグル後、3秒以内にATDを打てば、発呼できるように思われます。

*2008/01/21追記
その後、CTSを戻すにはBREAKの送出が有効なことが判明しました。こちらの記事を参照してください。

SAM7-H256のRev Up

OLIMEXと言えばプリント基板の作成に利用されている方が多いようですが、ハードが苦手だし面倒なわたしは、いつもDev boardの方ばかりチェックしています。ここんとこ、すっかりHP更新がなおざりにされている感じがしますが、良く見るとSAM7-EX256に続いてSAM7-H256もボードのレビジョンが上がってREV.C1になるようです。手元のボードを確認するとREV.Bでした。

REV.C1ではUSB周りが変更されているようですが、PA16の先のPUPという記載が気になります。USB pull up制御をPA16で行えるようにする事を意図しているようにも読めますが、USB側にはTrやFETは追加されていません。うーん、実物見ないといけないのかな？

タスク構成

作成したW-SIM/USB実験ソフトは、TOPPERS/JSPを使用しています。今回は、現在のタスク構成を整理しておきます。TOPPERS標準のシステムタスクを除外すると、次の6つのタスクから構成されています。

タスク名	説明
main_task	システムの初期化後、モデムの状態監視をおこない、着信ならびに切断の制御をおこなう。また、呼の状態に応じてステータスLEDを点灯/点滅/消灯させる。
usb_task	USB Hostから送られるUSB Requestを解析し、必要な処理をおこなう。
console_task	デバックポートから入力されるコマンドを解析し、必要な処理をおこなう。
modem_reader_task	W-SIMからのメッセージを読み取り、デバックポートに送る。
audio_receiver_task	USB Speakerに送られた音声を受信し、通話状態であればW-SIMに送る。
audio_sender_task	W-SIMからの受信した音声をUSB Mic経由でHostに送信する。

console_taskは、内部のフラグやカウンタの操作や表示をおこなうデバック用コマンドを使用するために用意してあります。動的な動作確認や割り込み処理のデバックに便利です。手動でW-SIMに対してATコマンドを打つ場合にも使用します。

W-SIMとUSB Audioとの間の音声のリレーを担当しているのがaudio_receiver_taskとaudio_sender_taskになります。通話中でない場合にも、ホスト側からSpeaker/Micが利用される可能性がありますが、その場合にはSpeakerへの再生音声データは読み捨て、Micへは"Hello World"の音声データを送出するようにしています。