うちで8台利用しているSeagateのST32000542ASのファームウエアが、「突然電源が切れる」「電源が入らなくなる」など、不具合のあるバージョンCC34でした。

恐ろしいので、アップデートすることに。

アップデータのダウンロード

http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=213915&NewLang=en

このサイトからアップデータCDのISOイメージをダウンロードします。これをCDに焼いて使います。

アップデート

アップデートに利用するPCにアップデート対象のHDDだけを接続し、CDを入れた状態で起動します。この時、USB変換とか使ってはいけません。SATAで直接接続してください。

無事CDから起動すると、READMEが表示されるのでESCを押すと、次のようなメニューが表示されます。

メニュー

Lを押すとこのCDが対象としているHDDの型番とバージョンのリストが閲覧できます。

まず、HDDが正しく認識されているか、Sでチェックします。

HDD Scan

Sを入力してしばらくすると、写真の様に認識されたHDDの一覧が表示されるので型番とバージョンが対象のものである事を確認します。確認できたらESCでメニューに戻ります。

で、メニューからアップデートできれば良いのですが、できないらしいので、「Ctl+C」「y」と入力して、メニューを終了するとプロンプトが表示されます。

コマンド入力

ここに、写真のように、

FDL486A.EXE -m Hepburn -f HECC358H.LOD -s -x -b -v -a 20

と入力しEnterを入力すると、ファームウエアのアップデートが始まります。ここから完了するまで、電源を切ったり、キーの入力はしないでください。

下のように、プロンプトが表示されれば完了です。

アップデート完了

「FLASH-M.BAT」と入力すると、メニューに戻れるのでZでシャットダウンしました。

イギリス人であればこれをクリアするとエントリーフォームからエントリーできるみたいです。

Can you crack it?

で、先日大学の友達と相談しながらクリアしました。

Can you crack it? クリア

実はこれ、表示されてる問題をクリアしたと思ったらstage 2 of 3が出て来ます(笑)。

面白かったので、解答までの流れをブログに書きたいのですが、期日まであと1日ちょっとあるので、その後にします。

最近STM32でCANとか使っているのですが、時々送信に失敗してしまうという問題がありました。

たまになので問題ないのですが、気になったので調べてみるとSTMicroが用意しているSTM32F10x standard peripheral libraryのバグでした。バージョンは04/16/2010 のV3.3.0と古いやつですが。

具体的に言うと、現在送信しようとしているメッセージの状態を確認する関数

CAN_TransmitStatus にあります。

ここでは CANxのTSRレジスタのTSS_RQCP0、TSR_TXOK0、およびTSR_TME0ビットの値を見て、

CANTXPENDING(送信中)、CANTXFAILED(失敗)、CANTXOK(成功)を返しています。

が、こんな風にレジスタにアクセスするようなコードになってます。

switch (TransmitMailbox)
  {
    case (0): state |= (uint8_t)((CANx->TSR & TSR_RQCP0) << 2);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK0) >> 0);
      state |= (uint8_t)((CANx->TSR & TSR_TME0) >> 26);
      break;
    case (1): state |= (uint8_t)((CANx->TSR & TSR_RQCP1) >> 6);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK1) >> 8);
      state |= (uint8_t)((CANx->TSR & TSR_TME1) >> 27);
      break;
    case (2): state |= (uint8_t)((CANx->TSR & TSR_RQCP2) >> 14);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK2) >> 16);
      state |= (uint8_t)((CANx->TSR & TSR_TME2) >> 28);
      break;
    default:
      state = CANTXFAILED;
      break;
  }

これでは、レジスタに3回アクセスしてしまっており、アクセスとアクセスの間でレジスタの値が変わってしまうと変なstatusになってしまいます。その結果 default で CANTXFAILED がセットされてしまうというのが送信失敗の原因です(実際にはこの瞬間に成功しているが、失敗したと判断してしまう)。

最も修正量の少ない解決策は簡単で、CANx->TSRの値を一旦変数に入れてやればいいのです。

uint32_t _tsr =  CANx->TSR;
switch (TransmitMailbox)
  {
    case (0): state |= (uint8_t)((_tsr & TSR_RQCP0) << 2);
      state |= (uint8_t)((_tsr & TSR_TXOK0) >> 0);
      state |= (uint8_t)((_tsr & TSR_TME0) >> 26);
      break;
    case (1): state |= (uint8_t)((_tsr & TSR_RQCP1) >> 6);
      state |= (uint8_t)((_tsr & TSR_TXOK1) >> 8);
      state |= (uint8_t)((_tsr & TSR_TME1) >> 27);
      break;
    case (2): state |= (uint8_t)((_tsr & TSR_RQCP2) >> 14);
      state |= (uint8_t)((_tsr & TSR_TXOK2) >> 16);
      state |= (uint8_t)((_tsr & TSR_TME2) >> 28);
      break;
    default:
      state = CANTXFAILED;
      break;
  }

こんな風に。

で、最新のV3.5.0ではちゃんと修正されてました。

  switch (TransmitMailbox)
  {
    case (CAN_TXMAILBOX_0):
      state =   CANx->TSR &  (CAN_TSR_RQCP0 | CAN_TSR_TXOK0 | CAN_TSR_TME0);
      break;
    case (CAN_TXMAILBOX_1):
      state =   CANx->TSR &  (CAN_TSR_RQCP1 | CAN_TSR_TXOK1 | CAN_TSR_TME1);
      break;
    case (CAN_TXMAILBOX_2):
      state =   CANx->TSR &  (CAN_TSR_RQCP2 | CAN_TSR_TXOK2 | CAN_TSR_TME2);
      break;
    default:
      state = CAN_TxStatus_Failed;
      break;
  }

一度でアクセスするようになってます。でも返値変わってて、最新版に置き換えるのは大変そう…

証明書の取得

本来はSECOMやVeriSign等に有料で証明してもらうのですが、今回は以前にも紹介したCACertを載せときます。

• CAcertから証明書をもらおう！(その0:紹介)
• CAcertから証明書をもらおう！(その1:アカウントの登録)
• CAcertから証明書をもらおう！(その2:鍵と申請書の作成)
• CAcertから証明書をもらおう！(その3:CAcertから証明書をもらう)

ということで、証明書の取得は省略します。とりあえず、サーバーの秘密鍵 server.key と サーバーの証明書 server.cer が手に入った事にします。

nginxに設定

nginxでの設定は簡単で、既存の設定をコピーして、80番ではなく443番に変更し、SSLを有効にしてサーバーの鍵・証明書のファイルを指定してあげるだけです。

ちょっとその部分だけ書いてみます。

server {
	listen   443 default_server ssl;
	server_name	_;
	ssl_certificate /keys/server.cer;
	ssl_certificate_key /keys/server.key;

	location / {
		この辺は適当に
	}
}

リバースプロキシとしてnginxとして使っている場合も同様です。

名前ベースのバーチャルホストを使っている場合

ドメイン名を複数つかってバーチャルホストを使っている場合もあると思います。SSLではアクセスされたサーバー名がわかる前に証明書を渡さなければならないので、名前ベースのバーチャルホストでSSLは利用できませんでした。

が、SNI(Server Name Indication)というプロトコル拡張ができたので、名前ベースのバーチャルホストでも可能になりました。(ブラウザによっては対応してません)

設定は簡単で、httpと同じくserver_nameを設定するだけです。

リバースプロキシとして使っている場合は、証明書を変えるために、バーチャルホストの数だけServerディレクティブを作ってあげてください。

どう重いのかというと、Apacheは一つのプロセスが一つのHTTPリクエストを同期処理で裁いてるのでその間は他の処理をしません。なので、同時アクセス数が増えるとApacheはプロセスをどんどん生成します。(あるいは後からきたリクエストを待たせる)

なので、アクセス数が増えると急激にパフォーマンスが落ちるという問題を抱えてます。(ほかにもプロセスIDが足りなくなってどんなにリソースがあっても最大プロセスIDで制限されてしまう)

で、最近話題のハイパフォーマンスWebサーバーがnginx(えんじんえっくす)です。

nginxは一つのプロセスで複数のリクエストを非同期で同時に処理します。なので、アクセス数が増えてもパフォーマンスが落ちにくいという特性があります。特に静的ファイルの場合は処理のほとんどがI/O待ちなので効果が大きいです。

そこで、PHPとかSVNとか設定がめんどくさいものはApacheに任せておいて、静的なファイルだけをnginxに処理させてみると、Apacheへのリクエスト数は激減するはずです。

例えば、このブログのトップページの場合PHPで生成されるHTMLが一個にたいして、CSSや画像等の静的ファイルが20個近くあります。単純計算で21個のリクエストのうち1個だけがApacheで処理されるのでApacheへのリクエストは約95%削減されます。

では設定してみましょう。OSはUbuntu Server 10.04(64bit)です。Apacheは既にインストール済みで運用されているとします。設定後はnginxがポート80で待ち受けて、Apacheはポート8080で待ち受けるということにします。

(記事の最後でキャッシュファイルをRAMに置くというのもやってみます)

nginxのインストール

そのままaptitudeでインストールすると0.7.65がインストールされてしまうので、nginxのPPAを追加してからインストールします。

$ sudo add-apt-repository ppa:nginx/stable
$ sudo apt-get update
$ sudo install nginx

設定ファイルは /etc/nginx/ にあります。sites-enableとかApacheに似た構造になっています。

リバースプロキシの設定

ではこの sites-enabled/default をこのように設定しましょう。

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen   80;
    server_name _;
    location / {
        proxy_redirect                         off;
        proxy_set_header Host                $host;
        proxy_set_header X-Real-IP            $remote_addr;
        proxy_set_header X-Forwarded-Host    $host;
        proxy_set_header X-Forwarded-Server    $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_pass http://backend;

    }
}

これはリバースプロキシに必要な設定だけです。すべてのアクセスをローカルのApacheに引き渡してます。

Apacheの方はports.confでリッスンポートを80から8080に変更し、各サイトの設定も80から8080に変更してください。そして、Apacheとnginxを再起動させます。(Apacheを先に8080にしてからnginxを起動させる)

$ sudo /etc/init.d/apache restart
$ sudo /etc/init.d/nginx restart

これでブラウザからアクセスすると、nginxを経由してApacheが処理します。ので、今までとかわらないはずです。

ところが、問題があって、Apacheのアクセスログを見るとアクセス元が127.0.0.1になっちゃってるはずです。これを解消するためにmod_rpafをインストールします。

$ sudo apt-get install libapache2-mod-rpaf

これでApacheを再起動すると正しくアクセス元が扱われているはずです。実はこのためにnginxの設定に X-Real-IP をHTTPヘッダに追加する設定やらを書いているのです。mod_rpafはプロキシサーバーが追加した X-Real-IP ヘッダをアクセス元として扱うモジュールです。

mod_rpafは127.0.0.1からのアクセスだけに対して処理をするのでもし、リバースプロキシが他のホストにあるのであれば /etc/apache2/mods-enabled/rpaf.conf の RPAFproxy_ips をリバースプロキシサーバーのIPアドレスに変更してください。(すべてのX-Real-IPを信用するとアクセス元の偽装ができてしまうためです)

プロキシキャッシュ

では、元々の目標であった静的ファイルをnginxでホストする設定をしましょう。本来はnginxが静的ファイルを直接ディスクから取ってくるのがいいのですが、nginxがApacheと違うホストにある場合も考えられますのでその場合でも対応できるように、静的ファイルへのアクセスをキャッシュしておき、2回目以降の同じファイルへのアクセスはApacheに引き渡さないように設定してみます。

defaultをこのように編集してみます。

proxy_cache_path /var/cache/nginx/static_file_cache levels=1:2 keys_zone=cache_static_file:128m inactive=7d max_size=512m;
proxy_temp_path /var/cache/nginx/temp;

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen   80;
    server_name _;
    location / {
        proxy_redirect                         off;

        set $do_not_cache 0;
        if ($request_method != GET) {
            set $do_not_cache 1;
        }
        if ($uri !~* "\.(jpg|png|gif|jpeg|css|js|swf|pdf|html|htm)$") {
            set $do_not_cache 1;
        }
        proxy_no_cache     $do_not_cache;
        proxy_cache_bypass $do_not_cache;
        proxy_cache cache_static_file;
        proxy_cache_key $scheme$host$uri$is_args$args;
        proxy_cache_valid  200 2h;
        proxy_cache_valid  any 1m;

        proxy_set_header Host                $host;
        proxy_set_header X-Real-IP            $remote_addr;
        proxy_set_header X-Forwarded-Host    $host;
        proxy_set_header X-Forwarded-Server    $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_pass http://backend;
    }
}

この設定ではメモリ128M,ファイル最大512Mで、7日間キャッシュするファイルを /var/cache/nginx/static_file_cache に作成してます。

そして、do_not_cache 変数を用意して、0にしておき、GETでのアクセスでない場合と、静的ファイルでは無い場合にキャッシュしないようにその場合は do_not_cache を1にして、proxy_no_cacheを有効にしてます。静的ファイルの判断は正規表現でURLの拡張子を見ています。(注意しなければいけないのが、WordPressのページをパーマネントリンクで.htmlにしている場合です。その場合はキャッシュされないように外しておく必要があります。)

つまり、静的ファイルにGETでアクセスしたものだけキャッシュされます。

proxy_cache_valid はどのステータスのレスポンスをどの期間キャッシュするかを設定する項目で、この場合200なら2
時間、それ以外なら1分キャッシュすることになります。

あとは /var/cache/nginx/ ディレクトリを作成し nginx を再起動するだけです。

$ sudo mkdir /var/cache/nginx
$ sudo /etc/init.d/nginx restart

それでしばらくブラウザからアクセスしてみると、キャッシュディレクトリの容量が増えているはずです。

$ sudo du -ch /var/cache/nginx/static_file_cache
(中略)
91M	/var/cache/nginx/static_file_cache
91M	合計

本当にApacheへのアクセスが減っているのかは、Apacheのアクセスログをみてみてください。

さらに一歩

もう一歩高速化してみましょう。いまキャッシュファイルは/var/cache/nginxに置かれているので、結局キャッシュからの呼び出しのためにHDDアクセスすることになります。こいつを全部メモリ上においてしまいましょう。

間違えたり、問題が発生するとシステムに問題が起きるかもしれないのでわからないor不安ならやらないほうがいいです。

tmpfsを使えば、メモリ上の領域をファイルシステムにマウントすることができます。

/etc/fstab に次の一行を追加してOSを再起動します。

tmpfs	/var/cache/nginx	tmpfs	defaults,noatime,mode=1777	0	0

そうすると、/var/cache/nginx ディレクトリはRAM上に配置されます。

が、うちのサーバーはSSDにしてあったので効果はわかりませんでした。が、SSDの寿命を延ばす効果はあると思います。

で、Quick Cacheプラグインをインストールして有効にすると改善しました。

WordPress with Quick Cache

レイテンシ12ms、転送4msです。

ハードウエアのスペックでごり押しはだめですね。ちゃんとキャッシュできるところはしましょうってことです。

ということで、僕も借りてるさくらのVPSで一からセットアップして実験してみました。OSはデフォルトではなくUbuntu 10.04が入ってます。

今回検証したのは、WebサーバーはApache/2.2.14とnginx/1.0.9、RDBMはMySQL(Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (x86_64) using readline 6.1)とPostgreSQL/8.4.9です。なので、合計4通りですね。

Apacheではmod_phpで、nginxでは後ろでspawn-fcgiが動いてます。

で、試してみた結果です。今回検証したいのは静的ファイルではなくPHPの出力なので、画像とかCSSがブラウザでキャッシュされてたりするのは気にしないでください。

Apache + MySQL + WordPress

Apache + PostgreSQL + WordPress

nginx + MySQL + WordPress

nginx + PostgreSQL + WordPress

平均もとってない1回こっきりのアクセスの結果なので互いの比較はそんなに意味がないです。

が、どれもレイテンシが数百ミリ秒あります。これは何回試しても同じでした。

あれ？…

先輩のVPSと同じ環境のはずなのになんでこんなに違うの？

が、どうしてもこのブログ(にかぎらず、稼働しているWordPress全部)が重い、というより遅いのです。
Memcachedでオブジェクトをキャッシュしてみたりしても改善されず…

で、Safariで開発ツールの「ネットワーク」をつかって取得の時間を見てみました。

Apache(mod_php) + WordPress ネットワーク時間

ここでPHPのファイルへのアクセスのレイテンシが334msもあることに気づきました。稼働しているどのWordPressもです。

で、WordPressはそうなのかと、さくらのVPSで運用してる先輩のWordPressを見てみると…

さくらのVPS nginx + WordPress(fast-cgi)

速い….レイテンシ45msです。静的ファイルはうちのサーバーのほうがレイテンシ含め速いので(どちらも304なので比較していいかな)、ネットワーク等の問題ではないみたい。

(あと、向こうはnginx+fastcgi(swanかな？)+WordPressですが、うちでもnginx+fastcgiにしてみたけど改善せず…)

なんで？

とりあえず、僕も借りてるさくらのVPSでDBをMySQLからPostgreSQLにしてみたり、いろいろ実験してみます。

まずはProFTPdのセットアップから。proftpdをapt-getでinstallするとproftpdの設定画面が出ます。

ProFTPd セットアップ

固定IPではないのでIPマスカレードを利用しないといけませんが、そのためにもスタンダードアローンではなくinetd経由にします。

それでは /etc/proftpd/proftpd.conf を書き換えていきます。

• ServerName を好きな文字列に
• ListOptions を “-l” に “-la” に
• PassivePorts をコメントアウトして ポート範囲を決定(デフォルトは49152 65534)
• MasqueradeAddress を コメントアウトして hogehoge.net(ドメイン名)に
• ServerIdent を off で追加
• RootLogin を off に
• DefaultRoot を ~ に
• RequireValidShell を off に

ここまではMySQLによる認証は関係ありません。これからMySQLで認証するための設定を追記します。この部分は「にわか鯖管のメモ – ProFTPD　～ MySQL + quota 編 ～」をもとにというかそのまま。

注意点はmodule.confをいじったときは sudo /etc/init.d/proftpd reload をしないとだめってとこです。

それと、メモみたいなもので解説はたぶんしないとおもいます。LinuxをCUIで使えるぐらいの知識がないともしかすると読めないかもしれないです。解説でなく日記ですね。

レンタルサーバといっても身内、友人、後輩などに貸してるだけですのであまりセキュリティ、特にユーザー間のセキュリティはよろしくない設定をしていくかもしれませんのでそういう意味でもあまり当てにはしないでくださいね。

で、なぜいまさらサーバー構築なのかということなのです。普段はMac OSX Serverの上でこのページ含め個人のサーバと上記のレンタル部分とを稼動させているのですが、いわゆる公私混同の部分の管理がめんどくさくなってきた(なんとなくしんどくなってきた)ので他人の分は仮想環境のUbuntuに移動させてしまおうと思い立ったわけです。

で現状は、Ubuntu 10.04 ServerをLAMP + SSHのみでインストールしたまでです。

このあとユーザー情報をMySQLで管理してユーザーごとにApacheのバーチャルホストを設定し、proftpdはMySQL上の情報で認証できるようにしていくことが目標です。

いまAVRとともにメインで使おうとしているSTM32ですが、とっつきにくい原因としてはその莫大な周辺機能のせいで分かりにくいレジスタ。これはライブラリが用意されていているのですが、今度は資料が少ないためどうやって使えばいいのかわからない、ということにあると思います。

事実コンパイルして動作させるまでにかなりの時間を要しました。(ストロベリーリナックスで用意されているサンプルをmakeするだけならできたが動作原理が捉えにくかった)

それを解決する本が徹底マイコン入門(http://miqn.net/)です。実はかなり前に作者の方から相互リンクのお誘いを頂きリンクしておりました。

１ヶ月ほど前からホームページで90日間原稿全てをPDFで閲覧できる企画をなさっているので早速申し込みさせていただき、一ヶ月ほどこの本を頼りにSTM32をいじってきました。

プロジェクトの関係でなかなか時間が取れずレビューを書く事が遅れてしまいました。

で、この本の良いところはマイコン初心者に対しても細かな説明がされており、基礎から学習する(C言語はあるていど理解できているレベルから)のにも対応でき、さらに使いこなすようになってからもリファレンスとして使いやすい構成になっている点です。なかなか両方に対応するのは難しいところですがどちらから見ても便利だと思います。(特に後者については体感しました)

しかも、CANなどのマイナーどころはないにしてもSTM32のほとんどの周辺機能をカバーしており、さらによく使われるモジュール等(i2c液晶、フルカラー液晶やEEPROMなど)、の解説もありすごく便利です。

(かなりニッチな要望ですがCANの解説も欲しいです！)

是非とも発売されたときには部室と自宅に一冊ずつ欲しいなぁと。

近々STM32で作ったライントレーサーの動画をアップします。初めてPID制御にチャレンジしたのでかなりなめらかな動きとなっております。

道の駅「とうわ」

まず最初の目的地はかつてカッパが多く住み、人々を驚かしたという伝説がのこる遠野のカッパ淵でしたが、途中で土木学会推薦のめがね橋を見学。(昭和18年改修)

めがね橋

その後カッパ淵へ、

カッパ淵

カッパ淵のすぐそばでKIRINのホップ農場を発見。こんなところでつくってたとは。

KIRINのホップ農園

ホップ

この後遠野の道の駅「風の丘」に寄るとハネの形が変わった風車が建っていた。

道の駅「風の丘」

こいつの風車は本体だけでなくハネ？の一本一本も回転する。(帰宅したら動画をアップする予定)

で、次は小岩井農場まきば園へ。ずっと小岩井牧場だと思ってたけれど小岩井農場だったらしい。

小岩井農場まきば園

小岩井農場の牛乳と飲むヨーグルト

ここで、おみやげを購入。

で、次に訪れたのは日本で最初の地熱発電所である松川地熱発電所へ。

松川地熱発電所

大きな牛乳のビンみたいな建物は使った蒸気を冷却し水に戻す施設。
温泉が湧き出ているので川は沈殿成分でいっぱい。

で、そこで見たビデオに写っていた八幡平に行きたくなったので八幡平の樹海ラインへ。

八幡平 その1

八幡平 その2

か細い回線で書くのがしんどいのでほとんどコメントが無いけれど、これにて3日目の日記は終了。

昨日から今日にかけて停泊していたのは道の駅「上品の郷」です。温泉もついていていい場所です。

道の駅「上品の郷」

で、今日はまず気仙沼漁港に行きました。

気仙沼漁港 その1

二階から見学できるスペースがあるのでたくさんマグロやサメが並んでいるのや、積み下ろし作業も見ることができました。

気仙沼漁港 その2

ここの販売所にある食堂の丼が大変美味しかったです。(後日写真掲載予定)

で、その次に向かったのが厳美渓。

厳美渓 その1

厳美渓 その2

あんまり画像を上げるのでしんどいのでコメントが少なくてすいません。

その後中尊寺に行ったのですが金色堂は撮影禁止でしたので本堂の写真です。

中尊寺本堂

ここで大雨になってきたため次の停泊地へ。

現在小雨ですが、台風は半分過ぎ去ったようでこれ以上ひどくならないようです。

そうそう、今日銭湯で京都日報ならぬ岩手日報を発見。(ただそれだけです)

ではまた明日。

明日には岩手県に到着すると思われます。

で、あまり今日は途中で寄ったところはないのですが、２枚ほど写真を。

まずは途中で寄った石川県、尼御前SA近くの尼御前岬です。かなり崩れていて立入禁止の場所も多かったのですが綺麗な海が見られました。

尼御前岬にて

で、もうひとつはというとこれまた途中で寄った福島県のSAで売ってた100%ももジュース。なんと一本にまるごとももが一個含まれているらしい。

福島県産のももジュース

まだ飲んでないので飲んだ感想は後日。

写真のアップロードしんどかった。写真が増えるであろう明日明後日の更新が思いやられます。

ちゃんと作業ができるようにMacとSTM32とJTAGデバッガーを持っていってるのでソフトウエア面ではかなり進めるはずです…

キャンピングカーなので移動中もAC 100Vと机が使えるので快適に作業できます。

で、せっかく旅行にいくので時々ブログを(ちなみにTwitterでも)更新しようと思います。

今日の目標は福島県らしいです。

それでは後ほど。

進捗状況が公開できるものは今日プロジェクトのブログで更新したライントレーサーですが、写真を撮ったのでこっちにも公開します。

合同ロボコン用ロボットの骨格

詳しくは大阪大学Robohanの今日の投稿をご覧下さい。

STM32を使う予定でいるのでそっちの研究にも役立つかと思っています。

CNCを購入してから基板がつくれたりかなり便利になってます。

近々別に開発しているシステムも完成するのでそちらも公開できると思います。(こっちは制御・回路中心です)

で、プロジェクト(大阪大学 Robohan)の方のブログを2日ほど更新しているのでついでにこっちに載せておきます。

プロジェクトでCNCを導入しました。これでロボットのパーツ製作や基板切削ができるのでいろいろできそうです。

参照：CNCフライスを導入 ビデオも載せています。

で、なぜタイトルがクリップモーターなのかというと、「電気物理学」という授業でクリップモーターの製作が課題になったからです。

小学生の頃から何度か作っているので単純につくるだけでは面白く無いのでCNCを使ってみました。詳しくは初アルミ切削(大阪大学 Robohan ブログ)を見てください。

あと、こっちには書きますが、配られたエナメル線が太く短かったので両端にだけエナメル線を用い、コイルの部分は細いUEW(ポリウレタン線)をたくさん巻きました(笑)

あと、そこCNC使うとこじゃないとか言わないでくださいね。

Macでコンパイルして生成したelfバイナリをWindowsに持って行き、STMicroのツールでDFUに転送するとちゃんと実行されるのでコンパイル環境は正常に構築できたようです。

また、前回最後に触れたdfu-utilも導入できたのですが、それをつかって書き込む方法がさっぱり分かりません。

sudo dfu-util -d 0110:1001 -a 0 -R -D $(TARGET).bin

というコマンドをLeaf LabsのMakefileに見つけたので以下のようにやってみたのですがダメでした…

sudo dfu-util -d 0483:df11 -a 0 -R -D main.bin

どなたかdfu-utilを使ってSTM32に書き込みをする方法を教えてください！

NHKロボコン2010「出場要項」

と、Robohanのブログに書きました。

あとは個人的な話を。
STM32を入手したので明日の昼休みは図書館で今まで構築してきた開発環境の動作確認ができそうです。

アルバに開発を頼まれているいくつかのセンサー情報をSDカードへの記録するロガーの方もすこしずつ実験をしていかないとなぁと。

こっちは以前に試作したGPSロガーを元にすればそんなに大変ではないと予想しています。

では。

大学の職員の方に協力してもらい、隣の建物の屋上を超えて35mのLANケーブルを敷設しました。

これでいままではPHSしか無かったネットワークへの接続も高速になります。現在クラブのHPのサーバーは有料のレンタルサーバーで、せっかくドメインを持っているのにブログは外部のブログサービスという状態であったので、明日と明後日の２日間でうちのサーバーに全てを引越ししようと思います。

なぜそれがネットワーク敷設と関係があるのかというと、家に帰るとそんな作業をする気力は無いし、かと言って部室でPHSの回線ではそんな作業は到底無理で…大学の無線ＬＡＮでやろうと思ってもHTTPポート等しかあいておらず、FTPすらブロックされている状態でなかなか作業をする気になれませんでした。が、部室にポートブロックされていないネットワークが来たので部室でなら作業する気になれるかなと….

あと、いままでHPはHTMLとCSSを用いた静的なページだったので更新しようと思っても実行に移すのが億劫な状態になっていました。そこで、これを機にHPの方をConcrete5というオープンソースのサイト管理システムを導入しようと思います。

問題はメールサービスなのですが、さすがにメールサービスを非固定IPのうちのサーバーで稼働させるのは不安なのでこちらはGoogleAppsを使おうと思います。

そこで、最近無性にSTM32が使いたかったのでとりあえず開発環境でもを用意してみようかということで進めていきます。

今回は以下の二段構えになっています。

• コンパイル環境の構築
• 書き込み環境の構築

まず、前者についてはCortex M3開発環境 on Mac OS Xというページを参考にしました。

• ARM用gccのインストール (Targetがarm-eabiのgcc)

ARM用のgccはSHやH8の時とはちがい、コンパイル済みのdevkitARMを利用します。このページからdevkitARMのOSXバージョンの最新版をダウンロードし、インストールします。

こいつはインストーラが無いので解凍してできたdevkitARMディレクトリを /usr/local/ ディレクトリにコピーしておきます。

そして、PATHを通すために~/.bash_profileファイルに(無ければ新規作成)

export PATH=$PATH:/usr/local/devkitARM/bin

なかなか最初はうまくいきませんでしたが、いくつかオプションを指定することでうまくいきました。

基本的にクロスコンパイル環境はbinutilsをコンパイルし、その後にGCCをnewlibといっしょにコンパイルすることになります。

その前に、GCCのコンパイルにはGMPとMPFR及び、MPCをインストールしておく必要があります。

今回使ったバージョンは以下の通りです。

• GMP 5.0.1
• MPFR 2.4.2
• MPC 0.8.1
• binutils 2.20
• newlib 1.18.0
• gcc 4.5.0

これらが~/src/以下に展開されている状態である場合のコンパイル例が以下の通りです。SHとH8の違いはTargetがsh-elfかh8300-elfかの違いだけです。

また~/.bash_profileに以下の二行を追加しておきます。

export PATH=$PATH:/usr/local/sh/bin

export PATH=$PATH:/usr/local/h8/bin

$ cd ~/src

$ cd ./gmp-5.0.1

$ ./configure

$ make

$ sudo install

$ cd ../mpfr-2.4.2

$ ./configure

$ make

$ sudo install

$ cd ../mpc-0.8.1

$ ./configure

$ make

$ sudo install

$ cd ../gcc-4.5.0

$ ln -s ~/src/newlib-1.18.0/newlib ./

$ cd ../

$ mkdir h8-binutils

$ cd ./h8-binutils

$ ../binutils-2.20/configure –prefix=/usr/local/h8 –program-prefix=h8300-elf- –target=h8300-elf –disable-nls –disable-werror

$ CC=’cc -no-cpp-precomp’ CFLAGS=”-O2 -fomit-frame-pointer” make all

$ sudo make install

$ cd ../

$ mkdir h8-gcc

$ cd ./h8-gcc

$ ../gcc-4.5.0/configure –prefix=/usr/local/h8 –program-prefix=h8300-elf- –target=h8300-elf –with-newlib –enable-languages=c

$ CC=’cc -no-cpp-precomp’ CFLAGS=”-O2 -fomit-frame-pointer” make all

$ sudo make install

$ cd ../

$ mkdir h8-newlib

$ cd ./h8-newlib

$ ../newlib-1.18.0/configure –prefix=/usr/local/h8 –program-prefix=h8300-elf- –target=h8300-elf

$ make

$ sudo make install

$ cd ../

$ mkdir sh-binutils

$ cd ./sh-binutils

$ ../binutils-2.20/configure –prefix=/usr/local/sh –program-prefix=sh-elf- –target=sh-elf –disable-werror

$ CC=’cc -no-cpp-precomp’ CFLAGS=”-O2 -fomit-frame-pointer” make all

$ sudo make install

$ cd ../

$ mkdir sh-gcc

$ cd ./sh-gcc

$ ../gcc-4.5.0/configure –prefix=/usr/local/sh –program-prefix=sh-elf- –target=sh-elf –with-newlib –enable-languages=c

$ CC=’cc -no-cpp-precomp’ CFLAGS=”-O2 -fomit-frame-pointer” make all

$ sudo make install

$ cd ../

$ mkdir sh-newlib

$ cd ./sh-newlib

$ ../newlib-1.18.0/configure –prefix=/usr/local/sh –program-prefix=sh-elf- –target=sh-elf

$ make

$ sudo make install

ので、GD付きで再コンパイル。と、gettextも有効にしたかったのでついでにいっしょにコンパイルします。

基本的に前回の記事にgettextを追加した内容になります。

• libpng 1.4.1
• libjpeg jpeg-8a
• gd 2.0.35
• gettext 0.17
• php 5.2.12

バグの修正については前回の記事と同様に適用します。

$ cd ~/Downloads/src/libpng-1.4.1
$ CFLAGS="-arch x86_64" CCFLAGS="-arch x86_64" CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" ./configure
$ make
$ sudo make install

$ cd ~/Downloads/src/gd-2.0.35
$ CFLAGS="-arch x86_64" ./configure
$ cp libtool ../jpeg-8a/
$ cd ../jpeg-8a/
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --enable-shared
$ make
$ sudo make install

$ cd ~/Downloads/src/gd-2.0.35
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --with-zlib-dir=/usr --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6
$ make
$ sudo make install

$ cd ~/Downloads/src/gettext-0.17
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64" CCFLAGS="-arch x86_64" CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" ./configure --prefix=/usr
$ make
$ sudo make install

$ cd ~/Downloads/src/php-5.2.12
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --with-apxs2=/usr/sbin/apxs --with-ldap=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-trans-sid --with-xml --enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-dbx --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-config-file-path=/etc --sysconfdir=/private/etc --with-mysql-sock=/var/mysql --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr --with-openssl --with-xmlrpc --with-xsl=/usr --without-pear --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-freetype-dir=/usr/X11R6 --with-gd=/usr/local -with-gettext=/usr
$ make
$ make test
$ sudo make install

phpinfoを確認すると無事GDとgettextが有効になっていました。

結果は残念ながら7位で世界大会には進めませんでしたが、いろいろあったのにリーグ戦から決勝トーナメントに進出できたり、最終的には3勝4負とまぁまぁの成績だったので良かったかなと。

技術力で負けたのではないのがせめてもの救いかな、来年は1年間しっかり開発に使えるはずなので大丈夫かな。

P.S.

隣のクラブ(大阪大学鳥人間チーム)のサーバーがハッキングされたみたいです….うちもセキュリティーの確認しないと。

大学の授業が始まって２週間目ですが、中高の時の親友(一緒にロボカップジュニアに出場してました)とRobohanという大阪大学のロボコンチーム(大阪大学工学部研究科公認団体)に入部しました。まだ設立して新しいのでNHKロボコンには2回目の出場です。

現在は6月のNHKロボコンに向けてロボットを製作中です。(詳細は言えません)

個人的には教育用ボードの試作品は届きました。基幹部分は部品も実装し、動作確認もできました。3PinのXHコネクタが入荷すれば完成し、センサー入力等も確認できるはずです。

DCC関係は…進んでいません。ただこのボードができればデコーダのプログラム動作試験はやりやすいかと。

ではまた。

GDぐらい一緒にコンパイルしておいて欲しいのですが…今回つかったライブラリのバージョンは以下の通り。

• libpng 1.4.1
• libjpeg jpeg-8a
• gd 2.0.35
• php 5.2.12

今回は前回のMacにおけるiconv関係バグに加え、DNS関係のバグ(Bug #50508)が有り、php-5.2.12/ext/standard/dns.c の58行目からを以下のように修正しました。前回のiconvについての修正も行う必要があります。

#if HAVE_ARPA_NAMESER_COMPAT_H
#include
#endif

を

#if HAVE_ARPA_NAMESER_COMPAT_H
#ifndef HAVE_ARPA_NAMESER_H
#include
#endif
#endif

に変更してから以下のようにコンパイルしました。

$ cd ~/Downloads/src/libpng-1.2.40
$ CFLAGS="-arch x86_64" CCFLAGS="-arch x86_64" CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" ./configure
$ make
$ sudo make install

$ cd ~/Downloads/src/gd-2.0.35
$ CFLAGS="-arch x86_64" ./configure
$ cp libtool ../jpeg-8a/
$ cd ../jpeg-8a/
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --enable-shared
$ make
$ sudo make install

$ cd ~/Downloads/src/gd-2.0.35
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --with-zlib-dir=/usr --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6
$ make
$ sudo make install

$ cd ~/Downloads/src/php-5.2.12
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --with-apxs2=/usr/sbin/apxs --with-ldap=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-trans-sid --with-xml --enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-dbx --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-config-file-path=/etc --sysconfdir=/private/etc --with-mysql-sock=/var/mysql --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr --with-openssl --with-xmlrpc --with-xsl=/usr --without-pear --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-freetype-dir=/usr/X11R6 --with-gd=/usr/local
$ make
$ make test
$ sudo make install

日本時間で15時20分に発注メールをOLIMEXに送信したら、19時40分にPDFの注文書が送られてきました。

たぶん今までで最速！。こんなに早いとうれしいなぁ

で、ロボットを作るためにはマイコンでモーターを回す回路を設計したりプログラムを作れるようにならないといけません。

がこれまで、いちから独学で回路もプログラムもとなると相当の実力をつけているころには高校生ということになってしまっていました。

なぜそんなに時間がかかるか考えると、プログラムをするためにはマイコンボードができてないと学習できない、基板設計するにはプログラムでどういうことをするのか理解していないといけない…..という無限ループになるからだということになりました。

そこで、僕らの学年の部長だったT-Engineとクラブ向けの学習用マイコンボードがついたロボットキットをつくることになりました。

完成した基板があることによりプログラムの学習が早期からできるというのが目論見です。しかもマイコンは汎用マイコンを搭載しファームウエア等もあえて搭載しないので今後1から回路設計した場合でもそのときの経験はそのまま利用することができます。また回路図を読むことによりどういう回路ならこういうことが実現できるのかという教科書にもなるため回路の学習の基礎にもなればと思っています。

これを用いて中学初期あたりから学習すれば早期にロボット作成の基本が学習できる”はず”です。

構成としてはAVRマイコンと2チャンネルのモータードライバとUSBシリアル変換&書込回路をワンボードにしたマイコンボードとタミヤのユニバーサルプレートにギアボックスをセットにしたものになると思います。

拡張性を考えてI2C、デジタル入出力、アナログ入力ポートも備えています。

で、僕はマイコンボードの設計をするので以下のような感じになっています。

教育用マイコンボード

あと、AVRStudioを使って1からレジスタを操作してプログラムをするまえに、NQCのように簡単にプログラミングができるような開発環境も用意することにしたのでそちらも開発しています。

Windowsだけの対応ですがC#で開発しています。といってもコンパイル時にこっそり用意しておいたヘッダファイルをインクルードし、リンク時に用意しておいたライブラリをくっつけるという作業をしているだけなのですが…

それでも1から操作するよりは容易にプログラミングに慣れることができると思います。以下は開発中の開発環境です。一番大変なのは実際の動作とは全く関係のない部分なのですが、コードの色分けを実装するとこでしたね(笑)。できればVisualStudioのInteliSenceのような入力補完機能をつけるのが目標です。

教育用開発環境

インクルードが全くないのに用意された関数がつかえます。

これはコンパイル時にこっそり用意しておいたライブラリのヘッダファイルをインクルードし、ライブラリをリンクするという作業を裏で行うのことにより実現しています。というかただそれだけなのですが…

追伸

DCCデコーダの開発用のための実験基板ができました。AVRとモータードライバとBEMF用の回路が載っています。

本日無事に大阪大学工学部 後期に合格しました。

これでやっとやりたかった事ができると思います。
今年はホームページもどんどん更新できるように頑張りますのでよろしくお願いします。

ホームセキュリティシステムが作りたかったのでそのための予備実験からという事になりそうです。
もちろんDCC関係はデコーダ製作からですね。ロジックアナライザーも購入したので効率よく進められそうです。

先に断って置くとうちの家は受信料を払っています。

1.受信料未払い

まずはよく問題になっていた「受信料未払い」です。つまり、NHKとは既に受信契約を交わしている状態での未払いの場合を考えてみます。

AさんはNHKと「地上契約」を交わしているとします。この場合、当事者であるAさんは民法によりこの契約を履行する義務が発生します、つまり契約内容であるNHKの「日本放送協会放送受信規約」に従って受信料を払わなければなりません。これは法律で定められた義務にあたります。もしも不払いをした場合は債務不履行となり民法第414条に則って債権者であるNHKは裁判所に強制履行を請求することができ、民法第415条に則って損害賠償請求を行うことができます。

つまりまとめると、契約しているのに不払いをおこした場合はNHKは強制執行や損害賠償請求等の法的措置をとることができます。

2.未契約

次に、受信契約すら交わしていない場合を考えてみます。

Bさんはテレビを購入し、家の屋根にアンテナを設置したとします。すると、NHKの人がやってきてこういうでしょう。「放送法で定められた義務ですからNHKに受信料を払ってください。」と。

NHKがいう放送法による根拠というのは放送法第32条にある「協会の放送を受信することのできる受信設備を設置した者は、協会とその放送の受信についての契約をしなければならない。ただし、放送の受信を目的としない受信設備又はラジオ放送（音声その他の音響を送る放送であつて、テレビジョン放送及び多重放送に該当しないものをいう。）若しくは多重放送に限り受信することのできる受信設備のみを設置した者については、この限りでない。」というものです。

「放送」とは一体何なのかという疑問もありますので、放送法第1条の1を読んでみると「「放送」とは、公衆によつて直接受信されることを目的とする無線通信の送信をいう。」とあります。ということはCATV等の有線はどうなるのかという疑問が湧きますがこれについては後で考えるとして、今はアンテナで受信する場合を考えます。

つまり、「協会の放送を受信することのできる受信設備」というのはアンテナとテレビのことと考えられます。アンテナが無くても受信はできませんし、テレビがなくても受信はできないのでこの2つはセットということになります。Bさんの場合はアンテナもテレビもあるので確かにNHKとの契約をする義務があります。

もし、契約せずに、NHKから訴えられたとすると考えられる最も悪い判決は「契約を締結し、テレビを設置してから現在までの受信料と「日本放送協会放送受信規約」によって決められた延滞利息を払え」というものでしょう。契約していなかったことに対する罰則はありませんのでこれが限度と思われます。ちなみにこの延滞利息というのは受信規約第12条の2「放送受信契約者が放送受信料の支払いを３期分以上延滞したときは、所定の放送受信料を支払うほか、１期あたり2.0％の割合で計算した延滞利息を支払わなくてはならない。」というものです。

しかし、よく放送法を読んでみると「ただし、放送の受信を目的としない受信設備(中略)ついては、この限りでない。」とあるので、例えNHKが映るテレビがあったとしても「民法しか見ない」のであれば契約する必要はありません。

つまりNHKを見る見ないに関わらず「受信料は払わなければいけない」とNHKがいうのであればそれに法的根拠はありません。ということは本当に民法しか見ないのであれば受信料は払わなくてもいいのです。(さらにいうとNHKが視聴者がNHKを見ていると証明するのは大変困難だと思われます…)

3.ケーブルテレビや光テレビ等の有線の場合

未契約の場合で触れたように放送法第32条によるNHKとの契約の義務があるのは「協会の放送を受信することのできる受信設備」を設置した場合です。前述したようにこの「放送」というのは放送法第1条の1により「無線通信の送信」ですから、「アンテナとテレビのセット」が「協会の放送を受信することのできる受信設備」です。ケーブルテレビを使っている場合はアンテナがありませんからそもそもこの「受信設備」を設置したことにはならずNHKを見ていたとしても契約の義務は発生しないことになりますから契約の義務はありませんし、契約していなければ受信料の支払いは必要ありません。

ここで注意しておかないといけないのはCATVだからといって契約していても払わなくてはいけないという意味ではありません。契約しているのであれば前述したように履行する義務がありますし、不履行の場合は法的措置もとられます。過去の東京地裁の判決においても契約しているのに支払わないのは認められないとしています。興味深いのはその理由として、「男性らは自由な意思に基づいて受信契約を結んでおり、解約の方法も事前に知ることはできた」としている点です。つまり解約していれば支払わなくてもよかったのに、ということです。

4.既に契約しているが、ケーブルテレビにする場合

今まで地上波でNHKを見ていたがケーブルテレビに加入し、アンテナを撤去する場合。

実はこれが興味深いのですが、「日本放送協会放送受信規約」の第9条には「放送受信契約者が受信機を廃止することにより、放送受信契約を要しないこととなったときは、直ちに、その旨を放送局に届け出なければならない。」とあります。つまり、アンテナを取り外すことによってNHKの放送を(無線で)受信できる受信設備がなくなる、即ち「受信機を廃止」した場合はNHKに届け出る義務があるのです。これは契約内容ですから履行する義務があります。さらに、第9条の2「放送受信契約の解約の日は、前項の届け出があった日とする。ただし、非常災害により前項の届け出をすることができなかったものと認めるときは、当該非常災害の発生の日とすることがある。」とあるように、この廃止届を提出すると同時に自動的に解約することになります。これも契約内容ですからNHKは断ることはできません。

ですからケーブルテレビに変える場合はNHKに届け出るのが義務であり、それと同時に解約となり受信料の支払いも不要ということになります。

興味深いのは届け出るのが義務ということは即ち解約することが義務ということですね。まぁこの義務を果たさなかったとしてもNHKに損害はありませんから損害賠償請求もされませんが…

まとめ

テレビをアンテナで受信している場合で且つNHKを見る場合は契約する義務があり、受信料の支払いも必要。

テレビをアンテナで受信しているが、民法しかみない場合は契約する義務はなく、契約していなければ受信料の支払いは不要。

ケーブルテレビや光テレビ等の有線を使っている場合はNHKを見る見ないに関わらず契約する義務はなく、契約していなければ受信料の支払いは不要。

ということですね。ただしこれは一個人が興味で考察した内容であり、事実と異なる場合があります。この内容による如何なる損害も当方は一切の責任を負いかねます。

が、その記事に書いた通りLinux(Debian)では正しく動作していたのにLeopard Serverにしてからうまく行かなくなっていました。

しかも「ディレクトリが見つかりません」というようなわかりやすいエラーではなく「ファイルをコピーできませんでした」というエラー…
表示されるパスには間違いはないし、パーミッションも777にしてみても(すでになっている)駄目。

ちなみに「ファイルをコピーできませんでした」というエラーはPHPがセーフモードで動いている場合によく出るそうですが、今回はセーフモードで動かしてはいません。

で、諦めていたのですが、いっそのことFTP_BASEやFTP_CONTENT_DIRやFTP_PLUGIN_DIRの定義をコメントアウト(削除)してみるとなんとすんなり成功。

（下部の追記参照）

ということで、セーフモードでもないのに「ファイルをコピーできませんでした」と言われた時は一度FTPのディレクトリ設定を削除してみるのも手かもしれません。

追記

どうやらCodexのFTP_BASE等の説明には「インストールした WordPress のベースフォルダへのフルパス。」と書いてあるので”サーバー内でのフルパス”だと思っていたのですが、少なくともOSXでは”FTPでアクセスした時のパス”が正しいようです。（OSの問題では無いようなな気もしますが）

Codexにも「FTPユーザとしてサーバ上にある各フォルダへのパスが分かっていれば…」とあるので”FTPでアクセスした時のパス”が正しいようです。

つまり「/Users/name/Sites/wp-content/」ではなくFTPから見た時のパスなので「/Sites/wp-content/」とするとFTP_BASE等を定義しても自動アップデートできました。

二条城の前を通ると大きな門松が置いてあったので撮ってきました。
ただそれだけですが、

二条城の門松 その1

二条城の門松 その2

夜にはライトアップもしていました。

二条城の門松 ライトアップ

ついでなので、よく観光客の人が撮っているのを見かける構図で撮ってみました。

二条城 よくある構図 その1

二条城 よくある構図 その2

各ライブラリの今回利用したバージョンは以下の通り。

• libpng 1.2.40
• libjpeg jpeg-7
• gd 2.0.35
• php 5.2.10

PHPをMacでコンパイルするとlibiconv関係でリンク時にエラーが出る問題があるそうなのでext/iconv/iconv.cの196行目あたりを以下のように書き換えてからコンパイルに移ります。(参照:PHP Bugs: #49267: Linking fails for iconv: “Undefined symbols: _libiconv”)
Before

#ifdef HAVE_LIBICONV
#define iconv libiconv
#endif

After

#ifdef HAVE_LIBICONV
#define iconv iconv
#endif

実行した手順だけを載せます。

$ cd ~/Downloads/src/libpng-1.2.40
$ CFLAGS="-arch x86_64" CCFLAGS="-arch x86_64" CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" ./configure
$ make
$ sudo make install

$ cd ~/Downloads/src/gd-2.0.35
$ CFLAGS="-arch x86_64" ./configure
$ cp libtool ../jpeg-7/
$ cd ../jpeg-7/
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --enable-shared
$ make
$ sudo make install

$ cd ~/Downloads/src/gd-2.0.35
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --with-zlib-dir=/usr --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6
$ make
$ sudo make install

$ cd ~/Downloads/src/php-5.2.10
$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch x86_64 -g -Os -pipe" CXXFLAGS="-arch x86_64 -g -Os -pipe" LDFLAGS="-arch x86_64 -bind_at_load" ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --with-apxs2=/usr/sbin/apxs --with-ldap=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-trans-sid --with-xml --enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-dbx --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-config-file-path=/etc --sysconfdir=/private/etc --with-mysql-sock=/var/mysql --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr --with-openssl --with-xmlrpc --with-xsl=/usr --without-pear --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-freetype-dir=/usr/X11R6 --with-gd=/usr/local
$ make
$ make test
$ sudo make install

インストールまでの道のりとファーストインプレッションです。

ヨドバシカメラでファミリーパックを予約して発売当日に入手したのです。が、なんとインストールの序盤で

Mac OS X Install DVDが読み込めませんでした。
ディスクを清掃してから、もう一度インストールしてみてください。

と表示されインストールできませんでした。DVDドライブの故障かとも思い他のMacや、USBのDVDドライブでも試しましたが全く同様のエラー。
その日の夜は「ファミリーパックの一部のディスクは読み込めない場合があるかもしれない」という情報をネットで掴み、翌日交換してもらおうと思い寝ることにしました。

次の日(本日29日)、朝にもう一度ネットを廻っていると、DVDの記録面の印字が以下のようになっているメディアに不具合があるらしいというブログの記事を発見。

上段：MEDIAGATE 2Z693-6990-A RECORDED IN SINGAPORE L1 (B09 000125)
下段：MEDIAGATE 2Z693-6990-A RECORDED IN SINGAPORE L0 (B09 000124)

自分のメディアを確認すると一致。ヨドバシに電話をすると交換してくれるとのこと。

早速昼に梅田まで出かけていくが、「交換しても読み込めないかもしれない。」と言われたので、店頭のMacで読み込みテスト(DVDからイメージの作成)できないかと聞いたができないと言われ、せめてロット番号の確認をと言うと在庫を持ってくると言われたが、既に在庫切れと言われました。(電話では取り置くと言ってたのに…まぁいいや)

そこで、返金をしてもらいApple Store 心斎橋で再度購入することに。
ところがApple Storeでファミリーパックを頼むと、「ファミリーパックには問題があったので引き上げている、いつ再販売になるかわからない。」と言われたので通常版を買うことに。
レジを担当して下さった方に通常版は大丈夫かと聞くと、通常版では不良品はまだ見つかっていないといわれました。まぁほんとにすいませんね。と言われたのでまぁいいか。

で、やっとSnow Leopardが入手できました。と、ここからが使ってみての感想。

インストールがすっごい簡単に。以前からWindowsのインストールよりは断然簡単だったのですが、今回のアップデートはボタンを押すだけで全自動でした。

XCodeも最新のものに入れ替えると20GByte近く空き容量が増加しました。(これは実際にSnow Leopardが軽量なのと、サイズの計算方法が従来の1Gbyte = 1024MByte から 1GByte = 1000GByteになったことも原因です。500GBのHDDはしっかり499.88GByteと表示されるようになりました。)

体感速度は格段に上がり、アプリケーションの起動が劇的に変わった印象です。特にSafari。iTunesはライブラリの読み込みのためかあまり起動速度に変化はありませんでした。

あといくつか、おぉ、と思った点を。

• Exposeでウインドウのタイトルが表示され、整列もして表示してくれるので大変見やすくなった。
• Dockのスタックにスクロールバーがついた。アプリケーションを探すのが大変楽に。
• スタックの中でディレクトリ階層に入っていけるようになった。
• 動画ファイルをアイコンのまま再生できるようになった。(アイコンにマウスを合わせると再生ボタンが表示されその場で再生できる。下の画像参照。)ミュージックも同様に可能で、PDF等の場合ページの切り替えができる。
• アイコンのサイズが512×512までプレビューが作成されるため、PDFでも大きなアイコンで中身がわかりやすくなった。

アイコンの状態でムービーのプレビュー

ほとんどLeopardのままなのですが体感速度が上がり、上記のような使っていてうれしくなるような細かいアップデートが施され個人的にはアップデートする価値は十二分にあった感じです。

ただ、Aperture 1.5が使えなくなったのが残念(Apple公式の告知)….. 2.2を購入するきっかけになりそうです。

特に意味はありませんが面白そうなのでやってみます。当然ですが全く同じになっています…

ちなみに、なんとこの記事が記念すべき第100番目の記事です。
ちなみにちなみに、アクセス解析の結果によると4日前がちょうどユニークユーザー3万人目でした。ページビューはもうすぐ5万件。その日を逃したので記念ついでに…

日食予報(09:51)

日食予報(09:58)

日食予報(11:02)

日食予報(11:05)

日食予報(11:11)

日食予報(11:12)

日食予報(11:16)

日食予報(11:21)

日食予報(11:26)

撮影方法は以前の記事の「日食撮影機材の準備」をご覧ください。

国立天文台の暦計算室が公開している「日食各地予報」を利用して大阪の日食の経過を計算してみると以下のようになりました。

2009年7月22日大阪での部分日食の予測

これによると、欠け始めは9時46分58秒で、食の最大は11時5分28秒です。大阪では最大82.2%欠けた太陽が見ることができたそうです。

それでは撮影した写真の一部を時刻と欠けた割合とともに並べてみます。

ほとんど見ることができませんでしたが、運良く食の始めと食の最大だけは見ることができたので満足です。

ちなみに次の記事「部分日食と日食予報との比較」でシミュレーション結果との比較をしています。

9時51分(5.2%)

曇っていたが、運良く雲の薄い所が太陽の場所までやってきた。観測開始後初めて見られた太陽。

大阪での日食(2009/7/22 9:51)

9時58分(14.2%)

雲が厚くなってきてほとんどわからない状態に。かろうじで欠けていることがわかる。

これ以降太陽は雲の向こう側…

大阪での日食(2009/7/22 9:58)

11時2分(81.7%)

次に太陽が出た来たのが最も食の最大に近い11時2分。雲のせいでぼやけて見えるが三日月状になっているのがはっきりとわかる。このあとすぐに隠れる。

大阪での日食(2009/7/22 11:02)

11時11分(81.1%)

次に見えたのがこのとき。このあとはしばらく見えたり隠れたり。

大阪での日食(2009/7/22 11:11)

11時12分(80.7%)

雲の加減で太陽が煙を噴きながら落ちてくるように見える。曇りでも面白い写真が撮れたしいいかな…

大阪での日食(2009/7/22 11:12)

11時16分(78.4%)

大阪での日食(2009/7/22 11:16)

11時21分(74.6%)

大阪での日食(2009/7/22 11:21)

11時26分(71.0%)

これが最後に観測できた太陽。これ以降分厚い雲がやってきて見られなくなる。

大阪での日食(2009/7/22 11:25)

で、そいつをCanonのEOS 40Dで撮影しようと考えているのですがそのためには2つの問題があります。

一つ目は、明るさの問題。望遠レンズ等をそのままつけただけで日光をCMOSセンサーに当ててしまうと一気に焼けてしまいます。それ以前に明るすぎてきれいに撮影できませんが….。そこで減光フィルターというものをレンズの先につけて撮影します。

二つ目は、ズームの倍率です。手持ちの焦点距離70mm-300mmのズームレンズでは大きく太陽を撮影することができません。そこでもっと焦点距離の長いレンズを購入するか、レンズと本体の間に挟むテレコンバータと呼ばれるレンズを利用して焦点距離を何倍かにすることになります。前者の方法では明るく撮影できますがなにせ効果です。さらに今回は暗くなるぶんには問題ないので後者のテレコンバータを利用することにします。後で試してみたのですが、予想よりも暗くならずレンズに搭載されている手ぶれ防止機能と合わさって普段の利用でも十分利用できる性能でした。

一つ目の減光フィルターは各社ラインナップがあるのですが、調べてみると太陽を撮影するには光の強さを400分の１よりも暗くするのが最適とありました。が、そのようなフィルターはケンコーのND400プロフェッショナルしかありません、これは以前製造中止になったND400を今回の日食に向けて七月一日に新製品として販売しているものです。従来品との違いは色のニュートラル性が高くなったそうです。が、大人気のため入手が大変でした、ネットでも調べてみると売り切れており、近所の電気屋も回りましたがすでにありませんでした。そこで、光を８分の１にするKenko プロND8というフィルターを数枚重ねることで同じ量の減光をすることもできます。この場合二枚で６４分の１、三枚で５１２分の１に減光できます。結果的にはテレコンバータを買いに梅田のヨドバシカメラマルチメディア梅田に行ったときに店員さんに聞くと僕が求めていた直径のフィルターは在庫がまだあるということで運良く購入できました。（電話で確認したときはもう在庫はない、取り寄せもできない。といわれたのに。。。たぶん電話で対応した方は製造中止になったほうのND400で調べたのでしょう。）結局ND４００とND8を一枚ずつ入手しました。

二つ目のテレコンバーターは同じくケンコーのデジタルテレプラスPRO300 ２倍／キャノンEOS用を購入しました。これをレンズとカメラ本体の間に挟むことによって焦点距離が２倍になります。

で、試しに太陽と月をこのセットで撮影してみました。月を撮影するときには減光フィルターは使ってませんが。(少しトリミングしてあります)

2009年7月4日の太陽

2009年7月4日の月

2009年7月4日の月(もうちょっと暗いとき)

• PHP 5.2.8
• libgd 2.0.35
• libpng 1.2.37
• libjpeg(jpeg v7)

コンパイル時にはいくつか注意点が…

jpeg-6bではなくjpeg-7にディレクトリ名が変っていることに注意します。また、libjpegのconfigureの際に複数のアーキテクチャーの指定ができなくなったようなので以下のようにしました。

$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS=”-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp” CCFLAGS=”-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe” CXXFLAGS=”-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe” LDFLAGS=”-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load” ./configure –enable-shared

それに伴いlibgdのconfigureでも複数のアーキテクチャーを指定できませんので以下のようにします。

$ MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS=”-arch x86_64 -g -Os -pipe -no-cpp-precomp” CCFLAGS=”-arch x86_64 -g -Os -pipe” CXXFLAGS=”-arch x86_64 -g -Os -pipe” LDFLAGS=”-arch x86_64 -bind_at_load” ./configure –with-zlib-dir=/usr –with-jpeg-dir=/usr/local/lib –with-png-dir=/usr/X11R6 –with-freetype-dir=/usr/X11R6 –with-xpm-dir=/usr/X11R6

phpのmake後にはmake testも実行しておきます。

これで無事GDが使えるようになりました。標準で組み込んでくれるといいのですが…

phpinfoで確認するとこのようになっています。

すでに住人は引っ越し済み、よかった。アシナガバチかな？

ついでに春に友達と嵐山に出かけた時の写真を「整理しているとき」に何となく撮った写真。

Aperture Window

保津川下りと嵯峨野観光線のトロッコ列車がかすかに写っています。