Mtk's Blog

2011年9月3日土曜日

[GPS] 経度1度の距離の求め方

How to get distance of 1degree longitude

緯度（北緯）1度あたりの距離はおよそ111kmですが、経度（東経）1度あたりの距離は緯度によって大きく変わります。
経度1度の距離は赤道に近づくほど大きく、遠ざかるほど小さくなります。
GPSセンサーを使ったアプリケーションで距離を測る時に困ってしまいます。

経度1度のおおよその距離(km)は次の式で求められます。

経度1度の距離(km) = cos(緯度×0.017453293) × 111.3194908
※0.017453293=2×π÷360（角度からラジアンを求める係数）
※111.3194908=6378.137×2×π÷360（地球を半径6378.137kmの球として断面の円周を求める係数）

cos関数の括弧の中は緯度（北緯）のラジアンです。経度（東経）ではないのでご注意ください。緯度と経度を間違えると正しく計算できません。

この計算は地球を真円としてしますが、実際の地球は楕円です。
計算結果がどれくらい誤差があるのか、国土地理院の距離と方位角の計算と比較してみます。

緯度（北緯）	計算値(km)	国土地理院(km)	大まかな位置
20	104.60610	104.64693	沖ノ鳥島
26	100.05330	100.11747	尖閣諸島
33	93.36038	93.45286	四国、九州
36	90.05936	90.16329	関東、近畿、竹島(島根県)
40	85.27568	85.39341	東北
44	80.07654	80.20570	北海道

案の定、赤道から遠ざかるほど誤差が大きくなってます。北緯44度の地点で誤差0.16%です。
とは言え、三角関数1個の計算で距離が求まるので、~~スマートフォン用アプリケーションには十分だと思います~~。 (※1)
実際に使ってみると計算誤差よりセンサーの誤差のほうが大きいくらいです。

distance(km) of 1degree longitude = cos(latitude_degrees * 0.017453293) * 111.3194908

計算にはMicrosoft Excel 2010を使いました。

(※1) 2010年当時、スマートフォンが今のものよりスペックが低くバッテリー容量が少なかった頃の考えです (2016年4月追記)

以上、参考になれば幸いです。

2011年8月27日土曜日

[AV] コンポーネント端子がついてないテレビにPS2や古いDVDプレイヤーを接続する

How to connect component terminal to D terminal?

テレビも液晶ディスプレイも故障したため新しいテレビを買を買ったのですが、このテレビにはコンポーネント端子がついていません。（承知の上で買いました）
今までのテレビが10年以上前に買った製品だったので、ゲーム機もDVDプレイヤーもコンポーネント端子でつなげていました。

テレビ背面の端子。コンポーネント端子やS端子がありません。

左がプレステ2用、左が汎用

綺麗な映像を見たいのでコンポジット端子は使いたくありません。
このテレビにはD端子がついてるのでD端子ケーブルを買えばいいのですが、機器に合わせて全部そろえるとしたら大きな出費です。
HDMIの時代に、アナログ規格のケーブルに投資するのは気が引けてしまいます。

そこで、1780円前後で売られているコンポーネント端子をD端子に変換するケーブルを買いました。
富士パーツD端子コンポーネント変換ケーブル AD-513　0.1m（D端子・オス－コンポーネント端子・メス）

AVケーブルD端子⇔コンポーネント端子変...
価格：1,785円（税込、送料別）

富士パーツ0.1mD端子コンポーネント変換ケーブル ...
価格：1,780円（税込、送料別）

これで綺麗に映りました。

私事ですが、プレステ用のAVケーブルはコンポーネント端子ケーブルの他、21ピンアナログRGBケーブルやS端子ケーブルも持ってます。
過去にいろいろなAV規格があったのに、デジタル時代の今ではHDMI、DisplayPort、Thunderboltといった異なる規格が乱立してます。
日本のメーカーのノートパソコンにはHDMIがついてますが、HP製にDisplayPort、アップル製にThunderboltといった別の規格がついてます。
ノートパソコンの映像を外部出力するにはそれぞれの規格に対応した装置が必要になってしまいます。
規格争いはいい加減にして欲しいですね。

2011年8月20日土曜日

[Android] ThumbモードとARMモード、どちらが速いのか？

Which is faster, Thumb or ARM?

多くのAndroid端末に使われているARM系CPUは16ビットのThumbモードと32ビットのARMモードとがあります。
「ARMモードの方が速い」という意見がある一方、「Thumbモードはプログラムサイズが小さい分メモリーアクセスが少ない」という意見があり、どちらが効率がいいのかよくわかりません。
そこで、ThumbモードとARMモードを比較してみました。

Activityのソース(Main.java)

package jp.fujiu.NdkBench;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.widget.Toast;

public class Main extends Activity {
 static {
  System.loadLibrary("ndk");
 }
 native private void ndkBenchInt(int arg);
 native private void ndkBenchFloat(float arg);
 native private void ndkBenchAtan2(double arg);
 
 @Override
 public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  long t1;
  long t2;
  String result;
  
  //(1)int型(32ビット)の検証
  t1 = System.currentTimeMillis();
  
  ndkBenchInt(100);
  ndkBenchInt(1000);
  ndkBenchInt(10000);
  
  t2 = System.currentTimeMillis();
  
  result = "ndkBenchInt: " + (t2 - t1) + "ms";
  Log.d("result", result);
  Toast.makeText(getApplicationContext(), result, Toast.LENGTH_LONG).show();
  
  
  //(2)float型(64ビット)の検証
  t1 = System.currentTimeMillis();
  
  ndkBenchFloat(0.01f);
  ndkBenchFloat(0.001f);
  ndkBenchFloat(0.0001f);
  
  t2 = System.currentTimeMillis();
  
  result = "ndkBenchFloat: " + (t2 - t1) + "ms";
  Log.d("result", result);
  Toast.makeText(getApplicationContext(), result, Toast.LENGTH_LONG).show();
  
  
  //(3)atan2関数(複雑な計算)の検証
  t1 = System.currentTimeMillis();
  
  ndkBenchAtan2(0.1);
  ndkBenchAtan2(1.0);
  ndkBenchAtan2(10.0);
  
  t2 = System.currentTimeMillis();
  
  result = "ndkBenchAtan2: " + (t2 - t1) + "ms";
  Log.d("result", result);
  Toast.makeText(getApplicationContext(), result, Toast.LENGTH_LONG).show();
 }
}

jni/nck.cpp

#include <jni.h>
#include <math.h>

extern "C" JNIEXPORT
void JNICALL Java_jp_fujiu_NdkBench_Main_ndkBenchInt (JNIEnv *, jobject, jint arg){
 const unsigned int SIZE = 0x008fffff;
 unsigned int i;
 
 int *p = new int[SIZE];
 for (i=0; i<SIZE; i++){
  p[i] = arg;
 }
 delete [] p;
}

extern "C" JNIEXPORT
void JNICALL Java_jp_fujiu_NdkBench_Main_ndkBenchFloat (JNIEnv *, jobject, jfloat arg){
 const unsigned int SIZE = 0x004fffff;
 unsigned int i;
 
 float *p = new float[SIZE];
 for (i=0; i<SIZE; i++){
  p[i] = arg;
 }
 delete [] p;
}

extern "C" JNIEXPORT
void JNICALL Java_jp_fujiu_NdkBench_Main_ndkBenchAtan2 (JNIEnv *, jobject, jdouble arg){
 const unsigned int SIZE = 0x004fffff;
 unsigned int i;
 
 double *p = new double[SIZE];
 for (i=0; i<SIZE; i++){
  p[i] = atan2(arg, (double)i);
 }
 delete [] p;
}

Android.mk(Thumbモードの場合)

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := ndk
LOCAL_SRC_FILES := ndk.cpp
include $(BUILD_SHARED_LIBRARY)

Android.mk(ARMモードの場合)

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := ndk
LOCAL_SRC_FILES := ndk.cpp
LOCAL_ARM_MODE := arm
include $(BUILD_SHARED_LIBRARY)

結果
(1)int型(32ビット)の検証
エミュレーター・実機(IS01)とも、Thumbモードの方が速い。

(2)float型(64ビット)の検証
エミュレーターではARMモードの方が速く、実機(IS01)ではthumbモードの方が速い。

(3)atan2関数(複雑な計算)の検証
エミュレーターではARMモードの方が速く、実機(IS01)ではthumbモードの方が速い。

結論
Thumbモードの方が速い場合がある。
ARMモードが常に速いとは限らないようです。Android-NDKを使ったアプリケーションを公開する時は機種ごと・アプリごとにベンチマークを取って比較した方がいいようです。

以上、参考になれば幸いです。

2011年8月13日土曜日

[Android] 自身をタスクキルするアプリケーションを作るには

How to kill the application's own self

Androidアプリケーションは終了すると、何の処理をしなくてもRAM(メモリー)に残ります。
（終了してもバックグランドで処理を続けるプリケーションもあります）
他のアプリケーションが起動するなど、空きメモリーが必要になったときにOSがRAMから消します。
アプリケーションがRAMに残っていた方が速く起動できるし、バッテリーやフラッシュROMの寿命も長持ちします。

ただ、アプリケーションが終了後もRAMに残ることに不安を覚えるユーザーも少なからずいらっしゃるようです。
そこでActivityを終了したらRAMから消える（タスクキル）サンプルを作ってみました。

ソースです。
Activityのソース用（Main.java）

package jp.fujiu.AndroidApp.ProcessKiller;

import android.app.Activity;
import android.os.Process;

public class Main extends Activity {
 @Override
 protected void onDestroy() {
  super.onDestroy();
  Process.killProcess(Process.myPid());
 }
}

※パーミッション不要のため、マニフェストは省略

onDestroyメソッドの最後に Process.killProcess(Process.myPid()); を書くだけです。

アプリケーションを起動するとタスクリスト（※）にパッケージ名が表示されます。
（※正式名称は不明ですがここでは「タスクリスト」と呼びます）
一度起動したアプリケーションは、RAMに十分な空き容量があれば終了してもタスクリストから消えないのが普通です。

Process.killProcess(Process.myPid()); が実行されると直ちにタスクリストから消えます。

ちなみにタスクキルすると
INFO/ActivityManager(**): Process jp.fujiu.AndroidApp.ProcessKiller (pid ***) has died.
というログが残ります。異常終了したときと同じ内容なので、あまりいい気分ではありません。
タスクキルのメリットを強いて上げるならメモリーリークを解放してくれるようですが、メモリーリークを起こしているならタスクキルに頼らずコードを直すべきです。
本当にタスクキルするかどうかをユーザーに確認する画面を用意した方がいいと思います。

以上、参考になれば幸いです。

2011年8月6日土曜日

[Android] Android-NDKでテクスチャを表示するには

How to draw textures in Android-NDK

Havaは大きいソースが扱えないので、[Android] 頂点の多いポリゴンを扱うにはでは頂点数の多いポリゴンをAndroid-NDKを使ってJNIからJavaに大きい配列を渡す方法でバナナを表示しました。この方法はFloatBufferの作成に時間がかかるという問題がありました。
今回は、頂点とテクスチャの機能もJNIで書いてみます。

JNIで画像を扱うには？
テクスチャを表示するためglTexImage2Dを使います。
glTexImage2Dで表示できるテクスチャ画像はunsigned char型配列のビットマップデータです。配列の内容は1ピクセルごとにRGBAの順に1バイトずつです。
このブログを作成している時点ではJNIからres/drawableフォルダーやassetsフォルダーのファイルを扱う方法が見当たりませんでした。
そこで、JNIで画像データを扱うために次のようにしました。

Javaでres/drawableフォルダーの画像をint型配列に変換してJNIに渡す
JNIでJavaから渡されたint型配列をunsigned char型配列に変換しテクスチャ表示する

以下ソースです。
ndk.cpp

#include <jni.h>
#include <GLES/gl.h>
#include <GLES/glext.h>
#include "glu.h"
#include "banana.h"

//テクスチャの各定義
GLuint textures[1];
unsigned char *texData;

//テクスチャのサイズ
int texWidth;
int texHeight;

//回転
float xrot = 0.0;
float yrot = 0.0;

extern "C" JNIEXPORT 
void JNICALL Java_jp_fujiu_NdkTexture_Main_setNdkPixels (JNIEnv *env, jobject, jintArray pixels, jint width, jint height, jint size){
 texWidth = width;
 texHeight = height;
 
 // jintArrayをjint配列に変換
 jint* arr = env->GetIntArrayElements(pixels, NULL);
 
 // int型(4バイト)ARGBのピクセル情報を1バイトごとにRGBAに並べ替えてunsigned char型配列に格納
 texData = new unsigned char[size * 4];
 for (int i=0; i<size; i++){
  int j = i * 4;
  texData[j + 2] = arr[i]; //Blue
  arr[i] >>= 8;
  texData[j + 1] = arr[i]; //Green
  arr[i] >>= 8;
  texData[j + 0] = arr[i]; //Red
  arr[i] >>= 8;
  texData[j + 3] = arr[i]; //Alpha
 }
 
 // jint配列を解放
 env->ReleaseIntArrayElements(pixels, arr, 0);
}

extern "C" JNIEXPORT 
void JNICALL Java_jp_fujiu_NdkTexture_Main_setNdkRotate (JNIEnv *, jobject, jfloat x, jfloat y){
 xrot = x;
 yrot = y;
}

extern "C" JNIEXPORT 
void JNICALL Java_jp_fujiu_NdkTexture_Main_onNdkCreated (JNIEnv *, jobject){
 //背景の色
 glClearColor(1.0, 1.0, 1.0, 1.0);
 glClearDepthf(1.0);

 //片面スムーズシェーディング
 glShadeModel(GL_SMOOTH);

 //深度テスト
 glEnable(GL_DEPTH_TEST);

 //モデルビュー変換
 glMatrixMode(GL_MODELVIEW);
 glLoadIdentity();
 
 //テクスチャ処理
 glGenTextures(1, textures);
 glBindTexture(GL_TEXTURE_2D, textures[0]);
 glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texWidth, texHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, texData);
 glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
 glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
}

extern "C" JNIEXPORT 
void JNICALL Java_jp_fujiu_NdkTexture_Main_onNdkChanged (JNIEnv *, jobject, jint width, jint height){
 glViewport(0, 0, width, height);

 //射影変換
 glMatrixMode(GL_PROJECTION);
 glLoadIdentity();

 //視点
 gluPerspective(45, (float)width/(float)height, 0.1, 100);
 gluLookAt(0, 0, 3, 0, 0, 0, 0, 1, 0);
}

extern "C" JNIEXPORT 
void JNICALL Java_jp_fujiu_NdkTexture_Main_onNdkDraw (JNIEnv *, jobject){
 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

 glEnableClientState(GL_VERTEX_ARRAY);
 glEnableClientState(GL_NORMAL_ARRAY);
 glEnableClientState(GL_TEXTURE_COORD_ARRAY);
 glEnable(GL_TEXTURE_2D);
 
 //バナナを表示
 glBindTexture(GL_TEXTURE_2D, textures[0]);
 glVertexPointer(3, GL_FLOAT, 0, bananaVerts);
 glNormalPointer(GL_FLOAT, 0, bananaNormals);
 glTexCoordPointer(2, GL_FLOAT, 0, bananaTexCoords);
 glPushMatrix();
 glRotatef(xrot, 0, 1, 0);
 glRotatef(yrot, 1, 0, 0);
 glDrawArrays(GL_TRIANGLES, 0, bananaNumVerts);
 glPopMatrix();
 
 glDisable(GL_TEXTURE_2D);
 glDisableClientState(GL_TEXTURE_COORD_ARRAY);
 glDisableClientState(GL_NORMAL_ARRAY);
 glDisableClientState(GL_VERTEX_ARRAY);
}

extern "C" JNIEXPORT 
void JNICALL Java_jp_fujiu_NdkTexture_Main_ndkFinalize (JNIEnv *, jobject){
 delete [] texData;
}

glu.h （Android-NDKのsampleの com.example.SanAngeles から抜粋しました）

#include <math.h>
#define PI 3.1415926535897932f

/* Following gluLookAt implementation is adapted from the
 * Mesa 3D Graphics library. http://www.mesa3d.org
 */
static void gluLookAt(GLfloat eyex, GLfloat eyey, GLfloat eyez,
 GLfloat centerx, GLfloat centery, GLfloat centerz,
 GLfloat upx, GLfloat upy, GLfloat upz) {
 GLfloat m[16];
 GLfloat x[3], y[3], z[3];
 GLfloat mag;

 z[0] = eyex - centerx;
 z[1] = eyey - centery;
 z[2] = eyez - centerz;
 mag = (float)sqrt(z[0] * z[0] + z[1] * z[1] + z[2] * z[2]);
 if (mag) {
  z[0] /= mag;
  z[1] /= mag;
  z[2] /= mag;
 }

 y[0] = upx;
 y[1] = upy;
 y[2] = upz;

 x[0] =  y[1] * z[2] - y[2] * z[1];
 x[1] = -y[0] * z[2] + y[2] * z[0];
 x[2] =  y[0] * z[1] - y[1] * z[0];

 y[0] =  z[1] * x[2] - z[2] * x[1];
 y[1] = -z[0] * x[2] + z[2] * x[0];
 y[2] =  z[0] * x[1] - z[1] * x[0];

 mag = (float)sqrt(x[0] * x[0] + x[1] * x[1] + x[2] * x[2]);
 if (mag) {
  x[0] /= mag;
  x[1] /= mag;
  x[2] /= mag;
 }

 mag = (float)sqrt(y[0] * y[0] + y[1] * y[1] + y[2] * y[2]);
 if (mag) {
  y[0] /= mag;
  y[1] /= mag;
  y[2] /= mag;
 }

#define M(row,col)  m[col*4+row]
 M(0, 0) = x[0];
 M(0, 1) = x[1];
 M(0, 2) = x[2];
 M(0, 3) = 0.0;
 M(1, 0) = y[0];
 M(1, 1) = y[1];
 M(1, 2) = y[2];
 M(1, 3) = 0.0;
 M(2, 0) = z[0];
 M(2, 1) = z[1];
 M(2, 2) = z[2];
 M(2, 3) = 0.0;
 M(3, 0) = 0.0;
 M(3, 1) = 0.0;
 M(3, 2) = 0.0;
 M(3, 3) = 1.0;
#undef M
 {
  int a;
  GLfixed fixedM[16];
  for (a = 0; a < 16; ++a)
   fixedM[a] = (GLfixed)(m[a] * 65536);
  glMultMatrixx(fixedM);
 }

 glTranslatex((GLfixed)(-eyex * 65536),
     (GLfixed)(-eyey * 65536),
     (GLfixed)(-eyez * 65536));
}

static void gluPerspective(GLfloat fovy, GLfloat aspect,
                           GLfloat zNear, GLfloat zFar) {
 GLfloat xmin, xmax, ymin, ymax;

 ymax = zNear * (GLfloat)tan(fovy * PI / 360);
 ymin = -ymax;
 xmin = ymin * aspect;
 xmax = ymax * aspect;

 glFrustumx((GLfixed)(xmin * 65536), (GLfixed)(xmax * 65536),
      (GLfixed)(ymin * 65536), (GLfixed)(ymax * 65536),
      (GLfixed)(zNear * 65536), (GLfixed)(zFar * 65536));
}

Android.mk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := ndk
LOCAL_SRC_FILES := ndk.cpp
LOCAL_LDLIBS := -lGLESv1_CM
include $(BUILD_SHARED_LIBRARY)

これら ndk.cpp、glu.h、Android.mk と、HBehrens-obj2opengl-a0f123e.zipのbanana.h をプロジェクトのjniフォルダーにインポートし、カレントフォルダーをjniに移してndk-buildを実行します。
HBehrens-obj2opengl-a0f123e.zipののbanana.jpgをres/drawableフォルダーにインポートします。

Activityのソース(Main.java)

package jp.fujiu.NdkTexture;

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import android.app.Activity;
import android.content.Context;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.opengl.GLSurfaceView;
import android.opengl.GLSurfaceView.Renderer;
import android.os.Bundle;
import android.view.MotionEvent;
import android.view.SurfaceHolder;
import android.view.Window;

public class Main extends Activity {
 static {
  System.loadLibrary("ndk");
 }
 
 native private void setNdkPixels(int[] pixels, int width, int height, int size);
 native private void setNdkRotate(float x, float y);
 native private void onNdkCreated();
 native private void onNdkChanged(int width, int height);
 native private void onNdkDraw();
 native private void ndkFinalize();
 
 private MainSurface surface = null;
 
 //タップの座標
 private float xtap = 0.0f;
 private float ytap = 0.0f;
 
 //回転角度
 private float xrot = 0.0f;
 private float yrot = 0.0f;
 
 @Override
 public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  requestWindowFeature(Window.FEATURE_NO_TITLE); //タイトルバー非表示
 }
 
 @Override
 protected void onResume() {
  super.onResume();
  surface = new MainSurface(this);
  surface.setRenderer(surface);
  surface.setFocusable(true);
  surface.setKeepScreenOn(true);
  setContentView(surface);
 }
 
 @Override
 protected void onPause() {
  super.onPause();
  surface.setKeepScreenOn(false);
 }

 @Override
 public boolean onTouchEvent(MotionEvent event) {
  switch(event.getAction()){
  case MotionEvent.ACTION_DOWN:
   xtap = event.getX();
   ytap = event.getY();
   break;
  case MotionEvent.ACTION_MOVE:
   xrot += (event.getX() - xtap);
   xtap = event.getX();
   yrot += (event.getY() - ytap);
   ytap = event.getY();
   setNdkRotate(xrot, yrot);
   break;
  }
  return true;
 }
 
 private class MainSurface extends GLSurfaceView implements Renderer{
  public MainSurface(Context context) {
   super(context);
  }

  @Override
  public void onSurfaceCreated(GL10 gl, EGLConfig config) {
   //画像ファイルをint型配列に変換してJNIに渡す
   final BitmapFactory.Options opts = new BitmapFactory.Options();
   opts.inScaled = false;
   opts.inPreferredConfig = Bitmap.Config.ARGB_8888;
   Bitmap bmp = BitmapFactory.decodeResource(getResources(), R.drawable.banana, opts);
   int width = bmp.getWidth();
   int height = bmp.getHeight();
   int size = width * height;
   int pixels[] = new int[size];
   bmp.getPixels(pixels, 0, width, 0, 0, width, height);
   bmp.recycle();
   setNdkPixels(pixels, width, height, size);
   
   onNdkCreated();
  }
  
  @Override
  public void onSurfaceChanged(GL10 gl, int width, int height) {
   onNdkChanged(width, height);
  }
  
  @Override
  public void onDrawFrame(GL10 gl) {
   onNdkDraw();
  }

  @Override
  public void surfaceDestroyed(SurfaceHolder holder) {
   ndkFinalize();
   super.surfaceDestroyed(holder);
  }
 }
}

画面をフリックするとバナナが回転するようにしました。

これをエミュレーターで実行したら一瞬でバナナが表示されました。JavaでFloatBufferを作成する方法（エミュレーターで2分くらい）とは大違いの速さです。
テスト環境では、Heapを見比べたらJavaでFloatBufferを作成する方法に比べて1MBほどメモリーの節約になりました。
Android-NDKでビルドしたアプリケーションはARMの端末でしか動作しないのが玉に瑕です。

以上、参考になれば幸いです。

2011年7月30日土曜日

[Android] Androidエミュレーターが起動しなくなった

How to solve a problem that Android-NDK dose not launch
android-sdk_r12-windowsをインストールしたらエミュレーターが起動しなくなりました。

エラーメッセージ
invalid command-line parameter: Files\android-sdk-windows\android-sdk_r12-windows\tools/emulator-arm.exe.
Hint: use '@foo' to launch a virtual device named 'foo'.
please use -help for more information

どうやらパスにスペースが含まれていることが原因のようです。
保存場所を
D:\Program Files\android-sdk-windows から
D:\android-sdk-windows に変更したら起動するようになりました。

android-sdk_r11-windowsまではパスにスペースが含まれていてもちゃんと動いたのでびっくりしました。
ちなみにAndroid-NDK（ndk-build）もパスにスペースがあるとコンパイルできませんでした。

以上、参考になれば幸いです。

2011年7月23日土曜日

[Windows7] メモリーを増設したら起動しなくなった (Kernel-power イベントID41)

Windows7 had been unstable since I added memory.

安くて有名だったサーバーHP ProLiant ML115 G5にWindows7-64bitをインストールしてパソコンとして使っているのですが、メモリー(RAMモジュール)を5GB(2GB×2 + 1GB)から8GB(2GB×4)に増やしたら起動が不安定になりました。
過去に故障のためメインボードを交換してます。
CPUはAthlon X2に交換済みです。

電源が切れた状態から起動(コールドスタート)すると
・「ファイルを読み込んでいます」と表示した後に勝手に再起動し、修復セットアップを要求する（無視すると正常に起動する）
・「このファイルのデジタル署名を検証できません」と表示される（再起動すると正常に起動する）
のどちらかの現象が起こります。
たまに正常に起動しますが復元ポイントに戻されます。再起動した場合はこの症状は起きません。
イベントビューアーをみるとKernel-power イベントID41が記録されています。

※この問題は
起動しなくなったHP ProLiant ML115 G5が直った
にて完全に解決しました。
以下の解決方法は2011年7月時点の内容ですのでご了承ください。

結論
BIOS設定の
Advanced
　－ CPU Configuration
　　－ Memory Channel Mode を
Independent から Combined に変更したら解決しました。
しかもメモリーのWindowsエクスペリエンスインデックスが7.1から7.2に上がりました。
容量もこの通り8GB(8MB×1024)と認識されてます。

試してみたけど解決に至らなかったこと

修復セットアップ
→復元ポイントに戻されるだけ、Windows Updateが台無しです
CドライブをフォーマットしてOSをクリーンインストール
→効果無し
ハードディスクのSATAケーブルを交換
→変化無し
BIOSのPowerNow!をDisableに設定する
→効果無し
グラフィックボードをRADEON HD5450(VRAM 512MB)からNVIDIA GeForce 8400GS(VRAM 256MB)に変更
→効果無し、ただし発熱量が下がりました
MEMTEST86+でRAMの不良確認
→異常なし
デバイスマネージャーのPCI標準PCI-to-PCIブリッジデバイス13（オンボードのグラフィック機能）を無効にする
→効果無し
システムエラーの「自動的に再起動する」の無効化
→エラーが起きた後に再起動するかしないかの設定なので意味がない

気休め１・デバイス13の無効化

気休め２・システムエラーの「自動的に再起動する」の無効化

最近のWindowsは不具合が起きたらOSよりハードウェアを疑うべきです。
ただし今回の症状はハードウェアは正常で、しかもコールドスタートするとたまに発症する内容でなので対処方法がわかるまで時間がかかりました。

以上、参考になれば幸いです。

登録: 投稿 (Atom)

新アプリケーション