SVX日記
2005-03-29(Tue) USBパラレル変換回路、製作開始
美品であるコトもありバラしは極力避けようと思っていたが、底面からクセの悪いケーブルが出ており、どーにもジャマなのでバラしてみた。2本のネジを外し、慎重にデッパリ部分をケースから抜いて、取り外す……なるほど、プリンタの機械部分はケース一体なので、制御基板部分だけがポッコリと外れた。ケース内には比較的余裕があり、赤丸で囲んだ部分にある基板を留めているネジあたりは、追加基板を共締めするのにピッタリである。
基板を観察すると、モータをゴリゴリと駆動するプリンタだけあって、220uFという比較的大きなコンデンサが付いている……が、ナニかが微妙にシミ出た痕跡があるのが気になるなぁ。コレは交換したほうがヨイかもしれん。220〜470uFの電解コンデンサを次回の部品購入リストに加えておこう。
他に気になったのは「HD6805V1」と記載のあるデカい石。DatasheetArchiveで調べたら、モトローラの6800系のセカンドソース、つまり日立製の6800というコトが判明した。ただしROM/RAM内蔵のワンチップマイコンタイプで、40pin中32pinまでがI/Oポートというストロングタイプである。オイラ68000系アセンブラの経験があるから、6800系の石を使うのに抵抗はないハズだ(ホントか？)。プログラム組みやすそうだなぁ。フラッシュタイプがあるなら使ってみたいモンである。
さて、観察はこれくらいにして、パラレルシリアル変換I/Fの開発にかかろう。今回はパラレル側から攻めていく予定を立てる。PICにパラレル通信機能を実装して単体で印刷できるコトを確認してから(以降、イ号作戦と呼称する)、シリアル通信対応(同、ロ号作戦)、USB対応(同、ハ号作戦)と進めていくのだ。
概ねの計画が決まったところで、トートツだがモルツタイムに突入。今日は「丹沢水系」である。東京近辺でモルツを購入すれば概ねこのタイプのモルツに当たるコトだろう。ぐびぐび……うむ、ここ数日恒例となっている前衛的表現をするならば「途方に暮れるペンギン」な味である。遊園地のコーヒーカップの上で、困ってウロウロするペンギンな感じ。なお、本表現に関してのみ、いかなる質問も受け付けていないのでよろしく。
作業再開。やっぱり変換I/Fはケース内に組み込んでしまうのが吉である。となると、できるだけ小さな基板を使う必要がある。前回、ケチって基板を再利用したために、使わずに済んだ基板の切れ端の出番である。最終的にUSB対応するとなれば、USB変換基板とのドッキングは必須であるから、ドッキングエリアを確保しつつも、単独でイ号作戦を遂行できるように配線と部品の配置をBschでデザインする。
ユニバーサル基板の切れ端は意外と便利である。必要に迫られて基板を切った際の残りの切れ端でも、なんとか詰め込もうと考えれば、意外と詰め込めてしまうものだ。しかし基板を切るのが面倒なのがいけない。EAGLEでユニバーサル基板をデザインし、細かく面付けするようOLIMEXに発注してしまおうか。追加のドリル代がエラいコトになりそうだ……それ以前にイヤがらせと受け取られそうではあるが。
今回使用するPICマイコンは16F648A。パラレル通信を実現するだけで10本のピンが必要となるので12F629では不足。16F819ではUSARTモジュールが付いてないので不適。USARTモジュールは使ったコトがないので不安だが、多分使えばラクできるのだろう。ダメなら以前に自分で書いたヤツ使えばイイし。
2006-03-29(Wed) WBEL4 in coLinux成功!!
さて、実はアドバンスド大戦略にうつつを抜かしつつも、以前からサッパリ動かすコトのできなかった、White Box Enterprise Linux 4(以下、WBEL4)の、coLinux環境へのインストールはチョロチョロと進めていたりする(仕事中に浮いた時間を探しては……)。
WBEL4はいわゆるRHEL4のクローンである。内容はほとんど同じ。よって、RHELのエクスペリメンタルバージョンであるFedoraとも親戚関係にある。だから「coLinux Fedora」なんてググってインストール方法を模索したりもしたのだが、見つかるのは決まって「本家のFedora-HowTOというWiki」で、コイツは熟読してもどーもよくわからんのだ。
・WBEL4のインストールCDでブート
・linux nofb でスタート
・CD Found で Skip
・Welcome で Next
・Language Selection で Japanese(日本語) で Next
・キーボード設定 で Japanese で 次
・アップグレードの検証 が出た場合 インストール で 次
・インストールの種類 Server で 次
・ディスクパーティションの設定 で Disk Druid で 次
・マウントポイント /、ファイルシステムタイプ ext3、容量 2008MB で OK、次
・ブートローダーの設定 で 次
・ネットワークの設定 で 編集、DHCP オフ、IPアドレス 192.168.0.4、ネットマスク 255.255.255.0 で OK
手動設定、ホスト名 wbel4-co、ゲートウェイ 192.168.0.1、1番目のDNS 192.168.0.1 で 次
・ファイヤーウォール設定 で 有効にする、すべてチェック、SELinux 無効 で 次
・追加の言語サポート で 次
・タイムゾーンの選択 で 次
・Rootパスワードを設定 で 適当に設定して 次
・パッケージインストールのデフォルト で カスタマイズ で 次
・パッケージグループの選択 で エディタ、テキストベースのインターネット、Webサーバ、メールサーバ、Windowsファイルサーバ、DNSネームサーバ、FTPサーバ、ネットワークサーバ、開発ツール、レガシーソフトウェアーの開発 を選択 ネットワークサーバ の中の dhcp を チェック 1,428M で 次
・インストール準備完了 で 次、続行
・インストール完了、再起動
・実際に一度再起動する(sshのカギを作るため)
・rootでログイン、shutdown -h now で、一度終了する・KNOPPIX(1CD Linux)でブート、端末画面を開く
・まずはcoLinux起動時にデバイスが足りずに止まってしまう問題に対処する。
$ su -
# mkdir wbel4
# mount /dev/hda5 wbel4
# mknod -m 600 wbel4/dev/console c 5 1
# mknod -m 666 wbel4/dev/null c 1 3
# mknod -m 666 wbel4/dev/zero c 1 5
・次にデバイスが正しく追加されない問題、デバイス認識関係の処理で止まってしまう問題に対処する。
# cp -a wbel4/sbin/start_udev wbel4/sbin/start_udev.org
# vi wbel4/sbin/start_udev
make_extra_nodes ルーチンの最後に
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do mknod $udev_root/cobd$i b 117 $i; done
mknod -m 666 $udev_root/ptmx c 5 2
を追加する。ファイル末尾付近の
scsi_replay、ide_scan、/sbin/udevstart
の行はコメントアウト
・USB接続の外付けHDDを接続、dmesgしてデバイスを調べれば/dev/sda1あたりのはず
・マウントしてWBEL4のインストールイメージを書き出す。
# mkdir usbhdd
# mount -t vfat /dev/sda1 usbhdd
# umount wbel4
# dd if=/dev/hda5 of=usbhdd/root_fs.wb4
※USB1.1しか対応してない母艦だったので、1時間強かかった
# umount usbhdd・coLinuxの走っているWindowsマシンにコピーする(c:\Program Files\coLinux\wbel4\root_fs.wb4)
・coLinuxの起動設定wbel4.colinux.xmlをdefault.colinux.xmlを元に作る、変更点は以下のとおり(オイラの場合)
13c13
< <block_device index="0" path="\DosDevices\c:\Program Files\coLinux\root_fs" enabled="true" />
---
> <block_device index="0" path="\DosDevices\c:\Program Files\coLinux\wbel4\root_fs.wb4" enabled="true" />
19,20c19,28
< <!-- block_device index="1" path="\DosDevices\c:\coLinux\swap_device" enabled="true" / -->
---
> <block_device index="1" path="\DosDevices\c:\Program Files\coLinux\wbel4\swap_fs.wb4" enabled="true" />
> <block_device index="2" path="\DosDevices\c:\Program Files\coLinux\wbel4\work_fs.wb4" enabled="true" />
> <block_device index="3" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-source-1.iso" enabled="true" />
> <block_device index="4" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-source-2.iso" enabled="true" />
> <block_device index="5" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-source-3.iso" enabled="true" />
> <block_device index="6" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-source-4.iso" enabled="true" />
> <block_device index="7" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-binary-i386-1.iso" enabled="true" />
> <block_device index="8" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-binary-i386-2.iso" enabled="true" />
> <block_device index="9" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-binary-i386-3.iso" enabled="true" />
> <block_device index="10" path="\DosDevices\c:\Program Files\coLinux\wbel4\manifestdestiny-binary-i386-4.iso" enabled="true" />
26c34
< <bootparams>root=/dev/cobd0</bootparams>
---
> <bootparams>root=/dev/cobd0 ro</bootparams>
40c48
< <network index="0" type="tap" />
---
> <network index="0" type="tap" name="coLinux40" />$ ./colinux-daemon.exe -c wbel4.colinux.xml結局、ハマったのはudevという、RHEL4から新しく追加になったデバイス自動管理機構のせいであった。一般にLinuxの場合、/devの下に強烈に多くのデバイスファイルが並んでいるが、接続もしてないし、使いもしないのになんでこうも多く並んでいるのだろうと疑問に思ったことはないだろうか？ それを必要なものだけに抑えたい、しかも自動的に……というのがudevの役割だ。だから、RHEL4では起動開始時点では/devの下はカラッポで、起動してから必要なデバイスファイルが作られる……のだが、どーもcoLinux環境ではうまく動かないっぽい。で、それをフォローしてやるのが、上記の/sbin/start_udevファイルへの記述の追加だ(udevの思想を無視したムリムリの追加だが、動けばいいのだ!!)。
2014-03-29(Sat) さくらのVPSを借りて、今、仮想の、デスクトップ！
どうも、オイラは「ぼぉーとゲームしてるのは性に合いませんね」というか、なんというか。のんびりしていると、むしろ「何かせねば」という強迫観念に襲われてストレスを感じる性格なのである。まぁ、別に「何か」といっても、さほどスゴいコトをやるわけでも、さほどスゴいモノを作るわけでもないのだけれどもさ。
で、イザ借りてみると、ちょっと前から、サーバの設置場所を選べるようになったとは聞いていたが、任意のISOイメージによるOSインストールもできるようになっていた。こりゃ、死角なしだな。今回は、ちょっと高いが、2Gプランを借りてみよう。ほぼデータを失う可能性がないストレージが200GB。高いといっても月に1500円弱だし、携帯電話の月額に比べりゃ安いもんだ。
インストールするOSは、せっかくなので最新のFedora20。どうも、ちょっとMINT15を味見したりしてるうちに、かなり様相が変わってしまっているらしい。もうすぐRHEL7が仕事の主戦場になることだし、多少は感覚を養っておかねば。
そもそも、Fedoraから離れてみようかと思ってしまった理由のひとつに、GNOME3のイマイチさがあったわけだが、いつの間にかFedoraでもMATEが使えるようになっているのは本当に助かる。ほとんどブラウザと端末作業ばかりのオイラだが、GNOME3はウィンドウを切り替えるだけでも苦痛だったんだよなぁ。
さくらのサイトから、ISOイメージインストールを呼び出し、sftpでFedora-20-x86_64-netinst.isoをアップロードする。systemdやfirewalldにとまどいつつ、手探りで「よく通る場所をけもの道に」しつつ、openvpnを導入……と、ふと、ここでなにげに「xrdpを導入して、リモートデスクトップ環境を構築」してみるのも楽しいのではないか、と思いついてしまった。
ところが、軽い気持ちでrdpを導入したが……接続はされるもののデスクトップ画面が現れない……なんじゃこりゃ。んじゃ、元祖のvncならどうか……こっちもダメ。うーむ、オイラ、GUI関係の仕組みについては弱いんだよな。結局、あちらこちらの情報を元に、問題の根っこが「デスクトップ環境にMATEを使っていること」であることを突き止めた。
デフォルトとはいえ、どうせみんなGNOME3なんか使わずにMATEの一択なんだろ、と思っていたのだが、こんなマイナバグが平気で残っているところをみると、そうでもないのか……オイラはマイノリティなLinux使いの中でも、さらにマイノリティなMATE使いなのか……というわけで、以下が、正しいvncの設定方法である。
・vncサーバ導入
# yum install tigervnc-server
・起動スクリプトを配置すべき場所だけ確認
# systemctl enable vncserver@:1.service
# rm /etc/systemd/system/multi-user.target.wants/vncserver@:1.service
・起動スクリプトを配置
# cp /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/multi-user.target.wants/vncserver@:1.service
・利用ユーザを設定
# vi /etc/systemd/system/multi-user.target.wants/vncserver@\:1.service
# diff /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/multi-user.target.wants/vncserver@:1.service
40,41c40,41
< ExecStart=/sbin/runuser -l -c "/usr/bin/vncserver %i"
< PIDFile=/home//.vnc/%H%i.pid
---
> ExecStart=/sbin/runuser -l user -c "/usr/bin/vncserver %i"
> PIDFile=/home/user/.vnc/%H%i.pid
・利用ユーザにスイッチ
# su - uesr
・vncパスワードを設定
$ vncpasswd
・デスクトップ環境の起動設定(MATEの場合はこれがキモ！)
$ vi .Xclients
$ cat .Xclients
#!/bin/bash
exec mate-session
$ chmod 755 .Xclients
$ exit
# systemctl daemon-reload
・vncサーバ起動
# systemctl start vncserver@:1.service $ vncviewer 10.8.0.x:1・vncサービス起動
・/home/user/.vnc/xstartupの実行……の中で、
・/etc/X11/xinit/xinitrcがあれば実行……の中で、
・/home/user/.Xclientsがあれば実行……が、ない(※)ので、
・/etc/X11/xinit/Xclientsがあれば実行……の中で、
・GNOMEかKDEならデスクトップセッション起動
・おぃ……ちょっとMATE？・rdpサーバ導入
# yum install xrdp
・rdpサーバ起動
# systemctl start xrdpxrdpの場合は、クライアントからのxrdp接続のあと、/etc/xrdp/startwm.shの実行の中で、/etc/X11/xinit/xinitrcが実行され、上記と同じルートを通るので、vnc設定の中で行った.Xclientsの設定により、こちらの問題も同時に解決されるのであった。
$ rdesktop 10.8.0.x今回の試行を行う前、rdpはプロトコル上、サウンドも扱えることを知っていたので、ちょっと期待していたのだが、実はrdpは、ほぼvncのラッパーに過ぎず(実際、内部でvncを起動して通信している)、そのような機能はないことに気づいた。
うーむ、それではリモートデスクトップ環境として、いかにも片手落ちではないか……と、ここで思いついてしまった。確か、pulseaudioにはリモートでサウンドデバイスを扱える機能があったような……というわけで、以下が、pulseaudioの設定方法である。
・デスクトップマシン(音声受信→スピーカー)側の設定
・一般ユーザでログインしてから
$ cd .config/pulse
$ cp /etc/pulse/default.pa .
$ vi default.pa
・外部からのtcp接続を受け入れる設定
$ diff /etc/pulse/default.pa default.pa
85c85
< #load-module module-native-protocol-tcp
---
> load-module module-native-protocol-tcp auth-anonymous=1
・デスクトップからログアウト、再度ログインすると、ポート4713が開かれる
$ netstat -anp | grep pulse
tcp 0 0 0.0.0.0:4713 0.0.0.0:* LISTEN xxxx/pulseaudio
tcp6 0 0 :::4713 :::* LISTEN xxxx/pulseaudio
・リモート(アプリ→音声送信)側の設定
・一般ユーザでログインしてから
$ cd .config/pulse/
$ cp /etc/pulse/client.conf .
$ vi client.conf
・デスクトップマシンへtcp接続するための設定
$ diff /etc/pulse/client.conf client.conf
24c24
< ; default-server =
---
> default-server = 192.168.0.x
・vncサーバを立ち上げると、ポート4713へ接続される
# systemctl start vncserver@:1.service
# netstat -anp | grep 4713
tcp 0 0 10.8.0.x:xxxxx 192.168.0.x:4713 ESTABLISHED xxxxx/mate-volume-c
tcp 0 0 10.8.0.x:xxxxx 192.168.0.x:4713 ESTABLISHED xxxxx/mate-settings$ vncviewer 10.8.0.x:1# yum install sox
$ play /usr/share/sounds/alsa/Front_Center.wav# systemctl start xrdp.service
・手元のマシンからrdpクライアントで接続してから、ポート4713へ接続される
$ rdesktop 10.8.0.x
# netstat -anp | grep 4713
tcp 0 0 10.8.0.x:xxxxx 192.168.0.x:4713 ESTABLISHED xxxxx/mate-volume-c
tcp 0 0 10.8.0.x:xxxxx 192.168.0.x:4713 ESTABLISHED xxxxx/mate-settings# rpm -ivh flash-plugin-11.2.202.346-release.x86_64.rpm 
