チップコンデンサーって壊れやすい?

だいぶ前に表面実装タイプのICをつい購入してしまい長らく死蔵していたのだが、ようやくSOP変換基板を入手して実装してみた。当時のはチップコンデンサーが付属しており、せっかくなので使ってみたら意外と壊れやすいようで苦労した次第。
電源のバイパスを含めて5個を実装したのだが、2個は壊れたようで、さらに2個はどこかへ飛んでいってしまい、結果として9個を消費。壊れた2個は基板のランドに片足のみ半田付けで立てて、もう一方の足は空中配線していた。配線間違いで付けなおしたりで、テンションがかかったりしたのだろうか?ショートはしていないがほぼ容量の無い状態になっていた。
まさかコンデンサーが不良になるとは思わず、ADM3202の電圧変換が機能せずに5〜6時間は悩んでしまった。

怪しいモバイルブースター

たまにDealeXtremeで買い物する。ちょっと買いたいものがあったついでに、以前購入したモバイルブースター($10.40)をもう一つ購入しようかと思ったら見つけられずにあせった。
写真がそのモバイルブースターで、自分で18650を1〜4本まで入れて使う。４か月ほど使っているがまずまず順調で、Nexus7だと1回(弱かも)、だいぶバッテリーの弱ったHybrid W-Zero3なら2〜3回は充電できそう。おそらく新品の18650を入れれば、その倍くらいの電気を持ち運べると思われる。
Nexus7は普通のUSB通信ケーブルで充電できるのだが、Hybrid W-Zero3はダメだったのでセリアで充電ケーブルを買ってきた。KM-01というやつ。もちろんこのケーブルでNexus7も充電できる。

モバイルブースターのふたを開けたところ右のケーブル下がふた

NECフォーマットの赤外線リモコンでリピートコードが意外と出ている

AVRマイコンのATTiny2313で赤外線リモコンの受信機を作ってみている。
KENWOODのミニコンポのリモコンRC-M1MDがどうもうまく受信できないと悩んでいたのだが、どうもリピートコードが頻繁に送出されるのが原因らしい。波形を見ていないので確信はないのだが、電源ボタン含めすべてのボタンで、長押ししなくてもリピートコードが出るっぽい。
当初リピートコード未対応でソフトを組んでいたら十中八九は受信エラーで、リピートコードへ対応したら九分九厘OKになった。
使い古しの電池が悪いのか?外光の影響なのか?とかいろいろ悩んでしまった。
ついでにサブルーチンから戻らないという現象にもちょっと悩まされた。ソースコードを複数ファイルに分けて整理したのだが、何気なく
avr-gcc -o led led.o morse.o irremote.o
とリンクしたのが良くなかった。逆アセンブルしてみるとスタックの初期値設定がおかしい気がする。-mmcu=attiny2313
と、型番指定が必要なのだった。こちらも電源のパスコンを入れていないせいなのか?とかけっこう悩んでしまった。

秋月でArduinoのバニラシールド200円!

秋月のWebを見ていたらArduino用のユニバーサル基板(いわゆるバニラシールド)を発見した。以前に自作してみたりしたので、苦労を考えると200円は買いだと思う。自作の場合は最上階専用のスタック不可(やれないこともないか?)なんだけど、この基板はピンヘッダとソケットを両方ともつけられそうに見えるし。

if (code[2] != (uint8_t)~code[3])などとキャストが必要の件

NECフォーマットの赤外線リモコンでは8bitのデータコードと、そのビット反転したものが送られてくる。なのでavr-gccで掲題のようなチェックをしたのだが、もともとはキャストしておらず常に不一致でおかしいなぁ〜と悩んでいた。
プログラム全体が一通りできたところで、いよいよ原因究明しようと逆アセンブリの該当部分を見ると案の定16bitにプロモートされたうえでビット反転されている。たとえば0x89と0x76が送られてきて0x0089と、0x0076のビット反転すなわち0xff89の比較となり、不一致となっていた。
前からシフトとかビット演算が必要ないのに16bitで行われていて、C言語の仕様だからしかたないけど命令数無駄だよなぁ〜と思っていたのだが、ちょっとこの結果は想定外で驚いた。gccの場合、こういった共通の言語仕様はコンパイラーの共通部というか、直しにくいところに実装されているそうで、随時キャストでしのぐしかないようだ。