2014/02/22

BeagleBoard-xM 上に Ubuntu 環境を構築する （Windows 編）
以前、BeagleBoad-xM 上に Ubuntu 環境を構築する方法を書きました。
参考
穀風: BeagleBoard-xM 上に Ubuntu 環境を構築する

ただ、この方法、Ubuntuまたは、他の Linux でも可能なはず を使うこと前提で書いたので、今回は Windows で行う方法を書いてみようと思います。
と言っても、Cygwin 使って raw image を焼くだけなので、Linux でも可能です。
以下、Cygwin がインストールされ、基本的なコマンドもインストールされているものとして書いていきます。
参考
BeagleBoardUbuntu - eLinux.org
Method 1: Download a Complete Pre-Configured Image - raw microSD img

Raw Image を用意

Cygwin のコンソール上では以下のようにダウンロードします。
ブラウザ等を用いてもダウンロード可能でしょう。
$ wget https://rcn-ee.net/deb/microsd/saucy/bbxm-ubuntu-13.10-2014-02-16-2gb.img.xz

正しくダウンロード出来たか確認します。
$ echo "3cb914ae8fb848139ba7311b980b54c0 bbxm-ubuntu-13.10-2014-02-16-2gb.img.xz" | md5sum -c
bbxm-ubuntu-13.10-2014-02-16-2gb.img.xz: 完了

解凍します。
Cygwin の unxz で簡単に解凍できますが、Explzh for Windows 等でも解凍出来ました。
$ unxz bbxm-ubuntu-13.10-2014-02-16-2gb.img.xz

SD Card スロットの確認

SD Card をスロットに差し込み、そのデバイスノードを確認します。
$ cat /proc/partitions
major minor  #blocks  name

    8     0 250064896 sda
    8     1  13302784 sda1
    8     2    102400 sda2
    8     3 236657664 sda3
    8    16  15110144 sdb
    8    17  15106048 sdb1

今回、16GB の SDカードを用意しましたので、sdb が対象のデバイスノードだとわかります。

イメージの書き込み

Cygwin コンソールを管理者権限で実行します。

以下のように書き込みます。
注意：/dev/sdb はご自分のデバイスと読み替えてください。誤ったデバイスを指定すると、その内容を全消去してしまいます！ 
$ dd if=./bbxm-ubuntu-13.10-2014-02-16-2gb.img of=/dev/sdb
3481600+0 レコード入力
3481600+0 レコード出力
1782579200 バイト (1.8 GB) コピーされました、 16.0868 秒、 111 MB/秒

Cygwin が無くとも、Windows 上で dd を行うソフトが様々公開されているようなので、それらを使用すれば可能だと思います。
参考
私は使用していないのですが、以下の様なソフトです。
DD for Windows

パーティションサイズを広げる

起動したら、以下のユーザとパスワードでログインします。
User: ubuntu
pass: temppwd

現時点ではSDカードの 2GB しか使用していないので、サイズを広げます。
$ cd /opt/scripts/tools
$ git pull
$ sudo ./grow_partition.sh
$ sudo reboot

パスワード変更

必須ではないですが、セキュリティ的にはパスワードを変更しておいた方が良いでしょう。
$ passwd
Changing password for ubuntu.
(current) UNIX password: 
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

以上でOSのインストール終了です。

2014/02/20

Windows の Bluetooth SPP で割り当てられた COMポートを変更する方法
Windows で Bluetooth SPP Client 機能を持ったデバイスとペアリングすると、自動的に COMポートが割り当てられます。
しかし、これが変なポートに割り当てられてしまうことも。
このポート番号、以下のようにして変更することが出来ます。
続きを読む »
2014/02/19

Windows を Bluetooth SPP Server として使用する方法
Bluetooth SPP の Server 機能を持った機器と Windows をペアリングすると、基本的には COM ポートを自動生成してくれます。
逆に、SPP Client 機器と Windows を通信させたい場合は、Windows 側が Server として待ち受けなければいけませんが、その方法がちょっとわかりにくいので、書いておきたいと思います。

以下の Windows で動作確認をしています。
Windows 7 Professional SP1
Windows 8.1
続きを読む »
2014/02/01

Android のログレベル使い分け
Android の Log には以下のようなログレベルが用意されていますが、その使い分けが明確に決まっているわけではありません。
  • Verbose
  • Debug
  • Info
  • Warn
  • Error
  • Assert
プロジェクトでルールが決まっている場合はそれに従えば良いのですが、個人の場合、使い分けに悩みます。
私も、しばらく試行錯誤してきたのですが、ある程度自分のルールが決まったので備忘録として書いておきます。また、そのうち変わるかもしれませんが。

Verbose

一時的なデバッグに使用。
例えば、以下のようにループ中のデータを確認したい場合等です。

        while ((buff = fileInputStream.read()) != -1) {
            Log.v(TAG, "read data " + buff);
            
            // Do something
        }

動作確認が終わった場合は、コードごと消してしまうのが前提。
このコードが残っていると、動作が非常に遅くなりますし、LogCat のバッファがあっという間に埋まってしまいます。
まさに Verbose （冗長）なログです。

リリースする前に検索をかけて Verbose を使用しているところが無いようにします。

Debug

名前のごとく、デバッグ用に使用します。
Verbose と違って定常的なデバッグログ出力用です。
自分（と内部構造に明るいメンバー）に動作状況がわかるような情報を提供します。
例えば、以下のように特定のメソッドが呼ばれたかどうかを観測するために使ったりします。

        view.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.d(TAG, "onClick");
                
                // Do something
            }
        });

リリース時、コードは残しますがログが出ないように細工します。（細工については後述）

Info

これもデバッグに必要な情報を出力するのに使用します。
Debug との違いは、そのプロダクトがライブラリだったと仮定し、ブラックボックスとして使っているユーザにも意味のある情報を提供するために使用する点です。
例えば、以下のように読み込んだファイルサイズを出力する等です。

        int size = 0;
        while ((buff = fileInputStream.read()) != -1) {
            // Do something
            size++;
        }
        Log.i(TAG, "The size of read file is " + size);

Debug との違いが微妙なので、判断が難しいこともありますが、あまり厳密に考えないのがポイントです。
リリース時、コードは残しますがログが出ないように細工します。（細工については後述）
ただし、ライブラリとして提供する場合は、ログを出しておく場合もあります。

Warn

本来、起こってはいけないが、場合によっては起こりえるエラーが発生した場合に使用します。
例えば、以下のようにファイルが存在しなかった場合等です。

        try {
            fileInputStream = new FileInputStream(file);
        } catch (FileNotFoundException e) {
            Log.w(TAG, "File not found. : " + file, e);
        }

Warn は必然的に catch句の中に記述されることが多くなります。
余談ですが、catch句の中に記述されるログは上述のように Stack Trace も表示するようにしています。

リリース時、コードは残しますがログが出ないように細工します。（細工については後述）
ただし、ライブラリとして提供する場合は、ログを出しておく場合もあります。

Error

プログラムの構造上起こりえないエラーが発生した時に使用します。
例えば、先ほどの FileNotFoundException も、事前にそのファイルを生成することが保証されているのであれば、Error を使用します。

        if (!file.exists()) {
            // Do something
            return;
        }
        try {
            fileInputStream = new FileInputStream(file);
        } catch (FileNotFoundException e) {
            Log.e(TAG, "File not found. : " + file, e);
        }

上記の例でも、ファイルの存在確認を行った直後に、別のプログラム等にファイルが消されたりすると Error が起こります。
そこまで考慮してプログラムを書いているのであれば、Warn を使用し、そのようなことを考慮していないのであれば Error とするわけです。
基本的には、自分が起こりえないと思っている、もしくは起こる可能性が限りなく低いと思っている事象に対して Error を使います。

Error は、リリース時にもログが出るようにしておきます。

Assert

基本的に使用しません。
このログレベルはシステムに重大な問題が起こった場合のものなので、一般プログラマが使用することは無いと思います。

ログが出ないように細工する件について

私はリリース時にログが出ないように細工をしています。
Java にはプリプロセッサが無いので、ログの出力を切り替えられるクラスを用意しています。
具体的には以下の様なクラスです。
参考
GitHub tmhouse/Padme

ただ、実際はもっと簡単なテンプレートを用意して使っています。
というのも、個人的には、この手のクラスはライブラリ化するより、都度作った方が良いと思っているので。

2014/8/12 追記
さらに良い方法がありました。
穀風: Android の Log をリリース時にだけ表示しないようにする方法