なんとかする予定

さて前回の続きですが、USBホストコントローラ部分の回路については触れていませんでした。ざっくりと言ってしまえば、Sparkfun の USB Host Shield と回路は同じです。

SparkFun Electronics - USB Host Shield
http://www.sparkfun.com/commerce/product_info.php?products_id=9947

DE0-nanoとの接続については、前回紹介した microbridge_nios2 の README.md に書かれていますので、そちらをご参考にということで。

DE0-nanoへ繋ぐ端子のうち、唯一オープンになっていないINT端子は MAX3421E 直近から引き出します。抵抗を挟んだ向かい側（電源側）に繋ぐと意味がなくなってしまうので注意です。

MAX3421E に供給する12MHzのクロックですが、せっかくFPGAがありますので水晶等は使わずにFPGAのPLLで生成することにしました。

FPGAのクロック50MHzを6逓倍して25分周する設定で12MHzが得られます。これはNiosIIコンポーネントに組み込む必要がないので、MegaWizardを使ってNiosIIの外に置きます。またクロックを出してくる端子は、MAX3421Eになるべく近くなるようにアサインします。

次に、ドットマトリックスLEDを制御するモジュールを、NiosIIのコンポーネントとして組み込みます。「SOPC Builder」と「Qsys」 というツールがあり、どちらを使ってもできますが、私はQsysを使いました。（QuartusがQsysを使えと言うので）

組み込み方法は・・・長くなるので省略します。スミマセン。

Sim さんの blog 「Qsysを使ってみた」という記事で紹介されていますので、そちらをご覧ください。

・Sim's blog
http://blog.goo.ne.jp/sim00

とりあえず、試行錯誤でやっていれば、そのうちなんとなく理解できて形になります。組み込んだ後の状態はこのようになります。

電源を切っても、回路データやNiosIIのプログラムが消えないように、EPCSにこれらを保存します。EPCSからプログラムをロードするには、EPCS Flash Controller のコンポーネントを追加しておく必要があります。

ただしリセットベクタの飛び先をメモリからEPCSに変えることになるので、NioｓIIのEclipseからプログラムを直接実行できなくなります。デバッグが終わってから組み込んだほうがいいかもしれません。（まあリセットベクタのアドレスをメモリに設定すればいいだけですが…）

NiosIIで走らせるプログラムは、@iseroidさんのサンプルプログラムに若干手を加えた程度です。Android側からは、ドットマトリックスの 32x16 の64バイトデータが直接来ることを期待しています。というわけで実はFPGAはあまり仕事をしていません。

修正したファイルです。
mb_de0nano_demo.c

後は回路合成後のsofファイルと、NiosIIプログラムのelfファイルをEPCSに書き込むだけ・・・と、まあこのような感じでDE0-nano側は作っています。途中の工程をかなりブッ飛ばして書いていますが、細かいところはグーグル先生にお任せすることにしましよう。

ここからいよいよお待ちかねの、Android側のプログラミングです。

早速ですが、Androidの画面に描いた絵をドットマトリックスLED上に表示させるデモを作ってみました。そんなに難しいことをしているわけではないので、詳細はソースコードをご覧ください。

LEDを点灯させるかどうかは、特定のポイントで判定するよりも領域の平均的な明るさから決めたほうが、輪郭が綺麗になるとは思いますが、今回は時間があまりなかったということを言い訳として簡単な処理にしました。

ソースコードはこちら。
touch2matrix.zip

動いているところなど。

最後にLED上で動画を表示させてみたかったのですが、

残念、静止画で～す。
動画表示は無理っぽいですね。というのも・・・

• 画面を取り込む手段が無い
  一番やりたかったことは、Android側で画面データを逐次取り込み、 LEDに送るデータに加工して転送するということでした。
  
  しかし、通常のJava（というかAndroid-API）を使っての開発では無理ということが徐々に判明してきました。フレームバッファ等に直接もしくは間接的にアクセスする手段がないので、例えば、動画を再生しつつその映像に対して独自の効果をかける、ということもできません。（カメラの映像ならできるんですよね。ファイルからの映像でできないのは著作権がらみ？）
  
  NDKならできるかもしれませんが、詳しくないのでわかりません。
  
  機種によっては、ADB経由でフレームバッファのデータを取得できます。日曜エレクトロニクスの @yishii さんが試されています。Garaxy-SでもできたのでSamsungの他の端末でもおそらくできます。IS01では無理でしたのでSHARPの端末は不可能かと。
  　
• 転送速度が遅い
  フレームバッファがADB経由で読めたとしても、800x480の画面サイズのデータがRGB888で送られてくるので、Hi-Speedでないと間に合いません。
  
  USBの転送速度、MAX3421EとFPGA間（SPI）の速度が遅いので、頑張っても1fpsいければいいところだと思います。

=====

先日5/19に、ECCコンピュータ専門学校を会場とした「関西FPGA・DE0勉強会」がありました。拙作のボードを持って行ってデモをしたところ、キャンパスニュースに（かなり大きく）載ることになりました。ありがとうございます！ (ﾃﾍ

・ECCコンピュータ専門学校
http://comp.ecc.ac.jp/

・ECCコンピュータ専門学校 キャンパスニュース (5/22)
http://comp.ecc.ac.jp/news/campus/detail.php?id=2592

2月初めには完成していましたが、とりあえず完成ー！ということで。

ボード右上に何やら怪しげなQFPのICが載っていますが、USBホストコントローラーのMAX3421Eです。実は最終的にAndroidと接続することを企んでいたりします。「なんだ結局Androidなのか」と思っちゃうかもしれませんが、まあそう言わずに。 ＾＾

急いで作ったので、若干雑な仕事になってしまいました。

ちなみに写真のQFP変換基板ですが、Aitem-Labにて購入しました。変換基板って無駄なスペースをとってしまうものばかりで、省スペースのものって電気街のパーツ屋を探し回っても見つかりませんでした。ネットで見つけて購入しましたが、狭いスペースでも使えて良い感じです。

ボード上の回路についてですが、ソース側は74ACTのシフトレジスタを、シンク側はトランジスタアレイを使用し、FPGAからそれらをコントロールしているというものになっています。　ボードの回路図

シフトレジスタは、以前の記事にも書いていますが、東芝の TC74ACT164 を使う予定でした。ただ、どの部品屋にも在庫がない状態だったため、TI の CD74ACT164 で代用しています。仕様的にも問題はありません。

LEDの電流制限抵抗は120Ω。決め方は下記の通りです。とりあえず 74ACT164のPch側のON抵抗は無視しています。流す電流も高々16mAですし、トランジスタアレイの Vce(sat) の特性ばらつきや温度による変動の方が大きいので、そこまで細かい値は気にする意味も無いと思います。

R = ( Vcc - Vf[LED] - Vce(sat)[TrArray] ) / 16mA

5V電源については今のところDE0-nano経由で、PCのUSBポートから供給しています。Androidを接続する場合は確実に供給能力不足になるので、外部電源が必要になります。

さて、FPGAの方に話を移しましょう。
ドットマトリックスLED制御部分のVerilogHDLはこちら。例によって無保証です。

matrix_led_ctrl.zip

構成としては、32bitx16のメモリを内部に持っていて、これにデータを書き込むことでその内容を表示します。またNiosIIのコンポーネントとして組み込むことで、ソフトウェア上で表示パターンを変更することができるようになります。

ゆくゆくはAndroidで制御しますので、ベースとしては＠iseroidさんが公開されているNiosII用のMicrobrigeを使います。githubから取ってこれます。

https://github.com/iseroid/microbridge_nios2
　
今回はここまで～。（次回は未定）

昨年末、AlteraのFPGA「CycloneIV」を搭載しているボード DE0-nano を買いました。

digikeyで7K円程度と、FPGAのボードにしては非常にお手ごろな価格です。

さて時を同じくして、秋月電子で16x16のドットマトリックスLEDを購入していて、なんとなくFPGAでドットマトリックスLEDを動かして遊びたいな～、という気分になりました。

下記、テキトーに考えた構成です。
　

• 16x16のドットマトリックスLEDを、横に2個ならべて32x16で表示。LEDはダイナミックドライブ（縦方向をスキャン）で点灯。

• CycloneIVには NiosII を搭載して、いろいろ怪しく遊べるようにする

• とりあえず秋月電子で手に入る部品で作る。
  ドライバとしてソース側 74HC541APx4個、シンク側 TD62083APGx4個 使用。FPGAからは縦横パラレルでデータを出力。FPGA外の配線数が異常に多くなってしまうが、秋月で買えるICがこれしかないので我慢。あとシンク側で4個使用するのは以下2つの理由から。

• ドット1個あたり平均1mAの電流で光らせたい。それ以下だと結構暗くなりそう。そんなわけでソース側の出力電流は16mA/ch程度に設定。

• シンク側のICは絶対最大定格500mAなので、IC1個で横方向32ドットの同時点灯は無理 （16mA x 32 = 512mA）
  仕方なく横方向は16ドットにつきIC1個使いで。

完成イメージ

かなり重量バランスが悪い・・・

ともかく部品も揃っているので早速製作に取りかかろう！と、仕様書を改めて見てみると、TC74HC541AP、使えない子でした・・・orz

TC74HC541APで8端子分のLEDを全て点灯させると、1端子あたりの電流値は問題ないのですが、電源電流 Icc の絶対最大定格 75mA を超えてしまうことに気づきました。

9mA/chに設定するといけそうですが、表示がかなり暗くなることが予想されます。

ただ、電流値を多めに設定しておいて、後でシンク側のパルス幅を調整して輝度を下げることはできますが、逆に輝度を上げることはできないので、これはやりたくないです。

結局、74HC はどのメーカー、どの品番もダメ。

74AC に変更すれば、Iccが200mAなので十分使えそうです。実は 74HC の場合も言えることなのですが、これらのICを5V駆動させる場合、FPGAからの3.3V出力を直接受けるのは規格的にかなり厳しいです。

そういうわけでTTLレベル入力に対応した 74ACT にすることにしました。

どうせ部品を変更するなら、配線数削減のため、シフトレジスタ付きの TC74ACT164 にしたいところです。シリアルアウトがある TC74ACT299 もありますが、余計な機能が付いてピン数が多くなっているのでイマイチ。

あー、またパーツ買うのが非常に面倒くさい・・・（つづく）

～ 絶対最大定格よもや話 ～

絶対最大定格は一瞬たりとも超えてはならないという規格ではあるのですが、超えたからといってすぐにICが壊れてしまうことはおそらくありません。ですが、絶対最大定格スレスレもしくはそれを超えるような回路を設計すると、仮に趣味の工作であっても、どこからかマサカリが飛んでくることが考えられます。

さて、その絶対最大定格の範囲内で使用するとしても、実はこれは動作が保証される限界というわけではありません。動作が保証されるのは推奨動作範囲内に限ります。そしてこの範囲で使用するのが一般的に（信頼性の観点からして）正しい使い方です。

推奨動作範囲から絶対最大定格までの空白の領域については、瞬時に故障しない保証はありますが、動作保証はありません。自己責任で使ってくださいということです。

ところで話が若干逸れますが、どのメーカーのどんな規模の集積回路も「バーンイン」や「高電圧印加」と呼ばれる加速試験により、わずかに劣化させてから出荷されます。初期不良を排除するためです。

例えば、「初めて電源を投入して1000時間連続で動作させて問題がない場合、99.9999%の確率でその後10万時間は故障せずに動作する」ということが、あらかじめ何らかの方法によりわかっているとします。

できた製品をそのまま出荷するのではなく、1000時間動作させてから出荷すれば、1000時間未満で故障してしまう不良品は排除でき、ほとんどが将来10万時間動作する製品だけになります。あくまで確率の話ですが。

しかし、出荷する全てのICを1000時間も放置しておくのは、時間的にも費用的にも、ただの無駄でしかありません。そこで、1000時間動作させた時の劣化度合と同等と考えられるストレスを短時間で与えます。高温に曝すバーンインをしたり、電源電圧として高い電圧を加えたり、もしくはその両方を実施することによって1000時間を数時間（場合によっては数秒）に短縮させます。

加速試験は絶対最大定格、もしくはそれ以上の過酷なストレスがかかる状態で実施されます。つまり、加速試験をパスして出荷されたものは、少なくとも絶対最大定格内では瞬時に壊れることはない、ということになります。

またこの試験では、ICに本来の動作をさせるのではなく、IC内のトランジスタが極力全て動くような特殊なモードにします。絶対最大定格が動作保証限界ではないのはこのためです。

ちなみに、IC本来の動作をみる検査は、通常は推奨動作範囲の最大・最小（多少マージンを加味したり）の条件で行われます。
 

結局結論は何だということですが、

上のバーンイン試験の内容からもわかるように、実は絶対最大定格内で使用すればICが劣化しない、というわけでもなく、通電している限り極めてゆっくりですが劣化は進行していきます。推奨動作範囲で動かすことは要するに想定された製品寿命を保証する基準と言ってもいいでしょう。

つまり、信頼性の確保が最重要である場合は推奨動作範囲で動かさなければなりません。

しかし、耐用年数や安全性等を十分に検証した上での使用、または趣味用途といった信頼性がさほど重要でなく、リスクを自ら負える状況で使用する限りは、推奨動作範囲や絶対最大定格を逸脱することがあっても構わないと私は考えます。

例えば、LEDを抵抗などの電流制限素子を使わずに点灯させることも、使用状況を理解しているならアリと思うわけです。（さすがに電子工作入門の書籍等、理解が十分でない人向けには、あまり取り扱うべきではありませんが…）

とはいえ、特別な理由がない限りは、趣味レベルにおいてもスペックに対して十分余裕のある動作をさせることがベストなのは言うまでもありません。