エントリー

DE0-nano + ドットマトリックスLED で遊ぶ

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

 

20120109_49-1.jpg

 

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個使いで。

 

完成イメージ

 

20120109_49-2.jpg

 

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

ともかく部品も揃っているので早速製作に取りかかろう!と、仕様書を改めて見てみると、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を抵抗などの電流制限素子を使わずに点灯させることも、使用状況を理解しているならアリと思うわけです。(さすがに電子工作入門の書籍等、理解が十分でない人向けには、あまり取り扱うべきではありませんが…)

 

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

 

ぶらり伊勢志摩

  • 2011/11/20
  • カテゴリー:

旅行というほどでもないのですが、伊勢志摩あたりを回ってみました。

 

笠木不動滝(雄滝)

 

20111120_43-1.jpg

 

雌滝までは道が険しそうだったので行きませんでした… ^^

葉もそれなりに色づいてきているようです。

 

20111120_43-2.jpg

 

安乗埼灯台

 

20111120_43-3.jpg

 

灯台の上から

 

20111120_43-4.jpg

H8マイコンでLinux 2回目

前回で開発環境が一応整ったみたいなので、Linuxカーネルのビルドを試してみました。
Linuxといっても、改めて言う必要はないかもしれませんが、組み込み向けの「uClinux」を使うことになります。

 

早速uClinuxのサイトから最新のソースパッケージを取得。
TOPページのhttp://www.uclinux.org/はなぜか頻繁に見れなくなるようなので、ファイルの置いてあるこのページに直接行ったほうがよいかもしれません。

現状では、uClinux-dist-20110810.tar.bz2 が最新のようです。
この記事では1つ前、"20110603"の日付のものを使用していますが、これから行う内容におそらく相違はないと思います。

 

ソースパッケージには、2.0.x、2.4,x、2.6.xのカーネルソースがそれぞれ入っています。今回はとりあえず2.4.xでビルドします。H8マイコンのメモリ増設はまだしていませんし、メモリ使用量が2.6.xよりも少なくなるようですので。

パッケージを展開して、make menuconfig、make dep、make、めんどいので詳細は略。

make CROSS_COMPILE=h8300-elf- menuconfig
make CROSS_COMPILE=h8300-elf- dep 2>&1 | tee make_dep_log
make CROSS_COMPILE=h8300-elf- 2>&1 | tee make_log

実はツールチェイン構築時の"--target=h8300-elf"は不要でした。このオプションを付けてしまったせいで、make時にもわざわざ"CROSS_COMPILE=h8300-elf-"をつけなくてはなりませんでした。
(何もつけない場合は"h8300-linux-elf"になります)

とりあえず今はこのまま進めます。

 

makeするとエラーて怒られてしまいました。滞りなく完了すると思っていたのに…
結論から言えば、ソースコードがGCC3以下でコンパイルされることを前提として書かれているのに対し、GCC4でコンパイルしたことが原因でした。GCC4から構文チェックが厳密になって、一部でこれまでの警告がエラーとして出てしまうようです。

いっそのことGCC3でやり直すか、いや待てそれは敗北宣言っぽい気がするな・・・、てなわけで、仕方ないので見ていくことにしましょう。

 

エラーその1

make CFLAGS="-fno-builtin -DNO_CACHE -D__KERNEL__ -I/usr/local/src/uClinux-dist/linux-2.4.x/include  -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-sprin
tf -fomit-frame-pointer -Wno-pointer-sign -pipe -DNO_MM -DNO_FPU -DNO_CACHE -mh -mint32 -D__ELF__  -DNO_FORGET -DUTS_SYSNAME=\"uClinux\" -D__linux__ -DTARGET=aki3068net -Os  " -C  drivers
h8300-elf-ld  -mh8300helf   -r -o aki3068net.o timer.o
ptrace_h8300h.c: In function 'getnextpc':
ptrace_h8300h.c:249:7: error: lvalue required as left operand of assignment
ptrace_h8300h.c:253:7: error: lvalue required as left operand of assignment

 

linux-2.4.x/arch/h8300/platform/h8300h/ptrace_h8300h.c

202 static unsigned short *getnextpc(struct task_struct *child, unsigned short *pc)
203 {
204         const struct optable *op;
205         unsigned char *fetch_p;
206         unsigned char inst;
207         unsigned long addr;
208         unsigned long *sp;
209         int op_len,regno;
210         op = optables[0].ptr;
211         op_len = optables[0].size;
212         fetch_p = (unsigned char *)pc;
213         inst = *fetch_p++;
214         do {
・・・
247                                 case relb:
248                                         if ((inst = 0x55) || isbranch(child,inst & 0x0f))
249                                                 (unsigned char *)pc += (signed char)(*fetch_p);
250                                         return pc+1; /* skip myself */
251                                 case relw:
252                                         if ((inst = 0x5c) || isbranch(child,(*fetch_p & 0xf0) >> 4))
253                                                 (unsigned char *)pc += (signed short)(*(pc+1));
254                                         return pc+2; /* skip myself */
257                                 }

 

エラーが出ている箇所は249行目です。
ググればすぐに出てきますが、左辺がキャストされていることでエラーとなります。やりたいことはわからなくはないですが、この書き方は確かにあいまいです。

 

修正方法は、2.6.xのソースから引っこ抜いてこればOKです。

247                                 case relb:
248                                         if (inst == 0x55 || isbranch(child,inst & 0x0f))
249                                                 pc = (unsigned short *)((unsigned long)pc +
250                                                                        ((signed char)(*fetch_p)));
251                                         return pc+1; /* skip myself */
252                                 case relw:
253                                         if (inst == 0x5c || isbranch(child,(*fetch_p & 0xf0) >> 4))
254                                                 pc = (unsigned short *)((unsigned long)pc +
255                                                                        ((signed short)(*(pc+1))));
256                                         return pc+2; /* skip myself */
257                                 }

 

エラーその2

h8300-elf-gcc -fno-builtin -DNO_CACHE -D__KERNEL__ -I/usr/local/src/uClinux-dist/linux-2.4.x/include  -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-spri
ntf -fomit-frame-pointer -Wno-pointer-sign -pipe -DNO_MM -DNO_FPU -DNO_CACHE -mh -mint32 -D__ELF__  -DNO_FORGET -DUTS_SYSNAME="uClinux" -D__linux__ -DTARGET=aki3068net -Os    -nostdinc -iwithprefix
 include -DKBUILD_BASENAME=ints  -c -o ints.o ints.c
make[3]: ディレクトリ `/usr/local/src/uClinux-dist/linux-2.4.x/drivers/media' に入ります
make -C radio
make[5]: ディレクトリ `/usr/local/src/uClinux-dist/linux-2.4.x/drivers/ide/arm' に入ります
rm -f idedriver-arm.o
h8300-elf-ar rcs idedriver-arm.o
make[4]: ディレクトリ `/usr/local/src/uClinux-dist/linux-2.4.x/drivers/media/radio' に入ります
make all_targets
n_tty.c: In function 'write_chan':
n_tty.c:1406:5: error: assignment of read-only variable '__gu_val'
n_tty.c:1406:5: warning: passing argument 1 of 'memcpy' discards qualifiers from pointer target type
rm -f mm.o

 

__gu_val が read-only ということで怒られています。 __gu_val を探してみると下記の場所にありました。
linux-2.4.x/include/asm-h8300/uaccess.h

 85 #define get_user(x, ptr)                                        \
 86 ({                                                              \
 87     int __gu_err = 0;                                           \
 88     typeof(*(ptr)) __gu_val = 0;                             \
 89     switch (sizeof(*(ptr))) {                                   \
 90     case 1:                                                     \
 91     case 2:                                                     \
 92     case 4:                                                     \
 93         __gu_val = *(ptr);                                        \
 94         break;                                                  \
 95     case 8:                                                     \
 96         memcpy(&__gu_val, ptr, sizeof (*(ptr)));                \
 97         break;                                                  \
 98     default:                                                    \
 99         __gu_val = 0;                                           \
100         __gu_err = __get_user_bad();                            \
101         break;                                                  \
102     }                                                           \
103     (x) = __gu_val;                                             \
104     __gu_err;                                                   \
105 })

 

ふむふむなるほど。
typeof(*(ptr)) としているんだけど、上記エラー箇所の場合、ptr が const unsigned char* なので、__gu_val が const になってしまい値が代入できない、というオチのようです。

get_userの詳細はさておき、結局やっていることは *ptr → __gu_val → x と値をコピーしていっているだけです。ということはつまり、暗黙的に x と *ptr は同じ(もしくは x が *ptr を内包する)型になっていると考えてもよく、下記でも問題ないはずです。

 88     typeof(x) __gu_val = 0;                             \

もちろん x が const となることはありません。

 

というわけで、これら2つのエラーを修正することで、カーネル自体のコンパイルはうまくいったようです。

しかしこの後、uClibやユーザランドのコンパイルでエラーがたくさん出てしまうことに…
それはまた次回・・・(って、あるのかわかりませんが^^)

H8マイコンでLinux (放置中止)

買ってから2年程度放置していた秋月電子のH8マイコンを久々に引っ張り出しました。

 

20110703_27-1.jpg

 

とりあえず今のところは、IDEインターフェースを作って、CFカードからLinuxをブートさせようとしています。IDEインターフェースの回路は、H8マイコンと同時期に買った 『はじめる組み込みLinux』 という本からそのままもってきました。

どうせならCPLDを使い、SDRAMを積んでメモリ空間をほぼフルに使えるようにしたり、怪しいI/Fをたくさん搭載したいですね。
 

さて、Linuxのビルド環境の構築ですが、ちょうど手元に、Ubuntu11.04-32bit版をインストールしたVMware仮想PCがあったので、これをホストとして使うことにします。

 

下ごしらえ

  • aptitude(apt-get) するもの
    libmpfr-dev
    (g++-4.1 libgmp3-dev libgmpxx4ldbl libstdc++6-4.1-devも依存関係で一緒に入ります)
    libmpc-dev
  • ソースをダウンロードしてくるもの
    binutils-2.21
    gcc-4.5.3
    newlib-1.19.0

 

そしてビルド・・・

・binutils-2.21

$ mkdir _build
$ cd _build
$ ../configure --target=h8300-elf --prefix=/usr/local/h8300 --with-newlib
$ make 2>&1 | tee make_log
$ sudo make install

 

・gcc-4.5.3

$ mkdir _build
$ cd _build
$ ../configure --target=h8300-elf --prefix=/usr/local/h8300 --enable-languages=c --enable-shared --disable-nls --disable-threads --disable-werror --with-newlib --with-headers=/usr/local/src/newlib-1.19.0/newlib/libc/include 
$ make 2>&1 | tee make_log
$ sudo make install

 

・newlib-1.19.0

$ mkdir _build
$ cd _build
$ ../configure --target=h8300-elf --prefix=/usr/local/h8300
$ make 2>&1 | tee make_log
$ sudo make install

これでひとまず完了。

 

そういえばgccのコンパイルで、初めは"--enable-languages=c,c++"としていたのですが、エラーが出てしまいました。gccのバージョンを変えても、その他のオプションを変えても、解消の兆しが見えません・・・

/usr/local/src/gcc-4.5.3/_build/./gcc/xgcc -shared-libgcc -B/usr/local/src/gcc-4.5.3/_build/./gcc -nostdinc++ -L/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/src -L/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/src/.libs -nostdinc -B/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/newlib/ -isystem /usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/newlib/targ-include -isystem /usr/local/src/gcc-4.5.3/newlib/libc/include -B/usr/local/h8300/h8300-elf/bin/ -B/usr/local/h8300/h8300-elf/lib/ -isystem /usr/local/h8300/h8300-elf/include -isystem /usr/local/h8300/h8300-elf/sys-include  -mh -mn -mint32 -x c++-header -g   -mh -mn -mint32 -I/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/h8300-elf -I/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include -I/usr/local/src/gcc-4.5.3/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /usr/local/src/gcc-4.5.3/libstdc++-v3/include/precompiled/stdc++.h \
        -o h8300-elf/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from /usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/random:54:0,
                 from /usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/stl_algo.h:66,
                 from /usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/algorithm:63,
                 from /usr/local/src/gcc-4.5.3/libstdc++-v3/include/precompiled/stdc++.h:64:
/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/random.tcc: In member function 'void std::seed_seq::generate(_RandomAccessIterator, _RandomAccessIterator)':
/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/random.tcc:2724:47: error: no matching function for call to 'max(int&, const size_t&)'
In file included from /usr/local/src/gcc-4.5.3/libstdc++-v3/include/precompiled/stdc++.h:65:0:
/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bitset: In member function 'void std::bitset<_Nb>::_M_copy_from_ptr(const _CharT*, size_t, size_t, size_t, _CharT, _CharT)':
/usr/local/src/gcc-4.5.3/_build/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bitset:1328:66: error: no matching function for call to 'min(size_t&, int&)'
make[8]: *** [h8300-elf/bits/stdc++.h.gch/O2ggnu++0x.gch] エラー 1

 

調べてみると、'min(size_t&, int&)' については下記のような解決方法があるようです。patchを当てると確かにエラーがでなくなりました。

http://old.nabble.com/Failed-to-make-h8300-toolchain.-td24088154.html

'max(int&, const size_t&)' のほうは、これといった情報を見つけられませんでした。でも同じ原因のような気がします。ramdom.tccの多分このあたりが怪しいとは思うのですが・・・

 764   template<typename _RandomNumberEngine, size_t __k>
 765     typename shuffle_order_engine<_RandomNumberEngine, __k>::result_type
 766     shuffle_order_engine<_RandomNumberEngine, __k>::
 767     operator()()
 768     {
 769       size_t __j = __k * ((_M_y - _M_b.min())
 770                           / (_M_b.max() - _M_b.min() + 1.0L));
 771       _M_y = _M_v[__j];
 772       _M_v[__j] = _M_b();
 773
 774       return _M_y;
 775     }
 ...
 2716       const size_t __s = _M_v.size();

 

C++でプログラミングをすることが目的ではないので、C++のビルドは今回は諦めることにしました。

ubuntu10.04 server + 3TB-HDDでちょっとハマる

現在Shuttleの古いベアボーンSG31G2と、ACアダプタのPC62で超静音ローカルファイルサーバを立てています。ファイルサーバといっても単なるファイル置き場として使っている程度で、また速度も特に求めていないので、RAIDは組んでいません。

つい先日お給料が入ったのを機に、ファイルサーバ増強を兼ねて3TBのHDDを試しに購入してみました。1TB+2TBというこれまでの構成から、3TBのHDDをブートドライブとして3TB+2TBの構成にするつもりです。購入したHDDはHGSTの0S03088。いやはやHGSTもいずれはWDになってしまうんですね…

 

OSは64bit版のubuntu-server(9.10?)を使っていますが、3TBのHDDへ10.04を新規でインストールすることにしました。

とりあえず、インストールでは何も考えずにガイドでディスク全体を使うように指定。
昔は「/usrはxxMB、/varにxxMB…」とか律儀にやっていましたが、さすがに今の大容量時代、個人で使う分にはその必要性もないような気がします。

作業はすんなり終わり、CDを取り出してリブート。起動するのを待ちます。ところが…

grub rescue>

おや?rescueなプロンプトが出てきてしまいました。
コマンドをいろいろ叩いて調べてみると、GPTディスクにはなっているようですがlsコマンドで中を見ようとすると「unknown filesystem」と怒られます。

 

もしやと思い、今度は20GBだけ領域を確保してOSをインストール、残りの領域は一旦放置しておきます。インストールはこちらも問題なく終わりました。リブートすると…無事に起動しました。

ブートローダーにGRUB2ではなくGURB Legacyがインストールされている??
「起動したからまあいいや」ということで結局調べていませんが、もう少し待って11.04を使ったほうが良かったのかもしれませんね。あと放置していた残りの2TB以上の領域は、その後問題なく使えています。

 

とにかく"非EFIマシンを使ってGPTで2TB超のHDDにクリーンインストールした事例"というのが、まだまだ少ないようです。

ユーティリティ

Author


oaks (twitter: @oks486)

記事の内容に関しては無保証です。何事も At your own risk ってことでよろしく。
リンクはご自由にどうぞ。

SPAM対策が面倒なため現在コメント投稿機能を停止しています。あしからず...

検索

エントリー検索フォーム
キーワード

Feed

リンク