製品ロードマップ

先週発表になったSAM4S。気がつくと製品紹介ページができていて、そこにこんな図が。。



良かった、SAM3XもSAM3Aも来年出てくるようですね。SAM-BAも新しいバージョンが出ていて、こちらのリリースノートを見るとSAM3S8, SAM3S16, SAM3X8, SAM3X4, SAM3X2がすでにサポートされていることになっています。SAM3SDって、どういう構成かな？フラッシュの容量としてはSAM3S8と同等だと思われますけど。

今回もSAM-BAのパッケージに含まれるデバイスのヘッダファイルを覗いてみていますが、SAM3XとSAM3AはHigh speedでOTG対応になる模様。XとAの違いはEtherの有無でしょうか？SAM3Xでは100ピンを超えるピン数のデバイスも出すようですが、LCDコントローラはサポートしないように見受けられます。SAM3SでサポートされていたParallel Capture機能も,
SAM3Xではサポートされていないようです。CMOSカメラつなげるには手軽に使える機能なんですが、SAM3SではHSMCIと端子割当がだぶっているのが痛かったので、SAM3Xで改善されないかと期待していたのに。。

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のクロックとすることができます。

SAM3+CrossWorksの覚え書き

引き続き、MBAへの引っ越し作業を継続中です。いつも参照するドキュメントやコードをコピーするとともに、動作の確認。先週、CrossWorksを使ってビルドを確認したBlueSAMのコードもJTAGで書き込んで、動作確認。今回、引っ越しとともにCrossWorksとj-Linkのドライバを最新版にバージョンアップしたので、この機会にすべて設定をやり直してみながら、これまで疑問に思っていた点を再度確認してみました。

• j-Linkのクロック設定。TargetのJTAGとしてj-Linkを選択すると、ディフォルトではJTAG Speedは Best Possibleになる。ところが、これではJTAGがうまく動いてくれないので、500KHzに設定。仮想マシンで動かすことによるオーバヘッドがUSB JTAG動作に影響しないか心配だったけど、問題なく動いてくれているようだ。
• Flash書き込み時のVerifyエラー。SAM3S4Bのフラッシュへの書き込みをおこなうと必ずVerifyエラーとなる問題は解消されず。実際には問題ないので、スルーすることにする。SAM3S4Aへの書き込みでは、この問題は発生しない。
• CrossWorksプロジェクトのProject Properties -> Preprocessor Definitionsには、次の２つを追加する。STARTUP_FROM_RESET, EEFC_FMR_FWS_VAL=3.

いずれもバージョンアップでは解決されませんでした。追加する定義は、ふたつともSAM3Sのスタート・アップコードに関連するもの。STARTUP_FROM_RESETがないと、スタートアップコードの先頭で無限ループしているだけで、コードが実行されない。これは意図的にそのようなコードになっているのですが、JTAGつないでいた時にはちゃんと動いていたコードが、JTAGなしで動かすと何も動かないことになってしまうので覚えておく必要があります。

EEFC_FMR_FWS_VALは、内蔵フラッシュにアクセスする際のウェイト数を指定する。ディフォルトでは2になっていますが、3にしないとSAM3Sの動作がとっても不安定。しばしばHard Faultを発生してくれる困り者。データシートでは64MHzまでのMCKで動かす場合には2でもいいことになっているのですが、実際にちょうど64MHで動かしてみるとアウト。マイコンのチップ固有の問題かもしれないと思っていましたが、SAM3S4AとSAM3S4Bの両方で経験したので、これはもはやレビジョンあるいはフラッシュの基本的な問題なのでしょう。SAM7の時もそうでしたが、ATMELのフラッシュはアクセスにウェイトが必要となる結果、実際のアプリでの性能が他社に劣る場合がみられます。このあたり改善してもらわないと、クロックが72MHzとか96MHzとかになってもあまり嬉しくないよなぁ。

さて、こうしてビルドしたバイナリをフラッシュに焼いて、その動作確認のためにシリアルでつなごうとして、わかったこと２点。

1. Windows 7にはHyper Terminalがない。皆さんよくご存知のことでしょう。わたしもどこかで読んだ覚えはあるのですが、これまでずっとXPを使ってきたのですっかり忘れており、スタートメニューの中を探してしまいました。
2. 一方、Mac OS Lionには まだ cuコマンドが残っている!!

レガシーなデバイスを代表する扱いとなってしまったシリアルポート。Windows 7でHyper Terminalがなくなっても、普通の人は何の不自由も感じない時代になったということなんですね。Mac OS Lionでもモデムのサポートがなくなったと聞いていたので、cuが残っていることには逆の意味での驚き。いまだにuucp時代の遺物を必要とするアプリがあるんでしょうか？「さすがにcuはチョットねー」と思ったら、screenがあったのでシリアル接続にはこいつを使うことに。screenも原型は 4.2BSDだか4.3BSDの頃からあったと記憶していますが、ずいぶんと機能が増えているようですね。



９月２９日追記：
SAM3S CPUサポートパッケージのアップデートがあったので、これを当てたことろSAM3S4Bへのフラッシュ書き込みエラーの問題が解決された。また、このアップデートによりEEFC_FMR_FWS_VALのディフォルト値も変更になったので、自分で変更を指示する必要がなくなった。

SAM7S用ボードにSAM3S4Bを載せる

先日記事にしたaitendoのAT91SAM7S用ボードを購入して、SAM3S4Bを載せました。150円の値段の誘惑に負けて思わず2枚購入。SAM3S4Bはdigikeyで購入です。その他のパーツは、ほとんど手持ちの秋月パーツで間に合わせています。



LDOにはAZ1086H-3.3を使用。

クリスタルには表面実装タイプのコイツを使用。基板のパターンは普通のPTH用HC-49/Sだったのですが、クリスタルの足を無理やり伸ばしてやったらサイズは同じなので、普通に基板裏側からハンダづけできました。SAM3Sは内部RC発振器でも動作可能なので、12MHzクリスタルが無くても良いのですが手持ちが余っていたので付けときました。

なくてもかまわない部品は実装していないので、電源確認用のLEDやリセット用のタクト・スイッチも未実装になっています。

12MHzクリスタルを付けたので、USBが動作可能。そこでSAM-BAでデバイスが見えることを確認しましたが、JTAGの動作確認は未実施。OLIMEXのヘッダ・ボードと比べるとひとまわり大きいのですが、値段も安かったし気軽に実験に使えそうです。

SAM3S16C

ATMELがSAM3SシリーズにSAM3S16Cを追加しました。これまでは、SAM3S[124][ABC]だったのが、いきなり16Cと型番が飛びました。数字はフラッシュの容量に対応しており、これまで最大で256KBだったのが、一気に1024Kになったためです。

フラッシュ容量以外の違いとしては、SRAMも128KBと倍以上になっていますし、クロック速度も64MHzから100MHzに向上。これくらいしないと、LPC1300シリーズとかに対抗できませんよね。クロック速くなっても、フラッシュのウエイトが増えるだけだと哀しいわけですが、実質的にどの程度速くなるんでしょう。データシートと実際の製品が出てくるのが待ち遠しいですが、プレス発表によれば量産は来年らしい。そういえば、そろそろSAM3XとかSAM3Aも出てきていいと思うんですが、どうなっちゃてるんでしょうかねぇ。

2011-07-17 追記
データ・シートが出ていたので、フラッシュのウェイト数を確認。クロック60MHzまではFWSで指定するウェイト数が2になっているけど、80MHzでは3、100MHzでは4に増やす必要あり。

SWDを試す

実験するつもりだったのに、ずっと忘れたままになっていた作業をようやく実施。それは、SWDを使ってみること。

これまではARM7/ARM9の延長でずっと普通のJTAGを使ってきましたが、Cortex-M3では信号数の少ないSWDを使うことができます。幸いにしてわたしが使っているSAM-ICEとCrossWorksは、ともにSWD対応となっています。

まずは、SAM-ICEとBlueSAMとの接続。SWDの信号は全てJTAG信号と兼用になっていますので、これまでのJTAGコネクタをそのまま流用できます。しかし、JTAGコネクタをそのままつないでしまったのでは、どの信号が実際に使われているのかはっきりとわからないので、ジャンプワイヤを使ってつないでみました。つないでいるのは、VCC, GND, SWCLK, SWDIO, NRSTの５本です。



CrossWorks側の設定は、次のようにSWDを選択するだけ。



フラッシュへの書き込みとブレークの設定動作を確認。問題なく動いているようです。SWDを使えば信号本数少なくてすみますから、今後はコネクタを小型化できます。20PinのJTAGコネクタについては標準的なコネクタ配列がありますが、SWDについては標準配列やコネクタの記述をみかけません。検索するとどうやら、1.27mmピッチで10ピンというのがあるようです。1.27はちょっと不便なので、2.54mmピッチ10ピンで使うことにしましょうか。でも、これではコネクタサイズが半分にしかならないので、自己流6ピンを決めて使えばいいかな。

ナビ・スイッチへの機能割りあて

SAM3SのPIOを使うことで、チャタリング除去処理が不要になったナビ・スイッチですが、A2DP再生時には2つのナビスイッチ(Nav1とNav2)に次のように機能を割り当ててみました。

• Nav1 押すことでPlay/Pauseの切り替え。上下に廻すことで曲送り(forward)または前の曲(backward)へトラック変更。
• Nav2 押すことで機能選択。廻すことでレベル変更。

Nav2の方は機能スイッチとして働き、次の3つの機能をサポートしています。

1. 音量
2. 3D効果
3. スペアナグラフ表示形式変更

それぞれの機能を選択した場合の画面表示例を以下に並べておきます。スイッチの役割を画面右側に縦方向に表示していますが、これはchiakiさんのTimpyのアイデアを真似ています。



まずは初期画面です↑。最初は機能スイッチであるNav2スイッチは、音量調節として機能します。もちろん、上下に廻すことで音量が増減します。



音量表示の状態でNav2スイッチを押すと、Nav2の機能が3D効果調節に変わります↑。ほとんど同一の画面内容ですが、Nav2スイッチを上下することで効果の効き方が変化します。



さらにもう一度Nav2スイッチを押すと、スペアナ表示の形式を変化させることができます。と、言っても単に上下を変えているだけなんですが。。



トラックの変更と音量調整ができるだけで、かなりプレーヤらしくなってはきましたが、これだけではプレーヤ画面から抜け出せないので、メニューに移動するための手段として Nav1の長押しを割り当てています。現在、メニュー画面と時計設定画面も用意しているのですが、操作性の向上のためにリピート機能も欲しくなりました。そこで、現在これらの機能の実装中です。

ナビ・スイッチのつなげ方

BlueSAMではナビ・スイッチを2つ使っていますが、これらのスイッチは言うまでもなく、GPIO(ATMEL用語ではPIO)のポートにつながっています。



裏返すとこんなデタラメな配線が丸見え↑。長さもとらずにテキトーに線材を切って配線していたので、線がみんなたわんでいます。(^_^;)

きょうの記事ではSAM3Sをつかうと、GPIOにつなげたスイッチの処理が簡単になるということを書きとめておこうと思います。

マイコンを使っての実験の第1歩がLEDチカチカ(Lチカ)であるとするならば、その第2歩2としてポピュラーなのが入力スイッチの状態検出でしょう。ここで問題となるのが、スイッチの機械的なチャタリングです。そのため、スイッチの状態変化を検知したならば、しばらく待って同一状態であることを確認してから初めてその時点で変化を確定するという処理がおこなわれます。一時的に状態変化がバタバタとする期間の変化を無視するためです。

SAM7やSAM3ではPIOポートの状態変化は、割り込みで検出することができます。SAM7では短期間の入力変化ノイズを除去するGlitch filterという機能がありましたが、このフィルタで除去できるのはマスター・クロック(MCK)の半分までの長さのノイズでした。MCKはメガHz単位なので、除去できるのはナノ秒単位であり、スイッチの機械的なチャタリング除去には使えないものでした。そのため、SAM7ではタイマーを利用して一定時間待った後に、状態を再確認するソフトウェア的処理が必要になっていました。

SAM3では新たにDebouncing filterという機能が追加されています。Glitch filterがMCKを使っていたのに対し、Deboucing filterでは32KHzのクロックを分周したクロックで、判定期間の長さを指定できるようになり、機械的なチャタリング除去に利用できるようになりました。チャタリング除去後に、状態変化を割り込みとして発生することができるので、ソフトウェア側ではチャタリング処理を全く考慮せずに良くなりました。加えて、割り込み発生条件として立ち上がり/立下りのエッジも指定することができますので、1)スイッチを押した時、2)スイッチを離した時, 3)押し/離しの両方というように割り込みを発生する条件も指定することができます。

このようにdebouncing filterを利用すれば、これまでチャタリング除去の処理のために用意していたタイマーやタスク/スレッド/割り込み処理を不要にすることができるので、便利です。今回のナビ・スイッチの処理でも、この機能を使ってみました。もっとも、スイッチの長押しとかオート・リピートとかの機能が欲しくなると、やはりタイマやタスクが必要となってきます。現在のわたしが、この段階なんですが。

2007/01/01

SAM3SにはRTC機能があるので、きょうはその動作確認。電源を入れるといつも日付が「2007年1月1日」になっていることに気が付きました。改めてマニュアルで確認すると確かに初期値は「2007年1月1日」になっていましたが、マニュアルには16進数表記で記載されているだけでしたので、これまでは全く気が付きませんでした。こうして実際に表示してみて、その事実に気が付くと、「この仕様が決められたのは2007年のことだったのだろうか?」などと想像を巡らせてしまいます。



電池で動作するようにすれば、SAM3Sのバックアップモードを使ってRTCの内容を保持することもできるようになりますが、しばらくは電源を入れる度に2007年に戻ることになります。HFPで携帯電話機に接続した時に、携帯側から日付/時刻情報を取得することができればいいのですが、残念ながらわたしのドコモ携帯ではそのために必要なATコマンド(AT+CCLK)がサポートされていません。わたしの場合、スマホを購入する際の機種選択条件にはAVRCP 1.3のサポートに加えて、AT+CCLK対応も必須条件となりそうです。

PDC動作の違い

前回の記事で書いたようにSAM3S4AにつないだSPI LCDが初期化もできずにハマッテいましたが、ようやくとその原因がわかりました。

SPI LCDは書き込むだけで読み出しができません。そのため思いどおりに動いてくれていない状態では、正しく書き込めているかどうかが確認できません。そこで問題の切り分けのために、同じSPIにつながっているSPIフラッシュ(serial flash)の方の動作確認を先にとることにしました。SAM-BAを使ってAT25DF641への書き込みと読み出し確認がおこなえますので、SAM-BAで使うためのSAM3S4用のAppletを作成するところから作業を開始。SAM-BAに含まれるソースコードにはSAM3S用にはserial flash用appletのソースが用意されていなかったので、SAM3N用のコードに若干手をいれてやらねばならず時間とられましたが何とか無事にapplete作成に成功。さっそく試してみると、AT25DF641への書き込み/読み込みともに問題無く動作することが確認できました。これで少なくともSAM3S側のSPIが正しく動いていることは確認できました。

SPI LCD側を気づかぬうちに壊してしまったのかと、不安になりながらも作業続行。LCD側の配線は何度確認しても間違いないですし、ショートしている箇所もありません。しかたないのでLCDは後回しにして、I2C(TWI)でつないだCODECへのアクセス確認をしておこうと思い、レジスタへの書き込みとダンプ試験を実施。するとレジスタへ書き込んだつもりが、正しく読み出せない場合があることが判明。さらに調べると、初期化データを連続してPDCを使ったDMAで書き込み後、読み出してみると全く書き込めていないことがわかりました。

LCDの初期化でも初期化データを連続してPDCを使ったDMAで書き込んでいますので、どうやらDMAでの書き込みに問題があるということがわかりました。DMAでの読み出しの方は、リセット後のレジスタ初期値が正しく読み出せていますので、問題があるのは書き込みの場合だけのようです。

そこで改めてマニュアルを読み直してみたところ、バス・マトリックス(MATRIX)の説明部分でようやくと問題の原因を発見! PDCがマスターになった場合には、内蔵フラッシュメモリをスレーブとするアクセスができないという仕様になっています。そのためにフラッシュに書き込んである初期化データをDMAで書き込もうとしても書けないようです。試しにフラッシュから読み出した初期化データをいったんSRAMにコピーしてからDMAするように変更してやると、無事にCODECへの書き込みができるようになりました。LCDのアクセスにも同様の変更を施すことで、無事に初期化もできて文字表示できるようになりました。



SAM7Sではこんな制約はなかったので、すっかりはまってしまいました。これまでごく普通にフラッシュ上に配置したメッセージやデータをPDCによるDMAでデバイスに転送していましたので、今後もコードを移植する際には注意する必要がありそうです。