やさしさゴシック

やさしさゴシックボールドをLCDに表示してみました。



ちょっとボケて見えますが、深さ8ビットのデータを使って表示しているために輪郭のギザギザが抑止されており、そのためにより一層ボケた感じを受けるのかもしれません。文字は一文字表示するたびにSDカードからビットマップデータを読み出しているので、表示に時間がかかります。どうやら10文字程度表示するのに20msくらいかかりそうです。文字列が長い場合には横スクロール表示するつもりなのですが、このままではスクロール処理にともなう再表示に時間がかかりそうです。メモリに余裕があれば、表示イメージを全てバッファしておけば良いのですが、RAMは32KBしかないのでそうもいきません。
ちょっと一手間加える必要がありそうです。

USART SPIでSDカードアクセス

USARTのSPIモードを利用することで、SDカードの読み取りができるところまで動作確認できました。SPIモード初めて使ってみましたが、大きくつまずくこともなく、すんなりと動いたと言ってもいいでしょう。本来のSPIインタフェースと比べると、転送ビット長に制約があるとか、細かな動作タイミング設定に対応できないとかいった制約があるものの、SDカードアクセスやLCDアクセスといった用途であれば充分に用が足りるので、かえって使い易いかもしれません。

今回のSDカードの利用目的はフォント格納用なので、FatFsは読み取り専用で構成。SDカードへの書き込み処理も省略しています。フォントについては、これまではIPAexゴシックを使っていたのですが、このフォントはそのままではちょっと線が細めです。そこで、ビットマップに変換する際にボールド化処理を施して使っていました。最近出た何かいいフォントはないかと思って検索したところ、IPAフォントからの派生フォントであるやさしさゴシックボールドというのを見つけました。これなら、そのままビットマップ変換して、タイトル表示に使えそうです。早速10ポイントと13ポイントのビットマップを生成して、SDカードにコピー。



これから試しに画面表示してみます。

倍増

先日、新しい版のデータシートを見つけたSAM4Lですが、この版からSAM4Lファミリーに追加されたATSAM4Lx8の説明も追加されています。このデバイスは、Flashが512k, RAMが64KBとどちらもSAM4Lx4の2倍に増えたものです。

これまでRAM容量32KBはちょっと少なめかなと感じていたので、64KB への倍増はわたしにとっては嬉しい知らせです。調べてみると、すでにDigikeyにはすでに在庫あり。ところが、例によって「日本サイト」からだと発注できません。もう少し、待ってみますか。。

こんどは、SAM4LC8を買ってみて、USBホストに挑戦してみようかと思案中。

SDカード追加

SAM4LボードにSDカードを追加。LCDの下側に配置することにしました。



SAM3S/SAM4SにはHSMCIがあるのでSDモードの4ビット幅でSDカードをつなげられますが、SAM4LにはHSMCIが備わっていないので、SPIモードで接続するしかありません。今回はUSART1につないで、USARTがもつSPIモード機能を使ってみることにします。

SDカードの用途はフォントの格納ストレージです。これまではフォント格納用にSPIフラッシュを使っていたのですが、そこそこ容量の大きいものを使うと結構なお値段するので、使い勝手も入手性も良いSDカードを使うことにしました。容量たっぷりなので、フォントデータも単純なビットマップではなく、８ビットの深さをもったデータを使うことにします。

跳ね方で区別する

EEVblogにちょっと面白いネタがあがっていたので、貼っておきます。



アルカリ電池をちょっとした高さから落としてみて、その跳ね方から電池がカラになっていないかを判別できるというものです。もともと、元ネタとしてコレとかコレがあったようで、その真偽のほどを検証してみたという内容です。結論としては、跳ね方が違うのは確かだけど、判断手段として用いるにはあるていどの経験が必要だろうとのこと。

どうして跳ね方が変わるのかについての説明はありません。元ネタのひとつでは、化学変化に伴い内部にガスが溜まるからだと言っていますけど。

飲み会でのネタに使えるかも？

ピーク表示を付けた

LCD表示が問題なくおこなえるようになったので、スペアナ表示をちょこっと改良。バーの高さに応じて色を変えてみるとともに、ピーク表示を付け加えてみました。ピーク表示部分は時間経過とともに、下がってきます。



LCDへの表示は頻繁に更新しても視認性が良くないので、約30ms間隔でしか更新していません。もう少し落としてもいいかも。したがって、バー表示に関わる計算処理も必要な時にしか実行しないように変更。上の写真は、バーの色がわかるようにわざと画面更新を止めた状態で撮影しています。

画面更新間隔は30msにしたものの、その元となるデータはI2Sで受信したデータです。受信データが無くなると画面更新も止まるので、再生が止まってもピーク表示が部分的に画面上に残ってしまうことがありました。そこで、受信データが無くなっても、タイムアウト処理によりダミーデータを生成して画面更新をおこなうようにしています。

SPI最大クロック速度

前回の記事で気になっていた、SPI送信時の最大クロック速度。「1.6MHzは、いくらなんでも遅すぎない?」と思っていましたが、ATMELのホームページを確認したら今月になって最新版のSAM4Lデータシート(Rev.E)が出てました。

やっぱり!! 最新版ではSPIのタイミング説明部分が修正されており、SPI2/SPI5の値が50ns以下になっています。これなら20MHzまでいけることになります。端子のスイッチング速度制限の方の制約もあるので、実際には15MHz～17MHzくらいが上限というところでしょうか。１時間ほど連続して動かしても何の問題もありませんでしたが、安心して12MHzで動かすことができます。

データシートは、四半期に一度はダウンロードしなおした方が良さそうです。

SPI割り込みではまる

デジタルフィルターによるBPFは動いたので、LCDへの各バンドの音量表示をおこなっているのですが、画面表示で問題発生。

LCDはSPIで接続していますが、本来は描画しないはずの領域に時たまゴミのように線が入るという症状が発生。SPIへはDMAを使って出力していますが、その終了はSPIのTXEMPTYがセットされたことを割り込みで検出しています。この割り込みの動きがおかしいのではないかと考えて調べてみると、送信回数のおよそ2倍ちかい割り込みが発生しているではありませんか。どういうわけか許可していない条件でも割り込みが発生しているようです。さらに追いかけていくと、この問題はIISCとABDACBを動かしてWT32からのストリームを再生している時に発生するようです。

改めてデータシートでSPIタイミングを確認してみて愕然。SPI2/SPI5の時間が613nsとなっています。これではSPIの送信クロックの最大周波数は1.6MHz程度という計算になります。ほんとにこんなもんなんでしょうか？これまでSAM3Sで使っていたコードを流用していたので、12MHzで動かしてましたよぉ。クロック下げてみると確かにおかしな割り込みの発生頻度は減るようですが、ゼロにはなりません。

無駄な割り込みが発生しているのは気味が悪いので、送信終了の検出にはDMA完了割り込みを使うように変更。ただし、送信DMAが完了しても、それは最後のデータがSPIへ送られたことを示しているだけで、SPIからLCDへの実際の転送はその後発生します。そこで、送信DMA完了を検出したら、さらにTXEMPTYがセットされるのをポーリング待ちしてやります。

考えてみると、SPIのDMAよりもIISCやABDACBのDMAの方が優先度を高く設定していますので、SPIへのDMA送信がタイミングが遅くなる可能性があります。すると、自動的にCSかHighに戻ってしまうかもしれません。ゴミ表示はその影響で発生していたのかもしれません。そこで、SPIの初期化にCSAATを追加してCSをアクティブにしたまま保つことに。



今度は調子良く動いているようなのでSPIクロックを12MHzに戻してみましたが、問題無く動いているようです。

耳で聞いて確かめる

しばらく停滞していたSAM4Lの作業を再開。ディジタルフィルタを使ってのスペアナ表示機能の実装です。DSP Linkを使って求めたBiquadフィルタの係数を実際に埋め込んで動かしてみました。

DSP Linkでは、フィルタの種類やカットオフ周波数等の条件を入力してやれば、それに応じたフィルタの係数を計算して、その結果をテキストファイルに出力することができます。今回は10バンドのBPFを用意することにしましたが、そのうちのひとつの係数は次のように出力されました。

この例では、31ビットで量子化した係数を10進数表記で示しています。フィルタ毎に係数を別々のファイルに書き出す操作をやらなきゃならないのが、ちょっと面倒でした。わたしとしては、複数フィルタの係数をいっぺんに出力して欲しいところ。

こうして求めた係数はCMSIS-DSP Libararyで使う係数の配列としてプログラムの一部として埋め込んでやります。

DSP Linkはq31_tの形式に合わせて正規化した係数を出力してくれていますので、基本的には求めた値をそのまま埋め込めばいいのですが、係数の並べ方には注意が必要です。上の例を見てもらってもわかるように、ひとつのフィルタは2段のBiquadフィルタで構成されていますので、５つの係数が2組でひとつのBPFに相当します。この５つの係数のうち、最後の２つの係数については符号を反転しておきます。これはCMSIS-DSPでは入力/出力の両方の係数ともに乗算後の値を足し込むのに対して、DSP Linkでは出力係数については反転してから足し込む仕様になっているためです。そのため、出力側係数を反転しておかないと正しくフィルタとして動作してくれません。なお、CMSIS-DSPでは入力側係数を b0, b1, b2 出力側係数をa1, a2と表記していますが、DSP Linkでは入力側をa0, a1, a2 出力側係数を b1, b2と表記しています。そのため、係数を並べる順番にも注意が必要ですが、CMSIS-DSPでは入力側係数から並べる仕様となっていますので、DSP Linkが出力した順番に係数を並べて、出力側の２つの係数だけ符号を反転すれば良いことになります。このように使うツール（あるいは参照する書籍やwebページ)によって、係数の名前付けや符号の扱いが異なるので、これを見落とすと大きな罠にはまります。

こうして用意いたフィルタを実際に動かしてみると....

フィルタを動かすと30MHz相当の負荷になっていることがわかります。そしてフィルタ結果に応じてLCD表示もしてみた際の数字が後半に表示されている値で、40MHzになっています。やはり結構CPUを喰いますね。16ビット演算に変更すると大幅に軽くなることも確認してみたのですが、低域のフィルタの動作が不安定でした。フィルタ後の音を実際に耳で聞いてみると、ブツブツとノイズが入るのです。こうして耳で聞いてみてフィルタの動作を確認できるのもおもしろいところですね。LCD表示はまだ「それらしく」表示できていないので、もう少し手を加えるつもりです。