Xplained Pro

ATMELの評価ボードとしてはXplainedが比較的手頃な値段で提供されているのですが、新たにXplained Proというのが出たようです。


本体のボードだけであれば$39という値段。STやNXPのボードに比べればまだ高いかもしれませんが、充分にお手頃感が感じられます。

SAM4Lを始めてみるのにいいかもと思っています。DigikeyやMouserには在庫ないので当面はAtmel storeから直接購入でしょうか。そもそもチップ単体も夏頃にならないと在庫入らないようです。Atmell storeはマレーシアからの出荷で送料が$22かかるみたいなので、やっぱしDigikeyやMouserから買えるようになるまで待とうかな。

店開き

今年に入ってからWCA-009が売れずにいるので、販売促進のために売店を開きました。


クレジットカードで購入できるので、振込手数料節約にはなるでしょう。当方にとってはカードの決裁手数料分だけ赤字になりますが、しょうがないですね。せっかく店を開いたので、WCA-009以外のものも並べてあります。昨年から製作しているLPC1114FN28を実装できるボードが中心です。



基板だけだと秋葉で入手できない部品が多数あるので、パーツセットとしました。LPC1114FN28を含む全ての半導体と主要コネクタ類を含むパーツセットですが、細かな部品であるチップ抵抗やチップコンデンサ等は含まれていません。



パーツキットはヘッドフォンアンプとマイクアンプが0.5mmピッチの表面実装部品となりハンダ付けに苦労するので、一応組み立て/動作確認済みのボードも準備中。



BlueHANDとして動作させるためには上の写真左側のようにキーパッド部分を載せなければなりませんが、今のところキーパッド基板の販売は予定していません。

現在、一部パーツを手配中であるとともに、資料の準備中です。そのためWCA-009以外は売り切れ状態としてあります。準備ができしだい「在庫あり」にするつもりですが、手持ちのパーツの都合もあり当初は１、２セット程度しか用意できないと思います。

消去に要する時間

MSC+CDCのドライバを使ってデータフラッシュ(AT45DB161D)への書き込みをおこな>うと、やたらと時間がかかる問題について調べてみました。 まずは、書き込み時間の計測から。

フラッシュの容量が2MBなので、これに近いサイズのファイルをコピーしてみました。 MacOS上でcpコマンドに続いてsyncすることでフラッシュへ書き出しましたが、およそ55秒もかかりました。33KB/secしか出ていないことになります。

フラッシュへの書き込みの際には、書き込もうとするページをいったん消去してから、書き込むという２段階の操作が必要となります。書き込みも時間がかかりますが、それ以上に時間がかかるのが消去です。チップ全体を消去するにはおよそ20秒が必要でした。 データフラッシュには消去と書き込みの一連の処理を一度にやってくれるページ書き込みコマンドがあるので、これを使っているのですが、改めてデータシートを読んで所要時間を確認してみるとページあたり平均で17msとなっています。1ページは512バイトなので、試験対象のファイルの書き込みには1855478/512*17=61607msとなり、61秒が必要となる計算です。遅いと思っていましたが、平均以上の速度で書き込めていたようです。ページ書き込みだけのコマンドであれば、平均3msしかかからないので、あらかじめ消去済みであれば、書き込み速度は大幅に向上することになります。

データを連続して書き込むような用途であれば、あらかじめ消去しておいてから書き込むようにするべきでしょう。今回は、フォントデータ格納が目的なので、一度書き込んでしまえば変更することもないので、原因がわかったことに満足して作業を進めることにします。

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の両方をサポートすることとし、これを切り替えて再起動することで両方の動作モードを使うことにしました。

ボリューム・ラベルを付けてみる

自作のMiniSAM3ボードに付いているDataFlashですが、今後の使い勝手を良くするためにソフトを用意していこうと思っています。構想としては、次のように作業を進めていくつもりです。

1. まずは、FatFSを載せて、アプリからのアクセス手段を用意する。
2. 次にUSB MSCドライバを作って、PCからDataFlashへファイル転送できるようにする。
3. フォントファイルをフラッシュにコピーして、LCD表示に使えるようにする。

以前製作したBlueSAMでのLCD表示を近くで見るとドットが目立ち、その前に作ったMP3プレーヤと比べるとあまりに見劣りするのが気になっていたので、この機会に改善してやろうと思い立った次第です。




両者の違いは画面サイズだけではなく、MP3プレーヤではアンチエイリアス処理を施して表示していたことが表示の質に大きく貢献しています。BlueSAMの表示もちゃんとアンチエイリアス処理してやれば、もっと綺麗になるだろうと思いわれます。表示処理に時間がかかり、スクロール表示が遅くなると予想されますが、どの程度遅くなるか試してみようかと思います。







まずは第１歩としてFatFsから。最新のR0.09bではボリューム・ラベルの設定/取得ができるようになったので、この機能を使ってみました。DataFlashの識別番号をラベル名に使おうかと考えていたのですが、内容がイマイチだったこともあり、SAM3Sの固有識別番号の方をラベル番号に使うこととしました。FatFsを載せる作業はこれまで何度も行っているので、特に問題もなく終了。ラベル付けの動作を確認しまいした。



上記のログの意味は次のとおりです。

1. 最初にdf chipでデータフラッシュのチップ全体を消去。
2. fatコマンドを使ってマウント(f_mount)後、ラベルの読み出し(f_getlabel)を試みるが、ファイルシステムが無いのでエラーとなる。エラーを検出して、f_mkfsをおこない、f_setlabelでラベル付けしておく。
3. 再度マウントすると成功するので、f_getlabelで取得したボリューム・ラベルを表示。

Made in Japan

EEVblog #418で、20年前のApple Newtonの内部を見ました。



まず裏蓋に「Made in Japan」と刻印されていることを、いまとなってはとっても新鮮に感じる。そうなんだよね。当時は当然のように感じていたハズのことが、いつのまにか特別なことになってしまっているんですよね。もちろん、箱の中身にもJAPANの刻印のついたチップがたくさん。ダイアモンド印のSRAMが載っているのを見て、20世紀にはまだルネサステクノロジすら設立されていなかったんだということに気付かされました。確認してみると、ルネサスができてまだ10年しか経ってないんですね。あぁ...

Data FlashのSecurity registerを読んでみる

前回、SAM3SのもつUnique Identifierを読み出してみましたが、そういえばボード上に実装しているATMELのData Flashにも同じような機能があったはずだと気がつき、調べてみました。



このボードに実装してあるのは、AT45DB161Dという16MbitのData Flashです。Security Registerとして64バイト分の容量があり、前半32バイトがユーザ側でOTPで書き込み可能な領域、後半32バイトが出荷時に固有の値が書き込み済みで変更できない領域となっています。読み出してみると.....



前半32バイトはまだ書き込んでいませんので、当然ながら全部0xffです。しかし、後半も0xffが半分あります。書き込み済みと言われても、「半分しか書いてないじゃん!」とツッコミたくなるような内容ですねぇ。

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した時にはちゃんと正しくシリアル番号が見えていました。