いよいよ困った -- その2

AT91SAM7SE256の内蔵フラッシュへの書き込みが必ず失敗するようになってしまったので、MCUを交換してみました。追加購入したピッチ変換基板の上に、MCUとチップ抵抗(0Ω)とチップコンデンサ(0.1uF)をハンダ付けして、変換基板ごと交換してみました。

ところが、書き込み後にベリファイするとやはりエラーになります！　ショックです。何が悪いんでしょう。前回の基板の時と同じように128Kを少し過ぎたあたりで、エラーが発生しています。製作開始時にAT91SAM7SE256はふたつ買ってあったのですが、これでどちらでも同じ結果となってしまいました。もっとも、このふたつ、同一テープ上に並んでいた２つをカットしたものですから、ロット不良が原因であれば症状が同じでも当然の結果なんですけど。

当面の対策は尽きはてました(ガックリ)。しばらくダマシダマシ使うか、MCUを追加で買うか、いっそのこと作り直すかしかありません。かなり凹んだので、しばらく気分転換に他のことしようかなぁと思い、新たなボードを手配中です。

気になるLCD

タッチパネル・ジャケットではTechToysの3.2インチLCDを使っているのですが、このLCDが売り切れ(SOLD OUT)状態になってしまい、今や値段も表示されていないようです。2, 3日前に見た時には旧製品(OBSOLETED)と書かれてたような気がします。どうやら、その代わりに新たに2.8インチのLCDが発売になったようなので、ざっと仕様を確認してみました。

• LCDのサイズは小さくなったが、ペースボードの大きさとヘッダーの端子数は同じ。端子もほぼ同じなので、最小限のハード/ソフト変更で3.2インチの代わりに使用可能。
• LCDコントローラはILI9320からILI9325に変更。まだ詳しくは調べていないのですが、機能的には大きな違いもなくほとんど同じように使えるように思えます。
• タッチパネル・コントローラと32MB NANDフラッシュには変更無し。16bitインタフェースが基本で、8bitラッチの使用で、8bitインタフェースも可能な点も同じ。
• LEDのドライバは、LCDモジュール内ではなくボード上に実装されている。3.2インチの時と同じようにPWMで明るさ制御可能。
• お値段はUS $89.00. 旧製品の3.2インチは$85.00でした。

こうしてみると、使い勝手にはほとんど違いがなくて、画面が若干小さくなっただけのようにも思えますが回路図を比べてみて、大きな違いが１点あることに気が付きました。ヘッダピンに出ているデータ線16本の上位と下位が入れ替わっています。

3.2インチ製品では32MBのフラッシュのデータ線には16bitのうちの上位8bitがつながっており、ほんとは8bitのフラッシュなのにあたかも16bitのように操作することでAT91SAM7SEの持つNANDフラッシュ・インタフェース機能を利用していました。また、それが原因となりAT91SAM7SEのECC機能を活用することができませんでした。今回の2.8インチ製品を使えば、この問題が解決されて、素直に8bitフラッシュとしてプログラムが組めてECC機能も利用できるようになるはずです。

うーん、いつか換装してみたいものです。

いよいよ困った

以前にも書いたように、MCU内蔵フラッシュへの書き込みが失敗するようになって困っていましたが、いよいよ深刻になってきました。近頃では多少コードサイズが増減しても、もはやべリファイが成功することはありません。必ずどこかでエラーとなります。エラーの発生する箇所によっては、LCD画面が初期状態まで進まないことすらあります。運が良ければエラー箇所を通らずに済むので、問題なく動作することもあります。時には、しばらく動いてから突然ハングすることもあります。これでは、動作がおかしいのが書き込みエラーに起因するのか、バグが原因なのかを区別することすら容易ではありません。

エラーの発生する原因はMCUのフラッシュなのかもしれませんが、他の可能性もあるかもしれないと思い、いくつか調べてみました。

• まず、書き込みに使っているKrisTechのデバッガが原因かもしれないと考え、書き込みソフトとしてOpenOCDを使ってみました。やはり、Verifyを入れると終わりの方でエラーが発生します。
• 同じくKrisTechのJTAGインタフェースが原因かもしれません。あいにくと、他のJTAGインタフェースはもっていないので、これを交換してみることはできません。そこで、JTAGは変えずにボードの方を代えてみることにしました。AT91SAM7SE256の代わりにAT91SAM7S256のヘッダーボードSAM7-H256に同じイメージを書き込んでみました。エラーは発生しません。
• JTAG信号にノイズが乗っているおり、そのために動作が不安定になっているかもしれません。JTAGクロックとして6MHzを使っていましたが、これを1MHzにしてもやっぱりダメです。

やはり原因はボードあるいはMCUの方にありそうです。うーん、どうしましょうか。MCUの交換を試す必要はありそうです。

タッチパネル・ジャケット -- Google Mapsの表示

タッチパネル・ジャケットを使ってのGoogle Mapsの表示の様子を動画にしてみました。表示速度が遅いのが問題だったのですが、どうやら電波の受信状況が原因だったようで、今回は操作に対する応答も、画面が表示されるまでの速度もさほど気になりませんでした。D4の発売に合わせて始まった「"話し放題"お試しキャンペーン」により、「新つなぎ放題」でも音声通話が可能になったのを契機に、契約を「新つなぎ放題」に切り替えたのも少しは影響しているのかもしれませんけど。



タッチパネルを操作する度にTCPを張り直して、HTTP GETの要求を送信して、新しい画面を取得しています。地図画像データを広めに取得しておいて、カッコよくスクロールしたいところですが、そこまでの処理はちょっと難しそうです。メモリ節約するためには、JPEG形式で表示できるようにしなければいけなくなるでしょうし。。。

タッチパネルはちゃんとキャリブレーションしていないので、タッチした位置とズームレベルの変更動作がうまくいっていないところもあります。まぁ、ご愛敬ということでご勘弁を。。

LPC2478

どうやらLPC2478が市場に流れ始めたようです。OLIMEXのLPC-2478STK紹介ページも内容が更新されたようです。素人臭さを漂わせるアルミ板のパネルがちょっとねぇ。販売を開始する前に夏休みに入るんじゃないかと思っていましたが、値段もPrice Listに載りましたから、ファーストランで作った分だけ、休み前にさばくつもりなのでしょうか。200ユーロですか。タッチパネルLCDがついているとはいえ、ユーロ高のおり、ちょっと高いですね。


Digi-KeyやMouserでもチップの販売を開始したようです。先週末の時点では、Digi-Keyも在庫あったのですが、きょうは売り切れになっていました。15ドルしないんですね。何て安いんでしょう！208ピンパッケージなので、変換基板とユニバーサル基板で配線していたのではかなり大変な作業になるであろうことは想像できます。でも、18bitとか24bit RGBでLCDつなげられるのには興味をそそられます。死蔵したままになっている18bit RGB LCDが全部で3枚もあるもので。。。

タッチパネル・ジャケット -- 発呼と録音/再生

ようやくとW-SIMジャケット第３弾、タッチパネル・ジャケットの動画を用意しました。ダイアル・パッドの数字も以前は字が細かったので、FreeTypeの機能を使ってボールド化して使っています。いまだに電界強度や電池残量の表示が用意できていません。表示アイコンがまだできていないのですが、そもそもDISP信号や電池電圧検出のための配線もまだできていません。そろそろ各ピンの用途も確定したので、残りをDISP信号に割り当てて配線にケリをつけようかと思っているところです。



いつもと同じように天気予報にかけていますが、通話状態になったら、「録音」ボタンを押して録音を開始できます。「停止」ボタンで録音を止めてから、「切断」ボタンで呼を切断です。再生操作はメニューボタンで再生を選択して行います。今のとこ、「再生/停止」のトグルボタンしか用意していませんが、進行状況表示バーのインジケータを動かすことで再生位置を変更できるようにしてみました。タッチスクリーンを使うことで、ボタンの数や位置、そして大きさを自由に変えられるのはやはり便利ですね。

きれいにデザインしたビットマップでボタンを作れれば、もう少し見かけも良くなると思うのですが、作業が面倒そうです。ビットマップのデータ量もバカにならないので、フラッシュに格納しておくことも必要になるでしょうから、さらに面倒そうです。録音と再生の機能確認を優先して作業したので、ダイアル中と通話中も同じキーパッド画面になっています。通話中画面を用意して、そこに録音ボタンや音量調節ボタンを用意した方がいいかなとは思っています。タッチパネルを使うことで自由度は大きくなったのですが、それを生かすのには根気が要りますね。

星空ナビゲータ

DWMの8月号に山崎尊永さんのARM基板を使った製作記事「星空ナビゲータの製作」があるようです。

山崎さんの製作記事はいつも入手性の良い部品を使っておられ、読んでいてもとっても楽しいしものですが、今回も期待を裏切らない内容のようです。昨年はインタフェースのV850、一昨年はDWMのARM7だったので、今年はCortex-M3とFR60のどちらの製作記事になるのだろうと思いながら待っていました。6月号でJTAGインタフェースの記事があったので、これで今年は終わりかと思ったのですが、JTAGはナビゲータ製作の序章だったのですね！

DWM先月号のフォトフレームの製作記事は、JPEGライブラリも入っておらず、あらかじめ画面サイズに合わせてBMP形式で写真データを用意しておかねばならないような代物でたいそうガッカリさせられましたが、山崎さんの製作記事なら、そんな心配は無用でしょう。昨年のインタフェースに続いて、2か月連載のようです。

今回の製作では、5Hz更新のGPSに4D Systemsのタッチパネル付きOLEDを使っているので、豪華な構成ですね。

録音/再生が動いた

しばらく進展のない状態でしたが、ようやくとDataFlashを使っての通話相手音声の録音と再生が動くようになりました。

録音/再生で悩んでいたのは、次の2つの問題でした。

1. 再生時にCODECに供給するクロックをどう作るか？
2. 録音した音声を再生してみると、音が割れている。何が原因か？

まずはクロックの問題です。以前の記事にも書いたように、再生時にはCODECのBCLKとBSYNC信号をMCUから供給してやる必要があります。SSCの持つTK/TFピンを使ってこれらの信号を供給することができるのですが、この信号をどうやって作るかです。BCLKとBSYNCは同期しており、BSYNCは8000Hzの周期を持っている必要があります。実現方法として調べたのは次の2つの方式でした。

1. 2.048MHzをタイマ0を使って4分周して作った512KHzをBCLKとしてTKピンにつなぐ。TKピンは入力に設定。タイマ2を使って、2.048MHzをカウントして8000Hz周期のBSYNCを作成して、TFピンにつなぐ。TFピンは入力に設定。
2. 2.048MHzをタイマ0を使って4分周して作った512KHzをBCLKとしてTKピンにつなぐ。TKピンは入力に設定。SSCでTKクロックを数えてTFピンより8000Hzを出力。TFピンは出力に設定。

どちらもBCLKとして512Kを使うところは同じで、BSYNCの作り方が違うだけです。最初に１の方式で基本動作が確認できたので、次に２の方式を試してみました。1の方式ではタイマを2つ使うのに対して、2の方式では１つしか使わないので好ましいのですが、この方法だとちゃんと音が出てくれませんでした。原因の究明ができていないのですが、SSCが出力するデータのタイミングがCODECの受信タイミングと合致していないようです。SSCの設定を変更することで解決できるかもしれないのですが、とりあえず１の方式に戻して使っています。

BCLKは512KHzを使っていますが、ML7041 CODECのデータシートによるとMCKと同じ2.048MHzを使ってもかまわないようです。今のところ他にタイマを使う用途がないので、タイマを２つ使ってしまっていても問題はないのですが、もったいなくなったら、512KHzの生成はサボることにしようかと思います。

2つ目の「音が割れる」問題は、当初割り込み発生周期に処理が間に合っていないのかと想像して調査して時間を費やしてしまいました。試験データを書き込み/読み出して確認してみたところ、読み出しのコマンドを送出後、データの読み出し前に１バイト分のダミークロックを送信する必要があるのを見落としていただけのことでした。これが原因で、読み出した512バイトのデータが１バイト分ずれてしまい、先頭の１バイトが常に0xffになってしまっていたのでした。

DataFlashへの録音と再生の基本処理はできたのですが、まだ、タッチパネルからのユーザインタフェースが無いので、そいつを作らなくてはなりません。

耳が隠れているのが良くないのか？

製作中のタッチパネル液晶を使うと、どうもGoogle Mapsの表示が遅くて気になることは以前にも書きました。CODECを付けて音声通話発呼ができるようになっても、しばしばNO CARRIERのエラーがW-SIMから返ってきて発呼に失敗することがあるようです。

まだW-SIMのDISP信号を配線していないので電界強度の様子も見れていないのですが、どうやら電波の入りが悪いように思われます。発呼ができない時に、本体を寝かせずに手でささえて縦にしてしばらく待ってみると、ほぼ確実に発呼ができようです。LCDボードとCPUを載せている変換基板が大きいせいで、今回のジャケットではW-SIMがLCDボードの下に隠れてしまっています。その関係で電波の送受に影響が生じているように思われます。



どうやら青耳の部分は隠さずに、ちゃんと出しておいた方が良かったようです。

DataFlashを使うには

音声の録音媒体としてはATMELのDataFlashというSPIでつながるフラッシュを使っています。LCDボード上に32MBのNAND Flashが載っていますので、これを使うこともできるのですが、DataFlashはSPIを使ってどんなマイコンにでもつなげられそうなので、試しに使ってみたくなったのです。

実際に使っているのはAT45DB161の8ピンパッケージです。容量は16MbitですのでW-SIMから出力されるmu-Law PCMをそのまま記録しても4分程録音できる計算になります。データシートを読んでみてわかった概要を書きだしてみると。。

• 1ページ512または528バイトで、4096ページの構成。
• ページ単位での読み書き、消去ができる。ブロック単位での消去の必要がないので、ブロックを全く意識しないで使える。
• 書き込み(プログラム)に先立って、自動的に消去をしてくれるコマンドが用意されている。こいつを使えば、消去操作を意識せずに使える。ただし、最大で40msの時間が必要。
• 512/528バイトのSRAMバッファを2つ内蔵。ホストがひとつのバッファへの読み書きを実行している最中に、もうひとつのバッファとフラッシュの間でデータの読み書き(プログラム)を実行可能。

上図はデータシートからブロック図を抜きだしたものです。64K PCM音声では512バイトは1/16秒すなわち62.5ms程度ですので、2つのバッファを使わなくとも書き込み処理は間に合いそうです。しかし2つのバッファを使えば処理時間には余裕がありますし、逐次音声データを内蔵バッファに転送していき、内蔵バッファがいっぱいになった時点でフラッシュのプログラムを行うことにより、マイコン側で用意するバッファメモリ量を小さく抑えることができます。わたしは、SSCで64バイト受信する毎にDMA完了割り込みにより、録音タスクを起床させてDataFlashの内蔵バッファへの転送をおこなうことにしました。

DataFlashにはいくつもコマンドが用意されているのですが、次のコマンドだけで録音/再生に必要な読み書きは実現できるようです。

Opcode	Command
84h	Buffer 1 Write
87h	Buffer 2 Write
83h	Buffer 1 to Main Memory Page Program with Built-in Erase
86h	Buffer 2 to Main Memory Page Program with Built-in Erase
53h	Main Memory Page to Buffer 1 Transfer
55h	Main Memory Page to Buffer 2 Transfer
84h	Buffer 1 Read
87h	Buffer 2 Read
D7h	Status Register Read