昔の最近の出来事(2018.08)

2018/08/31

早めに帰着。

PiでGDCのビルド。libphobos/src/std/math.d のコンパイルでエラーが出るも、 ちょっと弄ってビルドに成功。 ビルドにgdcを使用しない以前のバージョンでは std/net/curl.dのスタティックライブラリのコンパイルがいつまで経っても 終わらなくて最適化レベルを下げたのですが、今回はそういう事はありません でした。前のはバグってたのだろうか?さておき、 インストールして手持ちコードのコンパイル&実行もひとまず問題無さげ。

$ gdc -v
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc_20812_820/libexec/gcc/arm-linux-gnueabihf/8.2.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-8.2.0/configure --with-pkgversion='gdc-8 b201abfd00(DMD2.081.2)' --enable-languages=c,c++,d --prefix=/usr/local/gdc_20812_820 --with-arch=armv6 --with-fpu=vfp --with-float=hard --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-checking=yes --disable-libgomp --disable-libmudflap --disable-libsanitizer --disable-nls --disable-bootstrap
Thread model: posix
gcc version 8.2.0 (gdc-8 b201abfd00(DMD2.081.2))

$ cat -n iam.d
     1  import std.stdio;
     2  import std.string ;
     3  import std.compiler;
     4
     5  int main()
     6  {
     7    writef("%s %s %s.%03d (D%s)\n",name,vendor,version_major,version_minor,D_major) ;
     8    version( GNU     ) writef("I am GNU\n"    ) ;
     9    version( Unix    ) writef("I am Unix\n"   ) ;
    10    version( linux   ) writef("I am linux\n"  ) ;
    11    version( Windows ) writef("I am Windows\n") ;
    12    version( MinGW   ) writef("I am MinGW\n"  ) ;
    13    version( MinGW32 ) writef("I am MinGW32\n") ;
    14    version( MinGW64 ) writef("I am MinGW64\n") ;
    15    version( cygwin  ) writef("I am cygwin\n" ) ;
    16    version( Win32   ) writef("I am Win32\n"  ) ;
    17    version( Win64   ) writef("I am Win64\n"  ) ;
    18    version( Posix   ) writef("I am Posix\n"  ) ;
    19    version( X86     ) writef("I am X86\n"    ) ;
    20    version( X86_64  ) writef("I am X86_64\n" ) ;
    21    version( ARM_SoftFloat ) writef("I am ARM_SoftFloat\n" ) ;
    22    version( ARM     ) writef("I am ARM\n"    ) ;
    23    version( PPC     ) writef("I am PPC\n"    ) ;
    24    version( PPC64   ) writef("I am PPC64\n"  ) ;
    25    version( PPC_SoftFloat ) writef("I am PPC_SoftFloat\n" ) ;
    26    version( PPC_HardFloat ) writef("I am PPC_HardFloat\n" ) ;
    27
    28    return(0) ;
    29  }

$ gdc -O2 iam.d

$ ./a.out
GNU D gnu 2.081 (D2)
I am GNU
I am linux
I am Posix
I am ARM

マンデルブロ集合を書くコードも、I2C制御も大丈夫そう。素晴らしい。

あまりの眠さに急速停止。

2018/08/30

気持ち早めに帰着。

GDCの新しいのが来てるようだったので、先日 ビルドに失敗していたx86/x86_64ターゲットのビルドを試したり。 結果はビルドに成功し、簡単な手持ちコードのコンパイル&実行は問題 無し。

と言う訳でPiの方でGDCをビルドしてみる事に。見ている間には終わらず。

2018/08/29

気持ち早めに帰着。

途中から鳥人間コンテストを観られたり。 逆走台風来てた時だった為、人力プロペラ機部門は途中で中止。 60kmルールでどうなるか楽しみでしたが残念。 今回のらごぱすたん姉妹は喋らず(笑 Webページに書いてありますが、らごぱすは雷鳥(ライチョウ)の 学名(Lagopus muta)なんだそうな。雷鳥ってサンダーバード じゃないの?と思ってたのですが、サンダーバードは世の中に存在 しない架空の生物らしい (参考Wikipedia)。

2018/08/28

早くも無く遅くも無く。

プラ材について調べたり。先日 秋葉で買い物をしたときに、 タミヤの ユニバーサルプレートユニバーサルアーム などを買ってみました。必要な長さに切って使う感じで、 穴を空ける手間が省ける感じなのですが、ピッチが5mmの 間隔に合わない場合は逆に穴が開きすぎていて、バイスで 丁度良い位置に穴を空けるのが難しい感じです。 ユニバーサルアームの穴が開いてないバージョンが あればなぁ?と思ったのですが、プラ棒の5mm角を使う のが良いかもなぁ?と思ったりも。

2018/08/27

遅めに帰着。

調べ事をして終了。

2018/08/26

AM中に起床。

掃除したり洗濯したり。

サーボホーンの穴を広げようとピンバイスを使ったのですが、 1mmの穴を2mmにするのに いきなり2mmのドリル刃で広げようと したところドリル刃が空回りしたり。一気に広げようとしたところ 切れずにドリル刃が食い込んでしまったのが原因ですが、 ドリル刃を固定するチャックを固めに締めてても空回り するようです。しかたないので1mmのドリル刃で穴をほんの少しだけ広げ、 1.5mmのドリル刃で広げ、最後に2mmのドリル刃で目的のサイズに するという感じで対応。
所で、固めにヘッドを締めているつもりなのにドリル刃が 空回りする事についてWebで調べてみたところ、同じ質問を行っている ものがあったのですが、それに対する回答がイマイチな感じのもの ばかりに思ったりも。 大体がチャックをかしめるヘッドの締め付けが弱いか、ドリル刃が 切れなくなっているという回答なのですが、いずれも普通に使ってて 空回り経験が無いと思われる人の回答のように思えたりも。

2018/08/25

昼前起床。

秋葉でお買い物。

金属ギアのサーボ MG90S を買ってみたのですが、繋いで動作テストをしていると 尋常じゃない発熱だったり。手で持てないくらいの熱量だったので、 即通電をやめて冷却。冷めた所でもう一度、手で持ったまま角度固定で 動かしてみたのですが、次第に熱を感じられたので電源OFF。 同製品を複数購入していたので、もう一つ別のを試してみたところ、 こちらはしばらく動かしてみるも持てなくなるような 熱量にはならなかったり。
どこかショートしているのか?と思うくらいの感じだったので、 分解して基板を眺めてみるも怪しそうな感じではなかったり。 てか、表面実装ICのSOPの足に直接サーボモーターに繋がるリード線を はんだ付けしてて、大分無茶な実装をしているような気がしたりも。

先週買ったサーボ(SG90)と同型のサーボも追加購入したのですが、基板が 違ってたり。先週買ったサーボの基板は少し大きいですが、実装は 普通な感じなのですが、今週買ったのは前述 MG90S と同じ基板でした。 それが関係あるのか判りませんが、今週買ったSG90の一つを動作テスト してみたのですが、角度を止めてもなんかプルプル動いててイマイチな 感じがしたり。

2018/08/24

早めに帰着。

あまりの眠さに急速停止。

2018/08/23

早くも無く遅くも無く。

調べ事して終了。

2018/08/22

気持ち早めに帰着。

GDCの新しいのが来ているようだったのでPiでビルド。 でも以前、libdruntimeのビルドでICEズッコケする 状況は変わらず。

/bin/bash ../libtool --tag=D   --mode=compile /home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/gdc -B/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/ -B/usr/local/gdc_20812_820/arm-linux-gnueabihf/bin/ -B/usr/local/gdc_20812_820/arm-linux-gnueabihf/lib/ -isystem /usr/local/gdc_20812_820/arm-linux-gnueabihf/include -isystem /usr/local/gdc_20812_820/arm-linux-gnueabihf/sys-include    -fPIC -g -O2  -nostdinc -I ../../../../gcc-8.2.0/libphobos/libdruntime -I . -c -o core/demangle.lo ../../../../gcc-8.2.0/libphobos/libdruntime/core/demangle.d
libtool: compile:  /home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/gdc -B/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/ -B/usr/local/gdc_20812_820/arm-linux-gnueabihf/bin/ -B/usr/local/gdc_20812_820/arm-linux-gnueabihf/lib/ -isystem /usr/local/gdc_20812_820/arm-linux-gnueabihf/include -isystem /usr/local/gdc_20812_820/arm-linux-gnueabihf/sys-include -fPIC -g -O2 -nostdinc -I ../../../../gcc-8.2.0/libphobos/libdruntime -I . -c ../../../../gcc-8.2.0/libphobos/libdruntime/core/demangle.d -fversion=Shared -o core/.libs/demangle.o
../../../../gcc-8.2.0/libphobos/libdruntime/core/demangle.d: In function '__ctor':
../../../../gcc-8.2.0/libphobos/libdruntime/core/demangle.d:87:18: internal compiler error: Segmentation fault
             super( msg );
                  ^
0x904f33 crash_signal
        ../../gcc-8.2.0/gcc/toplev.c:325
0x408843 layout_aggregate_type
        ../../gcc-8.2.0/gcc/d/types.cc:412
0x409cb7 TypeVisitor::visit(TypeClass*)
        ../../gcc-8.2.0/gcc/d/types.cc:945
0x4085ef build_ctype(Type*)
        ../../gcc-8.2.0/gcc/d/types.cc:1000
0x3caad7 declaration_type(Declaration*)
        ../../gcc-8.2.0/gcc/d/d-codegen.cc:162
0x407fe3 layout_aggregate_members
        ../../gcc-8.2.0/gcc/d/types.cc:302
0x40898b layout_aggregate_type
        ../../gcc-8.2.0/gcc/d/types.cc:444
0x409cb7 TypeVisitor::visit(TypeClass*)
        ../../gcc-8.2.0/gcc/d/types.cc:945
0x4085ef build_ctype(Type*)
        ../../gcc-8.2.0/gcc/d/types.cc:1000
0x3cac63 type_passed_as(Parameter*)
        ../../gcc-8.2.0/gcc/d/d-codegen.cc:215
0x40911f TypeVisitor::visit(TypeFunction*)
        ../../gcc-8.2.0/gcc/d/types.cc:696
0x4085ef build_ctype(Type*)
        ../../gcc-8.2.0/gcc/d/types.cc:1000
0x3e38ff get_symbol_decl(Declaration*)
        ../../gcc-8.2.0/gcc/d/decl.cc:1071
0x3edbdb ExprVisitor::visit(CallExp*)
        ../../gcc-8.2.0/gcc/d/expr.cc:1725
0x3eaabf build_expr(Expression*, bool)
        ../../gcc-8.2.0/gcc/d/expr.cc:3081
0x3eabab build_expr_dtor(Expression*)
        ../../gcc-8.2.0/gcc/d/expr.cc:3103
0x3fa7b7 IRVisitor::visit(ExpStatement*)
        ../../gcc-8.2.0/gcc/d/toir.cc:957
0x3fa74b IRVisitor::build_stmt(Statement*)
        ../../gcc-8.2.0/gcc/d/toir.cc:254
0x3fa74b IRVisitor::visit(CompoundStatement*)
        ../../gcc-8.2.0/gcc/d/toir.cc:974
0x3fa74b IRVisitor::build_stmt(Statement*)
        ../../gcc-8.2.0/gcc/d/toir.cc:254
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Makefile:2932: ターゲット 'core/demangle.lo' のレシピで失敗しました
make: *** [core/demangle.lo] エラー 1

そういやICEズッコケしたときにスタックダンプが表示されるように なってるな?と思って、gcc-8.2.0/gcc/d/toir.ccとかを見てみた のですが、コード上の不具合があるのか否かはよく判らず。 因みに、ビルド過程で生成されたgdcではなく、コンパイル済の gdcを使ってみたら、やっぱりICEズッコケするのですが、 なんか違う理由のような気がしたりも。

$ gdc -isystem /usr/local/gdc_20812_820/arm-linux-gnueabihf/include -isystem /usr/local/gdc_20812_820/arm-linux-gnueabihf/sys-include -fPIC -g -O2 -nostdinc -I ../../../../gcc-8.2.0/libphobos/libdruntime -I . -c ../../../../gcc-8.2.0/libphobos/libdruntime/core/demangle.d -fversion=Shared -o core/.libs/demangle.o                                                                                                                                                                        /home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2283:5: error: declaration expected, not 'do'
     do
     ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2289:9: error: declaration expected, not 'if'
         if (flags & MItlsctor)
         ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2292:15: error: no identifier for declarator p
             p += typeof(tlsctor).sizeof;
               ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2292:15: error: declaration expected, not '+='
             p += typeof(tlsctor).sizeof;
               ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2294:9: error: declaration expected, not 'if'
         if (flags & MItlsdtor)
         ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2297:15: error: no identifier for declarator p
             p += typeof(tlsdtor).sizeof;
               ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2297:15: error: declaration expected, not '+='
             p += typeof(tlsdtor).sizeof;
               ^
/home/pi/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/libdruntime/object.d:2298:9: error: unrecognized declaration
         }
         ^
cc1d: ../../gcc-7.1.0/gcc/d/dfrontend/mtype.c:8353: virtual Type* TypeClass::semantic(Loc, Scope*): Assertion `sym->parent' failed.
cc1d: internal compiler error: Aborted
0x7fef03 crash_signal
        ../../gcc-7.1.0/gcc/toplev.c:337
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

うーむ。

そもそもx86/x86_64でも大丈夫なんだっけ?と思いVMware上のFedoraでも ビルドしてみたのですが、こちらもICEズッコケとなるものの、 また違う理由の様だったり。

/bin/sh ../libtool --tag=D   --mode=compile /home/tane/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/gdc -B/home/tane/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/ -B/usr/local/gdc_20812_820/x86_64-pc-linux-gnu/bin/ -B/usr/local/gdc_20812_820/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/gdc_20812_820/x86_64-pc-linux-gnu/include -isystem /usr/local/gdc_20812_820/x86_64-pc-linux-gnu/sys-include    -fPIC -g -O2  -nostdinc -I ../../../../gcc-8.2.0/libphobos/src -I ../../../../gcc-8.2.0/libphobos/libdruntime -I ../libdruntime -I . -c -o std/concurrency.lo ../../../../gcc-8.2.0/libphobos/src/std/concurrency.d
libtool: compile:  /home/tane/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/gdc -B/home/tane/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/build/./gcc/ -B/usr/local/gdc_20812_820/x86_64-pc-linux-gnu/bin/ -B/usr/local/gdc_20812_820/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/gdc_20812_820/x86_64-pc-linux-gnu/include -isystem /usr/local/gdc_20812_820/x86_64-pc-linux-gnu/sys-include -fPIC -g -O2 -nostdinc -I ../../../../gcc-8.2.0/libphobos/src -I ../../../../gcc-8.2.0/libphobos/libdruntime -I ../libdruntime -I . -c ../../../../gcc-8.2.0/libphobos/src/std/concurrency.d -fversion=Shared -o std/.libs/concurrency.o
uncaught exception
deh(507) fatal error
/home/tane/develop/gdc/GDC-dedec9ecccc882e825bc0b37d4e6efce67987491/gcc-8.2.0/libphobos/src/std/math.d:8869:47: internal compiler error: Illegal instruction
             return cast(Unqual!T) (T(1) << bsr(val) + type);
                                               ^
0xd2d43f crash_signal
        ../../gcc-8.2.0/gcc/toplev.c:325
0x16c7ed2 _D3gcc3deh9terminateFNikZv
        ../../../../gcc-7.1.0/libphobos/libdruntime/gcc/deh.d:425
0x16c8038 _d_throw
        ../../../../gcc-7.1.0/libphobos/libdruntime/gcc/deh.d:507
0x16c71bd onAssertError
        ../../../../gcc-7.1.0/libphobos/libdruntime/core/exception.d:441
0x767617 StructLiteralExp::addDtorHook(Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/expression.d:4002
0x77b446 ExpressionSemanticVisitor::visit(DotVarExp*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:4528
0x7776e1 expressionSemantic(Expression*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:9434
0x7776e1 ExpressionSemanticVisitor::visit(CallExp*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:3211
0x7764b2 expressionSemantic(Expression*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:9434
0x7764b2 ExpressionSemanticVisitor::visit(CallExp*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:3623
0x76e735 expressionSemantic(Expression*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:9434
0x79bb4a InferTypeVisitor::visit(ExpInitializer*)
        ../../gcc-8.2.0/gcc/d/dmd/initsem.d:660
0x79ad12 inferType(Initializer*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/initsem.d:52
0x7371f0 DsymbolSemanticVisitor::visit(VarDeclaration*)
        ../../gcc-8.2.0/gcc/d/dmd/dsymbolsem.d:618
0x734d0c dsymbolSemantic(Dsymbol*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/dsymbolsem.d:378
0x77b083 ExpressionSemanticVisitor::visit(DeclarationExp*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:3668
0x76e735 expressionSemantic(Expression*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/expressionsem.d:9434
0x7dbb1a StatementSemanticVisitor::visit(ExpStatement*)
        ../../gcc-8.2.0/gcc/d/dmd/statementsem.d:176
0x7dab05 statementSemantic(Statement*, Scope*)
        ../../gcc-8.2.0/gcc/d/dmd/statementsem.d:125
0x7dab05 StatementSemanticVisitor::visit(CompoundStatement*)
        ../../gcc-8.2.0/gcc/d/dmd/statementsem.d:234
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://bugzilla.gdcproject.org> for instructions.
make[4]: *** [Makefile:1835: std/concurrency.lo] エラー 1

なんだこりゃ?

2018/08/21

気持ち早めに帰着。

ここ最近、Piの電源を入れっぱにしていたのですが、妙にファン付きケース のファンがうるさくて一旦電源OFFしたり。ファンをよく見てみると、 埃が少し引っかかっていた(扇風機とかでしばらく使っていると、ファンの 風を切るエッジに埃が引っ掛かっているあれ)ので、掃除してみたところ 静かになったり。埃によって気流が乱れてファンが微妙に振動して いたという感じだったのかしら?

PCA9685制御向けクラスのデバッグ。ひとまず最低限の実装と動作確認はできた気も。

2018/08/20

早めに帰着。

ちょろり調べ事。

あまりの眠さに急速停止。

2018/08/19

AM中に起床。

掃除したり洗濯したり。

サーボ制御。なんとなく動かせる事が判ったので、 PCA9685制御向けのクラスを作る事にしてみたり。

2018/08/18

AM中に起床。

室内温度計で見ると33.5℃あるのですが、湿度が44% のためか あまり暑く感じないなぁ?

「オリンピア・キュクロス(1)」。面白いです。マラソンの話とか ノリノリで描いてる感じがしたりも。

「美の巨人たち」で放送されていた 大竹亮峯 の 鹿子海老。え?木製!?しかも自在置物(いわゆるアクションフィギュア)!? 現代の人でまだ20才代なの!? すげぇ...... (Webサイト)

サーボ制御。ローテーションサーボの停止位置と右回り最速、左回り最速 のパルス幅を調べたり。何故かデータシートには数値的な物が見当たらなかった ので、パルスの幅を少しずつ手動で変えて止まる位置を調べたり。 少し遊びがあるようなので、「大体これくらい」な感じの値を得られたり。 あと、可動域が180°のサーボについてもパルスの値と角度の関係を調べたり。 こちらはデータシートにパルス幅と角度の関係は示されていたのですが、 少しズレがあるように思ったり。こちらも遊びがあるようなので、 大体の位置を得られた感じ。

2018/08/17

早めに帰着。

となりのトトロを観ながらサーボ制御をごそごそと弄ったり。 パルスの周波数やデューティー比を変更するレジスタにアクセス するには準備手順が必要な事が判ったり。 とりあえずローテーションサーボ(角度を制御するのではなく 回転速度を制御するサーボ)でなんとなく制御できそうな事 を確認してみたり。
いくつかWeb上のコードを参考にしてみたのですが、 少し疑問に思う点があったり。パルスの形状を変更するには 4つのレジスタに値を書き込む必要があるのですが、Webのコード の中にはレジスタひとつずつ、4回に分けてアクセスして 書き換えているものがあります。ただこの方法では、1つの レジスタを書き換える度にそれに応じた波形を出力してしまう為、 全てのレジスタを更新し終わるまでの過渡期の波形が とんでも無い事になる場合があるように思います。 イマイチPCA9685の英語の説明書が読めていないので、これでも 大丈夫なモードで動かしているのかも知れませんが、 もう少しよく見てみる必要がありそう。

あまりの眠さに急速停止。

2018/08/16

AM中に起床。

思い立って秋葉で買い物。秋月電子でサーボ&PWM駆動キットと、 実験に必要そうな部材を購入。夏季休暇明けの営業初日だからか どうかは判りませんが、いつもにまして混雑していた気も。

ピンヘッダをはんだ付けして組み立て完了。接続してi2cdetect コマンドでデバイス認識されたので、ひとまず大丈夫そう。 いくつかレジスタを読んでみて、初期値が読めるのは確認 できたのですが、書く方が思った感じにならなくて、何か 手順が必要なのか?と思ったり。

2018/08/15

AM中に起床。

そういやサーボモーターってどうやって動かすんだ?と 思い調べてみたり。ラジコンなんかで使われているいわゆるサーボ ですが、アナログ的な位置決めをどうやってるのかはよく知りません でした。で、どうやらパルス幅変調(PWM:pulse width modulation) を使い、パルス波のデューティー比に応じて位置(回転角度)を決める というのを知ったり。PiのGPIOを使って制御ができるのか? と思って調べてみたところ、意外と面倒臭い感じだという事が判ったり。

PiのGPIOピンの内、2ピンについてはPWM制御向けにパルスをハード的に生成する 特別な仕組みがあるようですが、それ以外のGPIOピンはソフトウェアの OFF/ON制御でパルスの生成を行う必要がある模様。後者の ソフトウェアによるPWM制御では正確なデューティー比を生成するのが 難しい為、場合によってはブルブル震えるように動いたりするようです。 先日、GPIOを制御するライブラリとしてWiringPiを挙げましたが、 こちらは2ピンのハードPWMは制御できるようですが、その他のGPIOピンは PWM制御サポートしないようです。別のライブラリで pigpioという のがあり、こちらはソフトウェア制御ですが全てのGPIOピンを 良い感じにPWM制御できるようです。

1個もしくは2個程度のサーボモーターをちょこっと使って遊んでみたい 感じだと、PiのGPIOを直接使う感じみたいですが、ロボットの ように沢山のサーボモーターを制御する場合は、コントローラーICを 介して制御するのが良いみたいです。PCA9685というコントローラーIC で、I2Cを経由して 16個のチャンネルを独立制御する感じみたい。 指定したパルスのデューティー比で出し続けるような仕掛けみたいなので モーター制御も安定するものと思われます。因みに、PCA9685自体は LEDのコントローラらしく、パルスのデューティー比によりLEDの明るさ を制御する目的のものみたいです。メーカー自身がサーボモーター制御も 想定した製品なのか、他の人がサーボモーター制御にも使えると 目を付けたのかは分かりません。

2018/08/14

AM中に起床。

PiでI2Cデバイスアクセス。D言語でアクセスしてみたり。 open()とioctl()はそれぞれcore.sys.posix.fcntlと core.sys.posix.sys.ioctlにあるのでimportして、 fdを隠蔽するのにクラスで実装してみたり。 温度センサーアクセスに必要な分だけをlinux/i2c-dev.hから 移植する感じですが、基本的にベタ移植で大丈夫そうな感じ。 そういや、unionを使う事に意味がある例を初めて見た気が したりも。ひとまず動いたり。ただ、コンパイルが 遅いのと、生成された実行ファイルが巨大なのがイマイチかも 知れません。

PiのGPIOをC言語から操作する方法を調べたり。 WiringPiというライブラリを 使う方法があるようなのですが、実行時にsudoしなくてはならないらしくて、 あれ?なんか面倒臭くね?と思ったり。別の方法として /sys/class/gpioの下のファイルを介して制御する方法が あり、こちらの方がUNIX系OS向けっぽくて良いかも?と思ったり。 こちらはsudoの必要は無さげなのですが、そもそもpiという初期 ユーザーIDが特別な権限を持っているから可能なのか?とも 思ったり。

ファイルを介したGPIO制御をD言語で行ってみたり。 少々ハマり所がある模様。一つは /sys/class/gpio/export に制御したいGPIOの番号を書き込むと、 /sys/class/gpio/gpioX/ のディレクトリの下に各種ファイルが 生成されるのですが、直ぐにファイル群が生成される訳ではないようで、 100ms以上待つ必要がありそう。 もう一つは、/sys/class/gpio/gpioX/valueというファイルに 文字列0か1を書くと、GPIOのOFF/ONを制御できるのですが、 open(),write(),close()を繰り返していると何故かディレクトリが 丸ごと無くなる(echo XX > /sys/class/gpio/export したのと同じになる)。 後者は原因不明。シェルスクリプトで同じ感じのを書いても 勝手にディレクトリが無くなったりはしないのに。なんでだ?

原因判明。GPIO制御を行うクラスを作成したのですが、 unexportを行う為にcloseというメソッドを用意しました。 所がvalueを設定する別のメソッドで core.sys.posix.unistd.close()のつもりで単にclose() とだけ書いた所、unexportを行う為のclose()の方を実行 してしまってました。実際には close()せずに open()を繰り返して いたため、返るfdが 徐々に大きくなってたのですが、fdの値が たまたま使用していたGPIO番号と同じになった場合に、unexportを 行うclose()の方を実行し、そこでディレクトリが無くなって しまってたという流れでした。 修行が足りません。close()というメソッド名をやめてunexport() に変更してみたり。

ひとまずGPIOをON/OFFする事ができたり。1us単位で制御しても 大丈夫そう。といっても、10msよりも短い単位でLEDを点滅 させても、肉眼では点滅(チカ)しているのか、点灯(ピカ)している のかは区別できませんが(^^;

2018/08/13

昼前起床。

出掛けられそうかと思いきや雨が降り出したりとなんかイマイチな天候。

拙作 mcalendarをアップデートしてみました。2019年の天皇誕生日の変更、 2020年の祝日移動を反映してみました。他、1948年以前の祝日追加や バグ修正を行ってます。御参考まで。

PiでI2Cデバイスアクセス。以前、 Nucleo向けに組んだ温度センサーとキャラクタ液晶ディスプレイを 使ってみたり。ただ、キャラクタ液晶の方は電気的な都合で認識できず (エラッタ)。 温度センサーの方だけ試してみたり。Piに繋いでデバイス表示 すると以下のような感じに。

$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Nucleoの時は0x90で、RWビットを含む値をアドレスとしていましたが、 PiではRWビットを含まずに読むようです。これを、Webのコードなど を元に以下のような感じにコーディング。

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

#include <linux/i2c-dev.h>
#include <fcntl.h>
#include <sys/ioctl.h>

int main(int argc, char **argv)
{
    char *i2cdevName = "/dev/i2c-1";
    const unsigned char I2C_ADT7410_ADRS = 0x48;
    int fd;

    if((fd = open(i2cdevName,O_RDWR)) < 0){
        fprintf(stderr,"Can not open i2c port\n");
        return 1;
    }
    if (ioctl(fd, I2C_SLAVE,I2C_ADT7410_ADRS) < 0) {
        fprintf(stderr,"Unable to get bus access to talk to slave\n");
        return 1;
    }

    while(-1){
      struct timespec t = {1, 0} ;
      int rddt = i2c_smbus_read_word_data(fd, 0x00) ;
      int temp = (rddt & 0xff00)>>8 | (rddt & 0xff)<<8 ;
      nanosleep(&t,NULL) ;
      printf("%f\n", 0.0625*(double)(temp>>3)) ;
    }

    return 0;
}

1秒おきに温度を表示する感じに。Nucleoの時はデータ読み出しを 行うレジスタアドレス値を書き込んだ後、それによって得られる データの読み出しを行うというように書く必要があったのですが、 Piではそこんところが随分簡単に書けるように思います。 Nucleoとコーディング上の違いはあるのですが、一番の違いは ROMに書いて再起動する必要が無い所。ラクチンです(^^; 狙いを持って動かす必要のあるNucleoも良いのですが、 ソフトの方をちょっと変えて試す事のできるPiの方が、 とっつき易いとは思います。

Neucleoでは、やる事にもよりますが、回路接続、IOの設定、 ソフトウェア制御、ROMへのダウンロード、デバッグ表示など 全て正しくないと所望の動作結果は得られません。 特にプログラムがハングしている場合、ダンマリになる だけだったりしますので、原因を究明するのは大変だと 思います。それを込みで楽しめる人ならば問題ありませんが、 ちょっとどんなもんか試してみたいという人向けでは ないかも知れません。

2018/08/12

AM中に起床。

GDCビルド。libdruntimeのビルドでICE(Internal compiler error)ズッコケ してたり。最適化レベルを下げても状況が変わらなかったのでお手上げ。

Piでi2cアクセスする方法を調べたり。pythonを使う例が多数を占めている のですが、C言語でアクセスする方法でと思い調べてみるも、 情報が古いのも混ざっている為か方法がイマイチよく判らなかったり。 基本的にはioctl()システムコールを直に使う事になるようなのですが、 /usr/include/linux/i2c-dev.hというヘッダに、i2cアクセスの為の関数が入っている という情報を元に手元のファイルを調べてみるも、そんな関数定義は どこにも無かったり。なんだこりゃ?

どうやら userspace I2C programming library development files (libi2c-dev-*というパッケージ) をインストールする必要があった模様。インストールすると /usr/include/linux/i2c-dev.hが上書きされてi2cアクセスの為の関数 定義が含まれるようです。てかこれ、アンインストール(remove)で元の ファイルに戻せるのか?という疑問が生じますがそれはそれとして。 さておき、linux/i2c-dev.hに示されるi2cアクセスの関数は全て static inline 定義されている為、実質マクロ関数のような感じです。 この為、D言語向けに移植するのも難しく無いかも。

そういや2020年のオリンピック対応で祝日が移動しますが、 拙作のmcalendarを対応してみたり。と言っても、2019年までで一旦、 「海の日、山の日、体育の日」のルールを終了して、2020年の 「海の日、山の日、スポーツの日」を固定休日ルールで設定、 2021年以降は「海の日、山の日、スポーツの日」のルールを再度設定する という感じで対応してみたり。まぁ、煩雑ではありますが祝日の 定義変更だけで済みました。 それよりも2019年の5月1日が もし祝日になった場合のオセロルールに対応できていない事に気づいたり。 もし 5/1が祝日の場合、4/29の昭和の日に挟まれる4/30と、5/3の憲法記念日 に挟まれる5/2はオセロルールで「国民の休日」となりますが、 mcalendarでは月を跨いだオセロルールが想定できてなくて、 4/30が国民の休日に判定されません(^^; そんな訳で見直して みたのですが、まぁまぁ面倒な感じでどうにか対応。 でも、まだ5/1が祝日になるって決まってないんだよなぁ? また、祝日ではなく休日扱いだとすると、オセロルールは 適用されないのですが、mcalendarでは祝日しか定義が無いので 休日の場合はオセロルールを適用しないような対応が別途必要 というのに今気づいた......

その後、今のところ内閣府の「国民の祝日について」という Webページを 見る限り、2019年5月1日は祝日では無さげ。月跨ぎのオセロルールを 修正したけど意味無かったかも。ちぇっ。

2018/08/11

昼頃起床。

具合が悪くてぐったり。

GDCの8/5付けのmasterを元にgcc-8.2.0向けブランチが更新されて いたので、Piでビルドしてみる事にしたり。フロントエンドが D言語化されているので、先日ビルドしたgdcが必要になります。 見ているうちには終わらず。

2018/08/10

早めに帰着。

PiでPOV-Ray。1threadでもベンチマーク時間を計ってみたり。


$ tail -7 alltext.out
----------------------------------------------------------------------------
Render Time:
  Photon Time:      0 hours  0 minutes 13 seconds (13.054 seconds)
              using 4 thread(s) with 13.080 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       1 hours 43 minutes  0 seconds (6180.847 seconds)
              using 1 thread(s) with 6179.994 CPU-seconds total

因みにデスクトップPCの方は以下。

$ tail -7 alltext.out
----------------------------------------------------------------------------
Render Time:
  Photon Time:      0 hours  0 minutes  1 seconds (1.365 seconds)
              using 4 thread(s) with 1.374 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  9 minutes 26 seconds (566.043 seconds)
              using 1 thread(s) with 564.953 CPU-seconds total

Trace Timeだけで比べてみると、Pi:PC=6180.847sec:566.043sec なので 約10.9倍Piの方が遅いという感じ。周波数比は Pi:PC=1.4GHz:4.2GHzなので 3倍遅いとしても、残りの3.6倍遅い分はメモリの速度だったりCPUコアの 実装の違いだったりの比が含まれているのかな?と思われます。 先日の実行結果はPi(4t):PC(8t)=1687.320sec:120.012secで Piの方が14倍遅い 感じですが、PCも4threadで計ってみたところ、Pi(4t):PC(4t)=1687.320sec:159.671sec となり、約10.7倍Piが遅いという感じで、ほぼ1threadの比と同じになりました。

浮動小数点演算を沢山使うベンチマークだと思いますので、整数系の ベンチマークだとまた違った結果が出るかも知れませんが、 mp4の再生なんかも鑑みると 10年前のPCと同等かそれより速いと 言えそうです。

2018/08/09

早くも無く遅くも無く。

PiでPOV-Rayのビルドの続き。makeを仕掛けてたのが途中でコンパイル エラー。これもboost関連で、時間取得をするのに「boost::TIME_UTC」が 「boost::TIME_UTC_」に変更されていたというもの。それにしても こんなに色々直さないとダメなものなのか?
その後も、いくつか修正の必要な箇所を直してどうにかビルドに成功。 試しに scenes/incdemo/colors.pov をレンダリングしてみて ひとまず大丈夫そう。--benchmarkで動かしてみたところ、 サマリの最後の方だけですが以下のような感じに。

$ tail -7 alltext.out
----------------------------------------------------------------------------
Render Time:
  Photon Time:      0 hours  0 minutes 11 seconds (11.207 seconds)
              using 7 thread(s) with 12.900 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours 28 minutes  7 seconds (1687.320 seconds)
              using 4 thread(s) with 6683.938 CPU-seconds total


$ /usr/local/povray_370RC6/bin/povray --version
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
POV-Ray 3.7.0.RC6

This is a release candidate of POV-Ray version 3.7.0.
General distribution is strongly discouraged.

Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.

Built-in features:
  I/O restrictions:          enabled
  X Window display:          disabled
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
  Unsupported image formats: openexr

Compilation settings:
  Build architecture:  armv7l-unknown-linux-gnueabi
  Built/Optimized for: armv7l-unknown-linux-gnueabi
  Compiler vendor:     gnu
  Compiler version:    g++ 6.3.0
  Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -pthread

遅くは無いですが、凄く速い訳でもないかな?という感じ。温度は60℃くらいを前後してる感じでした。

Cygwinでもビルドして、Corei7-7700K(@4.20GHz)の8threadで実行した結果は 以下のような感じ。

$ tail -7 alltext.out
----------------------------------------------------------------------------
Render Time:
  Photon Time:      0 hours  0 minutes  1 seconds (1.192 seconds)
              using 11 thread(s) with 1.373 CPU-seconds total
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  2 minutes  0 seconds (120.012 seconds)
              using 8 thread(s) with 904.074 CPU-seconds total


$ /usr/local/povray_370RC6/bin/povray.exe --version
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
POV-Ray 3.7.0.RC6

This is a release candidate of POV-Ray version 3.7.0.
General distribution is strongly discouraged.

Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.

Built-in features:
  I/O restrictions:          enabled
  X Window display:          disabled
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
  Unsupported image formats: openexr

Compilation settings:
  Build architecture:  i686-pc-cygwin
  Built/Optimized for: i686-pc-cygwin (using -march=native)
  Compiler vendor:     gnu
  Compiler version:    g++ 7.3.0
  Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -malign-double -march=native

やっぱ速いね。

2018/08/08

早めに帰着。

PiでPOV-Rayのビルド。configureが通らなかった点は修正可能そう だったので、少し古いのですがpovray-3.7.0.RC6を直してみる事に。 configureが通らなかったのは、boostのライブラリが指定されてなくて リンクに失敗した模様。。そこを直せば先に進めました。で、問題はソースコードの 修正。こちらもboost関連の名前空間が問題のようで、エラーする所は 片っ端からboost::を追記する感じでひとまずコンパイルできそうな 所まで進めたり。

あまりの眠さに急速停止。

2018/08/07

早めに帰着。

昨日大分かかってgdcのビルドが終わっていたようですが、 途中でコンパイルエラーで終了してました。

ビルドにあまりにも時間がかかり過ぎるので、x86_64でのビルドオプションを参考に いくつか--disable-* オプションを積んでみたところ、大分時間が短縮されたり。 ひとまずコンパイルエラーするのは変わらず。

コンパイルエラーしてたのはlibphobosの std/math.d。ちょっと直して先に進めてみたり。 でも、std/net/curl.dのスタティックライブラリのコンパイルに メモリを大量消費してるようで、スワップしっぱなしになってて終わらす。 仕方ないので最適化レベルを下げると先に進めたり。高々標準ライブラリの 一モジュールのコンパイルに1GBじゃメモリが足りないってどんだけ?

ひとまずビルド完了。make installして簡単なコードをコンパイル&実行してみた 所、問題無く動きました。

$ cat iam.d
import std.stdio;
import std.string ;
import std.compiler;

int main()
{
  writef("%s %s %s.%03d (D%s)\n",name,vendor,version_major,version_minor,D_major) ;
  version( GNU     ) writef("I am GNU\n"    ) ;
  version( Unix    ) writef("I am Unix\n"   ) ;
  version( linux   ) writef("I am linux\n"  ) ;
  version( Windows ) writef("I am Windows\n") ;
  version( MinGW   ) writef("I am MinGW\n"  ) ;
  version( MinGW32 ) writef("I am MinGW32\n") ;
  version( MinGW64 ) writef("I am MinGW64\n") ;
  version( cygwin  ) writef("I am cygwin\n" ) ;
  version( Win32   ) writef("I am Win32\n"  ) ;
  version( Win64   ) writef("I am Win64\n"  ) ;
  version( Posix   ) writef("I am Posix\n"  ) ;
  version( X86     ) writef("I am X86\n"    ) ;
  version( X86_64  ) writef("I am X86_64\n" ) ;
  version( ARM_SoftFloat ) writef("I am ARM_SoftFloat\n" ) ;
  version( ARM     ) writef("I am ARM\n"    ) ;
  version( PPC     ) writef("I am PPC\n"    ) ;
  version( PPC64   ) writef("I am PPC64\n"  ) ;
  version( PPC_SoftFloat ) writef("I am PPC_SoftFloat\n" ) ;
  version( PPC_HardFloat ) writef("I am PPC_HardFloat\n" ) ;

  return(0) ;
}

$ gdc -O2 iam.d

$ ./a.out
GNU D gnu 2.068 (D2)
I am GNU
I am linux
I am Posix
I am ARM

$ gdc -v
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc_2076_710/libexec/gcc/arm-linux-gnueabihf/7.1.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-7.1.0/configure --with-pkgversion='gdc-7 067ed77828(DMD2.068.2)' --enable-languages=c,c++,d --prefix=/usr/local/gdc_2076_710 --with-arch=armv6 --with-fpu=vfp --with-float=hard --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-checking=yes --disable-libgomp --disable-libmudflap --disable-libsanitizer --disable-nls --disable-bootstrap
Thread model: posix
gcc version 7.1.0 (gdc-7 067ed77828(DMD2.068.2))

マンデルブロ集合を描くコードも動いたので、ある程度の事は できそうです。

サマータイム導入? 必要無いでしょ。マラソンも7時が心配なら5時に すればイイだけじゃん? オリンピックに便乗して関係無いもの乗っけすぎ。

2018/08/06

早めに帰着。

一旦止めてたgdcのビルドを再開したものの、見ている間には終わらず。

あまりの眠さに急速停止。

2018/08/05

AM中に起床。

掃除したり。

PiでPOV-Rayがビルドできないかとコンパイルを試してみるも、 何故かconfigureが通らなくてmake実行まで到達できず。 古いバージョンである3.6.1だとconfigureは通るのですが、 対応しているlibpngが古すぎて今のバージョンのlibpngでは コンパイルエラーになったり。
CPUに負荷をかけてみたかったのですが、仕方ないので 途中までコンパイルできるのを利用して make -j4 で 実行してみたり。すると、idle時は41℃程度だった温度が 59℃まで上がったり。ファンは消音の為にDC5V規格に対して 3.3Vで回しているのですが、ファン無しだともっと上がる 可能性があるかもとは思ったりも。因みにWebでの情報だと 80℃くらいまで上がる場合がある模様。

Piで動画とか再生するとどんな感じ?と思って試してみたり。 専用プレイヤーは入っていなさげだったので、 Raspbianの標準ブラウザであるところのChromiumをプレイヤー としてみました。FullHDの30fps,60fpsと4kの30fpsを試して みたのですが、FullHD-60fpsと4K-30fpsは激しくコマ落ちして 視聴に耐えられませんでしたが、FullHD-30fpsでは所々 コマ落ちする場合はあるものの概ね普通に見られる感じでした。 表示画面を小さくすればフレームレートは上がる感じの ようなので、ブラウザで動画を見るような場合はほぼ問題無い ものと思われます。何気にスゲー。 というのも、Pentium4(3.06GHz)ではFullHD-30fpsのmp4ですら 全く歯が立ちませんでしたから(参考)。

VNCでPiのデスクトップ画面をPCで表示してみたり。 UltraVNCのビュアを使った所、 「not supported authentication methods」なるメッセージが出て 接続できず。どうやらPi側のVNCサーバーでUNIXユーザーのパスワードを使う 設定になっているようなのですが、それをVNCユーザーパスワードを使う ように、右上のメニューボタン→Options内のSecurityの AuthenticationをUNIX passwordからVNC passwordに変更してみたり。 とりあえず接続可能になったのですが、1分ほどで応答無しになり、 なんか勝手がイマイチな感じだったり。その後、 VNCが応答無しになるのはWifi接続していたのが要因にある感じなのが判ったり。 有線LAN接続すると大丈夫そう。

VNCが使えるのでひとまずディスプレイ/キーボード接続無しにしてみたり。 所がVNC接続してみると解像度が低すぎてダイアログウインドウが操作 できない状況になったり。結局、「設定→Raspberry Piの設定」で 解像度をデフォルト(ディスプレイの表示解像度に合わせる?)から 1920x1080に固定するようにしてみたり。ひとまずOKそう。

そういやRaspbianのアプリに「タスクマネージャー」というのが あるのですが、使用中メモリの表示が「メモリ:213MB中の927MBが使用中」 と表示されてて、分子と分母が逆じゃね?と思ったり。

gdcをビルドしてみる事にしたり。インストール済のgcc -vでconfigure オプションを調べて、それを元にconfigureオプションを指定。GMPとかMPFR のdevelパッケージインストールするする必要がありましたが、ひとまず configureは通ってmakeファイルが生成されたり。make実行してみるも 手加減して1core使用にしたら終わらず。

気が付いたらAssembly 2018が終わってたり。結果や動画のいくつかは Pouetに上がってるようです。 で、combined 4kの1位の作品「HBC-00016: Core Critical」。 何この4096byteのhtmlファイル!?怖っ!!(褒め)そんな感じです。 因みに、IE,Chromeでは実行できず。Firefoxで実行できました。

2018/08/04

AM中に起床。

秋葉原でお買い物。

急に思い立ってRaspberry Piを買ってみたり。 買ったのは一番新しい Pi3のmodel B+。殆ど秋月電子で 調達したのですが、CPUの温度が高くなるらしかったので Seeed Studioのファン付きケースだけは千石電商(の最近 オープンしたらしいラジオデパート店の方)で購入してみました。 念のため買ったコネクタの圧着ペンチだとか、SDカード の方が思いのほか高かったりする罠。

帰って早速ケースを組み立ててみたり。パッケージ(チャック付きポリ袋に入ってるだけ) も組み立て説明書も無いという製品なのですが、何気に組み立てにコツが 必要な製品でした(^^; ファンの電源はPi本体のピンから給電 するのですが、5Vだとファンがうるさいという事だったので、 2ピンのコネクタ用ハウジングを1ピンにバラして3.3Vからの 給電を可能にする改造をしてみました。 ここで、ケーブルを切って新しくコネクタを圧着する必要 があるかと圧着ペンチも購入したのですが、元の2ピンのハウジング を外す事ができたので、コネクタはそのままにハウジングだけを 1ピンのものに交換して改造完了。圧着ペンチ、結構高かったの ですが...(T_T)

aarch64がどんなもんか見てみたかったので、OSは Fedoraの aarch64向けカーネルを試してみる事に。 専用のメディア書き込みツールを 使用したのですが、いきなりExt4のパーティションで書き込むらしく、 書き込み完了したらWindowsで認識できないファイルシステム になるようです。

本体を設置。HDMIはCC2のデスクトップモードで使用するケーブルを繋いで、 CC2をディスプレイに。USBキーボードとマウス、有線LANを接続して 電源ON(アダプターをコンセントに挿す)。 とりあえずbootが始まり、しばらくすると初回のユーザー登録 ダイアログが立ち上がりました。とりあえずユーザー登録 してリブート。ログインしてターミナルを開いたのですが、 何故かウインドウのフォーカスができない状態に。シャットダウン メニューも選択不能になった為、電源ブチ切で再起動。 やっぱり途中でマウス操作ができなくなる感じだったり。

ここでファンの音ですが、実際に5Vだと唸り音がかなりうるさいですが、 3.3VだとエアコンとTVを消さないと動いているのが判らないくらいの 音になりました。

Fedoraの方は全く用事にならなかったので、NOOBS(というOSインストーラ)を SDカードに入れ直してRASPBIANを試す事に。問題はFedoraを入れたSDカードが Ext4ファイルシステムになっている為、Windowsで認識できない メディアになってしまっている事。ドライブとしても見えないので、 フォーマットも起動する事ができません。そこで 「 AOMEI Partition Assistant」というソフトを使って、 ドライブを認識し、パーティションを一旦解放&領域確保で FAT32フォーマットを行ってまっさらな状態にする事で Windowsに認識されるようになりました。

で、改めてNOOBS LITEをSDカードに入れて(ZIPの中身をSDカードの ルートディレクトリにそのままコピー)、電源ON。 OS選択画面が立ち上がり、Raspbianを選ぶとネットワークインストール が開始され、ほどなくしてインストール完了。こちらはもっさりする事 も無くサクサクと動くようです。

別のSDカードを使ってWindows10 IoT COREを試してみる 事にしたり。NOOBSで選べるのでイケるかと思い試してみたところ、 今のバージョンではサポートしてないようでインストールに失敗。 どうやってインストールするんだ?と思い検索してみた所、 こちらのビデオ を参考にしてみたり。専用のツールでSDカードへの書き込みを 行う感じのようです。で、書き込まれたSDカードを挿して 電源を入れてみたのですが、Piの初期画面のままbootしている 様子は無かったり。

aarch64がどんなもんか一番見てみたかったのですが、不安定なので 様子がみられず残念。少し待てば状況変わるかな?

2018/08/03

早めに帰着。

金曜ロードSHOW!で放送されていた「オデッセイ」。 火星で1年過ごすよりも2回往復(片道1年として4年くらい)を 宇宙船で過ごす方が大変なんじゃないかとは思ったりも。
検索してたら 「 リアル『オデッセイ』−火星で一人ぼっちで過ごすのにかかる費用は?−」 という文書を知ったり。本当かどうかは分かりませんが、 「高っっっか」そんな感じ(笑。 まとめにある火星テラフォーミングの話は、 個人的には当分実現は無理なんじゃね?と思ったりも。というのも、それが できるくらいであれば、現在の地球温暖化問題とかとっくに対策可能と 思われるから。

調べ事。

そういや UWP(Universal Windows Platform)アプリのウインドウ描画が変になる件。 一つ前のメモで、マイクロソフト のコミュニティーに事例報告されているのを知ったのですが、 それとは別に同様の事例が報告されていたり。 動画が添付されてますが まさにこの状況で、投稿者のNVIDIAもしくはUWP基盤のバグ という推測にはTANEも激しく同意(NVIDIAが関係すると思ったときの メモ)という感じなのですが、 何も情報を持ってない人が話の腰を折っててガッカリ。 それにしても、このバグに遭遇してから 10カ月ほど経つ(その間、PCは全く別のに変わっても再現している)のですが、 世の中ではそんなに稀な現象なのか?

2018/08/02

気持ち早めに帰着。

そういやASSEMBLY SUMMER 2018 が始まります。ヘルシンキの現地時間でドアオープンされてそう ですが、ストリーム動画はまだ見られなさげ。

数十分後に見られるようになったり。

2018/08/01

早めに帰着。

あまりの眠さに急速停止。


TOP PREV