✖
ARM Linux EABI の asm で動的メモリ確保
asm で動的にメモリ取得をしたいと思っても、malloc は libc の関数であるので、libc 依存しないなら自分で書かねばらない。
ということで、動的なメモリ確保を書いてみる。malloc を書く、というと荷が重すぎるので、単にプロセスが確保するメモリを動的に増やしていく、という大変基礎的な部分だけをやってみる。
brk
まず brk システムコールを試す。brk は program break の意味らしい。program break とはプログラムの data セクションの最後のことで、brk システムコールはこの data セクションの最後の位置を変更するというシステムコールになっている。これにより、プロセスにメモリを割りあてたり、OS に返したりできる。いわゆるヒープ領域というやつ。
program break の初期値
brk システムコールの引数は変更後の program break のアドレスになっている。つまり、初期値をどこかから持ってきて、自分で必要なサイズ分インクリメントして渡さなければならない。
libc レベルでは sbrk という関数も提供されていて、こちらの引数は単に increment (または decrement) する数だけを指定する。要は sbrk 内でアドレス計算をやってくれている。malloc では内部的には直接 brk を使わず sbrk を使ってメモリの取得開放を行っている。
最初この初期値は ld script で定義されている _end (bss セクションの最後を示す) でいいのかなと思い、
brk: .word _end
としてリンク時解決にしてみたけど、gdb でステップ実行しながら brk の返り値を確かめてみると、実際の program break と _end は違うことがわかった。
どこからもってくればいいのかと思ったけど、brk システムコールを 0 で呼んで、現在の brk アドレスを取得すればいいようだ (引数が不正だったり、メモリがない場合 brk は単に現在の break アドレスを返す)。ほんとかと思ったので libc のコードを読んでみたが、libc の sbrk 実装もそのようになっていたので由緒正しい。
実装
機能的には sbrk 相当のものなので sbrk という名前にしてある。r0 に欲しいサイズを入れて bl sbrk すると、要求したバイト数確保して、先頭アドレスを返す。
.macro sys_brk
mov r7, $0x2d
svc $0x00 /* supervisor call */
.endm
sbrk: /* uint size -> void* */
push {lr}
ldr r3, =brk /* r3 = prev_brk */
ldr r1, [r3]
cmp r1, $0x00 /* if prev_brk == 0 */
bleq sbrk_init
add r0, r0, r1
sys_brk
cmp r0, r1
blt sbrk_nomem /* curr_brk == prev_brk */
str r0, [r3] /* update heap_start */
mov r0, r1
pop {pc}
sbrk_init:
push {r0}
mov r0, $0x00
sys_brk
mov r1, r0
pop {r0}
mov pc, lr
sbrk_nomem:
mov r0, $0x00
pop {pc}
.section .data
brk: .word 0 mmap システムコール
プロセスに動的にメモリを割り当てる方法としては mmap を使う方法もある。mmap の匿名マッピングは単に指定したサイズの連続した領域を確保する。ある程度大きいメモリを確保する場合はこちらのほうが管理が楽みたい。glibc の malloc は 128KB 以上一気に確保しようとすると mmap を使うらしい。
mmap のデメリットはページサイズ単位でしか割当られないことで、1KB だけ欲しい場合でも4KB 程度は割当される。以下の例では 8byte だけリクエストしているが 4096バイトまでは書きこめ、4097バイト目に書こうとすると Segmentation fault になる。
mmap の返り値もエラーの場合は負の数が返るのだけれど、最上位ビットが立っていても有効なメモリアドレスという場合もあるので、単に負かどうかでは判定できない。なんかよくわからないけど、-4096よりも大きい場合だけエラーとして扱いのがセオリーっぽい？
PROT_NONE = 0x00
PROT_READ = 0x01
PROT_WRITE = 0x02
PROT_EXEC = 0x04
MAP_ANONYMOUS = 0x20
MAP_PRIVATE = 0x02
.macro sys_mmap
mov r7, $0xc0 /* sys_mmap_pgoff */
svc $0x00 /* supervisor call */
.endm
.macro sys_munmap
mov r7, $0x5b
svc $0x00 /* supervisor call */
.endm
main:
/* mmap */
mov r0, #0 /* start */
mov r1, #8 /* length */
mov r2, #PROT_READ /* prot */
orr r2, r2, #PROT_WRITE
mov r3, #MAP_ANONYMOUS
orr r3, r3, #MAP_PRIVATE /* flags */
mov r4, #-1 /* fd */
mov r5, #0 /* page offset */
sys_mmap
cmn r0, #4096 /* if (r0 > -4096) */
rsbhs r0, r0, #0
blhs error
mov v1, r0
/* write 4096 bytes (SEGV on 4097) */
mov r2, r0
ldr r3, =4096
1:
mov r0, $0x2e
strb r0, [r2], $0x01
sub r3, r3, #1
cmp r3, #0
bne 1b
mov r0, $0x01
mov r1, v1
mov r2, #4096
sys_write
mov r0, v1 /* start */
mov r1, #8 /* length */
sys_munmap
mov r0, $0x00 /* set exit status to 0 */
sys_exit
error:
cmp r0, $0x00
moveq r0, $0x01
sys_exit brk か mmap か
malloc はどっちも使っているようだけど、いまいち brk を使うメリットがわからない。
- 小さいデータの場合 brk で段階的に伸ばしてシステムコール呼ぶ回数を減らすほうがよい?
- mmap である程度メモリ確保しちゃえばいいんじゃ
- メモリ再割当のコストが減らせる?
- 足りなくなったら mremap したらだめ? mremap は Linux 限定
- mmap が返すアドレスは毎回適当なので、管理コストが増える?
- brk なら全部必ず連続するのが便利?
よくわからなかった。
glibc 以外の malloc 実装を軽く調べた感じだと、OpenBSD は mmap しか使わず、jemalloc もオプションで指定しない限り mmap だけを使うようだった。
ARM Linux EABI の asm で簡単な ls を作る
単に実行したディレクトリのファイル名を表示するだけのプログラムを asm で書いてみる。
普段全くディレクトリエントリの構造を意識しないけど、システムコールを直接呼ぼうと思うと意識せざるを得ない。
使うシステムコールは以下の通り
- open
- getdents
- close
- write (表示用)
- exit
libc レベルだと opendir/closedir というふうにディレクトリ対象の open 操作は分かれているので、システムコールもそうなのかと思っていたけど、そうではなく普通の open/close で統一されている。ディレクトリ内容を読むには readdir というシステムコールもあるが、getdents が現代版らしいので、最初からこちらを使う。
getdents
open/close はともかく、getdents の挙動を理解するのに苦労した。
struct linux_dirent {
unsigned long d_ino; /* Inode number */
unsigned long d_off; /* Offset to next linux_dirent */
unsigned short d_reclen; /* Length of this linux_dirent */
char d_name[]; /* Filename (null-terminated) */
/* length is actually (d_reclen - 2 -
offsetof(struct linux_dirent, d_name)) */
/*
char pad; // Zero padding byte
char d_type; // File type (only since Linux
// 2.6.4); offset is (d_reclen - 1)
*/
} 以上のような構造体を渡したバッファに書きこんでくれるのだけれど、なんで構造体の後ろのほうコメントアウトになってるの？って感じ。よく定義を読んだら d_name[] は文字列へのポインタではなく文字列そのものなので、ここは可変長になっていて、コメントアウトされている分は d_reclen から実際の位置を計算する必要があることがわかる。また、このシステムコールはバッファが許す限りこのエントリを連続で書いてくるので、d_reclen をポインタに足しながら全部読み出す必要がある。
挙動さえ理解できれば難しくないので、とりあえず C レベルで1回書いたほうが早かったかもしれない。
ソートとかしていないので、表示される順番は ls -1f したときと同じになる。
errno
libc レベルだと errno というグローバル変数にエラー番号が入るが、システムコールを直で呼ぶ場合、r0 にエラー番号の符号を反転させた値が返ってくる。
つまり、libc はシステムコールから負の値が返ってくると、符号を反転して errno にセットして、C レベルの関数では -1 を返すという挙動をするみたい。
コード全文
/*#!as --gstabs+ -o ls.o ls.s && ld -o ls -e _start ls.o && objdump -d -j .text -j .data ls && ./ls
*/
.global _start
.macro sys_exit
mov r7, $0x01 /* set system call number to 1 (exit) */
svc $0x00 /* supervisor call */
.endm
O_RDONLY = 0x0000
.macro sys_open
mov r7, $0x05
svc $0x00 /* supervisor call */
.endm
.macro sys_write
mov r7, $0x04
svc $0x00 /* supervisor call */
.endm
.macro sys_close
mov r7, $0x06
svc $0x00 /* supervisor call */
.endm
.macro sys_getdents
mov r7, $0x8d
svc $0x00 /* supervisor call */
.endm
.section .text
_start:
bl main
/* not reached */
mov r0, $0xff
sys_exit
main:
/* open */
ldr r0, =current_dir
mov r1, #O_RDONLY
sys_open
cmp r0, $0x00
rsble r0, r0, #0
blle error
mov v1, r0
1:
/* getdents */
mov r0, v1
ldr r1, =dentry_buffer
mov r2, #dentry_buffer_len
sys_getdents
cmp r0, $0x00
beq 2f
mov v2, r0 /* read bytes */
rsblt r0, r0, #0
bllt error
ldr v3, =dentry_buffer
3:
ldrh v5, [v3, #8] /* linux_dirent d_reclen */
mov r0, $0x01
add r1, v3, #10
sub r2, v5, #12
sys_write
mov r0, $0x0a
push {r0}
mov r0, $0x01
mov r1, sp
mov r2, #1
sys_write
pop {r0}
sub v2, v2, v5 /* len -= d_reclen */
add v3, v3, v5 /* buffer += d_reclen */
cmp v2, $0x00
bne 3b
b 1b
2:
/* close */
mov r0, v1
sys_close
mov r0, $0x00 /* set exit status to 0 */
sys_exit
current_dir:
.asciz "."
.align 2
error:
cmp r0, $0x00
moveq r0, $0x01
sys_exit
.section .bss
.align 2
buffer: .skip 4096
dentry_buffer:
.skip 4096
dentry_buffer_len = . - dentry_buffer
ARM Linux EABI の asm で getenv する
asm だけで getenv をしてみようとしたらかなり大変で、本当はもっと先の目標があったけど、遥か遠いので、とりあえず getenv しただけで一旦まとめる。
getenv は何をするか？
そもそも、Linux のプロセスイメージをちゃんと知っていないといけない。環境変数ってどこからくるんだ？ というところからして、全く知らなかった。getenv とかシステムコールになってて呼んだら出てくるのかと思っていた。
このページがわかりやすかった。
結局以下のようにすれば r0, r1, r2 それぞれに argc argv environ が入るようになる。sp にスタック位置が起動時から入っているので、そこを基準にオフセットを計算するみたい。スタックはアドレスが小さくなるほうに伸びるけど、それの逆方向に argc やら何やらが入っている。
_start:
mov lr, #0
/* r0 = argc */
ldr r0, [sp]
/* r1 = argv */
add r1, sp, $0x04
/* r2 = argc * 4 (skip argv) */
mov r3, $0x04
mul r2, r0, r3
/* r2 += 4 (skip null word) */
add r2, r2, $0x04
/* r2 += offset (ok this is environ) */
add r2, r1 gcc で普通にコンパイルすると libc がこのへんうまいことやってくれているんだなあと思って libc の大事さを感じる。
そして getenv を実装するために最低でも strncmp 的なものが必要だし、strlen もないと出力するとき困る。
environ は文字列の配列なので、レジスタに今何がロードされているのか意識するのがこんがらがってつらい。LL とか触っていると、文字列の配列は文字列のリストにしか見えないので、しばしば実際は文字列のアドレスの配列になっていることを忘れてしまう。
ARM の場合さらに、遠いアドレスにあるメモリを直接参照できないので、さらに1段参照が増えていたりしてややこしい。オペランドの = を使うとそのへんあまり意識せずにすむようになって便利 (遠い場合は自動的に近くに値プールをつくってくれるらしい)
デバッグ方法
ちょっと複雑になってくるともはやデバッガのステップ実行なしではつらい。gdb が使えるのでつかう。as に --gstabs+ オプションをつけてコンパイルしたバイナリを gdb sketch とかで普通に起動してやればよい。レジスタの値は info registers で見ることができる。
$ as --gstabs+ -o sketch.o sketch.s && ld -o sketch -e _start sketch.o $ gdb sketch (gdb) b main Breakpoint 1 at 0x80ac: file sketch.s, line 46. (gdb) r Starting program: /home/pi/sketch/sketch Breakpoint 1, main () at sketch.s:46 46 bl getenv (gdb) info registers r0 0x80c8 32968 r1 0xbefff734 3204446004 r2 0xbefff73c 3204446012 r3 0x101cc 65996 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0xbefff730 0xbefff730 lr 0x809c 32924 pc 0x80ac 0x80ac <main+4> cpsr 0x10 16
コード全文
/*#!as --gstabs+ -o sketch.o sketch.s && ld -o sketch -e _start sketch.o && objdump -d -j .text -j .data sketch && ./sketch
*/
.global _start
.macro sys_exit
mov r7, $0x01 /* set system call number to 1 (exit) */
svc $0x00 /* supervisor call */
.endm
.macro sys_write
mov r7, $0x04
svc $0x00 /* supervisor call */
.endm
_start:
mov lr, #0
/* r0 = argc */
ldr r0, [sp]
/* r1 = argv */
add r1, sp, $0x04
/* r2 = argc * 4 (skip argv) */
mov r3, $0x04
mul r2, r0, r3
/* r2 += 4 (skip null word) */
add r2, r2, $0x04
/* r2 += offset (ok this is environ) */
add r2, r1
/* save char** environ to global variable */
ldr r3, =environ
str r2, [r3]
/* r0 = argc, r1 = argv, r2 = environ */
bl main
/* not reached */
mov r0, $0xff
sys_exit
main:
/* getenv("USER") */
adr r0, USER
bl getenv
/* if "USER" is not in ENV */
cmp r0, $0x00
bleq error
bl puts
mov r0, $0x00 /* set exit status to 0 */
sys_exit
USER:
.asciz "USER"
.align 2
error:
mov r0, $0x01
sys_exit
strncmp: /* char* s1, char* s2, size_t len -> 1|0 */
stmfd sp!, {v1-v5, lr} /* save variable resistors and returning address */
mov r3, $0x00 /* result */
1: cmp r2, $0x00
beq 2f /* if (r2 == 0) goto 2 */
sub r2, r2, $0x01 /* len-- */
ldrb r4, [r0], $0x01 /* r4 = *s1++ */
ldrb r5, [r1], $0x01 /* r5 = *s2++ */
cmp r4, r5
beq 1b /* if (r4 == r5) goto 1 */
add r3, $0x01 /* r3++ (this function always returns 1 when the comparing fails) */
2:
mov r0, r3
ldmfd sp!, {v1-v5, pc} /* restore variable resistors and set pc to returning address */
strlen: /* char* str* -> uint */
mov r1, $0x00 /* r1 = result */
/* r2 = *str++ (ldrb = load byte, and r0 increment after) */
1: ldrb r2, [r0], $0x01
cmp r2, $0x00
addne r1, r1, $0x01 /* if (r2 != 0) r1++ */
bne 1b /* if (r2 != 0) goto 1; */
mov r0, r1
mov pc, lr
getenv: /* char* name -> char* */
stmfd sp!, {v1-v5, lr}
/* v1 = name */
mov v1, r0
/* v2 = strlen(r0) */
bl strlen
mov v2, r0
/* v3 = environ char** */
ldr v3, =environ
ldr v3, [v3]
1: /* if (strncmp(name, *environ, len) == 0) { */
mov r0, v1
ldr r1, [v3]
/* *environ != NULL */
cmp r1, $0x00
beq 2f
mov r2, v2
bl strncmp
cmp r0, $0x00
/* if (*environ)[len] == '=') { */
ldreq r0, [v3]
ldreqb r0, [r0, v2]
cmpeq r0, #'=
beq 3f
/* } */
/* environ++ */
add v3, $0x04
b 1b
2:
/* not found return NULL */
mov r0, $0x00
ldmfd sp!, {v1-v5, pc}
3: /* found and return address */
ldreq r0, [v3]
add r0, r0, v2
add r0, r0, $0x01 /* skip '=' */
ldmfd sp!, {v1-v5, pc}
puts:
stmfd sp!, {v1-v5, lr}
mov v1, r0
bl strlen
mov r2, r0
mov r1, v1
mov r0, $0x01
sys_write
mov r0, $0x01
adr r1, linefeed
mov r2, $0x01
sys_write
ldmfd sp!, {v1-v5, pc}
linefeed:
.byte '\n
.align 2
.section .bss
.align 2
environ: .word 0
ARM Linux EABI on QEMU
いい時代なので、実機がなくても qemu で環境をつくることができる。
qemu を入れる
brew install qemu
で入る
イメージを用意する
ここにある debian のイメージを例にすると、適当に必要なファイルをダウンロードするだけ
- vmlinuz-3.2.0-4-versatile
- initrd.img-3.2.0-4-versatile
- debian_wheezy_armel_standard.qcow2
起動
qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4-versatile -initrd initrd.img-3.2.0-4-versatile -hda debian_wheezy_armel_standard.qcow2 -append "root=/dev/sda1" -m 256 -redir tcp:2200::22
で起動させる。中から外のネットワークには出られるが中に繋ぐ方法がないっぽい？ので -redir tcp:2200::22 でポートフォワード的なことをしている。
ssh
ssh -p2200 root@localhost password: root
Debian だと開発ツールがデフォルトで入っていないのがうざいけど、しかたない
ref.
ngResource は何が便利なのか？
ngResource は単にAPIのラッパーという感じではなくて、JS でサーバ側のモデルとうまく同期するように作られている。
最も簡単な例だと以下のように使うが、Entry.get は XHR が完了する前に、とりあえず空のオブジェクトが返るようになっており、XHR の完了とともに破壊的に書きかえられる。これにより、entry の変更がすぐ全体に伝わるようになっている。
var Entry = $resource('/entry/:id');
$scope.entry = Entry.get({ id : 0 }); デフォルトで定義されている query/get/save/delete だけを見ると単に REST API のラッパーのように見えるが、独自のメソッドを追加するとより理解しやすいコードを書ける。
以下のコードは、デフォルトで下書き状態で生成される Entry オブジェクトを、後から publish 状態に変えるような挙動を想定している。単に $save() とかを使ってもいいが、専用のメソッドを生やすことでやりたいことを明確にできる。
var Entry = $resource('/entry/:id', {}, {
'publish': { method: 'PUT', params : { publish : 1 } }
});
$scope.entry = Entry.get({ id : 0 });
....
$scope.doPublish = function () {
$scope.entry.$publish(function () {
alert('entry published!');
});
} この独自に定義したメソッドの場合も XHR が完了すると、API のレスポンスで元の entry インスタンスは破壊的に変更がかかる。すなわち $scope.entry を改めて自分で更新する必要はない。Angular の場合、オブジェクトの変更がうまいことビューに反映されるようになっているので、これだけでビューの更新までかかるコードになっている。
ngResource とサーバ側 API とうまく協調させることで、自動的にビューの更新までできるようになる。
ngResource の挙動とサーバサイドのAPIのインターフェイスをあわせる方法は前に書いた。ngResource は定義方法がいまいちわかりにくいし、挙動も若干マジカルだが、うまく使えば余計なことを気にせずにかっこよくビューまで一体したコードが書ける。
✖
✖
✖
✖
✖
巨大な .dmg ファイルを複数に分割する
hdiutil でできる。
hdiutil segment -o dest -segmentSize 500m src.dmg
これで複数に分割される。分割されても、全部パートが揃っていれば、最初の一個を開けばそのままマウントできる。
2G以上あるファイルを FAT32 なフラッシュメモリに入れたいときとかで便利。
あるいは sparsebundle にしても入れれると思うけど、 sparsebundle は1つのディレクトリにだいぶたくさんエントリを作るので、しょぼいファイルシステムだとかなり重くなる。
Togetter でまとめられた Twitter ユーザーを一括でブロックするウェブサービス
を作った。Togetter とかで「ああ、こういう話題に言及する人とは関わりあいたくないな」っていうことが時々あると思いますが、そういうときに使える便利なツールです。
余談
僕はホワイトリスト的な、つまり Twitter の場合プライベートアカウントだったりあるいは、そもそもフェイスブックだったり、というやりかたが好きではない。当然ホワイトリスト的なソーシャルネットワークのほうが安全ではあるが、新しい思いのよらなさ、というのがないのは詰らない。
しかし一方で、完全にオープンというのも全くよくない。表現をないがしろにするモヒカン的なゴミクズというのはそこらじゅうにいるし、一瞬でも隙を見せれば攻撃してくる人というのもいる。いろいろ面倒なことになるリスクだったり、思いもよらず傷つくリスクのほうが、思いもよらず良いことがある、というメリットを明かにうわまわる。
何らかの画期的な解決策、というのをいつも考えてはいるが、未だに完全にこれはというものは思いつかない。
そこで、ある程度現状で思いつく中で、なおかつ簡単に実行可能な方法として、関わりあいたくない人を先読みでブラックリストへ登録していく、というのがある。既存のサービスだと「ブロック」という言葉遣いなので、少し抵抗があるが、本来もっと活用すべき機能であると思っている。
Mac OS Xで ZeroPlus LAP-C
ZeroPlus LAP-C 16064 をというロジックアナライザを買ってみた。Windows にしか対応してないけど、一応 Mac でも動かせそうな感じなのでやってみた。ただ、ロジックアナライザの値段はソフトウェアの値段感があって、できれば Windows で使いたくなる。
- sigrok を使う
- VM 上で Windows を起動する
という方法を試した。結論からすると sigrok を使うほうが楽だけど、機能的にはちゃんと Windows 使ったほうがよさそう。
sigrok を使う
OSS で対応しているソフトがあるので使ってみる
$ brew tap rene-dev/sigrok $ brew install --HEAD libserialport $ brew install --HEAD --with-libserialport libsigrok $ brew install --HEAD libsigrokdecode $ brew install --HEAD --with-libserialport sigrok-cli $ brew install --HEAD pulseview
で頑張ると入る。libsigrokdecode がうまく入らなかったので いろいろ頑張った。
pulseview
pulseview コマンドで Qt で作られた GUI が起動する。あんまり機能はないので難しくはない感じ…
- [File] -> [Connect to Device...] で LAP-C を選択する。
- ツールバーの設定アイコンで Volatage Threshold を適切に設定する
- サンプリング数とサンプリングレートを設定する
- Run を押すと出てくる
Decoder の追加はそのまんまなので難しくない Threshold 設定するのが忘れがちでハマりそう。
左のラベルをクリックするとトリガーの条件をかけられる。なぜか状態トリガーしかない。ハード的にはエッジトリガもあるはずなんだけどよくわからない。
captureratio ってのがなんなのかわかりにくいが、トリガーがかかるまでのサンプリングレートを決定する割合みたい。たぶん設定したサンプリングレートに captureratio をかけた値でトリガーがかかるまでサンプルされ、その後設定したサンプリングレートでサンプリングされる、のかな。
よくわからないけど、基本、トリガかけたい信号の周波数の2倍になるように captureratio を設定して、あとは細かいタイミングを見るために高速にサンプリングする、という使いかたなのかな。
sigrok-cli
sigrok-cli --show --driver zeroplus-logic-cube
zeroplus-logic-cube - ZEROPLUS LAP-C(16064) with 16 probes: A0 A1 A2 A3 A4 A5 A6 A7 B0 B1 B2 B3 B4 B5 B6 B7
Supported configuration options:
samplerate - supported samplerates:
100 Hz
500 Hz
1 kHz
5 kHz
25 kHz
50 kHz
100 kHz
200 kHz
400 kHz
800 kHz
1 MHz
10 MHz
25 MHz
50 MHz
80 MHz
100 MHz
captureratio
voltage_threshold
Maximum number of samples: 65536 ここに出てくるサンプリングレート以外を設定するとセグフォして死ぬので注意
sigrok-cli --driver zeroplus-logic-cube --probes A0=SCL,A1=SDA --output-format bits --samples 1k --config samplerate=25K
で適当に表示されるはずなんだけど、なぜか手元のだと 4bit ごとにビットが立つみたいな挙動になってしまう…
あと sigrok-cli だとvoltage_threshold は設定できない (パースできない)。エラーもでないので罠。たぶん sigrok-cli あんまり使ってる人いない。
VirtualBox 上の Windows を使う
Mac、VirtualBox 上の Win XP で動かす
接続からドライバインストールまで
VirtualBox は USB extension を入れる必要がある。
ゲスト Windows が起動したら、VirtualBox のメニューの Devices -> USB Devices -> LAP-C〜 を選ぶ (つまり Windows 側へ接続する)
Windows 側では特に何も起きていないように見えるが、デバイスマネージャを見ると不明なデバイスが1つ見える。
そのデバイスのプロパティを開き、ドライバの再インストールボタンを押す。
- (Windows Update に)「いいえ、今回は接続しません」を選択
- 「一覧または特定の場所からインストールする」を選択
- 「次の場所で最適のドライバを検索する」を選択
- リムーバブルメディアは検索しない
- 「 次の場所を含める」に C:\Program Files\PC-Based Instrument\ZEROPLUS\DRIVER を入れる
- 次へをやると1段階進む
- 今度は再び自動的にドライバのインストールウィザードが開くので、同じように進める
- ドライバの選択では一番新しそうなのを選ぶ
これで起動はするようになる。
使いかた (I2C)
A0 を SCL, A1 を SDA にする場合 (当然これらと GND を結線しておく)
- [Bus/Signal] → [Channels Setup]
- [Delete All] して全部消す
- [Add Bus/Signal] を SCL, SDA 及びバスのデータ表示用に3回押す
- SCL 用には A0 を選択
- SDA 用には A1 を選択
- I2C 用には A0, A1 をどっちも選択
- [OK] で閉じる
[Tool] -> [Bus Property...] をクリックするとアナイラザを選択できるはずだが、エラって死ぬ……… ので終了。うまくいく方法はわからず。
ZeroPlus に問いあわせてみたら、これは V3.12.02 のバグらしい。Channels Setup から BUS を作ってはダメみたい。
V3.12.02 でうまくいく方法は以下
- [Bus/Signal] → [Channels Setup]
- [Restore Default] して元に戻す
- [OK] で閉じる
- メイン画面の左側のプローブ一覧から A1, A0 を Shift か Ctrl を押しながら複数選択して、右クリックから [Group into Bus] をする。
- [Tool] -> [Bus Property...] で開く (開ける)
- 適当に設定する
あらかじめ対応する DLL を入れる必要がある。http://www.zeroplus.com.tw/logic-analyzer_en/products.php?pdn=10&pdnex=list で、とりあえず Generic Free Protocols を入れたらいい
- シリアルが必要なアナライザの場合入れるコードは http://www.zeroplus.com.tw/ に登録して出てきたコード
- 入れる場所は設定画面
で、適当にセットしたらいける。
✖
