前に書いたのの続き。

• Code: https://github.com/cho45/AVR-TinyElekey

せっかくメインのICが小さいので、できるだけ小さく作るならどうするのがいいだろう？と考えてる。

まず、乾電池1本で動いたらいいなと思ったので、1.4Vを3.3Vに昇圧する回路を組んで駆動させてみたら、昇圧回路がどうもうまくいかなくて、やたら電気食う感じだった。昇圧回路の調整を別途やれば乾電池1本でもいい感じになるかもしれないけど、実際ブレッドボードで組んでみたら結構体積も食う感じになってしまったので、そもそもこの方法を諦めた。

じゃあリチウムコイン電池を使うことを考えよう、と思った。リチウムコイン電池なら1個で3V出せる。ただ、あまり電流を流すことができなくて、標準で 0.2mA 程度に抑える必要がある。消費電力を減らす工夫はしてるつもりだけど、スピード調節をADCにしたのでボリュームに常に電流が流れるとか (10kΩなのでこれだけで0.3mA流れる)、もうちょっと頑張る必要がありそうだった。

まず、ADC は1秒ごとに行うようにコードを変えて、そもそも頻度を減らした。また、ボリュームに電圧をかけるのも、ADCが行われるときだけにした。これはピン1個を出力にして、VCC の代わりにそこに繋いでる。VCC とピンの出力電圧は厳密には違うので、ADCの精度は落ちるけど、そもそも安定してない電池駆動だし、相対値だけがとれればいいのでまぁいいかな、という気がする。

それでだいたいアイドル時に0.3mA程度まで下がった。しかしこれ以上思いつかないので、とりあえずクロックを下げてみて挙動に問題がないか試すことにした。ATTiny13A の場合、内蔵クロックは 9.6MHz, 4.8MHz, 128kHz とそれらを8分周したものが選べる。なので 4.8MHz を8分周した600kHzで動かしてみると、思ったより変なことにならなかった。これでアイドル中はほぼ0.2mA未満に。

じゃあ 128kHz だとどうだろう、ということでやってみたら、

 bad AVRISPmkII connection status: Unknown status 0x00

とかでるように…… たぶんクロックを下げすぎたせいで ISP の書きこみのクロックを読めてないのかな……

うーん困ったと思っていたら avrdude に転送スピードを下げるオプション (-B) があったので、-B 100 ぐらいにしてやったらいけた。しかし書きこみ速度がだいぶ遅い。

コードを全体的に書きなおさないと 128kHz でバグってて動かない感じだけど、軽く試した感じだと、アイドル中で0.09mAぐらい。キーイング中で0.19mA。パワーダウンは変わらず0.6uA程度。コーディングが面倒になった割にはそんなに減らない。ベースの消費が無視できないほどクロックの支配率が低くなってるせいかな。

仕様から

• VCC=3V, f=128kHz
  • idle: 0.01mA
  • active: 0.04mA
  • power down: 0.00015mA
  • ADC: 0.225mA
  • Timer0: 0.002mA
  • pull-up: 0.08mA

• キーイング中は pull-up + active + timer0 + FET GS接地抵抗(440k)電流 = 0.122mA が最低でも必ずかかる
• アイドル中は idle + timer0 = 0.012mA
• ADC中は active + ADC + timer0 = ボリューム電流 = 0.567mA
• パワーダウン中はクロックに関係なく固定で 0.15uA
  • 比較すると実測値が結構高いけどなんでだろう

• 瞬間最大電流
• キー同時押し pull-up * 2 + active + timer0 + FET GS接地抵抗(440k)電流 + ADC
  • 0.7338mA

マイコンプログラミングとか、黙って Arduino やっとけハゲという感じではあるんだけど、Arduino の言語がどうも好きになれなくて使ってない。CっぽいけどCじゃない、でもC、みたいなのがなんとなく嫌だなと感じてる。それは置いておいても Arduino は素晴しいと思います。

Arduino も AVR を使っているし、結局 Arduino 頑張ろうとすると AVR のスペックを理解する必要があるので、じゃあ AVR でいいか、という感じになる (安いし)。

Arduino は、開発環境も含めたエコシステムが魅力で、そこがすごくいいと思うけど、自分みたいに CUI で vim で書いて Makefile でコンパイルして書きこんで gdb でデバッグするみたいのが好きな人間だと、少し魅力が薄れてしまうように思う。

IDE はあればあるで便利で良いんだけど、Makefile と gdb を使ってやっていれば、マイコンプログラミング以外のときにもその知識が生かせて嬉しいと思う (IDEの操作の知識はほかに生かせない)

浮動小数点演算を使ったとき、-lm を付けないとバイナリサイズが巨大化する問題がある。-lm をつけない場合、デフォルトの (libgccの?) 浮動小数点関数がリンクされるけど、avr 用には高効率なものが libm に実装されている。libgcc だと 3k -> libm だと 1k ぐらいのインパクトがあるので必ず libm を使うようにしたい。

とはいえ、ちゃんと理解してないと libm にリンクされない……

結論からいうと以下じゃないとだめだった。

$(COMPILE) -o main.elf $(OBJECTS) -lm

以下のようだとうまくいかない。

$(COMPILE) -lm -o main.elf $(OBJECTS)
$(COMPILE) -o main.elf -lm $(OBJECTS)

というのも、リンカは、引数を順番に読みこんで、読み込み中のファイルに今までで未定義のシンボルがあったとき、それを解決する、という挙動をするらしい (なんとなく逆に、先に定義して解決していくもんだと思ってた)。

なので、先に -lm を指定しても、その時点では未定義のシンボルが何もないので何の意味もない。

gcc のオプションに -v (verbose) を渡すと、最終的に ld (collect2) に渡される引数がわかる。

うまくいく場合は main.o -lm -lgcc -lc -lgcc というふうになってる。main.o で使ってるシンボルが -lm で解決されて、あとまだ足りないのは -lgcc とかで解決される。-lgcc が2回出てくるのは、-lc が -lgcc を使ってるからかな。よくわかんない。

割込みかけるように設定しているにも関わらず、それに対する処理を書いていないと、sei() を呼んだあと、割込みが発生するときに落ちてリセットがかかる。

sei() が呼ばれるまでは問題ないので、コメントアウトでデバッグしていると超ハマる。

USB-シリアルポートアダプタ (RS-232C) は前に買っていたけど、RS-232C は正負 -12~+12 で1/0を表現うるので、マイコンのロジックレベル(0 or VCC)とは違っていて、そのままではマイコンと接続できない。

調べてみると、RS232トランシーバー (ドライバ) ICというのがあって、それを使えば簡単にレベル変換できることがわかった。有名なのは MAX232 というやつみたいだけど、ほぼ同じインターフェイス(ピンアサイン)でビットレートや電源電圧が違うやつがいろいろとあるみたいだ。

今回は ICL3232CPZ という 3.3V〜5V で動いて、なおかつ外付け部品が 0.1uF 5個だけというのを選んで作った。

繋いで以下のような、ボーレート 19200 で吐き出すコードを書いてみた (チップは ATTiny2313、レジスタ名がチップによって違うので、チップ変えるとそのままでは動かない)

#include <avr/io.h>
#include <string.h>
#include <util/delay.h>

#define clear_bit(v, bit) v &= ~(1 << bit)
#define set_bit(v, bit)   v |=  (1 << bit)

static inline void uart_putchar(char c) {
	loop_until_bit_is_set(UCSRA, UDRE);
	UDR = c;
}

static inline void uart_puts(char* string) {
	unsigned int len = strlen(string);
	unsigned int i;

	for (i = 0; i < len; i++) {
		uart_putchar(string[i]);
	}

	uart_putchar('\r');
	uart_putchar('\n');
}

void usart_init(unsigned short baudrate) {
	unsigned int d = ((F_CPU + (baudrate * 8L)) / (baudrate * 16L) - 1);
	UBRRL = d;
	UBRRH = d >> 8;

	UCSRB =
		(1<<RXCIE) | // RX Complete Interrupt Enable
		(1<<TXCIE) | // TX Complete Interrupt Enable
		(0<<UDRIE) | // USART Data Register Empty Interrupt Enable
		(1<<RXEN)  | // Receiver Enable
		(1<<TXEN)  | // Transmitter Enable
		(0<<UCSZ2) | // Character Size
		(0<<RXB8)  | // Receive Data Bit 8
		(0<<TXB8)  ; // Transmit Data Bit 8

	UCSRC =
		(0<<UMSEL)            | // USART Mode Select: 0=Asynchronous Operation, 1=Synchronous Operation
		(0<<UPM1)|(0<<UPM0)   | // Parity Mode
		(0<<USBS)             | // Stop Bit Select
		(1<<UCSZ1)|(1<<UCSZ0) | // Character Size (with UCSRB)
		(0<<UCPOL)            ; // Clock Polarity
}


static inline void setup_io () {
	usart_init(19200);
}

int main(void) {
	setup_io();


	for (;;) {
		uart_puts("Hello, World");
		_delay_ms(1000);
	}
}

PC 側では、この USB シリアルポートアダプタの場合、/dev/tty.usbserial-FTB3L9UG というようなファイルができるので、これを指定して GNU screen の window を1つ作ってる。変なことしてないのでボーレートを指定するだけでいける。

screen /dev/tty.usbserial-FTB3L9UG 19200

これで RX/TX があるチップならかなりデバッグが捗りそう。

AVR は思ったより難しくなくて結構拍子抜けするぐらいだけど、今までやったことがない分野なので適度に難しい問題がたくさんころがっていてめちゃくちゃ楽しい。久しぶりに深夜3時ぐらいまでひたすらコーディングするとかしてしまった。

USB デバイスとか「作れない」という状態だとほんと全然アイデアが沸いてこないんだけど、やってみると結構「ああ、あれもできそう」「あれができたら楽しそう」みたいなのがでてきていい。

ウェブアプリのように誰かにすぐ使ってもらえるものを作るという感じではないのがもったいない感じだけど、なんか別に、自分そういうのなくてもいいなって感じなので良いです。

僕みたいな普段ウェブアプリみたいなかなりレイヤーが上のほうのことやってる人間でも、最近だとアセンブリとか全く書かなくてもよくていい。

ちょっと考えてみた感じ、何も持っていない状態からの AVR におけるとりあえずの開発に必要なのは以下あたりかなあと思った。

• プログラムの一般的な知識 (ウェブとか関係なく普通の)
• AVR ライター (純正 AVR ISP Mark II も別に高くないので純正のを買うのがよさそう)
• ブレッドボード・ブレッドボード用のジャンパピン集
• ピンヘッダ・オス・メス
• ミノムシクリップコネクタ
• レインボーフラットケーブル (裂いて使えるし、複数の線が纏められるし超便利)
• マイコンチップ (ATTiny2312=150円ぐらい, ATmega168P=200円ぐらい)
• 抵抗E12系一通り10本ずつぐらい
• コンデンサE6系一通り10本ずつぐらい (デジタルだと100uF以下ぐらいでよさそう)
• LED数個 (デバッグその他に必ず必要)
• 電源
  • 安定化電源、なければ電池ケース (エネループなら4本直列=4.8V程度のもの)
  • あるいはUSBから5Vとってもいいかもしれないけど、ポリスイッチ(何度も使えるヒューズ)を入れたほうがいい
• テスター (必須)

そんなに必要なものない気がしたけど、何もなしからだと結構ある。1万ぐらいあればぎりぎり集められるかな。

ダイオードだけ入れて対処したのがどうもひっかかっていて、やはりまずい気がするので、やめた。リグ側から電圧がかかっていないとき、こちら側から電圧がかかってしまうのが気持ちわるい。

リグ側からかかっている電圧を使ってFETをスイッチし、接続されているときだけ、特定のプルアップしているピンをグラウンドに落とすような感じにした。スイッチを使わず、実際に接続されているかどうかを見れるようになったので、ジャックは挿しこまれているけど、リグの電源がついていない場合なんかには機能的にも前より便利になった。

素直にこうしとけばよかった。これでそんなにまずいことはない、と思う……

懸念していた点が解消されたので、ブレッドボートをやめてユニバーサル基板に実装した。

今まで、回路図からユニバーサル基板に落とすときはいきあたりばったりでやっていたけど、今回はプリント基板作成ツールを使って事前に実装を考えてみた。

いろいろ、プリント基板を作れるソフトウェアはあるんだけど、どれも微妙に使いづらくて難しい。自分だけの最高の部品ライブラリを作ってからじゃないと基板作成ができないとか、そういうアレがある……

今回はいくつか試した結果、Fritzing という OSS の、プリント基板ビューを使ってやってみた。ビューがいくつかあって楽しいソフトウェアなんだけど、やはりこれも回路図やブレッドボートビューを使う場合、ライブラリを作るあげるのが面倒くさい。ただ、配線を試行錯誤やる程度なら、別の部品を代用して使っても問題ない。

しかし配線を試行錯誤するのも結構つらくて、選択したくないものが選択されてしまうことがものすごく多い。そのためのロック機能がある、と思いきや、ロックをかけても選択できてしまうので意味がない。結果、一切あたり判定が存在しなくて動かすことができない部品とかが存在する (一度かぶっているのをとれば移動できるけど)。かなり辛い。