ブレスマイルクリア(歯磨き粉)

 

■Windows7 / WindowsUpdateでネットワークアダプタが消える

Windows7 機を整備するために Windows Update を実行したら、ネットワークアダプタが消えてしまったという話です。

 

この Windows7 機を最後に更新したのは 3年近く前です。整備するためにまず Windows Update を実行します。

が、その前に、なにかトラブルがあった時のために HDD を丸ごとバックアップしておきます。何でもないことだけどこれは必須です。何度助けられたことか (^_^;)

蛇足ですが。バックアップを取られる人は多いと思いますが、リストアってやったことあります? たとえば別の HDD にリストアしてみるといった予行演習的なことは、常々やっておいたほうが良いです。いざというときに「リストアできない!」「方法がわからない!」という悲惨な目にあわないためにね。

 

閑話休題。

 

Windows Update の設定は「更新プログラムを確認しない」になっていましたので、それはそのまま「更新プログラムの確認」を行いました。いくつかの更新プログラムが表示されましたが、最新のものは 2019/05/14 のマンスリー品質ロールアップなどです。インストールを実行し、再起動の指示に従い再起動。とりあえず問題なく Windows7 は起動しました。

 

が、ネットワークにつながりません。タスクトレイのネットワークアイコンには ×印がついています。

そういえば Windows Update でネットワーク設定が変更されるって記事があったよなぁ、と思い出して、ネットワークアダプタの設定を確認しようとすると…… 無い…… ローカルエリア接続のアイコンが無い (^_^;)

デバイスマネージャを確認すると、ネットワークアダプタは「ドライバがインストールされていません」となっていました。ドライバの更新を実行するとなにやらエラーを起こしてインストールできません。

 

さて、どうするか?

なにかとお世話になっている「ぼくんちのTV別館」で Windows Update の情報を確認すると

今後、Windows7の更新は注意が必要 (再掲)

 

※この項目は、2019年4月度情報の再掲です。
今後、Windows 7 を2018年3月以前のイメージからリカバリを行おうと思った場合や、ゲスト仮想マシンでの運用では注意が必要。Windows Update 適用後に、ネットワーク設定が意図しないものに変更される場合がある。

とありました。

 

これかぁ、これに違いない。なんてったって最終更新は 3年前だもの (^_^;)

 

こうなってしまったら更新プログラムの削除とかシステムの復元とかを考えるわけですが、そんなことして深みにはまるより、さっさとバックアップからリストアして元に戻したほうが早いです。もうね、神様、仏様、バックアップ様ですよ。

というわけでリストア完了。もう一度 Windows Update をやり直します。

 

更新プログラムの確認をして、まず 2019年4月10日より前の日付の更新プログラムだけをインストールします。

次に、更新プログラムの確認をして表示された 5月分の更新プログラムをすべて非表示にし、もう一度更新プログラムの確認を行います。すると 4月分の更新プログラムが表示されますので、これも非表示にします。

さらに更新プログラムの確認を行うと、今度は 3月分のマンスリー品質ロールアップ (KB4489878) を含む 3月分の更新プログラムが表示されます。これをインストールします。

この「2019-03 マンスリー品質ロールアップ (KB4489878) 」こそが必須の更新プログラムなのだそうです。

 

引き続き更新プログラムの確認を進めます。

もう一つ必須の「サービススタック更新プログラム (KB4490628) 」が表示されますので、インストール。さらに更新プログラムの確認を行うと「利用できる重要な更新プログラムはありません」となりました。

ここで非表示の更新プログラムの再表示を行うと 5月分の更新プログラムが表示されます。たぶんもうこれをインストールしても問題ないのだろうと思いますが、念のためこれをもう一度非表示にして、4月分の更新プログラムを表示させインストールします。

そして最後に、5月分の更新プログラムをインストール。

 

無事、ネットワークアダプタには被害なく、Windows Update を完了しました。

 


■直す価値のないハードディスクを修復してみる の結果

ハードディスクの S.M.A.R.T. 属性について、英語版の Wikipedia S.M.A.R.T. にこんな記述を見つけました。これは「197 0xC5 Current Pending Sector Count」属性の解説の抜粋です。

 

However, some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the "Reallocation Event Count" (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.

 

代替保留中の不良セクタは、もう一度読み出しに失敗すると代替処理待ちとなり、次の書き込みで代替処理が行われます。しかし、「一部のドライブでは書き込みを行なってもただちに代替処理が行われない」というのです。不良セクタに対して、まず書き込みを行なってみて、書き込みが成功すれば良いセクタだとマークされます。この場合は Reallocation Event Count (0xC4) を増やしません。

 

まさにこれではないのでしょうか。

くだんの HDD は、dd コマンドでゼロフィルしたのちに Current Pending Sector が 0 になった。でも、Reallocated Event Count も Reallocated Sector Ct も増えていない。つまり、書き込みを行なったにもかかわらず代替処理が行われなかった。それは、代替処理の前に書き込みを行ない、それが成功したためだと。

これは、場合によっては不良セクタの代替処理が行われないことになるので「重大な欠点だ」と書かれています。

 

微妙な位置に立たされた HDD ということでしょうねぇ (^_^;)

 

ちなみに「198 0xC6 (Offline) Uncorrectable Sctor Count」について。

 

The total count of uncorrectable errors when reading/writing a sector. A rise in the value of this attribute indicates defects of the disk surface and/or problems in the mechanical subsystem.

 

この数値が増えるということは、「ディスク表面の欠陥」「メカニカルサブシステムの問題」があるということ。これはどうやら今後急速に劣化していく可能性を持っているようです。

 

ということで、最終結果。

この HDD は近いうちに故障する恐れがあります。でも、貧乏な俺はこの HDD を、あまり重要でない用途に、常に状態をチェックしながら使い続けてみることにします。\(^o^)/

 


■直す価値のないハードディスクを修復してみる のまとめ

もともと Windows7 のノートパソコンで使われていた 2.5 インチ 500GB のハードディスク。Windows が起動できなくなっていました。具合が悪くなると強制終了、なんて使い方を続けていたようです。そのハードディスクのままで OS を再インストールしたら正常に使えちゃったというのが、事の始まり。

で、完全に動かなくなるまでハードディスクを使い倒したい貧乏な俺は、いろいろ試しながら、グーグル先生に教えてもらいながら、あわよくばこいつを再利用できないものかと目論んでいたわけです (^_^;)

 

多くのサイトで勉強させていただきましたが、そんななかで出会ったサイトがこちら「PCと解 パソコントラブルにまつわるサイト」です。さまざまなパソコントラブルについてこれまでのご経験をもとに書かれているサイトですが、ハードディスクトラブルに関してもわかりやすく書かれています。とても参考になりました、ありがとうございます。

 

 

さて、おれが正確に理解できているかかどうかは怪しげです (^_^;) が、つまりこういうことかと。

 

S.M.A.R.T. テストは HDD の物理的な状態を調べるもの。

Windows で使ってみたらエラーもなく利用できたのは、ファイルシステムが物理的な異常を論理的に処理、回避してくれているから。Windows で動くチェックディスク chkdsk で不良セクタが表示されないのはそのためだということ。

S.M.A.R.T. によるセルフテストは読み書きのチェックを行ないますが、最初に不良セクタを見つけたところで停止します。badblocks コマンドも同じように読み書きを行ないますが、エラーがあっても停止せず HDD 全体をチェックしてくれます。

不良セクタをファイルシステムに論理的に認識させるには、Windows ならば chkdsk 、Linux ならば fsck のようなファイルシステムをチェックするコマンドを利用します。でも、すでに代替処理されたセクターにファイルシステムは関知しませんから、OS からは見えません。

 

読み出しエラーがあったセクターは Current Pending Sector となり登録されます。次に読み出しがあったときに、読み出しに成功すれば正常なセクタとなり Current Pending Sector の数は減ります。読み出しに失敗すると代替処理すべきセクタとなり、次の書き込み時に代替処理されます。

代替処理が行われると Reallocated Event Count が増やされます。処理済みとなれば Reallocated Sector Ct が増える。でも、処理に失敗した場合はどうなるのでしょうか? その場合は Offline Uncorrectable となる?

 

Current Pending Sector に書き込みを行なう ( dd や badblocks ) と代替処理が行われるので、Current Pending Sector は消失します。chkdsk や fsck はファイルシステムのエラーをチェックするものなので、いわゆる修復 (代替処理) にはならない。フォーマットもファイルシステム上の処理なのでダメ。

 

 

これらを踏まえてくだんの HDD のことを考えてみると。

 

dd コマンドでゼロフィルしたのちに、S.M.A.R.T. のセルフテスト (long) を実行し Current Pending Sector は 0 になった。でも、Reallocated Event Count も Reallocated Sector Ct も増えていない。Offline Uncorrectable は 108 が 209 に増えた。

とゆーことは、書き込みを行なったにもかかわらず代替処理が行われなかった。代替保留中だけれども、次の読み出しがまだ行われておらず、代替処理すべきセクターになっていなかった、ってことか? そこへ書き込み、読み出しを行なったら正常にできたので、代替保留中にはならなかった?

…… じゃあ、Offline Uncorrectable はなんなの?

 

まとめようかと思ったけれど、疑問はさらに続く…… (^_^;)

 


■直す価値のないハードディスクを修復してみる の参

全ブロックに 0 を書き込んでみた HDD (500GB) の S.M.A.R.T. テストの結果は、Current Pending Sector (現在保留中のセクタ) がなくなりましたが、Offline Uncorrectable (オフライン修正不可能) が 209 に増えています。これはいわゆる不良セクターって奴なのでしょうか?

badblocks コマンドを使って調べてみることにしましょう。

 

badblocks は、今回は破壊的 (書き込みモード) 検査をやってみます。man badblocks してみると、

 

-w     Use write-mode test. With this option, badblocks scans for bad blocks by writing some patterns (0xaa, 0x55,  0xff,  0x00)  on  every block (すべてのブロックにいくつかのパターンを書き込むことによって) of the device, reading every block and comparing the contents.  (後略)

 

ということです。ん〜、4つのパターンをすべてやってみるのかな。1パターンに 5時間かかるとすると 20時間 …    -t オプションでパターンを random に指定すれば良いのかもしれない。

 

-t test_pattern

Specify a test pattern to be read (and written) to disk blocks.   The test_pattern may either be a  numeric  value between  0 and ULONG_MAX-1 inclusive, or the word "random", which specifies that the block should be filled with a random bit pattern ("random" は、ブロックがランダムなビットパターンで埋められることを指定します) .  (中略) If multiple patterns are specified then all blocks will be tested with one pattern before proceeding to the next pattern (複数のパターンが指定されている場合は、すべてのブロックが1つのパターンでテストされた後に、次のパターンに進みます。) .

 

ということなので、以下のように実行してみることにします。

$ sudo badblocks -svw -b 4096 -c 256 -t random -o badblocks.txt /dev/sdb

ランダムなパターンを書き読みして、一回りで終了。1 ブロック 4096 バイトを 256個ずつテストしますので、一度に 1MB をテストすることになります。と思います (^_^;)

 

ちなみに、エラーを書き出したファイルを e2fsck に渡すといった方法を説明しているサイトがいくつも見られましたけど、いま俺がやっているような、全体を潰したファイルシステムが無い状況ではそれはできません。e2fsck はファイルシステム (ext2 / ext3) がないと実行できませんので。俺がファイルに書き出しているのは、単に記録として見るためです。

man には、e2fsck に渡す場合には badblocks を使わないように、と書かれています。

 

Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs (badblockの出力がe2fsckまたはmke2fsプログラムに送られる予定の場合) , (中略) it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs (ユーザーが badblocks を直接実行しないことを強くお勧めします。むしろ、e2fsckおよびmke2fsプログラムの-cオプションを使用してください) .

 

さて、実際の動きですが、開始からまずランダムなパターンの書き込みが行われたようです。4時間 40分で 100% に達し、

Testing with random pattern: done

となりました。現在のところエラーは検出されていません。

そして今度は Reading and comparing: が進行しています。たしかに、dd で全体に 0 を書き込むにも同じ時間がかかっていますから、納得できる作業時間です。

ということはですよ、デフォルトが 4つのパターンを指定しているとすると、書き込みだけで 18時間 40分を要することになります。読み出しと比較に同じ時間かかるならば、全体の作業時間は 37時間 20分と見積もられます。

 

そしてついに badblocks コマンドが終了しました。正確な時間をチェックしてないのですが、ほぼ書き込みと同じほどかかっています。

$ sudo badblocks -svw -b 4096 -c 256 -t random -o badblocks.txt /dev/sdb
Checking for bad blocks in read-write mode
From block 0 to 122096645
Testing with random pattern: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

結果、不良セクタは検出されませんでした。エラーがなかったので badblocks.txt も作成されていません。そして予定したとおり、ランダムパターンの書き込み読み出しを一回り実行して終了ということでした。

 

どうなんでしょう? この HDD ってまだしばらく利用できそうじゃないですか (^_^;)

 


■直す価値のないハードディスクを修復してみる の弐

さて、S.M.A.R.T. テストで多くの不良セクタが見られるにもかかわらず評価が PASSED の HDD (500GB) を、物は試しに修復してみようとしていますが、あまりに不良セクタ予備軍などが多いので、あっさり全部潰してしまおうかと (^_^;)

 

全ブロックに 0 を書き込んでみたいのですが、方法として、いつも HDD の廃棄のときに利用している shred コマンドで可能です。でも今回は、あまり使ったことがない dd コマンドでやってみようと思います。

なお、時間が長くなるので、以下、別のパソコン (linuxBean) で作業を行いました。

$ sudo dd if=/dev/zero of=/dev/sdb bs=4096

多分 4時間ぐらいはかかるのでしょうけど、進行状況がわかりません。そこで、別のターミナルを開いて

$ sudo killall -USR1 dd

とすると進行状況が表示されます。定期的に表示させるには watch コマンドを使うとよいです。

$ sudo watch -n 600 killall -USR1 dd

-n の値が繰り返しの秒数です。頻繁に表示しても仕方がないので、10分おきにしています。

 

ちなみに、ubuntu 18.04 の man dd で調べると、

 

status=LEVEL

The  LEVEL of information to print to stderr; (中略) 'progress' shows periodic transfer statistics ( 'progress' は定期的な転送統計を表示します)

 

と書いてあるので、status=progress をつければ良さそうですね。試してませんが (^_^;)

ubuntu の dd のバージョンは 8.28 ですが、linuxBean は 8.13 でこのオプションはありませんでした。

 

で、結果 dd は 4時間 40分で終了しました。続けて S.M.A.R.T. テストを行います。

$ sudo smartctl --test=long /dev/sdb

予定時間は 3時間 50分ほどですので、パソコンにおまかせして就寝します (^_^;)

 

一夜明けて、テストの結果を確認しました。

$ sudo smartctl -a /dev/sdb

テスト評価は PASSED です。

SMART overall-health self-assessment test result: PASSED

ログのステータスも正常に終了しています。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     25478         -

属性データの抜粋です。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       1 (1999, 1)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1 (5, 13648)
197 Current_Pending_Sector  0x0012   100   001   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       209

属性データについてざっとググってみたけど、なるほどって思えること書いてあるサイトにまだ出会っていません。今の俺には難しすぎる解説ばかりってことです (^_^;)

197 Current_Pending_Sector (現在保留中のセクタ) はなくなりました。予備軍は一掃されたってことですかね。

5 Reallocated_Sector_Ct (再割当てされたセクターの数) は 1 のままです。代替領域に再割当てされた不良セクターですので、OS からは見えない奴です。(1999, 1) というのは代替領域が 2000 あるってことでしょうか?

196 Reallocated_Event_Count (再割当てイベントの回数) は再割当てを試行した回数です。

198 Offline_Uncorrectable (オフライン修正不可能) が当初の 108 から 209 に増えました。再割当てできなかったセクターらしく、こいつがいわゆる不良セクターって奴かな?

 

それでは次は、badblocks コマンドで不良セクターの検査をしてみましょう。

 


■直す価値のないハードディスクを修復してみる の壱

以前修理したノートパソコン FMV-BIBLO NF/E70 から取り出した HDD ですが、表向きは特に異常が出ないけど、S.M.A.R.T. テストをすると read failure で中断してしまうという状態です。直す価値はないのではないかと思っています。が、物は試し修復してみようと思います。技術的な興味と後学のためとゆーことで (^_^;)

以下、壊れてもかまわない、データも消失してかまわないというレベルでの話ですので、真似してみようという物好きな人も自己責任でお願いします。

 

セルフテストの評価は PASSED になっています。

SMART overall-health self-assessment test result: PASSED

 

セルフテストのログです。read failure で中断しています。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%     25453         172907425

 

属性データの抜粋です。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       1 (1999 1)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1 (5 13648)
197 Current_Pending_Sector  0x0012   058   058   000    Old_age   Always       -       43
198 Offline_Uncorrectable   0x0010   046   046   000    Old_age   Offline      -       108

不良セクタに関連する数値の抜粋ですが、けっこう悪くなっている感じです。

 

テストでエラーになる LBA は 172907425 です。これがあるパーティションは /dev/sdf2 だということが以下でわかります。

$ sudo fdisk -l /dev/sdf
ディスク /dev/sdf: 465.8 GiB, 500107862016 バイト, 976773168 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x3f3c3b21

デバイス   起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/sdf1  *        2048   1126399   1124352   549M  7 HPFS/NTFS/exFAT
/dev/sdf2        1126400 976771071 975644672 465.2G  7 HPFS/NTFS/exFAT

ファイルシステムは NTFS でブロックサイズは 4096 バイト、1 セクターは 512 バイトですから、問題の LBA が含まれるブロックは、

 

(172907425 − 1126400 ) × 512 ÷ 4096 = 21472628

 

となります。

ちなみに、ブロックサイズは NTFS では Windows のコマンドプロンプトで

> fsutil fsinfo ntfsinfo X:

でわかります。ext3 などは Linux で

$ sudo tune2fs -l /dev/sdf2

で調べることができます。

 

このブロックを潰します。

$ sudo dd if=/dev/zero of=/dev/sdf2 bs=4096 count=1 seek=21472628

1+0 レコード入力
1+0 レコード出力
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000202855 s, 20.2 MB/s

$ sudo sync

sync はメモリーとディスクを同期させるっていうコマンドです。

 

S.M.A.R.T. ショートテストしてみましょう。

$ sudo smartctl --test=short /dev/sdf

結果のログです。Completed without error となりました。

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error

# 1  Short offline       Completed without error       00%     25457         -
# 2  Short offline       Completed: read failure       90%     25453         172907425

属性データもみてみましょう。

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       1 (1999 1)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1 (5 13648)
197 Current_Pending_Sector  0x0012   059   058   000    Old_age   Always       -       42
198 Offline_Uncorrectable   0x0010   046   046   000    Old_age   Offline      -       108

ん〜、Current_Pending_Sector が一つ減っただけです。一つ潰しただけだから当然ですよねぇ。潰したけど Reallocated_Sector_Ct が増えないのはなぜ? HDD の詳しい知識がないので俺にはわかりません m(__)m

 

で、次にロングテスト ( 4時間近くかかりました) を行うと別の LBA でエラーが出ます。それを潰して、またロングテストして… あ〜それを 40回以上やります? つまり、Current_Pending_Sector が一つぐらいならこうして潰してもいけるのかな、って感じ。こんなに傷んでる HDD ではやる価値ないってことです。

じゃぁ次は、あっさり全部を 0 で潰してしまいましょうか。

 


■LED Cube 4x4x4 を試してみた

シフトレジスターがうまく動きましたので、LED-Cube 4x4x4 を作ってみます。が、キューブ自体は組み立てる気がないので、ブレッドボード上に 64個の LED を並べて自由なパターンに点灯できるようにしました。

 

回路図です。

LED はアノードコモンで、アノード側のトランジスタ 2SA1015 でレイヤを制御します。レイヤのインターロックは省略しました。まぁ、気分です (^_^;)

シフトレジスタは 2段に繋いで、16コラムを制御しています。


led-cube_4x4x4_回路図

 

スケッチです。

 

#include <MsTimer2.h>

 

int ptn[][4] = {                  // Pattern data
//{LayerA,LayerB,LayerC,LayerD},

  {0x0001,0x0000,0x0000,0x0000},
  {0x0013,0x0000,0x0000,0x0000},
  {0x0137,0x0000,0x0000,0x0000},
  {0x137f,0x0000,0x0000,0x0000},
  {0x37fe,0x0001,0x0000,0x0000},
  {0x7fec,0x0013,0x0000,0x0000},
  {0xfec8,0x0137,0x0000,0x0000},
  {0xec80,0x137f,0x0000,0x0000},
  {0xc800,0x37fe,0x0001,0x0000},
  {0x8000,0x7fec,0x0013,0x0000},
  {0x0000,0xfec8,0x0137,0x0000},
  {0x0000,0xec80,0x137f,0x0000},
  {0x0000,0xc800,0x37fe,0x0001},
  {0x0000,0x8000,0x7fec,0x0013},
  {0x0000,0x0000,0xfec8,0x0137},
  {0x0000,0x0000,0xec80,0x137f},
  {0x0000,0x0000,0xc800,0x37fe},
  {0x0000,0x0000,0x8000,0x7fec},
  {0x0000,0x0000,0x0000,0xfec8},
  {0x0000,0x0000,0x0000,0xec80},
  {0x0000,0x0000,0x0000,0xc800},
  {0x0000,0x0000,0x0000,0x8000},
  {0x0000,0x0000,0x0000,0x0000},

};

 

  unsigned long cycle =200;   // Pattern cycle
  int dataPin = 2;
  int clockPin = 4;
  int layer[4] = {8,9,10,11};
  int nptn = sizeof(ptn) / sizeof(ptn[0]);
  int cptn = 0;

 

void chptn(){
  cptn++;
  if (cptn > nptn-1)
    cptn = 0;
}

 

void setup(){
  pinMode(dataPin, OUTPUT);
  pinMode(clockPin, OUTPUT);

  for (int i=0; i<4; i++){
    pinMode(layer[i], OUTPUT);
    digitalWrite(layer[i], HIGH);
  }

  shiftOut(dataPin, clockPin, MSBFIRST, 0xff00 >> 8);
  shiftOut(dataPin, clockPin, MSBFIRST, 0xff);

 

  MsTimer2::set(cycle, chptn);
  MsTimer2::start();
}

 

void loop(){
  for (int i=0; i<4; i++){
    shiftOut(dataPin, clockPin, MSBFIRST, ~ptn[cptn][i] >> 8);
    shiftOut(dataPin, clockPin, MSBFIRST, ~ptn[cptn][i]);
    digitalWrite(layer[i], LOW);
    delay(1);
    digitalWrite(layer[i], HIGH);
  }
}

 

パターンデータは 16進数になっています。

起動時にレイヤとコラムをすべて HIGH に初期化し消灯させています。

パターンの切り替えは MsTimer2 で割り込み処理しています。

シフトレジスタへの出力は shiftOut 関数を使います。LOW で点灯なのでパターンデータを NOT しています。シフト出力中に LED が点灯しないように、出力が終わってからレイヤを ON します。

その他、基本的に 3x3x3 と同様ですね。

 

ブレッドボードです。

今回は 0.5mm 単線で配線しました。ストリッパー使ったり面倒っちゃ面倒ですけど、まぁ慣れです。


LED-Cube 4x4x4

 

 


■シフトレジスターSN74LS164Nを使ってみる

LED Cube を制御するためにシフトレジスターを使ってみようと思います。

 

ググると SN74HC595N がよく出てくるのですが、いつも行くパーツ屋さんには在庫がなかった。毎度のことだけど品揃えは悪い。何か代わりはないかなと探して見つけたのが SN74LS164N という TTL のシフトレジスターです。CMOS のもあったのですけど、こっちが安かったから (^_^;) SN74HC595N と比較するとこちらはストレージレジスターがありませんが、まぁ実験に使うには問題ないでしょう。

 

さてとりあえず、あまり考えもせずに下のような回路を組んで動かしてみました。


shift-register-test01_回路図.png

 

スイッチを押すと LED が順番に点灯し、離すと順番に消えていくという回路です。の、はずです。

が、スイッチを押すと 8 個の LED がいっぺんに点灯する… 離すといっぺんに消灯する… しかもクロックの立下りでも反応する… なんでやねん (^_^;) ??? 

さんざん悩んで、ググって、でも SN74LS164N の情報がほとんどない。LED の駆動にバッファを入れたり、スイッチにコンデンサー入れたりしてみたけど、まったく改善しない。

 

そしてようやく見つけたサイトがここ 8-bit shift register 74LS164 not working でした。まさに今の俺と同じ症状です。

原因はクロックの波形が綺麗でないのではないかということ。対策は波形整形のためにシュミット回路を入れてみる、でした。早速シュミットインバータを挿入してみると、みごとに LED が順番に点灯してくれました。

 

そしてもう一つ、この記事に書かれていたのは、SN74LS164N から取り出せる電流の推奨値は 0.4mA だということ。逆に出力へ流し込むように使うほうが良いのだということでした。たしかにデータシートの推奨値を見ると IOH = -0.4mA 、IOL = 8mA となっています。

一般的に TTL の場合、入力は LOW で吐き出し、出力は LOW で吸い込みですから、その通りだと納得です。基本を忘れてはいけません (^_^;) 逆に入力が HIGH では電流がほとんど流れませんから、クリア (CLR) 入力のように直接 +5V ラインにつなげます。

 

ということで、最終的に出来上がったシフトレジスターのテスト回路は以下のようになりました。


shift-register-test02_回路図.png

 

出力 LOW で点灯ですので、データ入力も LOW で点灯、HIGH で消灯となります。クリア入力は常に HIGH にしていますが、これを LOW にすると出力がクリアされます。ただし、クリア時は出力 LOW となり全点灯します。

CMOS で HIGH 時点灯に慣れているとちょっと使いにくいかもしれませんね。

 


■LED Cube 3x3x3 を作ってみた - 組み立て

回路もスケッチもうまくいきそうなので、Cube を組み立ててみました。

 

Cube の組み立てはググるといろいろ出てきますので参考に。今回は LED のリードを折り曲げ加工してはんだ付けで組み立てましたが、数が多くなるとかなり難しいですね。治具に固定して作業するのですが、逆にフレームを作って LED を取り付けていくといった方法を考えたほうが良さそうな気がします。

ケースに収めて仕上げるのも良いのですが、今回はここまでにしようと思います。

 

 

led-cube_3x3x3

 

 

回路は、Arduino で直接駆動できる電流値を確認しているのでバッファをなくしました。その代りスケッチをミスってもレイヤが同時に ON しないようにインターロックを残します。それらを 5cm x 7cm のユニバーサル基板に組んで、ジャンパーで Arduino に繋ぐようにしました。

最終的な回路は以下のようになっています。スケッチは「LED Cube 3x3x3 を作ってみた - Arduino スケッチ」の通りです。

 


led-cube_3x3x3_回路図.png

 

さてと、次は Cube を 4x4x4 にして、シフトレジスターを使ってみようと考えています。

 


■ubuntu 18.04 / NASのPC連動電源機能を使う

我が家で利用しているバッファローの NAS TS-WXL には「PC連動電源機能」があります。これは、NAS Navigator2 をインストールした PC の電源の on/off に連動して NAS を自動的に on/off する機能です。HDD を起動/停止させるのが良いかどうかわかりませんが、夜間など誰もパソコンを使っていないときは節電しようよってことで利用しています。

しかぁし、NAS Navigator2 というアプリケーションは Windows 用で ubuntu では使えない。ubuntu をメインに使っているのに、NAS を起動させるために Windows を起動しなければならないとゆー本末転倒なことになっております (^_^;)

 

そこで、この PC連動電源機能を ubuntu でも利用できないか、という話。

 

Windows では何をしているのか。

WireShark でパケットのやり取りを見てみると、ときどき WOL (Wake on LAN) の Magic Packet が NAS へ送られていることがわかります。150 秒おきですが、なぜか 140 秒だったり 15 秒だったり…

「NAS Power Management Service」というサービスがこれを実行しているようで、Magic Packet は 3 回連続でポート 9 へ送られます。これを停止すると NAS は 300 秒後にシャットダウンします。NAS Power Management Service を再度起動すると Magic Packet がポート 9 へ送られ、NAS は起動します。

ちなみに NAS の WOL について説明書には、ポート 2304 を待ち受けていると書かれています。実際にはポート 9 でも起動できますけどね。

 

つまり、ubuntu でも 150 秒間隔で Magic Paket を送り続ければいいんじゃないのん?

 

スクリプト naspoweron.sh を書いてみました。

#! /bin/bash

while true

do

  for i in `seq 3`

  do

    wakeonlan -i 192.168.1.xx -p 9 AA:BB:CC:DD:EE:FF

  done

  sleep 150s

done

これを ubuntu 機で実行すると NAS が起動、150 秒おきに Magic Paket が送信されて NAS は稼働し続けてくれました。

 

ではこのスクリプトを ubuntu server に仕込んじゃいましょう。そうすればサーバーが起動すれば NAS も起動するようにできます。スクリプトを自動起動させる方法はいくつかあるようですが、サーバーの自動シャットダウン用に crontab を使っているので、これを利用することにします。

 

$ sudo crontab -e

 

次の一行を追加します。

 

@reboot /home/hoge/naspoweron.sh


パケットの送出を確認するには tcpdump を使います。

 

$ sudo tcpdump host 192.168.1.xx

 

クライアントの ubuntu desktop 18.04 では「自動起動するアプリケーションの設定」に追加すれば良いですね。

ではしばらく使ってみて、どうなるかみてみよう (トランプ氏風に (^_^;) )

 


| 1/59PAGES | >>

■calendar

S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
<< May 2019 >>

■search this site.

■recommend

毎日貯まるポイントサイト ECナビ

■recommend

* 楽天ROOM *

■Twitter

■recommend

■recommend

■selected entries

■categories

■archives

■recent comment

■recent trackback

■links

■profile

■others

■mobile

qrcode

■powered

無料ブログ作成サービス JUGEM