発車メロディー

ヤマハDX7でJRの発車メロディー詰め合わせ。
http://www.youtube.com/watch?v=biBCVDcaRls

一つ一つSHホニャララと名前が付いてたのはなんとなく
知ってたんだけど、その後ろの数字でリビジョン（？）が
分けられてたのは知らんかった。
http://ja.wikipedia.org/wiki/%E4%BA%94%E6%84%9F%E5%B7%A5%E6%88%BF
こんな歴史が有ったのか。


makeブログの船田さんの記事。
http://jp.makezine.com/blog/2011/02/godfathertrain.html
超最高！やっぱ妄想はカタチにしてこそ本気で笑える
んだよな。
おいらもPWMモーター駆動のアレの発振周波数を弄って
キラキラ星でも奏でようかな。


http://dailynews.yahoo.co.jp/photograph/pickup/?1296823221
県の名前を「ゲゲゲ県」にしちゃうのかと思った…。
いっそそこまでやると観光誘致になるんじゃないの？
そこらじゅうの地方で都道府県名変更ラッシュに
なったり。


なさそうであったアレ。
http://akizukidenshi.com/catalog/g/gC-04398/
秋月のこの細軸のピンヘッダ、もう入荷してるのかな？


http://headlines.yahoo.co.jp/hl?a=20110202-00000015-sph-soci
ガンダムとザクのパクリ？
名づけて「ガク」とか。あまりうれしくなさそうな名前。
怖いもの見たさにチラッと見てみたいかも。
まぁ、懲りない人達。
中国国内でも「悲しい」とかコメントされているところを
みると、やっぱりキワモノとかパチモノとかっていう認識
はあるんだろうな。


http://headlines.yahoo.co.jp/hl?a=20110204-00001061-yom-sci
何のトラブルだろうねぇ？


http://headlines.yahoo.co.jp/hl?a=20110204-00000631-san-pol
この人にはかげながら期待感があったんだけど、
ネガティブキャンペーンに走っちゃいかんよ。
もっと気骨のある人だと思ってたんだけどなぁ。

絶版本

simさんのところで紹介されていたCD-ROM版。

http://shop.cqpub.co.jp/hanbai/books/I/I000025.html?utm_source=twitterfeed&utm_medium=twitter
これ欲しかったんだよな。本は絶版だし、古本高いし…
でこれは吉報。さて、どうやって買ったらいいの？
amazon君では注文できないみたいだから、ＣＱ出版の
通販だけなのか…？
本当は、オイラ的には手にとってパラパラめくれる媒体
の方が好きなんだけどな。

でも、絶版本をこうやって比較的安価なCD-ROM版として
復活させてくれるのはありがたいな。


http://headlines.yahoo.co.jp/hl?a=20110203-00000486-yom-sci
宇宙人は実はいっぱい居るのかもしれないな。
地球に来てないだけで。


http://headlines.yahoo.co.jp/hl?a=20110202-00000001-zdn_ait-sci
作業中に思考中断するようなポップアップの出し方
するから嫌われてるんじゃないかなぁ。もうちょっと
ユーザビリティー考えた仕様にしないから行かんのよ…。

というより、そもそも単なるドキュメントの振りして
中身があれこれとスクリプトが動くようになってる
から狙われるんじゃないの？なのにこれまでサンドボックス
になってなかった（放置してた）ってことの方が問題だな。
　　　「技術面でもユーザーインターフェイスの面でも
　　　　改善を続けていく」
はぁ。いまさら感。
ＦＬＡＳＨなんてもっと心配だもんな…

全世界的なセキュリティーにかかわる話だから、
「無料のソフトに文句を付けるな」とはいえない問題
だと思うんだよな。


http://headlines.yahoo.co.jp/hl?a=20110201-00000043-mai-soci
電子の杖ですか。
技術的には、秋月辺りで買ってこれる部品で作れちゃう
気がするんだけど、技術とニーズのマッチングがこれまで
はかられてこなかったって感じなのかな？
（たくさんの人が同時に使ってもセンサーが混線しない
　ような設計／テスト／規格化とかは必要だろうけど）

目の不自由な方もそうなんだけど、これから高齢化が進んで
行くにつれて、高齢者ならではのニーズも当然増えていく
ことになるだろうから、そういうのを一つ一つ掘り起こして
行けば将来の輸出産業にならないかな？細やかな配慮は
他の国には負けないと思うんだけどな。


それと駅のホームドア。
http://mainichi.jp/life/health/news/20110127ddm013040029000c.html?inb=yt
確か、あの電動のホームドアって1箇所当たり小型車1台分とか
っていう話だったような。高いんだよな。

100%の効果を考えるならそうかもしれないんだけど、すべての
鉄道駅に設置するのはコストも期間もいっぱいかかるだろうから、
それまでの間に合わせとしてこういうのはどうだろう？って
アイデア。

ホームの線路際のうち、ドアの正面にあたらない箇所だけに
ズラッと柵を作ってしまったら良いんじゃないかなって。
高価な柵じゃなくて、道路にあるようなパイプ状の簡易な柵。
間に合わせの。

もちろん、ドアの部分にまで柵を作ると乗降できないから
ドア以外の部分だけ。
そうするとドアのところからは転落しちゃう恐れがある
んだけど、ドア以外の部分の方が長いわけだから、
当座の間に合わせとしては低コストで効果もそれなりかと。

やがて電動のドアに置き換えする際には、その柵は別の
駅に移設して使いまわす…と。

駅によってはその簡易的な柵だけでも済んじゃうかも
しれない…。
柵をまっすぐにせず、くの字型というか、大カッコ型
というか、形状を工夫することによってドアの付近は
ホーム際によりにくくする工夫とかもアリでしょう。

定置網みたいな効果を狙えば、メカや電気のチカラを
借りずとも充分な転落防止効果が得られるんじゃないの？
と。こんな感じ。


黄色のところに列を作って乗降、赤い柵がクイッと折れて
いるところがミソ。

一つ問題があるとしたら、山手線や京浜東北みたいな
4つドアと6つドアが混在している電車。これはちょっと…。
でもそれは電動のホームドアも一緒だよねぇ？

一応動作するように

昨日の続き。
http://brown.ap.teacup.com/nekosan0/1222.html

ようやく思ったように動いてくれた…。
WINAVRでインラインアセンブラ使って、ある程度正確な
遅延時間を作る処理のこと。


なぜ遅延時間が不正確なのか。
シミュレータのディスアセリストを眺めながら1ステップ
1ステップ追っていってみたら、16ビット変数（uint16_t型）
をアセンブラに渡すところで上位下位の8ビットが逆に渡ってた。
そりゃ無茶苦茶ですがな。

直してみてからあらためてシミュレーション。


微妙に遅延時間が長い…

遅延時間が伸びてる最大の理由は、シミュレータ画面上で
追ってみたら判明。1マイクロ秒単位の引数を、関数の先頭で
10マイクロ秒単位に丸める処理（単に10で割るという整数除算）
で300クロックほど要していることが原因みたい10マイクロ秒
単位の精度が欲しいのに、300クロック＝30マイクロ秒
（@10Mhz）の誤差はでかすぎ。

仕様変更することにして、引数を10マイクロ秒単位で指定
することに。
それでも関数の引数（定数）内で10で割る処理を明記して
おけば、コードの可読性自体は悪化しないだろう、と。
定数式はコンパイル時に最適化されて引数は1/10単位の値で
展開されていることは確認済み。

これなら300クロックほどの遅延が無くなり、最低限で済む
のでとりあえずｏｋ。


いい感じになってきたので、きちんと一通り全部のロジック
をシミュレータ通して確認してみる。

…部分的におかしい。なんだこりゃ？


あらためてディスアセのリストを1ステップずつ追ってみると、
引数を1/10させてた時と違って、時間稼ぎ処理のサブルーチン
（今回インラインアセンブラ使った部分）が意図しない
インライン展開されちゃってる。

呼び出し箇所のすべてでインライン展開されちゃってるなぁ…。
まぁ、コードサイズ的にはそれでも800バイト程度程度だから
充分小さいんだけど、問題はその一つ一つ展開されたロジック
が変な状態ってこと。

具体的には、引数がきちんと渡されているところと、まともに
渡されてないところがあって、渡されていないところは
引数ゼロで処理しちゃって、ループを一気に抜けちゃう。


うーん。何だコリャ？
同じ関数を複数個所にインライン展開してるだけなんだけど、
複数個所ゆえにレジスタ割り当ての管理で支障をきたして
いるのかな？だったらインライン展開してくれるなよぅ…。
コンパイラ君…。

ロジック自体には間違えがなさそうなので、かくなる上は
コンパイルオプションの最適化引数を弄ってみる。

Os　→　O1に変更してみたら、サブルーチンがきちんとサブ
ルーチンとして独立して生成され、想定どおりの動きになった。
ヨシヨシ。
一方、O0もO2もO3もOsも全部だめ。一部は実行コードサイズが
馬鹿でかく（3KB超え）なっちゃうし、一部は上述のとおり
不完全なインライン展開で引数が渡ってくれない…。


とりあえずコンパイルオプションをO1にしたところで動いた
ので、これでよしとしてしまおうと思うんだけど、
こういう綱渡りって、コンパイラのバージョンアップが
致命傷になったりするから嫌いなんだよねぇ…。
（だからこの手のタイミングクリティカルなプログラムは
　いつもアセンブラで組んじゃうんだよな）

あとはアレかな。インラインアセンブルじゃなくて、
アセンブリ言語で書いたサブルーチンをＣ言語サブルーチン
として繋ぐってやつ。
http://avrwiki.jpn.ph/wiki.cgi?page=avrgcc%A4%C7%A5%A2%A5%BB%A5%F3%A5%D6%A5%E9%A4%F2%BB%C8%A4%A6
avrwikiでも解説されてるこれ。

コードの可読性って意味ではこっちの方がスマートな
気もするんだけど、これだと必ず関数のカタチにしないと
いけない（必ずサブルーチンコールのカタチとなり
オーバーヘッドが生じる）っていう点と、makeファイル
弄らないといけないっていう面倒くささがあるんだよな。


なんにしても、今回書いたコード。まだＣとアセンブラの
引数周りについて少し心配なところがあるといえばあるん
だよな。100％理解できたのか？と言われたら、Noって
レベルだからなぁ。所詮付け焼刃なのだ。


まぁ今回は「想定どおりのhexファイル」ができたって
ことで、あとは実機に流し込んでリモコンが動作するか
どうかが確認出来たら凍結ってことにしよう…


winavrって、関数をインライン展開させないための
プリプロセッサってあったりするのかな？それがあれば
コンパイルオプション弄る必要が無いんだけどな…
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Inline.html
これか？いや、これの逆だな。

ちっと前進

例のWINAVR上でインラインアセンブラ使っちまおう
という話の続き。時間遅延処理を組んでるわけだけど、
なんだかうまく動いてなくてちょっと放置してた続き。

あらためてシミュレータ上で、ディスアセンブルリスト
を1ステップ1ステップ動かしてってみると、どうやら
引数として与えた遅延時間がうまく引き継がれてなくて、
カウント値＝０でループを抜けちゃうことがわかった。

とするとロジックそのものが原因じゃぁ無いってこと
だろうと思って見直してみる。どうやらアセンブラに
渡す引数（Ｃ言語変数タグ）との結びつき、ここの
指定方法が間違ってることが解ってきた。

ここは正直一番よく解ってないところ。あらためて
あちこち情報収集して眺めなおしてみると、とりあえず
一つは間違え発見。

ループはそれなりに回るようになったんだけど、
ループから抜けるまでの時間（クロック数）が
想定の2倍だったり30倍だったり…というだめっぷり。

うーん、ロジックのような、環境のような…
とりあえず今日はここまで。また今度。