USB電源といっても、USBの5VにコンデンサとLEDとポリスイッチをつないだだけの緊急対応用のもの。先日、とある案件で電源も何もないところでマイコンのデバッグをする羽目になったのだが、そのときにこういうのがあると便利だなと思って取り急ぎ手持ちパーツででっち上げた。

回路自体はシンプルで、秋月の16ホールユニバーサル基板を2×2で使ったモノに適当に部品を乗せてある。16ホール基板はまとめて買うと(通販だと実際どういう荷姿になるのかわからないが、店頭でまとめて買うと)、ある程度のサイズの基板にVカット状態のものが手に入る。これを適当なサイズに折って使うのだが、変な大きさの基板が欲しいときに大変重宝する。ブレットボードに挿せないようなチップ部品を片っ端から16ホール基板に実装して一列ピンヘッダを足にしたものも作るのが楽だ。

で。この電源、そのまま剥き身で使うといろいろ危ないし可愛くない、ので、久しぶりにCNCを起こす意味でちょっとケースを作ってみた。途中経過は端折るが、結果はこんな感じ。

得られた知見をメモしておく。

CNCで黒檀は削れる。重みの通り、割と樹脂と変わらない。ただし、木が密でないところは毟れるように割れたりするので、Plunge rate(切り込み送り速度)は小さめがおすすめ。F=50とかでも0.2mm切り込むと怖い。良いCAMで切り込みに横傾斜をつけられるのならば、そういう設定がおすすめ。

若干だが削ってる最中にゆがむ。木材なので致し方ないが、ケミカルウッドのようなつもりでやると思わぬ結果になるかもしれない。かなりのトライ＆エラーを繰り返す必要がありそう。今回はエンドミルの軸が木材にすれてガラスをひっかいたような音が立ったりして結構びくびくすることになった。

木材を削るときは火災が怖い。もろに摩擦で火をおこす、というようなことをやっているので、樹脂と同じつもりでしばらく放置なんてことはしないほうが良いと思う。幸い発火の気配もなかったが、怖いので全く手を離せなかった。切り子(というよりおが屑)はかなり頻繁に掃除機で吸った。

フルに削りだしは死ぬほど時間がかかる。今回、黒檀を0.2mmずつ切り込んだが、およそ3時間ほど要した。ちなみに上の写真にはあえて定規をいれていないのだが、縦横26mm、高さ20mmほど。中の空間は縦横20.5mmの深さ17mm。大きい削りだし物はスタイロフォームでもないかぎり、この手の小型非力CNCでやるべきではないだろう。楽しいけど。

久しぶりに何か作った気がした。この感覚から何かを得られればいいなと思う。

自分で言うのも何だが、私はかなり理屈っぽい性格である。だが、だからこそというべきか喧伝される理屈は好きではない。なんだか後付けだったりモノその物の制作意図ではない意図を感じてしまう。つまり嘘くさく感じる、のだ。

こんなpostを書こうと思ったのは、たまたまLEXUS LFAエンジン音のサウンドデザイン、なんていうページを見てしまったからだ。聴いてみると、音質がたいして良くないのと録音しづらい音源であるせいで細かいところはよくわからないが、いわゆるスポーツカーらしい音、に仕上がっているような感じは受ける。こういったモノはユーザの感性に訴えるものなので、好きな人嫌いな人、どっちもいるだろうし、それについては別にどうというつもりもない。だが、それってわざわざ他社に依頼してやって、リリースまで打つようなものなのだろうか。

当然、このひどい不況の中、ちょっとでも売り上げを上げたいのはよくわかるし、そのためにはあれやこれや手を尽くして説明文に書けることを１行でも増やしたいのは感覚としてはわかる。ゲームは中身にお金をかけるより広告にお金をかけた方が売れるなんていう話が出てきてしまうくらい、そういうプロモーションが大事だというのも知ってる。だが、それでもなおそういう売り方をしないという矜持のようなもの、それが物を作る人にはいるんじゃないだろうか、というように思うのだ。

矜持で飯が食えたら苦労しない、なんて言う奴はとっとと食えなくなればいいのだ。そういうものじゃないかね、何かを作って世に送り出すつうのは。

というところでちょっとこのネタを寝かせておいたのだが、昨日の帰りに相方と会話していて、自動車製造大手のような巨大企業は物作りをやるならもっと細分化したほうがいいのに、という話が出てきた。今はサスペンションだとかは外部企業がやっていたりするが(KYBとかオーリンズだとか有名だけれども)、エンジンに特化した会社だとか、フレームに特化した会社だとか、そういうのはあまり聞かない。詳しくない業界なのでそのあたりの細かい実情はとりあえずおいておくとして、要点はコンセプトワーク専業の会社、販売専業の会社(今は一応販社って格好になっているけどあれは他メーカ車を扱えない時点で同じ会社みたいなものに見える)、組み立て専業、エンジン専業、etcetc、と分かれていったらいいんじゃないかと思ったわけだ。そういうところでは、ミツオカなんかは本当に格好いいとおもう。

まー、そうなったらうちは何をやるかね。そこが課題かもしれない。

UEW線とETFE線の使い方のエントリを書いていたらマシンが転けて(正確にはサスペンドから帰ってこなかった)、エントリが消えたので別なネタ。UEW線とETFE線の使い方についてはまた後日書き直す。

ここしばらく、某所向けのプロトタイプ品を作っていたのだが、数点だけのプロトタイプの場合、なおかつプロダクト化するときとの差があまり大きくない場合(今回は制御基板モノだったのだが、こういうときは周波数があまり高くなくてシビアじゃない回路とかだった場合)、手元で作れるかどうか、は結構重要なポイントになってくる気がする。手元で作れないとどうにも気が重い。今回はユニバーサル基板に半田付けでプロトタイプを作ったが、たいして複雑な回路でもないので数時間程度で作ることが出来た。

気が重いのはなんでなんだろう、と思っていたが、主にリードタイムによる気の重さ、のような気がしてきた。基板を起こすにしても、回路図を組んで、そこから基板データを作って、ガーバーデータにして、基板メーカに発注。届くまで数日～数週間、届いてから組み立て。万が一間違いがあればもう一度直すところからやり直し、一瞬で一ヶ月が経ちかねない。それが、手元で作れてしまえば間違っても数日でリカバーできる。そんな気軽さは割と大事なのではないか。同じようにウェブアプリだったら手元でサーバをさくっと立ち上げて、誰かに見てもらえるレベルに持って行くことが出来ることが大事。いちいちサーバを契約して、なんていう壁を作ってはいけない気がしている。

もちろん、これは製品を作るための第一ステップ、可能性検討の段階での話、最終的な製品にむけてのステップの中では当然本番同等のものを作らないといけないし、時間も多く必要になる。だが、物事は一つ目のステップを踏み出すまでが重い。そこを超えるとなんとなく勢いがついてその先に向けて動き出す。その一歩目を軽くすることに時間をかけることは、決して無駄ではないはずだ。

以前、物事には物理法則が通用する、という会話を知人としていたのを思い出す。物理法則でも最大静止摩擦力を超えるまではモノは動かない。そういうものなのかもしれない。

さて、次は少数量産に向けての試作品作り。数を作るにはまだいろいろと遠い。

あまりにも仕事がない時期が終わったと思ったとたん、あちこちから仕事のオファーをいただいてうれしい限り。

うちとしては新規事業に近い分野もあって、yak shavingになってしまうことも多々。そんな中でもなんとか成果を出せそうになっていることだけが救い。後はプロダクト方面にもっと動ければ。

12月になればもう少しネタの種まきをする時間が取れるはず。それまでは目の前の作業にいそしむことにしよう。

またはまっていた。AVRのPCINT割り込みを使う場合のはまりどころ。特に頭が疲れているとやらかしかねない。

割り込みレジスタ関連：

PCMSKnにビットを立てただけでは駄目。PCICRにPCIEnを指定しよう。

割り込み内エッジ処理関連：

PCINT割り込みはINT割り込みと違ってエッジの指定が出来ないので自分でやる必要がある。ここでぼーっとしてると

ISR(PCINT3_vect)
{
	if(bit_is_set(PORTD, PD4)) {
		// rise
	} else {
		// fall
	}
}

と書いてしまいがち。正しくはこう。

ISR(PCINT3_vect)
{
	if(bit_is_set(PIND, PIND4)) {
		// rise
	} else {
		// fall
	}
}

PORTnだと生の値が拾えないので忘れずに。

なんというか、昔もこうだったっけ、ということだらけ。十分なリハビリが必要そうで泣ける。

ちょっと前のポストで壊れたと書いたThinkPad、ばらばらのままでは邪魔なので組み立て直したのだが、どうも症状が再現しなくなった。直ったかもしれない・・

というだけではポストとしてなんなので、何をしたかを書いておくと、ThinkPadのLCDをあけて、裏側をみると、１カ所半固定抵抗がついているのが見える(上の写真参照)。見えないならパネルが違う。よく見るとその半固定抵抗の部分だけかぶせてあるフィルムに切れ目が入れてあって、どうやら出荷時に何かの調整をするために残してある部分らしい。で、何をするかというと、これにデコピンをかますだけ。デコピンが嫌なら適当なものでかるーく衝撃を与えてやるかすると良いかもしれない。これだけ。

おそらく、半固定抵抗の接触不良かなにかで接触が悪くなったということなのではないかと推測する。この手合いの摺動抵抗器ではよく起こる現象ではあるので、致し方ないとはいえなんというか。

いざというときほど心を落ち着けて、故障解析をせよということを今後の教訓としよう。がっくし。

もういい加減寒くなってきたので、ベランダ菜園のトマトとゴーヤをたたむことにした。ベランダ菜園のトマトは数週間放置気味だったのでいい加減何もなかろうと思っていたら、青い実があるわあるわ、ボールに二杯ほど採れてしまった。勿体ないので青トマトのピクルスにすることに。

青トマトのピクルスはいくつかのサイトを調べたが、一番それっぽかったサイト(*)を参考に、１時間ほど5%程度の塩水に漬けた後、ピックル液(酢５に対して水１の割合で混ぜたものに月桂樹の葉数枚、丁字数個、大蒜数欠けを投入、沸騰してから10分ほど中火で沸かしてさましたもの)を使って漬けてみた。数週間後からは食べられるだろう、楽しみである。

(*)サイトのコンテンツはいいのだけど、運営者がSEO(Search Engine Optimization)を売りにしている会社なのがなんとも胡散臭い。正直SEOなんぞサーチエンジンの尻を追いかけるだけのしょーもない商売で、そういう会社がまじめに漬け物サイトを作るわけが無く。このサイトだっておそらくただの実績作り用で作ったら作りっぱなしでサーチエンジンが方針を変えたとき以外は変更されることもあるまい。有り難く参考にはさせてもらったが、釈然としないなぁ。

Digi社のXBee、かなり便利に使える道具だと思うのだが、割とはまっているのが速度。ああいった物に速度を求めるなという話もあるが、実際どれくらい出るのだろうと思って試してみることにした。なお、XBeeといっても802.15.4だけしか使えないOEM RF Moduleで、ZigbeeやDigimeshを使えるモデルではない。また、転送レートを調べることが目的なので、Transparent modeで使っての試験とした。

試験は自宅というごくありふれた環境で、送信元と送信先のXBee距離は40cm程度、WiFiの電波もそれ以外の妨害電波もばしばし飛んでいる状況である。その中でXBeeのボーレートを250kbpsにして、適当なソースをつないでフロー制御なしで走らせてみることにした。設定は8bit/Odd/1Stopとしたので、１バイトあたり9bit分のデータを飛ばすことになる。

その結果だが、数回繰り返したところ、おおよそ12～13kbytes/sec程度の転送レートが出ることがわかった。流れたビット数で108～117kbps、つまり出ても定格の半分程度ということになるだろうか。このテストでは、最大速度を知ることが目的だったのでフロー制御をしていない。そのため、パリティをつけている分欠損データは拾わない(カウントしていない)ものの、データの欠落は山ほど出る。実際に使うには送信側できちんとフロー制御しなければいけないだろう。また、XBeeは無線の制御にCSMA-CA方式をつかっているため、リアルタイム性も保証されない。ビットレートを落とせばある程度の安定したタイムラグを得ることは出来るだろうが、正確なリアルタイム制御をしたければNTP的にラウンドトリップタイムを得たりしなければならいような感じである。

ちなみに、マニュアルによれば、フロー制御をしたくない場合、DI Buffer size(202bytes)より１メッセージを小さくしたりボーレートを下げることを要点としてあげている。

簡単なテストではあったが、割と勘所はつかめた気がしてきた。ひとまず、CTSを握って制御してやることがまず第一のようだ。

引き続き開発。

追記：その後、CTSをきちんと処理するようにした結果、目視する限りビット落ち無しで、8k～9kbytes/sec程度のスループットが出ることもわかった。鉄筋コンクリートの壁を数枚隔てたくらいではほぼスループットは落ちない感じ。ビット落ちがきわめて少ないのは大変有り難い。

WinAVRの環境(avr-gccなら同じだと思うが)で複雑な割り込みがかかるようなプログラムを書いているとき、原因不明のリセットがかかる場合、可能性として考えられるのは1)ウォッチドッグ、2)電圧低下のBORリセット、3)割り込みベクタが変、が考えられる。このうち1と2は割とデバグしやすいのだが3がどう対応すればいいのかと思って調べてみたところ、こう書けばいいということがわかった。

ISR(BADISR_vect) 
{ 
    cli();    // これ以上割り込ませない
    // このあたりでデバグメッセージ	
    for(;;);  // ここで止めておく
} 

とりあえずこの中でデバッグメッセージを書いて止めてしまえば、何か起きていることまではわかる。その先はさらにデバグデバグ。

なんでこういうことになったかというと、送信可能状態になったときに飛んでくる割り込み(USART1_UDRE_vect)を書かないといけないところに、ぼんやりしていて送信完了時に飛んでくる割り込み(USART1_TX_vect)を書いてしまっていたからだった。そりゃBADISRにもなる。

同じはまり方をしないためにメモ。

追記：何も考えずにTXCIEnを有効にする場合、USARTn_UDRE_vectだけだとBADISRになる。USARTn_TX_vectも書いておくこと。

追追記：嘘書いた。TXCIEnはUSARTn_TX_vect、UDRIEnがUSARTn_UDRE_vectに対応ということのよう。もう少し調べてまとめたい。

友人のO氏に誘われて善福寺公園へ。普段はたいてい下流の善福寺川公園方面へ出てしまうので、上流側へ向かうのは久しぶり。

ちょっとぼかすだけでほぼ印象派になってしまうような秋の光であった。

たまにはぼんやり散歩もいい。カメラだけを担いで。