« 2015年12月 | トップページ | 2016年2月 »

2016年1月

2016年1月31日 (日)

文旦2016

地球温暖化が進んでいる。昔は甘夏でさえ、早期収穫して、貯蔵してから食べていた。
今は樹上で甘くなるまでほっておける。
文旦やグレープフルーツ、ネーブルなどは難しい。だがこれも早めに収穫し、貯蔵して食べるなら栽培できることがわかった。
貯蔵してあった文旦をこの時期に出してきて、暖かい部屋に半月ほど置いてから食べる。

Buntan2016

貯蔵した文旦は、樹上完熟には勝てないが、そこそこおいしい。
木の負担が少ないため、収穫も多いようだ。
文旦はまず品種不明のこいいつを食べて、それが終わるとメイポメロという品種が登場する。

2016年1月30日 (土)

シンク探し

昨年からシンクを探していたが、解体業者を回るのにも疲れた。仕事も忙しいし、これからの季節は花粉が飛ぶ。
少々高くてもいいから、ヤフオクで落札しよう。

ヤフオクで販売されている商品は高い。なぜなら高くて買い手がつかない商品がほとんどだから。せめて入札の有無くらいは確認して相場を判断したい。

薄いステンレスを使ったものだと、新品が2万円で買える。
新品はホースなどの付属品がそろっているし、送料だって2,000円程度と安い。このあたりを相場としよう。
中古品は一般的に送料が高い。送料が5,000円以上かかることも珍しくない。北海道から落札してはいけない。
それに付属品がないし、メーカーもわからないことが多い。自分が欲しい型を頭に入れて、ひたすら探すことになる。

私は、費用がたとえ同額であっても、中古を買うつもりだ。
ステンレス板が肉厚なら、きっと死ぬまで使えるだろうし、地球にもやさしい。
気に入ったシンクをいくつか見つけて、出品価格が高いものについては、価格交渉を持ち掛けた。

2016年1月29日 (金)

はやぶさDVD

はやぶさ映画は一通り観たので、はやぶさDVDをかたっぱしから観ておこう。
本日は用意したのは、HAYABUSA Back To The Earth 帰還バージョンである。どうやらこの映像には、新旧二つのバージョンがあるようだ。

▽HAYABUSA - BACK TO THE EARTH -
公開 : 2009年4月1日

▽HAYABUSA - BACK TO THE EARTH - 帰還バージョン
公開 : 2010年12月18日

プラネタリウムで上映するための映像なので、はやぶさ帰還に合わせて内容が追加されたらしい。
今だと帰還バージョンが普通だと思う。

語りがうまい。それに音楽がいい。私は大満足だったが、一般人にはどうなのかよくわからない。
このDVDで泣く奴は、ヲタク知識豊富な人ではないだろうか。
きっと、はやぶさに降りかかる困難を技術的な対策するところまで、すべて脳内補完した上での涙だろう。
あ、私は目にちょっと汗が入っただけだ。

この映画はDVDになっているが、本来は全天周映像で、プラネタリウムで上映される作品である。。
そういえば、四日市市博物館に併設されているプラネタリウムは、2015年にひっそりと更新され、世界一の投影機が入っているはず。できればそこで観たい。

このソフトも所有しているはずなので、またいつか上映することがあれば、足を運んでみたいと思っている。
今月は残念ながら、おじゃる丸と皆既日食を上映しているはず。

2016年1月28日 (木)

X200MAにSSD

さて、再び挑戦である。
リカバリツール ASUS Backtrackerは、NTFSで二度、失敗している。
今度はアンフォーマットでやってみよう。
IO-DATAのHDDFMT v2.31で、家電モードと呼ばれているフォーマットだ。
すると無事に起動USBを作成できた。
リカバリの手順をまとめるとこんなに感じだ。

▽用意した物

ASUS X200MA、SSD、16GBのUSBメモリ、
リカバリツール ASUS Backtracker、IO-DATA HDDFMV v2.31

▽換装の手順

HDDFMTを使用し、USBメモリを家電モードで初期化する。
Backtrackerを使用し、USBメモリを起動可能にする。
X200MAに内蔵されているHDDをSSDに換装する。
USBメモリを起動し、Windowsをインストールする。

SSDに換装したX200MAは起動が速くなり、きびきびと動作するようになった。
ASUS X200MAは3万円ちょっとで買える。これに6500円ほどのSSDを搭載すると4万円。
SSD化することで、マシンはきびきび動くようになった。
VisualStudioやマイコンの開発環境もさくさく動くし、開発環境としては申し分ない。

2016年1月27日 (水)

バカトラッカー #2

ASUS Backtrackerで起動USBメモリを作ろうとすると、USBメモリが壊れてしまう。
壊れたUSBメモリは、Windowsで再フォーマットすることもできず、困ったことになった。
Windowsのフォーマット能力が低いためにフォーマットできないだけで、ハードウエア的には壊れていないはず。他のツールを試してみよう。。
BUFFALOのUSBメモリなので、まずは同社のDiskFormatter2 v1.20を試してみる。
フォーマットが始まったものの、途中でフォーマットが停止した。自社製なのにフォーマットもできないのか。
続いてIO-DATAのHDDFMT v2.31を試したところ、無事にフォーマットできた。
いいぞIO-DATA。今度、USBメモリを買う時はIO-DATA製にしよう。

2016年1月26日 (火)

バカトラッカー

出勤途中にビックカメラに寄ってSSD/140GB@6,500円を購入した。地元の東芝と提携しているSanDiskのSSDである。

▽あとで写真

これをノートPC、ASUS X200MAのHDDと換装しようと考えている。
X200MAには光学ドライブが内蔵されていないため、USBメモリからWindowsをインストールする。
ASUSは、Backtrackerという専用のリカバリツールを用意しており、これを使ってインストール済みのWindows8.1から、起動用USBメモリを作成する。
このツールはバックアップやリカバリも可能だが、Windowsのインストーラも作ることもできる。
Windowsをインストールできる起動用USBメモリを作ったら、HDDをSDDに換装して、起動用のUSBメモリからリカバリする。

…予定だった。ところが、Backtrackerを使ってWindows8.1のバックアップをとると、USBメモリが壊れてしまう。
理由はわからないが、3本のUSBメモリが次々に壊れた。
壊れたUSBメモリは、Windowsが初期化した再フォーマットもできない。今日はここまでとしよう。

2016年1月25日 (月)

はやぶさ映画×3

イベントが一つ片付いたので、はやぶさ映画でも観ておこう。
仕事をしながら、はやぶさの映画を観ていた。ごめん、ウソ。
はやぶさの映画を観ながら仕事・・・いや、仕事もせずにはやぶさの映画を観ていた。まあ、観るのも仕事だから。
とりあえず映画を三つ片付けておこう。

▽はやぶさ/HAYABUSA



公開 : 2011年10月1日
出演 : 竹内結子・西田敏行・佐野四郎

はやぶさ自身が擬人化されて解説をしてくれるので、とてもわかりやすい。それ以外のことでも解説が多い。
こういう映画を見せておくと、理系の子供が育つ・・・かもしれない。
おもしろかった。

▽はやぶさ 遥かなる帰還




公開 : 2012年2月11日
出演 : 渡辺謙・山崎努・夏川結衣

イオンエンジン、リアクションホイール、1bit通信など、解説なしでストーリーに登場する。
オープニングの回路を見て「あ、例のダイオードだ」とか思っちゃう人には問題ないが、普通の人にはどうだろうか。
この映画を観る人は、きっと「はやぶさ/HAYABUSA」を観たはずだという前提に基づいているとすれば、なかなか計算された映画だと思う。
おもしろかった。
実在の商品や家電メーカが登場するので、ひいきしたくなる。

▽おかえり、はやぶさ
公開 : 2012年3月10日
出演 : 藤原竜也・杏・三浦友和

イオンエンジンの説明はわかりやすかったが、他の部分は説明も少ない。
映画だからフィクションもあるだろう。だが他の作品は科学を志す人を描いているのに対し、こっちは人間関係である。
肝臓移植のくだりなんて、はやぶさ映画に期待していない。
悪いけど、さようなら。



2016年1月24日 (日)

冬のイベント2016

年末からこの時期にかけて、私は二つのイベントにかかりきりになる。
前哨戦ともいえる一つ目のイベントは本日開催だ。
うちの部署からも午前と午後、それぞれの部門に1チームが出場している。
午前の部に出場したチームは技術力も高くないし、予算も少ない。まあ、参加することに意義がある。
本命は午後の部。こちらは優勝を狙っている。
いずれのチームも大きなミスもなくここまで来た。

まずは午前の部、審査結果の発表である。奨励賞などにもひっかからず、こちらはまあ、こんなものだろう。
残っているのは表彰台だけで、ちょっと無理。
が、長いドラムロールの後、コールされたのはうちのチーム番号だった。どうやら優勝らしい。
どんな審査をしているのかわからない。もしかしたら、審査員たちがライバルとなるチームへの投票を避けた結果、全体からまんべんなく票を集めてしまったのだろうか。
午前の部は、過去にも何度か優勝している。ただ前回は10年くらい前の話で、当時の私は違う部署を率いていた。
この部署を率いてここ数年、表彰台には何度か上がっていた。こんなところで優勝するとは思っても見なかった。

さあ、残すは大本命、午後の部。
だが午前の部が優勝している以上、午後の部の優勝は難しいような気がする。大人の理由ってやつだな。
そんな中、審査結果の発表となった。
だが早々に奨励賞を受賞してしまった。これはいわゆる協賛各社賞で、受賞したからといって表彰台が消えるわけではない。しかし、先ほども書いた通り、大人の理由的にはかなり苦しくなった。
その後、名前を呼ばれることはなく、奨励賞だけの受賞となった。午後の部はいつもレベルが高く、表彰台の一番上に上がったことはない。

また来年だな。

2016年1月23日 (土)

積雪

天気予報では大雪の可能性がある、三日分の食料を確保せよと言っていた。
うちはプロパンガスだし、移動式のかまども薪もある。対策といっても、せいぜい充電池を充電したり、飲料水を確保する程度だ。

01:00には月も星も見えるほど晴れていたが、それが02:00には雪が降っていた。03:00には雪が積もっていた。
04:00には積雪が5cmほど。そろそろ雪かきしてもいい頃だ。とりあえず家の周りの道路は、きれいに雪かきした。
雪が降り続くので、05:00に雪かき。06:00にも雪かき。
夜が明けて、積雪は15cmに達したが、うちの周りの道路はせいぜい2cmほど。
これも雪かきをして、きれいに片付けた。

午後には天候が回復し、日当たりのいい場所では雪もなくなった。畑も鉢の植物も特に被害はないようだ。

2016年1月22日 (金)

パイン避難

パインの鉢は玄関に置いて越冬させるつもりだったが、天気予報を聞いて不安になってきた。
明日からぐっと気温が下がるという。いったん部屋の中に入れることにした。
パソコンが置いてある部屋は、パソコンの排熱で少しだけ室温が高い。観音竹やアグラオネマ、エアプランツなどもここに並べている。
冬になってから、パインの鉢は水を控えめに管理してきた。その方が低温に強いからだ。
だが今夜は久しぶりの室内だから、水をたっぷり与えた。
水道水をそのまま与えると水温が低いので、ちゃんと室温の水を与えた。

▽あとで写真

同じサイズのパインを部屋に何鉢も並べると、普通に観葉植物と変わらない。なかなか見応えもある。冬の間、ずっとこの場所で観葉植物として育てるのも悪くない。

2016年1月21日 (木)

AQM-1248Aテスト

ArduinoからAQM-1248AというグラフィックLCDの動作確認をした。
さらにベンチマークなどのテストコードを書いたが、128×48ドットはそれなりに広くて快適。描画も高速ですばらしい。
途中、どうしてうまく表示できないのか悩む場面があったのだが、じつは表示が速くて見えていなかったくらいだ。

XEVIOUSくらいなら、そのまま動くんじゃね? とも思い、ザッパーを連射したところで、ようやく気付いたことがある。
拡大鏡がないと小さくて見えない…。何に使えばいいのだろう。

▽あとで写真

お約束ということで、BadAppleの影絵でも動かしてみようと思ったが、メモリがないから無理だな。


//	----------------------------------------
//	指定座標にボールを描く
//	----------------------------------------
void ballDisp(char x, char y) {			
	char pat[] = {
		0x06<<0, 0x09<<0, 0x09<<0, 0x06<<0,
		0x06<<1, 0x09<<1, 0x09<<1, 0x06<<1,
		0x06<<2, 0x09<<2, 0x09<<2, 0x06<<2,
		0x06<<3, 0x09<<3, 0x09<<3, 0x06<<3,
		0x06<<4, 0x09<<4, 0x09<<4, 0x06<<4,
		0x06<<5, 0x09<<5, 0x09<<5, 0x06<<5,
		0x06<<6, 0x09<<6, 0x09<<6, 0x06<<6,
		0x06<<7, 0x09<<7, 0x09<<7, 0x06<<7,
	};
	char patEx[] = {						// 下にハミ出たボール
		0x00, 0x01, 0x01, 0x00,
		0x01, 0x02, 0x02, 0x01,
		0x03, 0x04, 0x04, 0x03,
	};

	uint8_t page = y / 8;
	uint8_t mod = (y & 0x07);
	char* cp;

	uint8_t xH = x >> 4;			// address high
	uint8_t xL = x & 0x0f;			// address low
	lcdCommand( 0xb0 + page );		// page
	lcdCommand( 0x10 | xH );		// column High
	lcdCommand( xL );				// column Low

	cp = pat + mod * 4;
	lcdData( *cp++ );
	lcdData( *cp++ );
	lcdData( *cp++ );
	lcdData( *cp );

	if(mod>=5) {
		page++;
		lcdCommand( 0xb0 + page );	// page

		lcdCommand( 0x10 | xH );	// column High
		lcdCommand( xL );			// column Low
		cp = patEx + (mod-5)*4;
		lcdData( *cp++ );
		lcdData( *cp++ );
		lcdData( *cp++ );
		lcdData( *cp );
	}
}

2016年1月20日 (水)

電車が来ない

朝、起きたら外は一面、銀世界だった。
ほんの数cmの積雪だが、交通機関はひどい状況になっていた。
最寄りの鉄道は、電気系統の故障で動いていない。私は別の鉄道の無人駅に向かった。
電車を待つ人たちが小さな屋根の下に寒そうに固まっている。人が多いな。

しばらくすると案内放送がかかって、電車が50分も遅れていることがわかった。
この寒いホームで50分待ちだって?
それを聞いた客の何人かは、駅の出口に向かっている。別の鉄道の駅まで歩こうというのだ。
なるほど。それはいいアイデアだ。だが、その駅まで雪道を徒歩20分。こっちより電車の本数が多いかもしれないが、電車が遅れていないという保証はない。
どうすればいいのだ。私が出した結論はこうだ。

Snowmanstart

ぱふぱふとドッジボールくらいの雪玉を作って、あとはホームの雪の上を転がして行けばいい。時々、雪玉の向きを90度変えてやるのがコツである。
無人駅だが電車の状況を知らせる放送が入るので助かる。時間を有効に使って、高さ1mもある雪だるまを完成させた。
完成した雪だるまはフェンス側に溶けて落ちる場所に置いた。ここなら通行のジャマにもならないだろう。

Snowmancomplete

電車がやって来た。
運転席にいる運転手は、雪だるまにちらりと目をやっただけ。だが車掌さんとは目で挨拶をかわした。

私はただ雪だるまを作っていただけではない。
雪だるまを転がしていくと、雪だるまに雪がくっついて道ができる。ちょうど電車の乗り口まで続いている歩道は、誰がどうやって作ったか、車掌さんには一目瞭然である。

2016年1月19日 (火)

グラフィックLCD

AQM-1248AというグラフィックLCDを手に入れた。
このLCDはピン幅が狭くてブレボで使うのは難しい。変換基板とセットで買うのがオススメである。
ArduinoNANOで動作確認したが、特に問題はなさそうだ。

▽あとで写真

モノクロで小さいが、ひじょうに応答性がよく、ゲームを作るには向いていると思う。
大きなLCDでゲームを作るとなると、それなりの画像を用意しないと見栄えが悪い。だが小さなLCDなら、たいした画像を用意しなくてもいい。物は考えようだ。
とはいえ、今は仕事が激務。このLCDで遊ぶ時間が確保できるのは一カ月くらい先になりそうだ。

2016年1月18日 (月)

ジャガイモを買った

ジャガイモの種芋を買ってきた。昨年と同じく、シンシアとシェリーである。

ここ数年、シンシアが人気らしく、ひどく品薄である。1.0kgが1袋しか手に入らなかった。
品薄なことは数日前から気付いていたのだが、もっと早く買っておけばよかった。
シェリーは比較的手に入れやすい。ホームセンターの店頭に山積みになっている。シンシア不足を補うべく、1.5kgを購入した。
シェリーは保存性が悪く、夏になると発芽しやすい品種である。
その性質を利用し、そのまま植えて秋ジャガとして収穫することができる。秋ジャガの種芋は、小さい芋が適しているから、クズ芋をそのまま種芋とすればいい。
キタアカリでも同じことが可能である。

シンシアはオススメの品種だが、どうせ手に入らない。シェリーはまだたくさん残っているから、品種に困ったら試してほしい。
手頃な大きさで、芽のくぼみも少ない。甘くて煮崩れしにくい品種である。

2016年1月17日 (日)

キーボードとか

天気は悪くないが風が強い。家の中でずっと電子回路を組んで遊んでいた。
Arduinoで楽器を作るかもしれないと思い、ドレミファソラシドを演奏できるキーボードを作ってみることにした。
思いついた回路はこんな感じ。

Swkeyfailed1

配線する前から気付いていたが、うまく動かなかった。swCとswGが区別できずに同じ音になってしまう。
電流が回り込んでしまうからだな。
逆流防止用にダイオードを入れたいところだが、ダイオードなんて持っていない。
代わりにLEDを入れてこんな回路にした。

Swkeyfailed2

▽あとで写真

swC-Fはきちんと動作するし、swG-swC2も大体動く。ただしLEDを高密度に実装すると、ブレボ内部で隣のピンに接触して誤動作することがある。逆流防止用だから、少しの接触でも誤動作となる。
また、この回路は5V系のArduinoUNOやArduinoNANOでは正常に動作するが、3.3V系のStuduinoではうまく動かない。ちゃんとしたダイオードを使っていただきたい。
ところで、この回路は動くと思う?

Swkeyhint

Vccに接続していないので動くはずがない・・・と思っていたのだが、実際にやってみると正常に動作する。

2016年1月16日 (土)

死ぬほどうまい芋

年が明けたら寒い日が多くなった。毎日、石油ストーブを使うから、その上で焼き芋を焼く。
年末に安納芋を食べ尽くし、今はベニハルカとクイックスイートを食べている。
ベニハルカは安納芋と同様の粘質、クイックスイートはホクホクの焼き芋になる。

ベニハルカは収穫直後は粉質だが、保存しておくと粘質の芋に化ける。
乳が多い品種で、収穫直後は切り口から大量の乳を出す。ヤラピンと呼ばれる物質らしいが、それと関係があるのだろうか。
焼き芋にすると蜜を吹きとても甘い。べたべたの芋ようかんみたいな味だ。

▽あとで写真

サツマイモは凍らない程度の低温に晒すとひじょうに甘くなる。うちでは新聞紙にくるんで、玄関で保存している。
この方法はとても甘くなるが、低温で枯死するため、自家採苗もできなくなる。

里芋が死ぬと芋が透明になり、煮てもやわらかくならない。食えないからゴミである。
山芋(というか大薯)は死ぬと粘性が失われる。玉子と混ぜて焼いて食べるくらいはできるが、トロロ汁にもできない。
サツマイモは、べたべたのまま甘くなり、おいしく食べられるというわけだ。

2016年1月15日 (金)

カラーピンヘッダ

以前にも書いたが、中華製Arduinoは精度が悪い。完成品を買うべきではない。
部品を取り寄せて自分でハンダ付けした方がいい。
その際、秋月の細ピンヘッダに交換すると、さらに使い勝手がよくなる。
細ピンヘッダにはカラー版もある。まとめ買いするならこっちの方が安いので、試しに買ってみた。

Pinheadercolor

せっかくハンダ付けするなら、ピンによって色を変えるといいかもしれない。
D0-13、A0-7、それからVccを見やすくしてみよう。すべての色を変えるのは趣味が悪いので、これくらいで落ち着いた。

Arduinocolor

私はブレボで回路を作るので、手前の5Vを赤にしておくと、目印になってちょうどいい。

2016年1月14日 (木)

BBマニアのハンドシグナル

回路の説明書を作っていたのだが、せっかくお絵描きソフトを起動したので、その勢いで作ってみた。

Bbhandsignal

ハンドシグナルについては、こちらの説明を読んでいただきたい。

2016年1月13日 (水)

ヴァシニウム

理化学研究所の仁科加速器研究センターの超重元素研究グループが、113番元素を発見し、2015年12月31日、その命名権を獲得した。
ちなみにニュースで登場したニッポニウムやリケニウムという名は使えない。
そしてヴァシニウム(Vaccinium)であるが、これはスノキ属を意味し、その話とはまったく関係がない。

私は定期的に果樹の情報収集をしている。英語の文献なので、キーワードは英単語となる。検索にはちょっとしたコツが必要だ。
たとえば、ポポー(pawpaw)という名は、ハパイヤの通名らしく、学名(boanical name)のasimina trilobaの方が無難である。
ブッシュチェリー(bush cherry)は、ユスラウメの別名だったりする。情報収集しているのは、ロマンスシリーズと呼ばれる、おっさん向きではない名前の系統なので、品種名を追加して検索するようにしている。
blueberryはわりと簡単だ。育種は公的な機関で行われており、まとまった情報がきちんとリリースされているからだ。blueberryでも、学名のVaccinium corymbosumでも検索できる。

問題はblackberryとかraspberryである。blackberryで検索すると、キーボード付きのケータイがヒットするし、raspberryで検索すると、RaspberryPiと名乗るマイコンボードが検索のジャマをしてくる。
こういうことはよくある。たとえばに洋ランの「デンドロビウム」を画像検索するとこんなこと になる。

そういう時は学名を使うのが普通だが、やつらは他の亜属との属間交配がひどい。だからRubusとアバウトに検索すると、どうでもいいベリーもたくさんヒットしてしまうのだ。
blackberryなどと属間交配(正確には亜属らしいが)が可能なため、よくわからない名前のベリーもたくさん存在する。そのうち、

新型のRaspberryPiが$5.0か…。

そう呟いて、いつも本来の目的から脱線するのである。

2016年1月12日 (火)

はやぶさ動画

仕事の関係で、はやぶさの映画を一通り観ておくことにした。
ネットで借りて、自宅へ届き、ポストへ返却♪というCMでおなじみのアレなら、一歩も動かずにDVDが手元に届く。
一ヶ月無料体験というキャンペーンをほぼ一年中やっているので、一度利用してすぐに月契約を解約しておくのがオススメ。
登録してさえあれば、いつでも単品レンタルができるからだ。
はやぶさ関係のDVDは本当にたくさんある。まずは映画が3本。

▽はやぶさ/HAYABUSA
公開 : 2011年10月1日
出演 : 竹内結子・西田敏行・佐野四郎

▽はやぶさ 遥かなる帰還
公開 : 2012年2月11日
出演 : 渡辺謙・山崎努・夏川結衣

▽おかえり、はやぶさ
公開 : 2012年3月10日
出演 : 藤原竜也・杏・三浦友和

それに加えて、プラネタリウム限定の映画やドキュメンタリーが多い。

▽HAYABUSA - BACK TO THE EARTH -
公開 : 2009年4月1日

▽HAYABUSA - BACK TO THE EARTH - 帰還バージョン
公開 : 2010年12月18日

▽HAYABUSA2 - RETURN TO THE UNIVERSE -
公開 : 2014年07月9日

▽おかえりなさい はやぶさ
発売 : 2010年12月15日

▽NHK-DVD 小惑星探査機“はやぶさ”の軌跡
発売 : 2010年12月22日

んー、こんな多いとは思わなかった。時間がかかりそうだ。

2016年1月11日 (月)

レトロプリンタ

カラープリンタを2015年末に買い替える予定だったが、結局、そのまま使い続けている。
2014年と同じEPSON PM-G730で印刷した。
この機種は2005年発売の機種で、メーカサポートも終了しているから、故障しても修理さえできない。
インクカートリッジも売り場から消えつつある。そんな状態だから、古いインクカートリッジは格安で手に入る。
品質保持期限が切れているものの、本来1,200円のインクが、送料込みで300円ほどで手に入る。
食品でもないし、真空パックのインクが劣化するとは考えにくい。古いインクを使えば、コスパがひじょうにいい。
互換インクも安いが、あれはダメだ。すぐにプリンタのヘッドが詰まってプリンタを壊してしまう。

ヘッドを詰まらせなければ、プリンタは長く使える。
だがこういった機種は、印字用ヘッドの目詰まりを防ぐため、起動時にインクを吐出する仕組みになっている。
インクは廃インクタンクに吐出されるのだが、プリンタは何回インクを吐出したかカウントしており、一定のカウントに達すると警告が出て、プリンタは使えなくなる。
タンクは余裕を持って設計されており、専用のソフトでカウンタをリセットしてやれば、まだまだ使える。ちなみにリセットするソフトはロシア製である。
ロシア語専攻のツノ丸に説明を読んでもらおうとしたが、時間のムダだった。

2016年1月10日 (日)

音色キャッシュ

下調べも終わったので、今夜は音色キャッシュを実装しよう。
試しに先頭から10音色をキャッシュするとこんな感じ。

//	----------------------------------------
//	音色キャッシュに先読み
//	----------------------------------------
void timbreCacheRead260( uint16_t mdxAdd ) {
	timbreOffset = timbreOffsetGet( mdxAdd );	// 音色offset
	timbreAddress = mdxAdd + timbreOffset;		// 音色のROMアドレス
	for(int8_t i=0; i<__TIM_CACHE; i++) {
		eeprom.Read( (long)(timbreAddress + 27*i), (char*)(timbreCache + 27*i), 27 );
	}
}

プリフェッチキューと音色キャッシュ、二つのキャッシュメモリが存在することになるから、 それに応じた読み出し処理が必要になる。

//	----------------------------------------
//	external EEPROM read
//	----------------------------------------
uint8_t eepromRead8( uint16_t add ) {
	uint8_t dat8;
	uint16_t offset;

	if( timbreOffset ) {				// 音色キャッシュがあれば...
		offset = add - timbreAddress;
		if( offset<=(27*__TIM_CACHE)-1 ) {
			dat8 = timbreCache[offset];
			return dat8;
		}
		Count++;
		Count &= 0x000f;
	}

	offset = add - pfqCacheAddress;
	if( offset<=(__CACHE_SIZE-2) ) {	// プリフェッチキュー内なら...
		dat8 = pfqBuffer[offset];
	}
	else {
		eeprom.Read( (long)add, (char*)&dat8, 1 );
	}

	pfqNextAddress = add + 1;			// 次のアドレスを記憶
	return dat8;
}

確かに音質は改善したが、まだ少し物足りない。
だが、メモリも残っていないし、今回はここであきらめるとしよう。
演奏できるのは15曲、スイッチで曲を選択して演奏できる。
曲に合わせてLEDアレイが光るようにした。

ちなみに、今回のコードをコンパイルすると、ArduinoIDEはこんな警告を出す。

> グローバル変数が 1,791バイト (87%) の 動的メモリを使用しており、
> ローカル変数に 257 バイトが残っています。最高は 2,048バイトです。
> Low memory available, stability problems may occur.

続きはまた今度。仕事がもっと暇になってからだな。

2016年1月 9日 (土)

RAMの節約

今回のアルゴリズムで、演奏のもたつきは解決すると思うが、RAMが足りないため実装が難しい。
アルゴリズムを試す前に、どうやってキャッシュメモリを用意するか。
残っているRAMはすでに512bytesを切っていて、コンパイルの度に警告が出ている。
音階の処理は軽いとみて、音階データをEEPROMに置くことにした。

const char KeyCodeTable[] = {
	0x00,0x01,0x02,0x04,0x05,0x06,0x08,0x09,0x0a,0x0c,0x0d,0x0e,
	0x10,0x11,0x12,0x14,0x15,0x16,0x18,0x19,0x1a,0x1c,0x1d,0x1e,
		:
};

という部分を、こんな感じにする。

PROGMEM const char KeyCodeTable[] = {
	0x00,0x01,0x02,0x04,0x05,0x06,0x08,0x09,0x0a,0x0c,0x0d,0x0e,
	0x10,0x11,0x12,0x14,0x15,0x16,0x18,0x19,0x1a,0x1c,0x1d,0x1e,
		:
};

AVRマイコンは、通常の変数(RAM)とEEPROMではアクセスする方法が違う。テーブルの参照も以下のようになる。

write(0x28 + ch, KeyCodeTable[ offset_note ] );
        ↓
write(0x28 + ch, pgm_read_byte_near(KeyCodeTable + offset_note))

これで12音階×8オクターブ=96bytesのRAMが節約できた。
似たようなコードをすべて、EEPROMに放り出すと、さらに145bytesを空けることができた。
プリフェッチキューのサイズを半分にして16bytesを空けた。
これで96+145+16=257bytesの余裕ができた。なんとかなるだろうか。

2016年1月 8日 (金)

オカマバー

処理がタイトになっているのは、おそらく音階データではない。音色の切り替え処理だ。
音色データはシーケンシャルに並んでいない。そういった処理の直前に、音色データはキャッシュに入っていない。
だったらプリフェッチキューなんぞ作らず、音色だけキャッシュに入れるという手が考えられる。
音色データは、おそらくファイルの前方に配置され、1音色あたり27バイトある。
ファイルの前方をアバウトにキャッシュに入れれば、簡単に高速化が期待できる。
だがキャッシュを配置するべきRAMは、すでに残り512bytesを切っていて、ヒープの確保さえ危ぶまれる始末だ。
よってこの方法は不可能である。
音色データだけをキャッシュする方法について考える。

(1)音色を次々にキャッシュに入れ、古い音色に上書きする。いわゆるFIFOバッファで、キャッシュのお手本のような作り方だ。
→ただでさえ遅いのにリアルタイムでキャッシュに入れる作業が必要になる。遅れるのは初回だけで、次からは速い。

(2)MDXファイルをROM化前に変換し、キャッシュが必要な音色ほど若い番号になるように変換しておく。これなら若い音色番号だけをキャッシュに入れればよい。
→仕事であればならこの方法がいい。ただし、生MDXをそのまま演奏していないのでMDXプレイヤとは言えない。

(3)MDXを演奏前に解析し、よく登場する音色だけをキャッシュする方法。
→解析に時間がかかるが万能かもしれない。

(1)は、演奏開始からいきなりつまづく曲がある。初回のキャッシュが遅くては使えない。
(2)の方法は、元データを加工するのが反則。では、音色番号の再編だけをリアルタイムに行なうのはどうか。
EEPROMに格納されている曲データを書き換えてやろうというわけだ。反則かどうかなんて、もはや気分の問題(※1)である。
そんなわけで(3)の方法を試してみる。

演奏が間に合わない曲はそんなに多くはないのだが、凝った曲ほど苦しい。
たとえば地元ソフトハウスが作ったとあるゲームのオープニング曲を試してみた。
新田君が作って、DENさんが移植して、DISさんがMDX化した曲だと思うが、元がPC88で演奏されていた曲なので、PCMパート抜きでもわりと聴ける。
Windows上でMDX(曲データ)を解析するプログラムを書いてみた。

音色 = 回数 ->
  Timbre[2] = 16
  Timbre[3] = 48
  Timbre[5] = 280
  Timbre[8] = 21
  Timbre[9] = 15
  Timbre[15] = 65
  Timbre[16] = 8
  Timbre[17] = 48
  Timbre[21] = 37
  Timbre[22] = 204
  Timbre[29] = 8
  Timbre[35] = 6
  Timbre[49] = 8
  Timbre[51] = 8
  Timbre[52] = 48
  Timbre[57] = 5
  Timbre[103] = 11
  Timbre[108] = 6
  Timbre[109] = 43
  Timbre[110] = 36
使用音色 = 20個
音色設定回数 = 921回

んー、20音色かあ。キャッシュが27bytes×20=540byteなんてとても無理だ。
どうみてもRAMが足りない。どうしようかな。まあ、明日、電車の中で考えよう。

※1. 今回作っているサウンドボードをオカマバーとして考える。
曲データは客に相当する。男女どちらの客でも入れるオカマバーを作ろうとしているわけだ。
演奏できないデータは女に相当する。女だから入れない。だからといって店に入る前に性転換するのは反則だと言いたいのだ。
いやいや、男女どっちだって来てください。女だったら店の中で性転換するけどねっていうのはアリなのかナシなのか。
いずれの方法でも反則だと思うのだが、どうだろう。

2016年1月 7日 (木)

プリフェッチキュー

外付けEEPROMの読み出しが遅いため、演奏が乱れる曲がある。
EEPROMの内容を内蔵EEPEOMにロードするとかなり改善されるが、ロードに時間がかかる。1曲4KBで12sec待ちは厳しい。
ただしロードしてから演奏する方法をとるなら、zip圧縮された曲データを、解凍しながらロードすることも可能だ。
曲データは約1/3に圧縮できるから、現在の3倍もの曲を記憶できる。(※1)
圧縮データを読むので、内蔵EEPROMからの読み出しが高速化されるが、
展開したデータを書き込む処理がとても遅いため、ロード時間の短縮にはならない。

それからもう一つ。データシートによると、EEPROMは10,000回程度の書き込みに耐えるとなっている。
言い換えると10,000回書き込むと、壊れるかもしれないということだ。
たとえばloop()が100回/秒で回っていて、その中にEEPROMへの書き込み処理があれば、たった100秒で壊れてしまう可能性がある。
曲の切り替えボタンでロードという使い方だと、毎日100曲切り替えても100日は持つ。マリオのジャンプ音みたいな音楽だったら何百回も演奏される可能性がある。
前回と同じ曲を演奏するなら、再ロードしないという工夫は欲しい。

とはいうものの、EEPROMへのロード時間が不満なら、この方法は使えない。
曲データは基本的にシーケンシャルだから、次に使いそうなデータをRAMに先読みしておくのはどうだろう。
こういった仕組みをプリフェッチキューという。
この先読み処理のために、音楽のテンポが遅くなっては意味がない。
タイマの値を調べ、余裕がある時に先読みすればいい。
計測したところ、外付けEEPROM(24xx512使用)からの読み込みには、16bytesには660us、32bytesには1160usかかることがわかった。
この時間はそこそこ正確で、10回中9回はこの値。ずれてもせいぜい+2usだった。
読み込んだデータはI2Cのバッファサイズに合わせて32bytes、読み書きがもっとも速いRAMに置くことになる。
プリフェッチキューを試したところ、全体的に軽くなったが、処理落ちには何の効果もなかった。私の休日を返せ。

※1. zip圧縮された曲データを解凍しながらロードすることも考えた。
それはいかにも楽しそうな作業だが、大容量のEEPROM、たとえば24LC1025は350円で買える。
たとえ数時間で開発できたとしても時給100円。それは金で解決すべき問題だと思う。

2016年1月 6日 (水)

曲の選択

非圧縮zipの曲が演奏できるようになった。EEPROMに複数の曲が入っているので、曲を選択できる仕組みが必要になる。
新しいArduinoでは、A6-7が使えるらしい。
A6-A7は入力専用だが、アナログ入力できるのだからこれを利用しよう。
アナログピンが1本あれば、抵抗で分圧して複数のスイッチ入力として使える。
私の部品箱には抵抗があまり入っていない。数少ない抵抗を使ってテキトーに配線したのがこれ。

A7switch4

分圧の計算など不要だ。入力値を表示して、表示された値で入力判定すればいい。
倍々となるように配置するといいよ。
スイッチのところはすべてGNDに落とす。
コードは以下のように書いた。

//	----------------------------------------
//	switch test
//	----------------------------------------
uint8_t swGetA7() {
	char buf[10];
	int temp;

	temp = analogRead(A7);
	if( temp< 10 ) return 1;
	if( temp< 60 ) return 2;
	if( temp<150 ) return 3;
	if( temp<600 ) return 4;
	return 0;
}

たった1本のピンで、4個のswを処理できるので助かる。
こんな感じで配線すれば、比較的キレイに、そして高密度で配線できる。

選択swでカウンタを増減し、決定swで演奏開始とした。
表示は4ピンも使ってLEDアレイを接続した。LEDアレイを2進数と考えて16曲が選択できる。
これはカキフライ要求装置の頃から定番の処理である。

「カキフライが食べたいです」
「本当ですね」
「いつ作ってくれますか」
「明日なら作ってくれますか」
「ありがとうございます」

などと選択し、決定ボタンでしゃべるわけだ。

2016年1月 5日 (火)

非圧縮zip

曲データ(mdxファイル)は、非圧縮zipとしてアーカイブし、そのままEEPROMに書き込むことにする。
ファイルはフォルダにまとめて放り込み、フォルダごと圧縮すると作業が楽になる。
指定番号のmdxデータの先頭アドレスを返す関数を、Windows上で書いて検証する。

//	------------------------------------------------------------
//	非圧縮zipに格納された指定ファイルのoffsetを返す
//	------------------------------------------------------------
int zipGetFileOffset(int num) {
	int len;			// ファイル名の長さ
	int size = 0;		// ファイルサイズ
	int offset = zipHeaderSkip();			// zipファイルのヘッダをスキップ
	printf( "offset = %04x\n", offset );

	for ( int i=0; i<=num; i++ ) {
		printf( "mdx(%d) info ---------->\n", i );
		size = eepromRead16i( offset+0x0016 );		// ファイルサイズ
		len = eepromRead16i( offset+0x001a );		// ファイル名の長さ
		printf( "fileSize = %d\n", size );
		printf( "filenameLength = %d\n", len );
		fseek(fp, offset+0x001e, SEEK_SET);			// ファイル名へ
		fread( name, 1, len, fp );
		name[len] = '\0';
		printf( "name = %s\n", name );
		offset += 0x1e + len + size;
	}
	offset -= size;
	return offset;
}

//	------------------------------------------------------------
//	フォルダごと非圧縮zipでアーカイブされたファイルの
//	先頭部分をスキップする
//	------------------------------------------------------------
int zipHeaderSkip() {
	int len = eepromRead16i( 0x001a );
	printf( "filenameLength = %d\n", len );
    fseek(fp, 0x001e, SEEK_SET);			// filename length
	fread( name, 1, len, fp );
	name[len] = '\0';
	printf( "name = %s\n", name );
	return ( 0x001a + 2 + 2 + len );
}

コツコツと作るだけだ。バグが出るような場所はない。
eepromRead16i()という関数は、ディスクからファイルを読み込む処理を、EEPROMからの読み出し処理に似せたものだ。
MDXはX68000の音楽データだから、2バイトデータはすべてビッグエンディアンである。
よって、ビッグエンディアンのeepromRead16()に対して、リトルエンディアンのeepromReadi()を用意した。
この関数の出力結果はこんな感じになった。

ファイル名=mdxLib.zipをテストします
filenameLength = 5
name = test/
offset = 0023
mdx(0) info ---------->
fileSize = 15240
filenameLength = 13
name = test/DS04.mdx
mdx(1) info ---------->
fileSize = 6850
filenameLength = 19
name = test/dTwinbee17.mdx
target offset = 3c07

出力された3c07番地は、たしかに曲データの先頭だった。特に問題はなさそうだ。
そのまま演奏システムに組み込んだが、特に問題なく動作した。

2016年1月 4日 (月)

I2Cのクロック

年末年始は、ArduinoとYM-2151で遊ぶことになっている。
無事に曲を演奏できるようになったが、さらに多くの曲を演奏するとなると、外部記憶を使いたいところだ。
今回は外付けEEPROMからMDX(曲)データを読み出して演奏することにした。
EEPROMは24LC512を使っている。
だがEEPROMからの読み出しに時間がかかっているようで、テンポが遅くなってしまう曲がある。
EEPROMの書き込みはひじょうに遅く、1バイトに5msもかかるらしいが、読み出しはそんなに遅くないはず。
とりあえずI2Cの通信速度を上げてみることにした。たった1行加えるだけでいい。

    Wire.begin();
    TWBR = 12;        // 通信速度(400kHz)

デフォルトでは、TWBR=72と設定されており、100kHzで動作しているようだ。
この値を32とすれば200kHz、12とすれば400kHzで動作する。
I2Cの信号線、SDAとSCLの抵抗値は、こちらのサイトで詳しく説明されている。
http://www.picfun.com/i2cframe2.html

この修正によって、演奏はかなり改善されたが、まだ少しテンポにムラがある。
これくらいならバレないかも・・・というレベルだ。
外付けのEEPROMはI2Cによるシリアル通信だから、内蔵EEPROMに比べると速度が遅いのだろう。
だったら曲を切り替える時に、外付けEEPROMから内蔵EEPROMに、1曲分のデータをロードしてから演奏すればいい。
と思ったのだが、内蔵EEPROMへの書き込みは1バイトが3.3msかかる。8KBだと3.3×8000=26400ms=26secもかかってしまう計算になる。
ちょっと現実的ではないなあ。

高速なRAMにロードするのは当然無理。
ブロック転送して、キャッシュされたデータだけは演奏とか、とにかくトリッキーな手法が必要になる。
とりあえず、テンポが乱れるが無圧縮zipを演奏してから考えるとしよう。

2016年1月 3日 (日)

PICkit2入手

EEPROMの書き込みが不安定なので、中古品のPICkit2を入手した。
職場ではPICkit3を何台も導入し、その時にすべて処分した。それをまた手に入れる羽目になるとは思わなかった。
製造元のMicrochipでは、PICkit3が主流となっており、販売が終了したPICkit2のサポートはほとんどない。
書き込みソフトであるPICkit2 Programmerを探すのには苦労したが、ようやくここで見つけた。

PICkit 2 V2.61 Install Aという4MBほどの小さなソフトである。
PICkit2 downloadなどで検索しても見つからず、このページにたどりつくのは至難の業である。
いつ消えるのかわからないので、ここにも置いておく。

▽あとでファイル(置けないかも…)

PICkit3では動かないが、PICkit3には、専用のソフトウエアで公開されている。
そういえば、PICkit3 Programmer v3.01の動作を強制的に止めてやるとこんな画面が表示される。

Pickit3error

PICkit3は、今時のPICマイコンのために、低電圧動作するよう改良されているが、内部的にはほぼPICkit2 Programmerである。
まあ、イチから作り直すはずもないから当たり前だけど。

今回入手したPICkit2によるEEPROMへの書き込みは安定しており、結果には満足している。
私は職場のPICkit3を無許可で壊すわけにもいかないし、仕事が始まるまで待てなかったから、中古で安いPICkit2を使っただけである。
一般的には純正品のPICkit3を入手し、正しく改造して使った方がいいと思う。
中華製のPICkit3のバッタモンも見かけることがあるが、PICマイコンだけならともかく、EEPROMライタとして使うのはやめた方がいい。

2016年1月 2日 (土)

ダイシモチ2016

年末の仕事で一気に体重が増えた。さすがにこれはまずいと思い、畑に出た。
20mほどの畝を作り、一部に大麦をまいた。
年配の方にはこれが仕事に見えているようで、正月早々せわしい人に見えているようだ。
私にとってはただの道楽だし、そもそもこの畑は他人の土地。本来なら耕す必要さえない。
むしろ家の中でプログラミングしている方が本職なんだが。

大麦の品種はダイシモチ。ダイシモチはモチ性の裸麦である。
裸麦は殻がはずれやすいため、家庭で精麦ができる。精麦さえできれば、大麦は小麦より用途が広い。
炒って麦茶、ご飯に混ぜて麦飯(正確には麦入りご飯)など、大量消費しやすい用途が多い。
麦は本来12月くらいにまくものだが、それは水田が空いているからだ。
畑だったら、12月はまだ作物が多い。1月まきにすれば、白菜や大根の後が広く使えるので助かる。
その分だけ育ちが遅いというなら、2倍の密度でタネをまけばいい。

2016年1月 1日 (金)

プログラマの正月

昨日からずっとパソコンで遊んでいる私である。いつもと違って傍らにはビールとツマミ。充実した正月である。
時々、正月から何をやっているんだと思わないでもないのだが、そんなことをやっているのは私一人ではない。
偶然使っていたバイナリエディタFavBinEdit、ゲームのBGMプレイヤhootなど、使っていたソフトウエアが、相次いでバージョンアップしたのだ。
インターネットの向こうでは、作者がちょうど開発を続けているいうことである。
ちょっと用があってメールしたら、数分後に返事が届いて驚いた。頼もしい話である。

そういえば、バイナリエディタで解析していたReviverをのぞいていたら、懐かしいコードを見つけた。

    ED 79 03 ED 79 03 ED 79 03...

ただED 79 03が80回も並んでいるだけである。
Z80のニーモニックだとこうなる。

top:
	OUT	(C),A
	INC	BC
	OUT	(C),A
	INC	BC
	OUT	(C),A
	INC	BC

本来、OUT (C),A という命令は、I/OポートのC番地に、Aレジスタの値を出力する命令である。
Z80というCPUでは、こっそりBレジスタもポートに接続されており、じつはOUT (BC),Aというポートにデータを出力する用に作られていた。
X1というパソコンは、このポートBCを利用してV-RAMを接続していたから、V-RAMに描画したいものがあれば、OUT (C),Aのように出力することになる。
たとえば60×8ドット分のデータを出力するには、普通はこんなコードを書く。

	LD	D,40
loop:
	OUT	(C),A
	INC	BC
	DEC	D
	JP	NZ,loop

しかしこれでは1バイトを出力する度に、カウントダウンや、ジャンプ命令を実行することになり、実行速度が落ちる。
そこで1ライン640ドット(=80バイト)分を出力する処理を80回そのまま並べておき、top+(20×3)番地にジャンプするのだ。
こうすればループにかかる処理がなくなって高速化できる。

« 2015年12月 | トップページ | 2016年2月 »

最近のトラックバック