ジャンル不定の日記です。

LinuxでAVR

ファームを更新した中華USBaspを使ってLinuxでAVRの書込みできました。
作ったのは、hello world的な簡単なコード。
母艦環境はArch Linux。

先日の記事に書いたが、
母艦にインストールしたのはavrdude,avr-gcc,avr-binutils,avr-libcの4パッケージで全部公式リポジトリにある。
avr-gccでC言語のコードをAVR用にコンパイルして、avr-binutilsに含まれるavr-objcopyコマンドでavrdudeで書き込めるihex形式のファイルに変換する。

今回のコード。
main.c
#include <avr/io.h>

int main(){
    DDRB=0b00000000;
    DDRD=0b01111111;
    while(1){
        PORTD=PINB;
    }
}
PC用プログラミングの"hello world"ではその名の通り"hello world"と文字を出力するのが一般的だが、
文字出力のできないマイコンの入門には出力確認としてLEDを光らせる。
AVR入門のコードではLEDを点滅させるコードが多いと思うのだが、入門用プログラムにはタイマーを使った"点滅"などさせずに"点灯"だけの方が良いんじゃないかと思う。
が、固定で電圧を出力するだけだとマイコンの処理結果で電圧が出てるのかわからないので、特定ピンの入力状態によって対応ピンに出力するコードにした。

#include <avr/io.h>
は、IOピン関連のライブラリをインクルード。

今回使ったAVRはDIPパッケージのATtiny2313で、

ピン配列はこのようになってる。
20ピンのうち、20番のVCCと10番のGNDはマイコン電圧用なので入出力には利用できない。
A,B,Dの3グループ(ピン数の多いマイコンではCグループもある)に分けられており、
PA0-2 = 3本
PB0-7 = 8本
PD0-6 = 7本
が入出力用に利用できる。
このうち、PA2,PB7,PB6,PB5の4本はマイコンへのファームウェア読み書き用に使わず空けておきたい。
PDは全部使えるので、PB0-6の入力がhighなら対応する番号のPD0-6の出力をhighにするプログラムにした。

今回のコードの、
DDRB=0b00000000;
DDRD=0b01111111;
は、ピンを入力用にするか出力用にするかの設定。
DDR[A,B,D]に値を設定するとピンを入力用にするか出力用にするかを切り替えられるが、
値を2進表記(0bから始まる数値)するとわかりやすい。
2進表記時の最下位ビットが各グループの0番ピン。
対応位置が0なら入力用で、1なら出力用になる。
PB0-7の8本は全部入力用にして、PDは0-6番の7本なので最上位を0にして桁合わせした。普通の10進数と同じで最上位が0なら無意味。

while(1){
    PORTD=PINB;
}
の部分は、
状態の変化に応じてLEDを切り替えるために無限ループにした。
PORTDはPDの出力で、PINBはPBの入力状態。
PDにPBの状態をそのまま代入したが、特定ピンを対象にコードを書きたいならDDR[A,B,D]と同じで2進表記するとわかりやすい。


で、回路の方。

PDグループのピンの出力を同じ番号のPBグループピンの入力状態に対応させるプログラムなわけだが、
マイコンのピン配列的にやりやすそうに見えた4番ピンだけを使うようにした。
まず、PD4にLEDを繋いで、電流制限のために300Ωの抵抗を入れた。
PD4に対応するPB4に電圧をかけるわけだが、PB4と電源との間にON/OFFできるスイッチとしてジャンパを入れた。
そして、PB4は大きい抵抗を挟んでGNDに繋いだ。
PB4をGNDに繋がない場合、スイッチONなら電源電圧がかかるので入力状態がhighだが、スイッチOFFで電源と断線している時にどことも繋がっていないので電位が不明。
スイッチOFF時に確実にlow(0V)にするためにPB4はGNDと繋ぐ。
PB4とGNDを直結してしまうとスイッチON時に電源からGNDにショートしてしまい大電流が流れてしまうので、スイッチとなるジャンパとGNDの間に大きい抵抗を入れる。
この時の抵抗がプルダウン抵抗という。


コードと回路が出来上がったわけだが、avr-gccでコンパイル。
$ avr-gcc -mmcu=attiny2313 -Os -c main.c
main.oが出力される。
-mmcuオプションでターゲットマイコンの種別を指定する。
-cオプションでコンパイルされる。
-Oオプションで最適化ができるのだが、-Osだとサイズが小さくなるように最適化される。
-Osつけた場合とつけなかった場合で、今回のコードだけでも.hexファイルに140byteと50byteくらいの違いが出る。

gccの出力したmain.oを、avr-objcopyコマンドでavrdudeで書き込めるihex形式に変換する。
$ avr-objcopy -I elf32-avr -O ihex main.o main.hex
-Iオプションで入力ファイル形式。
-Oオプションで出力ファイル形式。
オプションに続けて入力ファイルと出力ファイル名。
gccの出力したmain.oはelf32-avrという形式らしい。

avrdudeコマンドでマイコンのflash領域に書き込み。
$ sudo avrdude -c usbasp -p t2313 -U flash:w:main.hex -B 10
AVRプログラマはUSBasp化した中華のやつだが、-Bオプションをつけて速度を落とさないとエラーとなった。
-Bの値は大きい方が遅いぽい。


<実験>

OFF状態

回路図記載のPB4とPD4以外に、PA2,PB5,PB6,PB7に線が繋がってるが、USBaspと繋いだままなので。
VCC(5V)とGND(0V)もUSBaspと繋いだままで、そこからマイコンに給電。
赤いケーブルが1個抜けてるが、これがジャンパでスイッチOFF状態。


ジャンパをPB4につないだらPD4に繋いだLEDが光った!


というわけで実験成功。

こんなLED光らせるだけのプログラムでは全く実用性がないが、
USB接続のPC用デバイスを自作したり、PCから制御できる特殊デバイスを作る技術を得るために、
クリスタルが届いたらV-USB系の実験をやろうと思ってる。

あと、USBの通信は不要で実用的なものとして、USB電源でのニッケル水素充電と、
先日届いたステップアップDCコンバータでニッケル水素電源での5V(USB)出力の制作を考えてる。

ファーム書き換えできたぽい

昨日届いた中華製ニセUSBaspだが、またファーム更新試したら成功したぽい。
まだ書き込み確認してないが、少なくともファームの書き換えは成功してる。

まず、昨日はハンダでのショートに失敗した可能性があると思ってたので、
ジャンパホールに通せる針金を調達して試そうと思って近所のホームセンターで0.28mmの真鍮針金を買った。(ステンも0.28mmからだったので)
だが、昨日の失敗でホールがハンダで埋まっており、0.28mmの針金の熱では貫通できなかった・・・
というわけで、また結局ハンダでw


で、一度ハンダで固定できて、試しにAVRWRTで検出してみたらATmega88と認識した!
ここの神は外見同じものだが、ATmega8と言ってるが、自分のはAVRWRTの自動検出でATmega88。
どうも複数のタイプが存在するようで、ATmega8用のファームではダメぽい・・・
というわけなのだが、上記ページのコメント欄にATmega88版のファームがあった。

ATmega88のファームで書き込みをしようとしたのだが、
AVRWRTでflashの読み込みは出来るのだが書き込みが出来ない・・・
それで調べたり試行錯誤してるうちに、ジャンパした線が外れちゃったりして苦労したのだが、
AVRWRTの速度を標準の1Mhzから500kHzに変更したら書き込めた。
ヒューズビットは初期状態で0xDD 0xFFだったが、変更の必要なしと思うので変えなかった。
ロックビットとやらが設定されていたが、ファーム更新したら変わった。


ファーム更新してLinuxにつないでlsusbしたらデバイスが出てこなかったのだが、
抜き差ししてるうちにジャンパ線が外れちゃって、そしたら認識したwUSBaspはジャンパはずさないと認識しないぽい?
lsusbの結果に、
Bus 003 Device 003: ID 16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb
が出てた。
IDがUSBaspの物になってる。

書き込めるAVRをまだ繋いでavrdudeでの読み書き試してないが、
sudo avrdude -c usbasp
でIDのエラーはでないのを確認した。
後ほどATtiny2313つないで試してみる。

ATmega644pでUSBaspを作ろうと考えているのだが・・・

中華AVRプログラマがニセUSBaspだったんで、ATmega644pでUSBaspを作ろうと考えているのだが、情報まとめ。

USBaspを書き込む際にAVRのヒューズというのもプログラムと別に書き込む必要があるようなのだが、
USBasp標準のATmega8用で、
ヒューズ上位バイト: 0xC9=0b11001001
ヒューズ下位バイト: 0xEF=0b11101111
となっている。

ATmega8の初期値は、
ヒューズ上位バイト: 0b11011001
ヒューズ下位バイト: 0b11100001
となっているらしい。

データシートを見ると、
CKOPT: 1→0
CKSEL3-0: 0001→1111
に変えているぽい。

CKSEL3-0の値によってクロック元が変わるようで、
クロック種別CKSEL3-0
外部発振子1111-1010
外部発振子(低周波)1001
外部RC発振1000-0101
内蔵RC発振0100-0001
外部信号0000
とのこと。

CKOPTの意味はクロック種別により変わる。
元の設定は0001で内蔵RC発振の範囲だが、内蔵RCで1MHzの設定らしい。内蔵RCの場合はCKOPTは常に1。
1111は外部発振子の範囲だが、CKOPTとCKSEL3-1の組み合わせにより周波数範囲が変わり、CKOPTが0でCKSEL3-1が111の組み合わせは1.0MHzから上限なしの設定らしい。
外部発振子の際のCKSEL0は、SUT1,0との組み合わせで起動時間遅延設定となるらしい。


ATmega644で使おうとしているわけだが、ATmega644の初期値は、
ヒューズ上位バイト: 0b10011001
ヒューズ下位バイト: 0b01100010

CKOPTは無く、CKSEL3-0はATmega8と同じく下位バイトの下位4bit。
ATmega8と同じでCKSEL3-0の値でクロック元が決まるが、範囲がちょっと違う。
クロック種別CKSEL3-0
外部発振子(低電力)1111-1000
外部発振子(全振幅)0111-0110
外部発振子(低周波)0101-0100
128kHz内部発振0011
内蔵RC発振0010
外部信号0000
予約0001
とのこと。

初期値は内蔵RCで、内蔵RCの範囲が一つしか無く最大の8MHzになるようなのだが、
ヒューズ下位バイト最上位ビットのCKDIV8が初期値の0だとCLKPR(クロック前置分周レジスタ)を設定することで分周することが出来るらしい。
CKDIV8が0にされるとCLKPRは0011の8分にリセットされ、初期値もそうで出荷時のクロックは8MHzが8分されて1MHzらしい。
CKDIV8が1にされるとCLKPRは0000になるとのこと。
この機能使うと最高周波数以上の発振子を使うことも出来るぽいようなことが書かれてる。

外部発振子は低電力モードと全振幅モードがあるが、低電力だとノイズの影響を受けやすいらしい。
全振幅モードの場合のCKSEL0は、ATmega8と同じくSUT1,0との組み合わせで起動時間遅延。
全振幅モードのCKSEL3-1は011固定で0.1-20MHzとのこと。
全振幅にした方が無難かな?


というわけなので、元のATmega8用のヒューズが周波数関連しか設定されてないので、ATmega644用にするにはヒューズ上位バイトはそのままで下位バイトを、
CKDIV8 0→1
CKSEL3-0 0010→0111
下位バイト全体 0b01100010→0b01100010
にすれば良さ気かな?


USBaspの配布ファイル内にはバイナリが入ってるが、ATmega8用とATmega88用で別のバイナリが用意されてるので、
コンパイルもしないとダメぽい。
コード内にもターゲットデバイスを設定するような箇所があるのを確認したが、ターゲットデバイスの設定以外は変更しないで良さ気かな?

USBaspの回路はUSBtinyと同じ感じになっているが、V-USBみたいにツェナーダイオードじゃなくて2連順方向ダイオードで平気かな?
マイコン自体は5V動作させたほうが良いのかな?


ってな感じ。
V-USB派生のAVR-CDCは内部発振8MHzのATtiny45でクリスタル無しで動作するらしいが、クリスタルなし化は難しいだろうしクリスタル届いてから試す。

中華USBaspがパチもんだった・・・

今日はeBayで買って届いたUSBaspでLinuxでAVRプログラミングしようとして、
テストコード書いてavrdudeで書き込み・・・

のはずが、avrdudeで認識しない・・・
というわけで、ずっとハマってた。


まず、Arch Linuxの公式リポジトリから「avr」で検索すると、それっぽいのは、
avrdude,avr-gcc,avr-binutils,avr-libc,avr-gdb,simavr
辺りが出てきた。
avrdudeがUSBaspというプログラマに対応しているのを確認して購入したのだが、書き込み用に必要。
avr-gccでコンパイルが出来て、avr-binutilsとavr-libcも書き込み用ファイルの作成には必要ぽい。
avr-gdbとsimavrはデバッグ用ツールぽいんで今回は入れなかった。

avr-gccは、
avr-gcc --help
でヘルプが見れるが、
avr-gcc -mmcu=attiny2313 -c main.c
でmain.oが作成される。
-mmcuオプションでターゲットマイコンの種類を渡して、-cオプションでコンパイル、最後にコードファイルって感じぽい。
avr-gcc -mmcu=attiny2313 -Os -c main.c
と-Osオプションをつけるとサイズが小さくなるように最適化されるとのことだが、avr-gccが出力する.oファイルはむしろ大きくなったんだが、書き込み用の.hexファイルに変換したら、
オプション無しで140byteがオプションありで50byteに減ったんで効果でかいぽい。

avr-gccの出力ファイルはelf32-avrという形式のようで、そのままではavrdudeで扱えないらしく、
avr-objcopy -I elf32-avr -O ihex main.o main.hex
でavrdudeで書き込むことができるihexという形式に変換できるぽい。
avr-objcopyはオプション無しで実行するとヘルプが出る。

avrdudeの使い方はオプション無しで実行するとヘルプが出るが、
-cオプションでのプログラマ指定と-pオプションでターゲットマイコンの指定が必要ぽい。(-pは自動認識できる?)
avrdude -c 非対応文字列
とすると対応しているプログラマの一覧が表示され、usbaspのつもりだったんで、
avrdude -c usbasp -p 非対応文字列
とするとターゲットマイコンと指定する文字列の一覧が出る。

で、書き込むのは、
avrdude -c usbasp -p t2313 -U flash:w:main.hex:a
と-Uオプションでwをつけると出来るようなのだが、
avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor='www.fischl.de' product='USBasp'
こんな感じで怒られた・・・
lsusbコマンドでUSBデバイスを確認すると入手した中華AVRプログラマは「03eb:c8b4」だった。

というわけで解決法を探ったが、/etc/avrdude.conf でプログラマのベンダIDとプロダクトIDが指定できるぽかったので、
usbasp-cloneのusbvidとusbpidを03eb:c8b4に変更してavrdudeの-cオプションをusbasp-cloneにしてみたが、結局ニセusbaspの様でダメだった・・・


さらに解決法探してたが、
ここの人が同じ様にUSBaspのつもりが偽物で、usbasp化改造してた。全く同じものぽい。
自分もWindows用のAVRWRTを用意して改造しようとしたのだが、ジャンパする箇所がすごく小さい。ジャンパピンとか0.6mmの線じゃ入らない。
で、細い線買おうか迷ったがハンダでやることにした。

が、うまく行かなかった。AVRWRTで認識しない。
ランドが小さすぎてハンダが失敗してる気もするが、AVRWRTには給電機能がないので無理なのか?
とも思ったのだが、
ここの人AVRISPmkIIという給電機能のないプログラマで改造成功してる。
自分も同じようにMOSI,MISOをストレートで結線して別のところから5v給電したのだが・・・
中華プログラマが5Vではなく3.3Vで動いてるとAVRWRTでダメって可能性もあるか?
一応、中華プログラマのVCC出力が5Vなのは確認済みだったが、マイコン自体は3.3Vかもしれない。


まあ、今回は断念した。
中華プログラマはUSBaspではなくUSBISPというものらしく、Progispというツールで扱えるようなのだが、Windows専用ならAVRWRTでいいし・・・

とりあえずAVRWRTはインストールして使える状態になっていると思うのだが、やはりLinuxでやりたい。
別のUSBaspを購入するか、USBaspの回路を見たところクリスタルが到着すれば作れそうな気がするんで自作するか・・・
ただ、ATtiny2313では容量不足ぽくて、他のAVRはATmega644pってのしか持ってない。
オリジナルのUSBaspはATmega88かATmega8と記載があるが、644でいけるだろうか?
今回の偽USBaspはメタルジャケット付きで外見良い感じなのだが、むき出しでもICソケット付きの形状のは良いかなと思ってる。
別のプログラマを再購入するとまた偽物つかむ可能性が考えられるが、メタルジャケットではなくプラジャケットのやつはUSBaspとプリントされてるのが確認できるな。
値段同じようなもんだったしプラジャケットのにしておくんだった・・・

あと、今回は1pinのジャンパケーブルでつないだが、ピンアサイン確認しながらじゃないと厳しい。
多分合ってたと思うが、間違えて結線しちゃって失敗した可能性も否定できない・・・
逆指し不可の10ピンソケットと、6pin-10pinの変換ケーブルかコネクタも欲しいと思った。

まあ、金もないしクリスタルが届いてからUSBaspの自作を試みて、
購入の検討はその後にしようと思う。