加速度ログを採ってみる

新しく作ったボードでSAM3Nを使ったLチカができたので、今度はSAM3Sの方を使って加速度センサーとSPIフラッシュを使ってみました。




SPIフラッシュにはFatFsを使ってファイル書き込みができますので、加速度変化のログを記録する実験をやってみました。これまで、MMA8452QやMMA8652FCではイベント検出の実験ばっかりやっていて、加速度データを直接読み出すような「普通の使い方」をまったくやっていませんでした。今回はMMA8652FCのFIFOとHPFを有効にして、取得した加速度データを記録してみました。

MMA8652FCではMMA8451Qと同じように32サンプル分のFIFOが用意されています。12ビットの分解能で使用した場合には、実際のデータは2バイトになりますが、このデータをX, Y, Z軸の各軸毎に32サンプル分FIFOに貯めておくことができますので、2×3×32=192バイトの容量のFIFOを持っていることになります。今回はデータの出力レートを200Hz、FIFOの動作モードをFillモードに設定。この設定だと32サンプル分のFIFOが一杯になると割り込みで知らせてくれますが、それには160msかかることになります。そのため、読み出したデータをSPIフラッシュに書き出していても充分に時間に余裕があります。そこで、取得したデータは、FatFsのf_printf()関数を使ってCSV形式で書き込むことにしました。

データが記録できたら、MSCを有効にしてボードを再起動。記録したファイルを読み出してGoogole DriveのSpread sheetでグラフ化してみました。縦軸の値は12ビットのデータを16ビットに左づめしていますので、実際の値を16倍したものになっています。




ダブルタップを３回行った様子です。タップ操作では、急峻な加速度変化が生じていることが良くわかります。




こちらは、基板を縦に持った腕を振り下ろしてみました。しっかりと振り止めたつもりでもタッピングと違って反動が続くことがよくわかります。

どちらの例もハイパスフィルタ(HPF)を有効にしていますので、静的に加わる重力加速度成分が打ち消されたデータを読み取ることができています。そうは言っても、HPFが重力加速度を消し去るにはいくつかサンプリングしてみなければならないはずです。ダブルタップの例ではZ軸、振り下ろしの例ではX軸の加速度値が最初に下がってほぼゼロになっているのが読み取れます。これは、タッピングではZ軸を上にて基板を置き、振り下ろしではX軸を上にして実験を開始した事実と符号しています。この立ち下がり時間が、HFPが働いて重力成分を消し去るのに要している時間なのでしょう。

新基板へ移行

CDC+MSCのドライバとFatFsを入れたMiniSAMボードですが、今後の開発は新たに製作したボートに舞台を移して作業することにしました。このボード１ヶ月以上も前に届いていたのですが、製作が後回しになっていました。




基本的な構成は似たようなものなのですが、外観的にはARM10ピンのJTAGコネクタに変更したのが一番の違い。一度ケーブルを入手してしまうと、この大きさと使いやすさは大きな魅力です。




新旧のボードを並べてみたところ。右側の新ボードでは使用する部品も一部変更しています。大きな変更は加速度センサーをMMA8452Qから同じくFreescaleのMMA8652FCに変更したこと。パッケージは3mm×3mmのパッケージから2mm×2mmのパッケージに小型化されていますが、0.5mmピッチ16ピンから0.4mmピッチ10ピンへと変わっています。パッケージが小さくなったからといって基板が小さくなるわけでもなく、ピン間が狭くなることでハンダ付けが難しくことを心配していましたが、実際にやってみると、心配したほどではありませんでした。

• 16ピンのMMA8452では四方にピンがあるので、ハンダ付けの際に位置がずれてしまわないように注意が必要だったが、10ピンMMA8652では両サイドにしかピンがないので、位置ずれの心配や影響が少ない。0.4mmピッチのハンダ付けも思ったより簡単だった。
• 機能的にはMMA8652はMMA8451とほぼ同等であると思われる。新製品のせいか、MMA8652の方が価格は安い。
• ピン数が少なくなった影響でI2Cアドレスの選択はできなくなったけど、とりあえず自分には影響なさそう。

裏側では使用するSPIフラッシュをAT45DB161DからAT45DB642Dへ変更。パッケージが違うのですが、ピン間は同一だったので基板パターンは変更せずにハンダ付け。アンチエイリアス処理のためにピクセルあたり4ビットから８ビットの深さのあるフォントビットマップを使おうと思うと16Mbitの容量ではフォントだけでいっぱいになってしまいそうなので、一気に大容量化してみました。

ついでにもう一枚作成。こちらはLチカ遊び用に用意しました。


このボードは電池で使うことを前提としていますので、レギュレータやUSB関連部品を搭載していません。USB使わないので、水晶も使わず内蔵RC発振器で動作させます。写真がピンボケになってしまったので、わかりずらいのですが実はマイコンもSAM3S4Aではなくて、SAN3N0Aを使っています。SAM3NはSAM3SからUSBを取り去って安価にしたような製品です。今回はフラッシュ容量32KBのSAM3N0Aを使用。これで、一応SAM3Nにも手をつけたという自己満足達成が一番の目的なんですが。

CDC+MSC -- その２

CDC+MSCが動き始めました。FatFsとの競合を避けるために、電源投入時にはUSBはCDCで動いて、FatFsが動作可能とすることにしました。

いったんUSB CDCで仮想コンソールを開いて、MSCの動作を許可してリセットすることでMSC+CDCを起動します。


FatFsで設定したラベル名を持つディスクが見えるようになりました。


MSCが動いている状態では、FatFsでの読み書きをしようとするとエラーとなります。
再度、設定を変更してリセット。

FatFsでマウントしてやると、コピーしたファイルがちゃんと見えます。

ちゃんと読み書きできているようですが、書き込みややたらと遅い。もう少し調べねば。。

Revision History

今月始めにSAM3のUnique Identififerについて記事を書いたのですが。。。

久しぶりにATMEL ARMのページを訪れて最近の文書更新を確認。SAM3Sのデータシートが更新されているのを見つけたのでダウンロードしてRevision Historyを確認してみると。。

なんと「Unique Identifierの格納される番地を0x400000-040008F番地に変更」と書いてあるではありませんか!! 前の版を開いてみると0x80000-0x8000F番地となっています。アドレスが変わっているって、どういうことよ!? おまけに、Uniq Identifierは 128bitしかないはずなのに、範囲まで広がっているし。。。アドレス範囲は誤記だとしても、アドレスが変更されたことは間違いないようなので、実際の動作を確認してみました。



同じ内容が読み出せました。最新データシートによるとSAM3S1xに限って Rev Bのデバイスが出荷されているようなので、Rev Bでは古いアドレスではIDを読み出せないといった都合があるんじゃないかと想像します。

CDC+MSC

FatFsに続いて、今度はCDC+MSCのUSB複合デバイスのドライバを整備中。同様の作業は以前AT91SAM7Aを使ってやったことがあるのですが、その際は基本実験だけで実用的には使用していませんでした。今度はちゃんと使ってみるつもりです。

ARM7コアであるAT91SAM7のシリーズで一番手頃だったのはSAM7Sでしたが、このデバイスではUSBのエンドポイントが４つしか用意されていませんでした。CDC+MSCをサポートするためには、それぞれのバルク入出力に２つのエンドポイントとコントロールにひとつの合計５つのエンドポイントが必要となるので、SAM7Sではこれを実現できませんでした。SAM3Sではエンドポイント数が８つに増えているので、問題無くCDC+MSCの複合デバイスをサポートすることができます。

MSCをサポートすることで、フォントを始めとするデータファイルを簡単にPCからコピーすることができるようになります。そしてこれをFatFsで参照することができます。逆にFatFsを使って書き込んだデータを後からPCで参照することもできますので、ロガーのようなアプリを作る場合にもこの機能を活かすことができます。しかしながら、FatFsとMSCは排他的に動作させる必要があります。USBでつながっていない場合にはFatFsを動作させ、USBでつながっている場合にはMSCを動作させればいいのですが、そのためにはマイコンを電池駆動してUSBをセルフパワーで動かす必要があります。

現在のところMiniSAMボードはUSBパワーで動かしているので、VBUSのレベルを見て動作を区別するわけにはいきません。それにFatFsを動かす時でもUSB CDCでのアクセスが使えた方が便利です。そこで、USBのドライバの動作としては、CDCとCDC+MSCの両方をサポートすることとし、これを切り替えて再起動することで両方の動作モードを使うことにしました。

unique identifierを読み出してみる

SAM3マイコンは、それぞれのデバイスに固有の128ビットの識別番号を持っています。以前からUSBのDevice Desciptor中のシリアル番号情報を生成するために使ってみようと考えていたのですが、すっかり後回しになってしまっていました。これまでシリアル番号情報は001で決め打にしてあったのですが、いい加減ちゃんと生成しようと思い立ち作業開始。

まずはシリアル番号の読み出し動作を確認します。SAM3SではEEFCというフラッシュのコントローラに対してコマンドを送ることで0x80000番地からの16バイトに格納されている128ビットの識別番号が読み出せる仕掛けになっています。この読み出し処理をおこなうプログラムを書けばいいわけですが、フラッシュのコントローラを操作する都合上、そのコードはフラッシュから実行することができません。したがって、SRAMの空間にプログラムコードを配置して、実行してやる必要があります。

gccでの具体的な記述としては section attributeを指定することで、コードを配置するセクションを指定することができます。そして、指定したセクションをRAMに配置するようにリンカスクリプトを用意しなければなりませんが、調べてみるとCrossWorksではあらかじめ.fastというセクションがコードをRAMに配置するために用意されていました。そのため、次のようにコードを書いてビルドするだけでOK.

#define STUI    0x0e
#define SPUI    0x0f

/* To obtain 128bit uniq identifier, code needs to run out of RAM */

void get_uniq_identifier() __attribute__((section(".fast")));

void get_uniq_identifier(uint8_t *uniqId)
{
  uint8_t *pUniq = (uint8_t *)0x80000;
  int i;

  ctl_global_interrupts_disable();
  EFC->EEFC_FMR |= EEFC_FMR_SCOD;
  EFC->EEFC_FCR = EEFC_FCR_FKEY(0x5a) | STUI;
  while (EFC->EEFC_FSR & EEFC_FSR_FRDY) ;
  for (i = 0; i < 16; i++)
    *uniqId++ = *pUniq++;
  EFC->EEFC_FCR = EEFC_FCR_FKEY(0x5a) | SPUI;
  while ((EFC->EEFC_FSR & EEFC_FSR_FRDY) == 0) ;
  EFC->EEFC_FMR &= ~EEFC_FMR_SCOD;
  ctl_global_interrupts_enable();
}

セクション名が.fastになっているのは、SRAMからは0ウエイトで命令を読み出して実行できるからでしょうね。実際に読み出してみるとこうなりました。

128ビットの番号とは言っても、実際にはアスキーコードで7桁の数字が２つ入っているようなので、文字列としても表示してみました。まぁ、これはこれで便利かもしれませんが。。

USB Device Descriptorのシリアル番号情報としては、こうして得られた固有識別番号の下７桁部分をそのまま借用することにしてみました。Mac OS Xにつなげてみると、次のようにttyデバイスが作成されました。

違うチップでも試してみましたが6桁分はちゃんと識別番号が反映されるのに、どういうわけか最後の一桁がいつも１になってしまいます。うーん、どうしてだろう? シリアル番号情報が正しく送信できていないように推測できますが、ubuntuにつないでlsusbした時にはちゃんと正しくシリアル番号が見えていました。

2枚目は電池で

MiniSAMボードの2枚目を製作。こちらは電池駆動で使ってみようかと思います。思えば、いままでLiPo電池は使っても、乾電池で動くようなものを作ったことがありません。これまでバックアップ用途で使っていた手持ちのCR2032をつなげてみましたが、今度はこれを主電源に使って動かしてみようかと思います。sleepとか deep sleep使わないと電池もたないでしょうから、これらの勉強するのも目的のひとつです。

小型LCDでもつなげたいところなのですが、手持ちがないので、とりあえず手持ちの２色LEDで動作状況表示することにしてみます。スペースもあったので、なんとなく２つ使用。ずいぶん前に買ってあったのですが、改めてみるとこのLEDは赤、緑、赤になっており、赤が２つ入っています。なんかうまい使い方あるんでしょうか？

SAM3S4Aボード - その2

ひととおりの部品のハンダ付けを完了。いつものようにJTAG接続で、デバイス認識できるところまで確認できました。



SAM3S4Aだけのボードでは面白くないので、基板にはいくつかのオプション部品を搭載できるようにしてあります。今回は試験のためにフル実装することに。まずはSAM3Sのすぐそばには加速度センサーのMMA8452Qを載せられます。このセンサーは、自由落下検出はもちろんのことタップやダブルタップの検出、縦横向きの検出機能等も備わっているので、使い方を覚えるといろいろと便利に利用できそうです。問題はパッケージが3mm×3mmのQFPであり、小さくてハンダ付けが難しいことなんですが、お値段が128円＠Mouserと大変に安かったので、ダメもとで挑戦してみました。なんとかハンダ付けできたと思うのですが、I2Cで操作するソフト用意しないと動作確認できません。

主要部品は表側に配置してありますが、裏側にもオプション扱いの部品を２つ実装できるようにしてあります。ひとつは、32KHzのクリスタルで、もうひとつはSPI接続のData Flashです。この基板単独でも加速度センサのデータをData Flashに記録する用途に利用できることになります。運良く手持ちのAT4DB161Dを発掘できたので、これを実装。



JTAG用のヘッダピンは２列になっています。上側の列の5ピンはVCC, nRST, SWDIO, SWCLK, GNDとなっており、SWD接続ならこれだけで用が足ります。下側の２ピンはTDI, TDOでありJTAG接続したい時に追加で使用します。今回は、JTAG接続することとし、変換アダプタを用意。



アダプタ装着時はこうなります。



はい、アダプタの方が本体ボードよりもひとまわりデカいです。ヘッダピンの横にあるタクトスイッチはリセットです。レギュレータとSAM3S4Aの間に2ピンのジャンパを実装できる穴が用意されていますが、これはERASE端子のジャンパ用です。ショートすることでSAM3S4Aのフラッシュを強制的に消去することができます。SAM-BAを使ってフラッシュへ書き込む場合を考慮して用意してありますが、JTAGを使うぶんには必要ありません。

SAM3S4Aボード

OLIMEXからSAM3-H256が出てからは、ちょっとした実験や工作にSAM3-H256ボードを使っていました。値段が手頃なこともあり、CMOSカメラをつなぐにはSAM3S4Bを使ったこのボードは大変便利に使えましたが、ちょっとした実験をするには不向きな点もあります。SAM3-H256ボードは10x2ピンのソケットがふたつついており、ブレッドボードに挿すこともできません。そのため、いちいちユニバーサル基板に配線する必要が生じます。USB接続もBコネクタなので、ボード高も高くなってしまいます。秋月のアクリルケースに保管したくてもフタが閉まらなくて悲しい思いをしていました。

SAM3S4Aでいいので、もう少し小さいボードがあった方がちょっとした実験には便利だろうと思い立ち、Fusion PCBで基板つくってみました。



SAM3-H256と並べてみるとこんな感じ。使用デバイスが64ピンから48ピンになっていますので、ひとまわり小さくなります。



USBはミニBにして、場所を喰うARM標準20pin JTAGコネクタを使わないことにしました。JTAG接続はアダプタを介して接続することにします。

7月出荷予定

久しぶりにDigikeyを覗いて、何気に"SAM3A"で検索をかけたところが、結果が出てきてビックリ。SAM3A, SAM3XのDigikey型番が登録されており、値段も載っています。でも、残念ながら全て在庫ゼロ。「これは、もうすぐ入荷されるという前触れなのかぁ??? 」と期待して試しに数量入れてみると、出荷予想は７月４日と出ました。

SAM3A/SAM3XではUSB OTGがサポートされて、ようやくとホスト機能が使えるようになります。SAM9ではOHCIがサポートされていましたが、SAM3A/3Xでは独自のmini Host機能だけのようです。最小でも100ピンなので工作するにはハードル高いのが難点ですが、在庫が入り次第注文せねば。