<< 12月 2011 | Home | 2月 2012 >>
PR: 転職    お墓    エコ    通販    結婚相談所    シルバー    質屋    葬式    漫画    エステサロン   

年賀状

インクジェットプリンタを持っていても使うのは年賀状印刷くらいで、そうすると間がやたらあくのでノズルが詰まっていて、そのクリーニングでインクタンクが空になってと、お財布にも精神衛生上も最悪なので、カラー印刷は外に頼むようにしている。ハガキサイズの印刷も、昔はL判などに比べると妙に高かったのが、最近は1枚10円を切るのが当たり前になってきた。それなのに年賀状印刷がいまだに妙に高いのはなぜなんだろう。


モノクロ印刷だけはA4レーザプリンタが残してある。正直セブンイレブンの印刷サービスでほとんど用は足りているんだけど、年賀状の宛名をシールに印刷する必要があり、残念ながら宛名印刷を安価でやってくれるサービスが、まだ見当たらないので。

おまけ。大昔の夢久の写真。最近、肥満をこじらせていてデブ猫化がやばい。

赤外線取り込みができた。

赤外線取り込み部分ができたので表にしてみた。東芝のビデオのリモコンの「1」を押した時の信号。単位はμ秒で、10μ秒の桁を四捨五入している。

点灯9,000
消灯4,500
点灯600
消灯1,700
点灯700
消灯400
点灯600
消灯1,700
点灯600
消灯500
点灯600
消灯500
点灯600
消灯500
点灯600
消灯1,700
点灯600
消灯500
点灯600
消灯500
点灯600
消灯500
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯500
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯500
点灯700
消灯500
点灯600
消灯500
点灯600
消灯500
点灯600
消灯500
点灯600
消灯500
点灯600
消灯500
点灯600
消灯500
点灯700
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯1,700
点灯600
消灯39,800
点灯9,000
消灯2,200
点灯600

最後の39,800μ秒以降がトレーラのようなんだけど、何回か取り込んでみると、ここが出力されない時がある。プログラム側のバグかと思ってオシロで観察してみたところ、実際に出ていないようだ。多分リモコンの受光側が、40,000μ秒近く変化無ければ、そこでおしまいというロジックで、特にトレーラ部が無くてもいいんだろう。

このデータは、たかだか70個くらいなんだけど、日立のエアコンだと、これが1000個くらい出ている。何しろメモリが少なくてバッファが取れないんで、なんとか圧縮かけて256バイトに(ヘッダとかあるので、もう少し小さめに)したい。オーソドックスにハフマン圧縮かな。PICは高速だからハフマン符号の解凍くらいなら十分に間に合うんじゃないかと見ているが、さて。

PICのUSB割込の優先度を変更。

リコモンの赤外線信号をPCに転送するのに、PIC18Fシリーズの18F14K50でコードを書いてみた。赤外線受信モジュールをPICの入力端子に接続して、端子の状態変化に対して高優先度割込みを設定。状態変化が起きるごとにタイマをリセットして、タイマ値から時間経過を測定して、リングバッファを経由して同時並行でUSBを介してPCに転送という感じ。しかしオシロの結果と比較すると妙に誤差が大きい。考えてみたらUSBもフレームワークで高優先度割込に設定されていたのだった。USBの処理って結構重そうだから、これが原因かも。

試しに赤外線受信中にUSB転送をするのをやめて、一通り受信し終わってからUSBに転送するようにしてみたところ、誤差が大幅に改善された。とはいえ、このPICはRAMが768バイトしかなく、USBのバッファとかランタイム用で512バイト近く持っていかれてしまい、スタックにも128バイトくらいは欲しい(USBフレームワークからアプリのエントリに来た時点で64バイトくらい消費されてしまっている)ので、アプリには128バイトくらいしか残されていない。しかも最初に実験に使っていた東芝のリモコンは割と信号長が短かくて、これなら頑張れば行けるかもと思っていたのが、ふと日立のエアコンのリモコンを試したら、その10倍くらいデータ量が多くてびっくり。流石に無理かもしれない。赤外線受信だけならまだしも、このあとXBeeという無線モジュールを介して別の場所にあるリモコン対応機器を制御したいなと思っているので。PIC24の24F64GB002のカタログを横目で見つつ、他に手はないかと悪あがき。そもそもUSB割込を高優先度にしなければ良いような気がしてきた。USBのところはバッファもふんだんに割り当てられているし、そもそもフレームワークではポーリングという選択肢も用意されている。それならUSBを低優先度割込にして、高優先度割込の処理をなるべく軽くしておいてやればいいのではないか。

とはいえUSBフレームワークのソースを見ても、優先度設定のオプションが見当たらない。仕方がないのでパッチを当てることにした。USBのフレームワークのMicrochip/Include/USB/usb_hal_pic18.hというファイルの383行あたり。

#  if defined USB_INTERRUPT_PRIORITY_LOW (追加)
    #define USBEnableInterrupts() {RCONbits.IPEN = 1;IPR2bits.USBIP = 0;PIE2bits.USBIE = 1;INTCONbits.GIEH = 1;} (追加)
#  else (追加)
    #define USBEnableInterrupts() {RCONbits.IPEN = 1;IPR2bits.USBIP = 1;PIE2bits.USBIE = 1;INTCONbits.GIEH = 1;}
#  endif (追加)

あとは自分のアプリケーションのusb_config.hの中に、USB_INTERRUPT_PRIORITY_LOWのdefineを追加してやる。

//#define USB_POLLING
#define USB_INTERRUPT
#define USB_INTERRUPT_PRIORITY_LOW

とりあえず、これで動いているようだ。

このサイトの掲載内容は私自身の見解であり、必ずしもIBMの立場、戦略、意見を代表するものではありません。
日本アイ・ビー・エム 花井 志生 Since 1997.6.8