2009年02月06日

Linuxでの動作(3) Debian Lenny Live CD

メインPCのLinux領域が破損中で当分直せそうにないので
PC−LinuxはKNOPPIXのようなLiveCD/DVDが便利。
使用したPCは以前と同じ。

レスキュー用途やちょっと遊んでみるには最適。

Debian Live Project
http://debian-live.alioth.debian.org/
Download
http://live.debian.net/cdimage/lenny-builds/20090131/i386/iso-cd/
DVDに焼いたのはこれ
debian-live-lenny-i386-gnome-desktop.iso

起動してみると「Ubuntuにそっくり」というか言い方が逆なんだけど(^^;
シンプルでいい感じ。ただし英語版で漢字表示はできない。
これの日本語版が是非ほしいな。デフォルトで
usename: user
password: live
基本的にsudo操作が可能になっている。
rootになるにはsudo -i でOK。

あとこれはgccのFAQかもしれないが
apt-get install gcc
しても標準ヘッダファイルが全くインストールされないのはどういうことだ?
Ubuntuもそうだったけど納得いかん。

結局、dh-makeとlibusb-devいれたらOKだったけど。*-dev系かな。
ようやくコンパイル可能になった。

で、hidspx。

結果としては(HUBあり)で「-d9」までは大丈夫になった。
「-d10」以降はエラー発生。
ベリファイ単独でも結果は同じ。これをWindowsでベリファイしても
全く同じ場所がエラーになるので書き込みエラーが発生している模様。

で、usleep.cテスト

time ./usleep 100
real 0m0.105s
user 0m0.000s
sys 0m0.000s

time ./usleep 1000
real 0m1.007s
user 0m0.000s
sys 0m0.004s

time ./usleep 10000
real 0m10.059s
user 0m0.000s
sys 0m0.016s

こんどはいい感じだと思う。ようやく100msecが100msecに近くなった(^^;

で、usleep2.cテスト。ソースはこれ。

#include
#include
#include
int main(int argc, char *argv[])
{
int i, cnt;

if (argc != 2) {
printf("usage usleep N ... [ms]\n");
exit(1);
}
cnt = atoi(argv[1]);
usleep(1000*cnt);
return 0;
}

これをrubyで、1msec〜100msecまで10msec単位で10回ずつ実行させる。

#!/usr/bin/ruby
for i in 1..10 do
puts "--- bash -c \"time ./usleep2 #{1*1}\"---"
system("bash -c \"time ./usleep2 #{1*1}\"")
puts "----------------------------------------"
end
for i in 1..10 do
for j in 1..10 do
puts "--- bash -c \"time ./usleep2 #{i*10}\"---"
system("bash -c \"time ./usleep2 #{i*10}\"")
puts "----------------------------------------"
end
end

結果はこれ。lenny-usleep2.zip
標準出力とエラー出力同時取り込みは。
ruby usleep2.rb > out.txt 2>&1 とかで。

結果を見ると1msecの精度が2〜7msecまでばらつく。


で、原因はべつなところかなと言う気もする。
玄箱PROやSH系の500MHz以下のマシンにAthlon 1.5GHZが速度の点で
負けるとは思えない。(^^;

うちには「-d」値が大きい時に正常に動作するLinuxがないので不明だけど
正常動作するLinux上での「usleep2.c」テストの1msecの結果が気になる
ところではある。

あと感覚的にはディレイが小さくなってエラーならなわかる気もするが
(ディレイが小さい方が誤差が大きいので)
ディレイが大きくなってエラーになるのは誤差がどこかで蓄積されるってことかな。


posted by Copyright (C) avrin All Rights Reserved. at 23:24| Comment(7) | TrackBack(0) | etc | このブログの読者になる | 更新情報をチェックする

2009年02月05日

Linuxでの動作(2)

玄箱HG Debian etch での書き込みエラーで
senshuさんのページで肝(キモ)はusleep関数の精度というこで
確認用のテストソースが掲載されたので試してみました。

玄箱HG:
time ./usleep 100
real 0m0.404s
user 0m0.000s
sys 0m0.004s

time ./usleep 1000
real 0m4.003s
user 0m0.004s
sys 0m0.000s

time ./usleep 10000
real 0m40.007s
user 0m0.004s
sys 0m0.000s

と出ました。(汗汗
./usleep 100は100msecと出るはずが400msec。
これじゃだめだわな。

まぁ、ある意味高い精度で4倍ずれてるってことか(オーーーーイ




VMWare上のUbuntu8.04でもusleep.cをやってみると
100msecと出るところが 196msec〜266msecにばらつく。
だいたい200msecくらいに集中している感じ。
100msec以上は意味なさそうなので試さず。

KNOPPIX 5.3.1 DVDをPC直で動作させて同様にusleep.cをやると
100msecと出るところが335msec〜337msecとなる。


そんなわけで、うちのLinuxはちょっと変わってるっぽい(^^;


つか、100msecを100msecと出してくるLinuxがほしいぞ(爆



で、ちょっと調べてみた

C言語: 実行時間測定の方法
http://kzk9.net/column/time.html
とか
4. 高い精度のタイミング制御
http://www.linux.or.jp/JF/JFdocs/IO-Port-Programming/high-resolution.html
など。なかなか難しいらしい。

実際のソース上での使われ方をみるとusleep(n*1000)という形で
数ミリ〜数十ミリ秒を指定しているようなので、
テストコードも10msecならusleep(10*1000)だけを実行するという形に変えてみた。
「usleep2 20」 なら 関数としてusleep(20*1000)を実行する
結果はこう。usleep-test-kuro-box.zip

必ず7〜9msecくらいのオフセットが付くようだ。
たまに過激に時間を消費する場合もある。
usleep関数の最小精度10msec+αらしいがαの部分が結構大きい。

これだと100msecが107msecくらいになって4倍とかでなくて少し
安心した(^^;

sleep関数の時間を計ってオフセットを引いてキャリブレーションするという手は
上の結果からだと難しい感じ。

たまの過激な時間消費は過激に重いデーモンがあったせいでコレを停止したら
なくなった。多分。
posted by Copyright (C) avrin All Rights Reserved. at 23:36| Comment(0) | TrackBack(0) | etc | このブログの読者になる | 更新情報をチェックする

Linuxでの動作

さて、#216(1/26のファーム)の基板でのR/W動作。
hidspxは1/28版。
動作確認は玄箱HGとPCでのKNOPPIX5.3.1DVD
PCはAthron XP 1.52GHz UHCI、ハブあり
玄箱HGは PowerPC 266MHz OHCIでハブなし.

ブレッドボードでは[-d]値が大きいと書き込みエラーが発生した。

結果から書くと#216基板でも状況は変わらず。

でも[-d]値が小さければ(書き込みスピードが速い)エラーは起きないので
まぁ十分かと。


玄箱HGはエラー数が-d4で100個前後。kuro-box-err.zip
ライタをUSB接続したときのdmesgにエラーメッセージはなかった。

KNOPPIXは-d4で1個。
同様にdmesgには「can't find input interrupt endpoint」が出ていた。

ためしにVMWare 5.59 for Windos上のUbuntu6.10と8.04で試したが
仮想OS上ではどの[-d]値でも書き込みエラーが盛大に発生して使えない。
posted by Copyright (C) avrin All Rights Reserved. at 00:04| Comment(0) | TrackBack(0) | etc | このブログの読者になる | 更新情報をチェックする

2009年02月03日

100万回ON/OFFテスト

ということで、HIDaspxのUSB-IOモードでの100万回ON/OFFテスト。

経緯:
基本的にはPCの電源電圧が低いのでここがあやしそうではある。

BB(ブレッドボード)版:
以前50万回以内に必ずエラーとなる。ただ、その後のある日に2回トライしたところ
2回とも50万回通った。
今回、100万回にトライしてパスした。(試行回数1)

#216基板:
100万回にパス。(試行回数1)電源電圧4.76V <− 前より低い(^^;

>hidmon
TARGET DEV_ID=55
HIDaspx is Programmer mode.
AVR> bench
hid write start
hid write end, 37.109 kB/ 1.91 s, 19.470 kB/s

100万回ON/OFFテスト(途中経過未表示、Dephiで実行)
Version Number: Windows NT 5.1 (Build 2600)
Exit Time: 10:23 pm, Tuesday, February 3 2009
Elapsed Time: 0:17:26.703
Process Time: 0:00:56.359
System Calls: 7069301
Context Switches: 5241844
Page Faults: 63802
Bytes Read: 11630926
Bytes Written: 668590
Bytes Other: 20975848

17.5分くらい。

と大成功風。

ただし上のテストとは関係なくUSBの5Vをたまに測ると
4.71Vだったり4.76Vだったりとやはりあやしげ。
4.71Vは5V±5%を満たしていないのでアウト。
これはHDDを1台抜いて負荷を減らして、PC上でHDDアクセスが起こらない
ようにしている。

次は通常使用状態でのテストへ
posted by Copyright (C) avrin All Rights Reserved. at 23:02| Comment(5) | TrackBack(0) | etc | このブログの読者になる | 更新情報をチェックする

HIDaspx ライタ #216基板 動作した編

ws216-single.jpg

ws216-on-bb.jpg

この基板に対するファーム書き込みも終了しました。
Firmというか魂(たましい)というかHeart(ハート)を書き込んでるような感じですね。

丸ピンヘッダソケットにTiny2313を挿してみましたが結構テンションがかかるようで
ここは本物のソケットのほうがよさそうです。(^^;

ライタとしても動作しましたのでまずはバッチリOKと。(^_^)v
posted by Copyright (C) avrin All Rights Reserved. at 00:49| Comment(2) | TrackBack(0) | etc | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。