SAM3の開発環境

ようやくと製作を始めたSAM3ボードですが、きょうはソフトの開発環境について書いておくことにします。これまではほとんどのプロジェクトをLinux上でGCCを使ってコンパイルしていました(実際にはXPをホストとするVMWareを使い、LinuxをゲストOSとして使用)。また、RTOSとしてはTOPPERS/JSPを使っており、昨年からSAM3Uで実験的にASPを使っています。今回のSAM7Sを使ったドッチーモジャケットも、最初は (VMWare上の)LinuxとTOPPERS/ASPで作っていたのですが、途中から開発環境をRowleyのCrossWorks for ARMに引っ越しています。

ちまたではembed/LPCXpressoやSTM32が開発環境を含めて提供されていることから人気ですが、ATMELを中心に使っており時々はLPCやSTM32等にも浮気するかもしれないという嗜好を持つわたしとしては、ベンダー・ニュートラルな環境の方が便利です。CrossWorksは基本的にはgccベースなのですが、ATMELを含む各社のARM7,ARM9,Cortex-M3のCPUサポートが含まれる開発環境となっており、個人向けにPersonal License($150)が用意されているのが魅力です。じつはすでに昨年末に購入してあったのですが、3月からようやくと使い始めたような次第です。このCrossWorksですが、ライブラリの一部として、CTL (CrossWorks Tasking Library)というマルチタスクのライブラリが用意されています。そこで、今回はTOPPERSを使わずに、このCTLを使ってみています。RTOSとしての機能はかなり限定されている印象を受けるのですが、最低限必要な機能は備わっているので、TOPPERSで使っていたコードを、思ったよりも簡単に移植することができそうです。




SAM7Sで書いたコードを、順次書き換えてSAM3に持ってきています。いつものように、最初にUSB仮想シリアルのドライバを動かして、デバック用モニタを動かすとこまできました。CrossWorksではARMのDCC (Debug communication Channel)を使ってのデバック用メッセージの表示もできますので、シリアルを使ったデバック用メッセージ出力を使わずに済むのも助かります。

これまでIDEというやつをほとんど使ったことがなかったので、最初はちょっと戸惑いましたが、ようやくと慣れてきました。開発環境がレッツノートCF-T5という5年も前のノートPCなので、Eclipsは重くて耐えられなかったのですが、CorssWorksは使い物になります!!



JTAGにはATMELのSAM-ICEを使っています。これはSeggerのJ-LinkのOEM品です。J-Linkに比べると安く買えますが、ATMELのARMでしか使えないという制約があります。SAM-ICEはSAM-BAでも使えるので、ATMEL中心のわたしとしては持っていても損はないだろうということで購入したものです。もちろんCrossWorksでもJ-Linkはサポートされていますので、このSAM-ICEも利用可能です。そしてSAM-ICE(J-Link)とCrossWorksの両者ともにSWDにも対応しているので、Cortex-M3使用時にはSWDでのデバックが可能となっています。今のところはまだJTAGで使っていますが、最初動作が不安定でデバッガを使って実行を開始するとエラーが出たり、JTAGをコネクトしようとするとSAM-ICEはATMELのデバイスでしか使えませんというエラーが出たりして、しばらく悩んでいました。JTAG接続の設定の中にあるクロック速度のパラメータをためしに500KHzに設定したら安定して動くようになりました。もう少し早くしても大丈夫かもしれません。このあたりは、ボードの配線のまずさが影響しているのかもしれません。

いよいよSAM3Sを始める

前回の記事にも書いたように、まだまだドッチーモ・ジャケットの開発途中なのですが、並行して新たなボードの製作を始めました。こちらのボードではW-SIMを搭載しないBluetooth専用として小型化することで、少しでも見栄えを良くして「トラ技オフ会」に持ち込むことを短期的な目標としていますが、それ以外にも次のような目的を持っています。

1. 購入しただけで手をつけていなかったSAM3S4Aを使い、ようやくとSAM3Sの利用と勉強を本格化させること。
2. Bluetooth専用として試作をおこない、その後プリント基板の製作まで進める。
3. ドッチーモ実験ボードではCODECとしてAIC3253を使用したが、これをAIC3254に変更する。

ドッチーモジャケットも最終的にはSAM3SかSAM3Uに変更したいと考えているので、その準備も兼ねてARM7からCortex-M3に乗り換えです。コアは変わっても周辺機能には大きな違いはないので、SAM7S用に書いたコードは簡単にSAM3Sに移行できるはずです。



主要な部品の配置を終えましたが、まだLCDとデジタルマイクが載ってません。これらは別基板にして載せるつもりでいますが、具体的な方法はまだこれから検討しなければならないような状態だったりします。まずはマイコン廻りの最低限の配線だけは済ませて、なんとかSAM-BAでアクセスできるところまで漕ぎつけました。しばらくクリスタルのハンダ・ブリッジに気が付かずに、かなり時間消費してしまいました。メッシュ基板は電源とパスコンの配線が楽なので重宝するのですが、その半面VCCやGNDとの短絡も発生しやすくなるのがつらいところです。

使用しているマイコンは48ピンのSAM3S4Aです。SAM7Sと比べると、次のような点が非常に嬉しいです。

• UDP(USB Device Port)がUSBプルアップ機能を内蔵しているので、GPIOを消費しない。
• RTC内蔵なので、外付け不要。
• PLL用の外付けRCが不要になった。
• TWI(I2C)でPDC(DMA)が使えるようになった。
• 12MHzのクリスタルが標準になったので、入手が用意。

SAM7では18.43MHzというボーレート生成向けの周波数が標準だったため秋葉でも安く買えなくて不便でしたが、今回は32KHz, 12MHzともに秋月で調達。RTCのための32KHzクリスタルを付けると、USARTでRTS/CTSが使えなくなってしまうのがちょと残念かな。

SAM3S4Aの上に配置されているのは32ピンのAIC3254。今回はアイテムラボの変換基板を使ってみました。AIC3253が24ピンだったので、パッケージは一回り大きくなりましたがコア電源用のLDOを内蔵しているので、わたしの用途では実質的な部品面積は小さくできます。最初からこちらを使っていれば良かったんですが。。。

CODECの上にはBluetoothのWT32がかぶさる予定で、ソケットだけ立てました。左上のソケットは20ピンのARM標準JTAGソケットですが、これも場所取るのでこの実験ボードでSWDを使うことを覚えて、プリント基板製作時にはこのJTAGソケットを取り去りたいと考えています。

曲情報表示

前回の記事で書いたようにしてAVRCPを使って受けた曲情報を、LCD画面に表示できるようになりました。もちろん、曲が変わると表示も更新されます。



曲名部分には東雲フォントの14ドット、アーティスト名とアルバム名の部分には同12ドットのフォントを使っています。スペアナ表示部分については、不要なディレイを削ったり、LCDの表示速度に合わせてSPIのクロック速度を12MHzに設定したりした結果、毎秒36回くらいの書き換えが可能となりました。変化する棒グラフ表示部分だけをDMA転送を使って更新することで この性能が達成できています。



HFPで受信したアンテナ信号強度と電池残量も一緒に表示できますが、まだ着信時の相手側電話番号や、通話画面への変更といった機能はできていません。何より着信応答するためのボタンとかのUIが無いので、いまだにUSBシリアル経由でのデバックコンソールからのコマンドで操作するしかありません。これらの機能を組み込む前に、もうすこし曲情報表示に機能追加するつもりです。それは、表示したい情報の文字数が多い場合に1行に入りきらなくなるので、横スクロールする機能です。曲情報をスクロールするとなると、それだけ更新が必要な画素数が増大してしまうので、書き換え回数も減ってしまうはずですが、どの程度遅くなるかちょっと不安です。

まだまだドッチーモ機能の実現までは時間かかりそうなので、W-SIMを外してBluetooth HFP/A2DPヘッドセットに徹したプロジェクトも並行して進めようと考え、新たな基板の製作を開始しています。なんとか「トラ技オフ会」までにもう少し見てくれの良いものを動かそうと思い立ったからです。こちらの基板については、また次の記事以降で取り上げていくことにします。

# ちなみに発売から1カ月ほどたった Interface付録のRX62基板は
# いまだに開封すらできていません。

曲情報を受けるには

フォントの準備ができたので、いよいよAVRCPを使って再生中の曲情報を入手してLCDに表示することにします。まずは、どうやって曲情報を入手するかをおさらいしておきます。

曲情報を拾うためにはWT32のavrcp pduコマンドを使って、その要求を出してやります。するとプレーヤ側が応答として要求した情報を送出してくれます。ここまでの実験はすでに以前の記事でも書きましたが、サンプルを再掲しておきます。



こうやって曲名、アーティスト名、アルバム名を入手することができますが、これは現在再生中の情報を入手するための手段です。実際にコントローラ機器として使用する際には、いちいち情報入手のためにボタンを押したりする操作なんかしていられません。再生が始ったり、次の曲へ進んだりしたら自動的に新しい曲の情報を表示してくれなきゃ困ります。そこで、再生中のトラックが変わったりした時に、通知を受ける仕組みが用意されています。AVRCPでは、この通知をもらう条件を指定して、その要求を出しておきます。



要求を出すと、いったんINTERIMという応答が返ってきますが、これは要求がプレーヤ側で受理されたことを示す応答です。そして実際に曲が終わって、次の曲へ進むと...



というように「トラックが変わった」という通知が届きますので、続いて曲情報の要求を出してやればいいことになります。このようにトリガをかけられる便利な機能ですが、いったんトリガ条件が発生して通知が送られると、このトリガはリセットされてしまいます。連続して曲が変わったことを検出するためには、通知を受ける度ごとにあらたにトリガの要求を出し直す必要があります。とてもじゃないですが、手動でいちいちこれをやってはいられませんので、動作確認実験はここまでにしてプログラム書くことにします。

SPIフラッシュへフォントを入れた

SPIフラッシュへの書き込み手段が用意できたので、さっそく日本語フォントを用意して書き込み。それを使ってのLCD表示をできるようにしました。使用したフォントは東雲フォントの14ドットと12ドットです。



東雲フォントには16ドットも用意されていますが、横128ドットしかないこのLCDでは、ちょっと大きすぎると感じられたので使用しないことに。ANKと漢字フォントを14ドットと12ドットの2種類の大きさで用意しても360Kバイト程度でしたので、64Mビットのフラッシュ容量のうちの3Mビット分しか使っていないことになります。もったいないから、基板作り直すときにはフラッシュ容量を減らすことにしましょう。

NANDフラッシュではページ単位でのリードが必要でしたが、SPIフラッシュでは任意のバイト位置からの任意バイト数での読み出しが可能なので、アクセスはとっても簡単でした。AT25DF641では普通のSPIで利用できる Read Arraryコマンドと、SOだけでなくSI端子も出力に切り替えて2ビットを同時に出力に使うDual-Output Read Arrayコマンドの2種類の読み出し方法が用意されていますが、AT91SAM7SのSPIでは後者へは対応できないので、Read Arrayコマンドの方を使用。Read Arraryコマンドは対応クロック速度に応じてさらに3種類に分かれていましたが、一番簡単だけど低速な 03hを使用。低速とはいえクロック速度45MHzまで対応しているので、もともと48MHzで走らせているAT91SAM7Sには充分に高速です。48MHzだとスペックオーバになってしまうので、半分の24MHzで使うことにしました。現在の表示ルーチンでは一文字毎にフラッシュから読み出してはLCDに表示しています。フラッシュアクセスよりもLCD表示の方に時間がかかってしまうので、フラッシュのクロックをこれ以上速くしても、全体の性能はそれほど向上しないはずです。

トラ技オフ会

きょうは秋葉原でエレキジャック・フォーラムが開かれましたが、ずいぶんと盛況だったようですね。わたしは用事があったので、今年も見物に行けませんでした。この春はMTMも開かれないことになったので、このテのイベントとしては貴重な機会だったかもしれません。

わたしもこの秋のMTMへの参加を目指すつもりでいますが、この春は5/10に開かれる「トラ技オフ会」に参加します。どこまで完成度を高められるかわかりませんが、現在製作中のものを中心にデモするつもりでいますが、昨年製作の作品も持ち込むかもしれません。まだ、人数には余裕があるのでARMで工作されているかたは、参加してみてはいかがでしょうか。

SPIフラッシュへの書き込み

SPIフラッシュAT25DF641を追加したので、次のステップとしてこいつへの書き込みができるようにしなければなりません。2009年から2010年にかけて製作したMP3プレーヤではNANDフラッシュを使っていましたが、この時はSDカードももっていたので、フラッシュへ書き込みたいデータをSDカードからフラッシュへコピーするプログラムをマイコンに内蔵させることによって、書き込み手段を提供していました。しかし今回はSDカードをもっているわけではないし、それをわざわざ追加するのもナンセンス。

ひとつの方法として考えられるのはUSB MSCをサポートすることで、SPIフラッシュをパソコンのUSBメモリとしてアクセスできるようにすることです。そうすれば、書き込みは普通のパソコンから可能となります。こうして書き込んだデータはFatFsを使って読み込めば便利に使えます。しかしUSBは現在CDCをサポートしておりデバック用のコンソールとして使用しています。CDCとMSCの両方をサポートする複合デバイスを構築できればいいのですが、残念ながらSAM7Sではサポートできるエンドポイントが少ないため実現できません。

いざとなったら、CDCの仮想シリアルから読み込んだデータをSPIに書き込むという方法も考えられますが、ATMELが提供するマイコン内蔵フラッシュ書き込みツールであるSAM-BAには、SPIフラッシュへの書き込み機能も備わっているので、今回はSAM-BAを使ってみることにしました。SAM-BAでは起動時にターゲットのボードを選択しますが、AT91SAM7S256を使用しているSAM7S-EKボード上にはSPIフラッシュが搭載されていないため、その書き込み機能も当然のことながらサポートされていません。しかしながら、SAM-BAはユーザが自分で機能拡張したりカスタマイズすることが可能なように作られているので、今回はSAM7Sターゲットに対してAT25/AT26シリーズの書き込み機能を追加してみました。

まずGUIの部分はTclで書かれており、比較的簡単にSPIフラッシュのタブを追加することができます。同機能をサポートしている他のターゲットボードからコードを拝借して、ちょっと変更してやることでこんな↓ふうにSPIフラッシュの操作画面を追加できました。



Tclでできるのはあくまでも操作画面の追加だけであり、実際に書き込みをおこなうコードは別途必要です。SAM-BAのGUIを操作すると、SAM-BAはSPIフラッシュへの書き込みをおこなうコード(アプレット)をSRAM空間にダウンロードして、そのコードに制御を移すことで書き込みを行う仕組みになっています。この書き込みコードはソースコードとして提供されているので、これをgccを使ってSAM7S用にコンパイルしてやる必要がありました。

このような手順を経て、無事にAT25DF641への書き込みとベリファイが動作することが確認できました。

SPIフラッシュ

HFPの接続実験をしていたら、次第にスマホが欲しくなってきました。もっとも、わたしの場合アプリを使うことよりも、もっぱら実験機材として利用する方に興味があるのですが。。IS01/IS03はAVRCP 1.3にも対応しているようですので、HFPとA2DP/AVRCPの接続実験を1台でこなすことが可能であることが確認できました。他のAndroid端末もAVRCP 1.3に対応しているのでしょうか？

ここでいったんHFPの方は一区切りつけて、再度A2DP/AVRCPの方に取り組むことにします。スペアナ表示ができたので、次はやはりAVRCP 1.3を使っての曲名表示です。LCDを使うので、曲名だけでなくアーティスト名も一緒に表示可能にできます。この目的を達成するためには、日本語フォントを用意する必要がありますが、まずはそのストレージが必要です。と、いうわけでSPIフラッシュを追加しました↓。



使用したのはATMELのAT25DF641です。容量64メガビット。こんなに容量なくてもいいのですが、ついつい大は小を兼ねるという方向に考えて買い物してしまいます。同じSPI接続のデバイスであるLCD基板下の空いているスペースに配置しました。いっそのことLCD基板と一緒にしてしまえば、今後の使いまわしに便利だったのですが、LCDをつなげた時にはそこまで考えていませんでした。



AT25DF641を選択した理由は、他に適当なデバイスを知らないこともあるのですが、マイコンと同じATMEL製であることが大きな理由です。これは書き込み方法を考慮してのことなんですが、この点については次回の記事にしようかと思います。

miniDSPを用いたトーンの生成

HFPでの着信時の着信音はヘッドセット側で鳴らすことにしたので、その仕組みを用意しなければなりません。また、発信時にも呼出音(RBT)を生成してやる必要があります。これらの機能もCODECのminiDSP機能を用いて実現することにしました。PurePath Studio(PPS)が提供する部品には、トーン・ジェネレータも用意されているので、これを用います。PPSの画面をコピペしたいところですが、それは許されていないので、似たようなブロック図を描いておくことにします。



上図はHFPまたはW-SIMでの通話時に使用するminiDSPコードのブロック図です。PCM信号で受けた音声信号はu-Lawデコーダにより伸長されて出力されます。出力段にはセレクタが入っており、u-Lawデコーダからの入力あるいはトーン・ジェネレータのいずれかを選択するようにしています。着信や発信時にはトーン・ジェネレータを選択することで希望するトーンをユーザに聞かせ、通話が確立した時点で入力をu-Lawデコーダに切り替えるという仕掛けです。トーン・ジェネレータが生成するのはサイン波であり、１つだけでは単調な音になってしまうので2つ使って、和音を出すようにしています。生成する周波数やトーンのオン・オフはI2Cのレジスタで制御できます。

送信側は基本的に受信側と対称な構成ですが、トーン生成の必要がないのでよりシンプルになっています。PCM信号のサンプリング周期は8000Hzであり、4000Hzまでの周波数成分しか送れません。そこで、あらかじめ不要な高周波成分はローパス・フィルタを使って除去しておきます。

HFP接続での呼の状態はcallならびにcallsetup通知で知ることができますので、これを使って上述したI2Cレジスタを操作してやります。callsetupが1になると着信を示しますので、セレクタをトーンジェネレータ側に切り替えて、着信音の周波数設定ならびにオン/オフを周期的に行います。実際にはトーン生成タスクを作成して、この周期処理を担当させています。応答するとcallが1になってcallsetupは0になりますので、トーン生成タスクを終了させて、セレクタをu-Lawデコーダ側に切り替えます。

発信の際には相手側で呼出が始まるとcallsetupが3になりますので、呼出音を生成してやりますが、これも同じトーン生成タスクに担当させています。

こんな仕掛けでようやくと計画したとおりに動作するようになってきました。じつは、ここに至るまでに、重要なことを見逃していたためにしばらくトーン生成が動作せずに悩んでいました。それは通話が始らないとPCM信号は流れてこないということです。CODECが動作するためにはマスタクロックだけでなく、PCM信号のビットクロックとサンプル周波数を表現するフレーム同期信号が必要です。これらの信号は相手との通話が確立されれば、WT32側から流れてきますが、通話確立前の着信時や発信呼出時にはPCMクロックが流れてきません。そのためにトーン・ジェネレータが動作できないのです。この問題に気が付いてあわてて通話確立前にはホストCPUであるSAM7からクロックを供給してやり、通話が確立したらクロック供給源を切り替えるようにハードを変更しましました。PCM信号についてはこの記事で説明したように74HC157で供給源を切り替えるようにしてあったのですが、これに加えてSAM7を供給源として選択する必要が生じたのです。74HC157は2入力ですが、幸いなことにG端子を使って出力をHZ状態にすることができます。そこでSAM7からクロックを供給したい場合には、この機能を使って74HC157を無効化してやります。W-SIMあるいはWT32から信号を供給する場合には74HC157を有効にして、SAM7側のクロック出力端子のコンフィグをGPIO入力に変更してしまうことで、こちら側をHZにしてやることで問題を回避しています。

iPhoneともHFP接続してみる

昨日の記事には含めることができなかった、iPhoneとの接続のログが取れました。

iPhone 4, iOS 4.2
HFP 1 BSRF 495
HFP 1 STATUS "service" 1
HFP 1 STATUS "call" 0
HFP 1 STATUS "callsetup" 0
HFP 1 STATUS "battchg" 4
HFP 1 STATUS "signal" 5
HFP 1 STATUS "roam" 0
HFP 1 STATUS "callheld" 0
HFP 1 READY
HFP 1 NETWORK "SoftBank"

ネットワーク名も出力してくれました。ここまでは良かったのですが、試しに着信を入れてみると。。。

HFP 1 STATUS "callsetup" 1
RING 4 7c:c5:37:a6:41:de SCO
HFP 1 RING
HFP 1 UNKNOWN (0): \r\n+CLIP: "03XXXXXXXX",129,,,"?? ?? (Mobile)"\r\n
HFP 1 RING
HFP 1 UNKNOWN (0): \r\n+CLIP: "03XXXXXXXX",129,,,"?? ?? (Mobile)"\r\n
HFP 1 RING
HFP 1 UNKNOWN (0): \r\n+CLIP: "03XXXXXXXX",129,,,"?? ?? (Mobile)"\r\n
> hfp answer
> @1 answer
HFP 1 STATUS "call" 1
HFP 1 STATUS "callsetup" 0
HFP 1 VOLUME 8

CLIPの出力をパースしようとして、エラーと判断しているようです。どこが気に入らないのでしょうか? コロンの後にスペースが入っているからか、あるいはサブアドレス情報の部分が連続カンマで省略されている部分がデコードできずにエラーとしてしまっているのでしょうか？このどちらかが、原因だと想像しています。iWRAPのファームのバージョンアップで直るかもしれないと思い、Bluegigaのサイトを覗いてみましたが、新しいファームは公開されていないようです。