USARTにとりかかる

続いてUSARTをWCA-009とつなげて動かします。




USART機能は、これまでのSAM7/SAM3と似ているのですが、LIN機能まで統合されているようです。SAM4LにはPicopower UARTという受信検知を省電力でおこなう機能も備わっており、これも試してみたいところなのですが、残念ながら通信速度が9600bpsで固定されているという制限があります。WCA-009はいつも115,200bpsでつないでおり、9600だと操作や表示速度にも影響が出そうなので、今回はPicopower UARTは使いません。

SAMシリーズのUSARTは伝統的(?)にFIFOを持っていません。一文字ずつ送受信していたのでは、割り込みのオーバヘッドが大きすぎます。そこでDMAを使うことになります。SAM7/SAM3では各ペリフェラルにPDCというDMAチャネルが付いているという構成になっていました。これが、SAM4Lでは少し変わっています。従来のPDCと同等のPDCAという機能が用意されていますが、PDCAはペリフェラルからは独立したDMAチャネルという構成になっています。従ってDMAを使う場合には、ペリフェラルとPDCAとを結び付けるという設定処理が必要となっています。またひとつのPDCAチャネルは受信か送信かの１方向しか処理できないので、例えばUSARTの送受ともDMA処理をおこないたければ、2チャンネルのPDCAの割り当てが必要となります。SAM4Lでは16チャネルのPDCAが備わっています。

このように構成は変わったものの機能的には大きな変化はないので、理解は難しくないのですが、実際にドライバを作ると割り込みハンドラーが３つも必要になります。SAM7/SAM3ではPDCがUSARTに付属していましたので、DMAの終了割り込みもUSARTの割り込みハンドラ内で処理することができました。SAM4Lではこれが分離されており、しかもPDCAは送受信で別チャネルであるために、割り込みのベクタも別に用意されています。そのため、合計で３つの割り込みハンドラーが必要になってしまうのです。



３つも割り込み使うこともあり、ついついPDCAの割り込み許可するのを忘れてしまったりしましたが、送受信とも動き始めました。

ASTを動かしてみる

SAM4Lの方ですが、どうにかUSB CDCでPCとつなげられるところまではきました。しかし、時々うまくつながられないことがあります。どうやら CONTROL転送にバグがあるらしく、ZLP (Zero length packet)のINパケットを処理しそこなっているようです。どういう条件でこの問題が発生するのかをちゃんと絞り込めないとバグを取れそうもありません。まだちゃんとSAM4LのUSBCの動作を理解できていないってことですね。

USBの方はじっくりと見直すことにして、簡単にできそうな作業を並行して進めていこうかと思います。まずは試しにRTCを動かしてみることにしました。ところが、SAM4L にはRTCという名前のペリフェラルがありません。AST(Asynchronous Timer)が、RTCの機能をもっているようです。ASTは、SAM3SのRTTとRTCの両方の機能を兼ね備えたものになっており、ASTをカレンダーモードに設定することで、RTCと同じように使えます。ASTではクロック源も選択できるので、これを正しく選択して適切な分周比を設定してやらねばなりません。

今回は内蔵の32KHz　RCオシレータを使うことにしましたが、次のような手順での設定が必要でした。

1. BSCIFのRC32KCRにて、32KHz RCオシレータをイネーブルする
2. BPMのPMCONにて、32KHzクロック源として32KHz RCオシレータを選択する
3. ASTのCLOCKレジスタにて、ASTのクロック源として32KHzクロックを選択する

選択できるのはいいけど、設定するのは面倒になりました。

こうしてUSBでPCとつないで、ASTで計時できるようになりました。



今回は内蔵のRCオシレータを使っていますが、もちろん外付けの32KHzクリスタルを使うこともできます。SAM3Sでは、32KHzクリスタル用の端子(XOUT32/XIN32)がPIOと兼用になっていましたが、SAM4Lでは専用のピンが割り当てられています。SAM3SではUSARTのRTS/CTS機能とぶつかっていたので不便に感じていました。これは、ちょっと嬉しい相違点です。

デモ準備

先週、Twilioを簡単に紹介しましたが、今週開かれるTwillio meetupにてBlueHANDを使ったデモをする機会をいただきました。基本的には先週の記事と同じようなデモを実施する予定ですが、着信時に流すメッセージ内容にちょっとヒネリを加えるつもりです。

メッセージはCeVIOを使って作成していますが、どうしてもイントネーションがおかしい箇所が生じてしまいますので、修正作業が必要となります。音素の大きさ、長さ、高さを調整することができるのですが、なかなかうまく修正できません。慣れれば少しは上手に修正できるようになるのかもしれませんが、わたしが手を加えるとどんどんとすっとんきょうな声になっていってしまいます。

CeVIOで作成した音声をエクスポートすると、48KHz, 16bit PCMのWAVファイルが生成されます。Twillioで再生させるにはMP3ファイルが必要なので、Audacityを使って800Hz MP3に変換してやるとよろしいようです。

USBの作業中

しょっちゅう寄り道ばかりしているのですが、SAM4Lのコードも書いてはいます。まだUSBのCDCドライバを作っているのですが、まだようやくとenumerationが動き始めているところで、CDCでの通信までには至っていません。




動き始めてはいるのでクロックがらみの設定は問題ないことは確認できました。しかし、USBのコントローラであるUSBCの仕様がこれまでのSAM7, SAM3のUDPとは全く違うものなので、手探り状態でコードを書いたり、修正しているようなありさまです。わたしはAVRとかAVR32のUSBについては全く知らないのですが、そちらの方に近いのかもしれませんね。

SAM7/SAM3のUSBがFIFOメモリ経由でデータを読み書きしていたのに対し、SAM4LのUSBはSRAMメモリとダイレクトにDMAしてくれます。この方がわかり易く使いやすいのですが、もともと32KBしかないSRAMを割かなくてはならないのがちょっとツライところです。

Space Oddity

この３日ほど、頭の中を Space Oddityが流れ続けて止まないので、とりあえず貼っておきます。大きなニュースだと思うんですが、意外と知らない人がいるようだし。。最後のクレジットには息子の名前も入っていて、そんなところも楽しめます。



歌詞が ISSからソユーズで帰還するにふさわしく替えられているのも素敵ですね。Hadfieldの他の動画を見た人ならわかると思いますが、日頃からマイクを廻していただけあって、ギターも上手に廻しているのも笑えます。

オリジナルのDavid Bowieの動画も簡単にみつかりますが、次の動画はChris Hadfieldが撮影した画像がバックになっています。



ちなみに、Space Oddityの歌詞では Major Tom(Tom少佐)ですが、本人は大佐みたいです。

BlueHANDとTwillio

先週掲載したBlueHANDのデモでは、途中で電話の着信が入ってきます。この電話の発信には、KDDI Web Communicationsが提供しているTwillioというサービスを利用しています。

KDDI Web Communicationsは、昨年からBoundioをというクラウドから架電するサービスを提供しており、このブログでも2度ほど取り上げました。先般、同社は米国で普及しているTwillioサービスを提供することになり、Boundioサービスは終了する運びとなりました。Twillioになって料金も手頃になったうえに、機能的にも発信だけでなく着信もできるようになったので、BlueHANDのデモに使うにはもってこいです。

現在、Twillioを用いたデモとしては、以下に説明する2種類を用意しています。まずは単純な着信です。PCやスマホからTwillioに対して発信要求を送ってやると、Twillioが指定した番号に電話を架けてあらかじめサーバ上に用意しておいたメッセージを再生してくれます。メッセージは、MP3ファイルで用意しておき、Twillioサービスとは別のサーバ上に置いておくことができます。デモ動画は、この方法を使っています。



もうひとつのデモは、転送サービスです。BlueHANDと携帯とをBluetooth接続すると、BlueHANDがPC(or スマホ)を経由して、その電話番号をサーバに通知します。Twillioサービスでは、050電話番号を取得することができますが、その番号に電話すると自動的にBlueHANDに接続した携帯電話に電話が転送されるというものです。



BlueHANDと接続する携帯が変わると、自動的にあたらしい電話番号がサーバに通知されて、転送先番号が変更されます。

目覚め

朝からうるさいんです。こいつ(キジ)の鳴き声で目が覚めることもしばしば。

今朝は、朝食後になってもとなりの空き地で鳴いていたのでパチり。鳴き声は毎日聞いていても、いざ写真に撮ろうと思うと草むらにいたり距離が遠すぎたりするので、なかなかきれいには撮れません。きょうも、近くで見ることはできても、手持ちのデジカメではズームしてようやくこんなとこ。デジタルズームかかっているので、ちょっと荒いです。





斜め向かいの空き地でももう一羽鳴いていますが、そちらの土地は先日売却先が決まった模様。こいつらの鳴き声が聞ける日々も、残り少ないのかもしれません。

BlueHAND

昨年より製作していたBlueHANDのデモ動画をこさえました。当初は、SAM3Sと家庭用電話機の"うわがわ"を流用したものをBlueHANDと呼び、LPC1114と電話機の受話器部分だけを使ったものをBlueHAND-Miniと呼んでいたのですが、LPC1114版の方ばかりに機能追加やバグ修正を施してきたので、こちらの方をBlueHANDプロジェクトとして整理することにしました。




動画ではペアリングから始まって、AVRCPを使った音楽再生の制御、HFPによる着信と発信の操作/動作を示しています。サイズと画質を調節してもらえれば、LCDの表示内容も確認することができるかと思います。


音楽再生中には、矢印表示が移動していきますが、これはA2DPが流れていることを示します。AVRCPを使ってpauseすると、しばらくしてからA2DPが止まります。

音はヘッドフォン端子につなげた外部アクティブスピーカーで出しています。

着信デモ中での音声は、CeVIOの音声キャラクターであるさとうささらさんです。連休前にリリースされたCeVIOを早速使ってみた次第です。CeVIOで作製した48KHz WAVファイルをMP3に変換/アップロードして、電話の向こう側で再生させています。その部分の仕掛けについては、そのうちに改めて説明記事を書こうかと思います。

Display + yes/no button

連休を使ってBlueHANDの動画を撮っているのですが、イザとなるともう少し手を加えてみたくなる箇所が出てきました。それが、SSP(Simple Secure Paring)の使い方です。これまでは、SSPを使ってのペアリングには Just worksというモードを使っていました。このモードだと例えばスマホからBluetoothデバイスを検索して、見つかったBlueHANDを選択するだけでPIN番号の入力やパスキー確認をすることなくペアリングが行えてしまいます。この機能はもともとマウスのような表示、キー入力機能を持たないデバイスを意識して用意されたものです。

BlueHANDはLCD表示器と電話キーパッドをもっていますので、スマホとBlueHANDの両方に同一のパスキーを表示して、両方のデバイス上でそれを確認してキーを押すことで、互いのデバイスを確認した上でペアリングさせることもできます。SSPではデバイスが持つ能力をいくつか想定していますが、これは "Display + yes/no button" という能力に相当します。この能力を使うように設定するには、WT32上では

SET BT SSP 1 1

という設定をしておきます。スマホ側からペアリング/接続操作をおこなうと、WT32には

SSP CONFIRM 0c:71:5d:10:85:1e 089944 ?

というようにパスキーの確認を要求するイベントが出力されますので、

SSP CONFIRM 0c:71:5d:10:85:1e OK

と応答してやることでキー確認を行います。この動作をBlueHAND上に反映させた様子が下の写真です。




両者の画面上に同じ６桁の数字 089944 が表示されました。スマホ側ではOKボタンを押し、BlueHAND側では0キーを押してペアリングを了承してやると、ペアリングが完了して接続されます。赤い*または#キーを押せば、ペアリングを拒否できます。このように接続する側/される側の両方のデバイスを操作する必要があるので手間がかかりますが、こうすることで互いを確認でき、悪意をもつなりすましデバイスと誤ってペアリング/接続してしまうことを防ぐことができます。

断線

やられました。激しくやられました。



犯人はコイツです。



もともと、カーテンとかシャツやパンツの袖や裾を噛みちぎったり、食べたりする習性を持つ悪魔です。ここのところ、カミさんのiPodケーブルを狙う様子が見られていたのですが、いきなりわたしのMac Book Air用 MagSafeが襲われました。今後は席をはずすたびにMagSafeを片付ける必要ありです。あぁ、めんどくさ。

被害にあったアダプタは修理して予備用にしておきたい。どこかでMagsafe用コネクタが付いたケーブルだけ売っていないかしらん?