2014-04

2014-02 FM3 RX62N SH2A PIC32MX

2014年4月


1)はモチベーションの低下。(もうすでに飽きている)

2)は完成済。

3)でAndroidのADKを試そうとしていて足踏み中。(進捗どうですか:永遠に零)






mbedについて

/ATMEL_AVR/jpg/mbed_1768.png

初期のころのmbedがサポートしていたハードウェアmbed NXP LPC1768mbed NXP LPC11U24

mbedって、何だったんですか?

  • オランダNXP(旧フィリップス)のLPCマイコン用のお手軽開発環境。(Arduino風というかそんな感じ)
  • オンラインコンパイラ(統合環境)が使える、というのが大きな特徴だった。
  • 言語はC++。
  • (ボード上にはターゲットのLPCマイコンの他に、PCとの接続用のLPCマイコンも載っていた。)

2014年現在の mbedって何ですか? という質問

  • 今となっては、「8bitから進化しなかったArduinoに取って代わるもの」です。
  • 32bitのArduino風な基板としては、Arduino DueとかMapleとかPinguinoとか、ありました。
  • しかし、それらはどれも中途半端なもので、広く使われることなく消えていくでしょう。(残念ですが)


なぜかというと、

  • mbedは、ST-MicroのMPUをサポートし始めたので、事実上、ARM(Cortex-M)のプロトタイピングをすべてカバーしています。
  • mbedは、特徴的なオンラインIDEコンパイラでも開発できますが、それ以外にも、KEILとか普通のgcc-armとMakefileによる開発環境もサポートされています。
  • オンラインIDE環境で作成したスケッチ(と呼んでいいのやら?)を公開出来るので、他の人の成果を参照したりそれをベースに改造していったりとかが自由に出来る。
  • ライブラリが公開されていて、ライセンスが緩いので(Apache,MITLとか)改造しやすいとか、サポートするボードを自分で増やせるとか
  • 開発言語が普通にC++。(賛否両論あると思います)


参考URL:

mbed-sdkの秘密: オフライン・コンパイルhttp://mpu.seesaa.net/article/399685682.html
mbed リファレンスjphttps://mbed.org/users/okini3939/notebook/ref_jp/
mbed 日本語フォーラムhttp://mbed.org/forum/ja/
LPC1347 CMSIS-DAPhttps://bitbucket.org/va009039/lpc1347_cmsis-dap/src






Ubuntu 14.04 LTSに移行したよ。

実際にはリリースデーより半月くらい前から運用してたんだけど。

アップデートのこつ

  • grubの起動DEFAULT=2 (Xen) は 0に戻しておいても大丈夫。というか戻せ。
  • そうしないと、一時的にXenがアンインストールされて再起動になった時に、次回起動がmemtest(笑うところ)
  • Xenは入れ直しになる。
  • XenのVM起動スクリプトはxmからxlになるので、書き直しになる。
    • だが、簡単。xlscript.pvlinuxをコピペして自分のvif=とdisk=を書き換えるだけだった。
    • xmコマンドが無くなってるけど、xlとほぼ一緒なので適当にバッチ置いとくと違和感ない。
      • /usr/local/sbin/xm
        #!/bin/sh
        /usr/sbin/xl $@
        とか。
  • 同様にlxc-listも適当に
    #!/bin/sh
    lxc-ls --fancy
    とかで誤魔化す。
  • LXCは13.10からのアプグレでは、そのままOKだった。/etc/lxc/auto/ が消えて、configのほうにautoが書かれてたみたい。
  • あと自分は /dev/sdaと同容量の/dev/sdbハードディスクにdailyでrsync掛けてる。raidにしないのは、dmraidがあまりにもカス実装で使えないのと、ICH-*R入りのマザーボードが高いから。
    • それと、ファイル消したり間違って上書きしても、昨日Verが残っているという安心感
  • 起動パーティションは32GBくらい取ってるけれど、予備に/dev/sda1,/dev/sda2 が両方ともLinux System(/)になっている。
  • OSをアプグレするときは、運用中のsda1をsda2に丸コピーしてからやるので、何かあったときはgrubを操作すればアプグレ前のOSも起動できる。
    • ただし、丸コピーした後、UUIDを書き換えて、誤認識しないようにする必要がある。
    • あと、絶対に、コピー元、コピー先を逆にしない、という注意を払う。


言い忘れたけど、Ubuntu14.04 LTS Serverね。

  • Desktop版はVMWareでその場で作っては壊す程度にしか使わない。








Android入門

いまごろになってAndroid入門してみる

もっと読む: Android








今週の「宇宙ちゃんねる」 NHK

お、おう。勉強になった。備忘メモ

  • 星の寿命は、大きいほど短い
    • 例えば、オリオン座のベテルギウスは1000万年ぐらいしかない。
    • 太陽は、もう45億年燃えていて、あと50億年ぐらい寿命がある。
    • 太陽クラスの星は、水素から燃やし始めて、炭素くらいまでで終わる。最後はダイアモンドの塊(?)
    • ベテルギウスのような星は鉄になるまで燃える。鉄が出来始めたら、たったの2、3秒で超新星爆発が起きるらしい。(ほんとか?)
    • とにかく、重い元素になるほど、すぐに燃やし尽くしてしまうらしい。
    • 鉄が一番安定な元素なので、鉄より重い元素は核融合では作れない。
    • しかし、超新星爆発では、金銀ウランのような重い元素まで生成される。
    • 超新星爆発では、星の重力エネルギーをニュートリノが全部持ち去ってしまうらしい(星が裏返るともいう)。想像できないほどの強烈なニュートリノシャワーによって、被爆してしまう。ニュートリノは普通の物質を簡単にすり抜けるので、まったく遮蔽不可能(なのに被爆するのは生命体を構成している電子をも弾き飛ばしてしまうから、らしい)。とりあえず鉄が出来そうになる前に数光年ジャンプするしかない。
  • こうやって、星が一生を終えると、まき散らされた物質によって、次の世代の太陽が出来て、というのを数世代繰り返して今の太陽と地球がある。
  • 生命を構成する物質は、超新星爆発が無ければ作られない。

つまり、太古の超新星爆発のおかげで、生命が誕生した。



Active Galactic:ベテルギウスの最期:超新星の兆候とその威力





あんどろいど駄目じゃね説

  • 始めてはみたものの、全然動かない。
  • なんかやりかた間違ってるのかな?
  • SDKからAVD起動はOK.
  • EclipseからAVDが起動しない。
  • 先に起動させておいたAVDに接続できない。
  • Windowsが駄目なのかと思って、Linuxで試してみたけれど、LinuxではそもそもAVD起動でエラー(libswtが・・)。
  • あと、new projectで作ったスケルトンもコンパイルエラーする始末。
  • AVD起動遅すぎるし、すぐにSnapShotイメージが使えなくなる不思議。

原因究明中。

というかこれ、もう飽きた。

実機?

ああ、実機ね。

面倒臭えー。


結論

  • Windows上ではいろいろ駄目な感じだった。(環境によっては、たまにうまくいくこともある。けれど非常に遅い)
  • Linux(Ubunt14.04LTS)上で同じことを試したら、とりあえず動くようになった。


コツ

  • AndroidSDKには32bit-ELFがいろいろ混じっているので、32bit-elfが使えるようにしておかないといけない。
    # apt-get install gcc-multilib g++-multilib zlib1g:386
  • とか。


  • なんか、LinuxのほうがAndroid開発しやすいような気がする。





Windowsでリベンジしてみた

  • AVD、GenyMotion、どちらの場合も、それ用のプラグインっぽいものを突っ込まないとだめなようだ。
  • Eclipseの場合、ヘルプ->新規プログラムをインストールする->URLを入力->インストールしたいプラグインにチェックを入れて、インストール。
  • AndroidStudioの場合もそんな感じ。


  • Eclipseで、AVDとかSDKの起動メニューが出なくなったときは、
  • Window->パースペクティブのカスタマイズ->コマンド可用性 とかで、チェックを追加する。
  • サンプルソースがビルドエラーするのは、そんなもんらしい。(裏は取っていない)





Android-x86 on リアルPC

KitKatのrc版isoが2月くらいから公開されているので、実在PC(Core2 Duo6750 4GB)に入れてみた。

  • インストール方法はiso起動してfdiskのGUIで普通に/dev/sda に8GB程度のLinuxパーティションを切って boot flagを立てておくだけ
  • ついでに/dev/sda2にFAT32の8GBも切っておいたけど、関係なかったかも。
  • ごく普通にインストール出来る。WiFi無くて普通のオンボードのNICでもOKだった。


どこが便利?

  • Terminal Emulatorが最初から入っている。(前からそうだった)
  • su が最初から入っている。(前からそうだった)
  • /system/ をrwマウントで使うことが出来る(前からそうだった)
  • Google Playが最初から入っている。(New)
  • WiFi無しで有線の Ether NIC でも特にコマンド叩かずに普通にAndroidで使えている。(New)


???な点

  • ARM Emulatorは入っていないっぽい(裏は取ってない)
  • GenyMotionのARM Translatorを無理やりunzipして入れてみたら、OSが起動しなくなった。(やり方が悪いだけ?)
  • サスペンドに入って画面が消えたあとの復活のさせかたが分からない。
  • 画面の解像度の指定方法が分からない。(grub?)


なんかHowTo解説が欲しい気分。





Ubuntu Linux: GUID Partition Table (GPT)なハードディスクの罠

メモ

  • 2TB以下のHDDでは、昔から使われているMBR(マスターブートレコード)パーティションで十分なので、問題は起きない。
  • 2TBを超える容量のHDDでは GPTパーティションしか選択肢はない。
  • ところで、Ubuntu(に限らずOS)をブートさせるためには、GPTの先頭パーティションに何らかのブートローダー領域を用意する必要がある。(必須)


2種類ある

属性コード 0xEF00 : EFIブート100MB以上確保する。vfatでフォーマットされる。Linuxでは /boot/efi/ にこのパーティションがマウントされる.
属性コード 0xEF02 : BIOSブートローダーMBRのブートローダーのようなものを書くだけなので、1MBとか10MBでよい。/boot/efi/にマウントできない。

注意:

  • ブートローダー用のパーティションは 必ずGPTの先頭に配置しなければならない。
  • GPTパーティションを使用する場合でも、MBRセクターにはダミーとして、GPT全確保(とはいえ2TB越えられないが)のダミー情報が用意される。
  • レガシーなマザーボードでは、このMBRダミーパーティションにboot flagが付いてないとOS起動できないものが存在する。


もっと大事な注意:

  • Linuxをインストールする前に、インストールメディア(CDROM等)をUEFI起動するか、旧来BIOSモードで起動するかによって、インストール先のPCのアーキテクチャーが切り替わり、全く別のシステムとして(ブートシーケンスとして)振る舞う。
  • というわけなので、インストールする前に、自分は、 UEFIか旧来BIOS(i386-pcという名前)かどちらのアーキテクチャーにOSを入れるのか、あらかじめ決めなければならない
  • これがごっちゃになると、起動しないHDDが量産される。Ubuntu13.04->13.10->14.04とupgradeする場合にgrubの仕様が変わるのでたいてい罠にはまる。
  • 新規インストールする場合は自動的に確定するので大丈夫だとは思うけれど、パーティションを手動で切る人は、意識しながら作業しないとだめっぽい。






<前の月次の月>