猫の手シリーズの基板設計

食わず嫌いのKiCadであったが、慣れてしまうとどうということはなく、猫の手シリーズの基板くらいの規模だと一日1枚出来上がるようになった。

猫の手3号c

3号c(PS PAD送信機)は既にM.A.D.社の試作品があるが、HOSIDEN版のPADに対応できていなかったので、今回の基板でMITSUMI、HOSIDEN両対応にした。KiCadにはショートランドのパターンが入っていなかったので、適当にフットプリントをでっち上げた。MISUMIとHOSIDENの基板はケーブル接続に同じピッチの7pのコネクタを使っているくせにアサインが異なるのがイヤラシイのだが、PICの初期化プログラムでJP1を調べてピンアサインを変更する仕組みとした。自動対応も検討したが無理だった。HOSIDENの基板を改造するときにはあらかじめJP1をショートしておく。

PAD内部スペースの都合でICソケットが使えないので、ファームの書き換えができるようにICSPパターンも用意した。秋月のスルーホール用ジャンパワイヤーが差し込めるように穴経は0.8mmに設定。とはいえ、バグでもない限りは使わないような気がする。JP2は通常CLOSEで運用し、ICSP時はパターンカットしてOPENにする。

 

PS PADの基板に実装してしまうと見えなくなってしまう裏面。ICSP時のJP2の扱いはこちらの面にしか書いていないが、表面に余裕がないので致し方なし。

猫の手3号b

引き続き3号b(SFC PAD送信機)を設計。これはM.A.D.社設計のものと機能的には同じ。コピーした訳ではないが、PICやコネクタのアサインやPAD内部のスペースの制約から必然的に似たようなレイアウトになる。

赤外線LEDは斜め方向にリードを曲げて実装する関係で、斜めのフットプリントを作ってみた。この基板は配線数も少ないので設計も簡単だった。

配線しやすいようにPICのピンを割り当てていたのでビアは不使用。M.A.D.社のものとは異なり、面実装タイプの部品には非対応。PICのピンに余裕がないためICSPには非対応であり、ファームを書き換える場合はSFCコントローラ基板から取り外す必要がある。

猫の手1号

最後に猫の手1号送信機。M.A.D.社で既に商品化されているが、一応自分なりに作ってみた。

猫の手1号は処理速度を優先してプログラムを書いてしまったため、PICが基板実装しやすいピンアサインになっていない。数本の信号はビアを通して引きまわしたが、なるべくビアは少なくなるように、ベタGND領域が広くなるように配慮したつもり。

この基板はDサブコネクタとJP1を利用してICSPができる仕組みになっているため、ICソケット不使用でも問題なし。コンパクトに作れるようにJP1は2㎜ピッチのピンヘッダにしてみた。ちなみに猫の手4号(FC送信機)も同様の仕組みでICSP可能。

一度実寸でプリントして干渉等の問題がないことを確認し、FusionPCBに発注しようと思う。5枚で7.9$のキャンペーン中にやってしまいたいところ。

重い腰上げてKiCad

昨年より開発していたレトロゲーム機用赤外線コントローラ「猫の手リモコン」シリーズは趣味の範囲でM.A.D.社に製造・販売をお願いしていたが、M.A.D.社の本業が忙しいらしく、今後基板の新造や量産をお願いするのが難しくなってきた。個人的には製品としての量産とか収益とかは興味の対象外ではあったが、このまま埋もれてしまうのも忍びなく、自分でやれる範囲で作って「家電のKENちゃん」さんを通じて委託販売してみることにした(双方にコンタクトを取って了解済み)。

とりあえず猫の手1号(MSX受信機)と3号b(SFC-PAD内蔵)、3号c(PS-PAD内蔵)の基板はM.A.D.社設計のものがあるが、2号(MSX/MD-PAD送信機)と4号(SFC受信機)の基板設計が手付かずだったので、重い腰を上げて基板設計をやってみた。KiCadはトラ技で2回(2016.7月、2017.10月)特集が組まれていて、これに収録されているチュートリアルの動画で一通りの手順は覚えた。概念とフローが分かってしまえば、特別難しいものではなく、約1週間で「猫の手4号」の設計と発注が完了した。

基板製造業者はElecrowとFusionPCBで検討したが、Vカットが追加料金不要らしいFusionPCBの方にしてみた。基板の配列は、pcbnewを単独で起動し、表示をOpenGL(3D)に切り替え、ファイル>ボードを追加で適当なところに置き、右クリックで「配列の作成」を選択して基板サイズの間隔で並べればOK。Vカットの指示は基板外形のレイヤーに書き込めば良いとのことで、適当に線を引っ張って矢印と文字を作成した。

この状態のガーバーデータを出力して、FusionPCBにアップロード。その場でイメージを確認したのがコチラ。FusionPCBは2017.12月現在SALE中らしく、10x10cm以下の基板5枚で7.9$(しかも送料込み)とバカみたいに安い。1枚の基板に3×4で面付けしたので、60個分の基板で1000円以下。初めての発注なので何かやらかしていなければ良いが、失敗しても大した痛手でないのは有難い。

引き続き、猫の手2号の基板も設計。コチラはほぼ1日でできた。仕上がりのイメージを3Dビューで確認できるのが素敵。

コチラの基板は10x10cmに5×2で面付けできるから、50個分で1000円以下。こんなにお手軽で安く基板が作れるのなら、チマチマ配線する人もいなくなるよなぁ…。

CAPTCHA画像の生成

DS216jでWEBサーバーを構築する備忘録の続き。

サーバーにImage::Magickのインストールができない状況で現状のBBSを温存するためには、何か別の方法でCAPTCHA画像の生成をしなければならない。画像の生成だけならPHPで書かれた「Securityimage」で比較的簡単に出来たが、cgiから呼び出して使うにはキーの認証に難がある。で、perlでImage::Magickを使わずにCAPTCHA画像を生成する方法が無いか調べてみたところ、GD::SecurityImageというperlモジュールが使えそう。

試しにCPANを利用して下記コマンド実行したところエラー無くインストールは完了。

keyinit.plの改造

GD::SecurityImageはCAPTCHA画像の生成のみを行うもので、キーの認証機能は含まれない。そこで、キーコードの生成・認証については今までどおりこちらで配布されているスクリプトを使うことにした。keyinit.plはキーのランダム生成と、出力する画像フォーマットの設定、キーの暗号化と復号の役割を持ち、cgiのプラグインとして動作する。これを以下のように改修した。

まずはImage::Magick用の設定項目である下記部分はザックリ削除。

代わりにGD::SecurityImage用の設定項目を追記する。なお、フォントのluxirb.ttfはNASにインストールされていなかったので、古いサーバーからコピーした。画像フォーマットについてはこちらのサイトを参考にパラメータを設定。

image_gen.cgiの改造

image_gen.cgiは暗号化された確認キーを引数として受け取り、keyinit.plを通じて復号し、CAPTCHA画像を出力する役割を持つ。これを下記のように書き換えた。

これらの改修にて、BBSのcgi上でCAPTCHA画像の生成と認証が正常にできるようになった。Image::Magickを使った時と比べてやや単調なイメージになってしまうが、一応キーは暗号化されているし、ロボットSPAMに対しては一定の抑止力にはなるだろう。

開発環境のインストール

Synology DS216jをWEBサーバーとして設定する備忘録、前回からの続き。

BBSのCAPTCHA画像の生成には旧blog記事に書いたようにこちらのサイトのスクリプトを利用させてもらっている。導入前はSPAM投稿が頻繁にみられていたが、ここ数年SPAMを削除した記憶がないので効果はかなりあったと思う。今ではCAPTCHAはAIで解読できるらしく、時代遅れという説もあるが、現時点ではSPAMの被害はゼロといってよく、当面はこのまま様子を見ることにしたい。

運用中のCAPTCHA生成スクリプトは、画像イメージの作成にImage::Magickというperlのモジュールを必要とする。インストールはyumやcpanといったパッケージマネージャ経由か、ソースパッケージからのビルドで行うが、このNASでyumは使えないようなのでソースパッケージをビルドできるように開発環境をインストールすることにした。

パッケージマネージャーのインストール

まずは、Entware-ngというパッケージ管理ソフトをインストールするが、こちらのサイトの記載通りの手順でできた。これでopkgコマンドが使えるようになるのでPackages listを見てsectionがdevelとなっているものは一通りインストールしておいた。

また、Synologyの開発環境のインストールとして、こちらのサイトを参考にして、DS216jと互換性のあるDSM Tool Chainをインストールした。これでソースパッケージのビルドができるようになるはず。

Image::Magickがインストールできない

Entware-ngのPackages listを見ると、imagemagickのインストールに対応しているが、cgiから利用するにはこれだけではだめで、PerlモジュールのImage::Magick(perl-magick)のインストールも必要となる。残念ながらopkgではperl-magickのインストールは出来ないようだが、opkgでCPAN(perlbase-cpan)をインストールすればCPAN経由でImage::Magickをインストールできるかも、ということでやってみる。下記はエラー無く完了。


これはインストールの途中で、ccache-gccが無いというエラーが出て止まってしまう。Cコンパイラの動作を高速化するキャッシュだそうだが、ccasheのソースパッケージをビルドしてインストールしてみたが解決しなかった。パスを通してもccache-gccとしてシンボリックリンクを貼ってもダメ。たぶん、上でインストールしたDSM Tool Chainにccacheが入っていないのがご不満なのだろうと思う。

CPAN経由は諦めて、Image::Magickのソースパッケージを展開してビルドしてみたが、sudo make installの段階で「致命的エラー」が出て終了。

CGIからPHPは使えるか

どうやってもImage::Magickがインストールできなかったので、方針転換して画像生成を他の方法で行うことにした。SecureimageというPHPスクリプトを使うと、比較的簡単かつ凝ったCAPTCHAイメージを作れるらしいということで、試してみた。

こちらのサイトを参考に、Secureimageをサーバーに展開し、BBSのcgiのCAPTCHAイメージ挿入部分を下記のように書き換えてみたところ、綺麗に表示されるようになった。


表示までは簡単であったが、ここからが問題。キーの認証はどうするのか。perlとphpに互換性はないので別々にスクリプトを動かすことになるが、引数のやりとりに難があるし、セキュリティ上も好ましくないことが分かったため、この方法は却下となった。

perl / cgiスクリプト実行環境の整備

前回からの続き。SynologyのNASはDSM経由でapache,perlのインストールができるが、任意のディレクトリでcgiを動作させるためにはコンフィギュレーションファイル等の編集による設定が必要。以下に設定した項目について覚書として記録しておく。

 httpd22.confの設定

DSMではapache2.2と2.4のインストールに対応しているが、2.4は何かとトラブルが多いとの話なのでapache2.2で運用することにした。この場合設定ファイルはhttpd22.confとなり、これをroot権限で書き換える。

以下のようにcgiを動作させたいディレクトリの分だけhttpd22.confに追記する。.htaccessファイルを置く方法もあるが、httpd22.confに記述したほうがパフォーマンスが良いらしい。

 

httpd.conf内のAddHandlerの記述に追記して.plファイルもcgiスクリプトとして設定する。

 

なお、viの操作は、iキーで挿入モード、escで戻り、:wで上書き、:qで終了。設定を有効にするにはapacheのrestartが必要であるがDSM上で停止、始動が可能。

cgiファイルの編集

cgiファイルの先頭のperlのパスを明示する部分については、下記のようにしておけばOK。

パーミッション設定

cgi,plファイルの属性はchmod 755 で変更しておく。ログファイルは666、書き込みの発生するディレクトリは777にしておく。

jcode.plの修正

perlのバージョン違いによりjcode.plがエラーを吐くようになったため、下記を参考にjcode.plを書き換えた。http://icepotato.cocolog-nifty.com/blog/2014/04/jcodepldefinedh.html

ここまでやって、BBSのログが表示されるようになったがCAPTCHA画像が出てこない。これについてはまた次回。

旧コンテンツの移転準備

PS2Linux’に換わる新サーバーは世間での評判の良いSynology製のNAS DS216j を選択した。理由はDCTP-IP対応のDLNAメディアサーバーとしても使えるから。有料アプリが必要であるが、nasneのコンテンツをダウンロードムーブできるところが決め手になった。WEBサーバーとしての設定であるが、数回に分けて備忘録として書いておくことにする。

導入と概要

とりあえずNASにDiskStation Manager(DSM)を使って必要そうなパッケージをインストールする。デフォルトではWEBサーバーとしてNginxが設定されていて、webフォルダにindex.htmlファイルを置いたところトップページとしてアクセス可能になった。SAMBAを有効にするとWindows機からネットワークドライブとして直接アクセスできるため、ファイルの読み書きについては非常にラク。ただし、新規に書き込んだファイルは属性が777となるため、変更が必要な場合はSSHでログインし、コマンドで行わなければならない。

cgiスクリプトで書かれたアクセスカウンタやBBSを動かすにはback-end serverとしてapache、インタプリタとしてperlが必要になるのでこれもDSMでインストールし、Web Stationの設定でback-end serverをapacheに設定する。apacheはバージョン2.2と2.4の選択ができるが、2.4は何かとトラブルが発生するらしいので2.2を入れておいた。

DSM上では、apacheのインストールのほか、サービスの始動・停止ができるが、細かい設定はコマンド操作が必要となる。DSM上でSSHサービスを有効にしておき、Windowsマシンからteratermでログインする。

まずはapacheの設定としてhttpd.confを編集することになるが、$sudo find / -name httpd.conf で検索してみたがヒットしない。どうやらこのシステムでapache2.2を稼動させる場合の設定ファイルは httpd22.confという名前になるらしい。詳細は次回に記述するが、このファイルを編集してapacheをrestartした。cgiにも若干の手直しは必要だが、これでアクセスカウンタcgiが動作するようになった。

BBSのcgi一応機能するようになったが、スパム対策に組み込んだCAPTHA画像が表示されないため投稿ができない状況であった。CAPTHA画像の生成のためにはperlのImage::Magickモジュールのインストールが必要であるが、この問題をクリアするために、非常に苦労させられることとなった。

新サーバー、blogの構築開始

当サイトの自宅WEBサーバーとして12年前から稼働させているPS2Linux’の寿命に備え、新サーバーを構築中。MovableTypeの旧blogはデータベースのクラッシュにより更新不可となったため、新しくWordpressによるblogの構築をしてみる。

旧サーバーはジャンク品の富士通のノートPCマザーをPS2のガワの上半分に入れた機体で、ACアダプタにて24時間連続稼働状態。中古の3.5インチHDD一基での運用だがこれまで大きなトラブルはなし。ノートPC用のマザーボードは元々長期連続運用を想定しない作りになっていると思うが、ここまで長持ちするとは予想外だった。そろそろクラッシュに備えるべきと考え、バックアップを取りつつWEBサーバーの移行作業を進めているところ。

旧サーバーのMovabletypeと比べてあまりに簡単にblogが設定できてしまって驚いた。特にデータベースのmysqlの設定が難解だった気がするが、今はほとんど自動でやってくれるんだな…。