PiTFTを使ってみた

部屋の電気のスイッチに液晶つけて、操作パネル表示させたら面白いかなと思ってこれを買ってみた。タッチに対応してる。

https://learn.adafruit.com/adafruit-pitft-28-inch-resistive-touchscreen-display-raspberry-pi

https://learn.adafruit.com/system/assets/assets/000/012/560/medium800/raspberry_pi_1601_LRG.jpg?1385669826

セットアップ

セットアップ方法もリンク先に書いてある。

ただ開発に使ってるRaspberry Piではうまくセットアップできなかったので、新しくSDカードにOSをインストールしてからセットアップした。

既存の環境はwin32diskimagerを使ってバックアップした。

読み込みと書き込みに少し時間かかるけど、新しいデバイスのセットアップする時にやるくらいならあまり手間にならない。

[Raspberry Pi]SDカードのディスクイメージを複製する – o24ブログ

GUIを表示してみる

セットアップができたのでwxPythonでボタンを表示してみた。

スイッチ代わりだから大きめのボタンを表示したんだけど、どうも描画が遅くてちらつきが目立つ感じだった。

CPUで描画して遅いならGPU使えばいいじゃんと思って色々調べたら、Raspberry PiはOpenGLES2に対応してるらしい。

なのでOpenGLで描画してくれるGUIライブラリを探したらKivyというPythonのライブラリを見つけた。

Kivy: Cross-platform Python Framework for NUI Development

でもRaspberry Piだとうまく動かなくて、また色々調べた結果、SPI接続のディスプレイにはGPUを使って描画ができないということだった。

結局操作パネルとして使うのは今回は見送ることにした。

PiTFTの所感

色々試して使ってみた感想としては、

  • Raspberry Piのデスクトップを操作した感じではメニューなんかはパッと表示される。
  • 一定時間経つと液晶のバックライトがOFFになるのは良い。
  • 指だと少し強めにタッチしないと反応しないのでそこを設定で調整できたらよかったかも。スタイラスなら普通にタッチしても反応する。
  • 1回タッチしただけでも2回以上選択したと判定されることが多くて、選んだつもりがないのに指の下にあったアプリケーションが起ち上がったりするのが不便。
  • SPI接続だと描画が遅くて使い所が限られる気がする。HDMI接続ならOpenGLESが使えるので問題はなさそうなのに残念。

SPI接続だと描画が遅いのが一番ネックだと感じた。

今回はGUIコントロールを表示してみたけど、インフォメーションボード的な使い方だとどうなるかは興味ある。

その他

Kivyは見た目が洗練されてたのでWindowsなどで使うときは良さそうだと思った。

ブログの方針変更

今このブログとQiitaを併用していて、メインはこのブログ、Qiitaは技術Tipsという使い分けをしていたんですが、方針を変更してQiitaをメインにしようと思います。

それでこのブログは自分の考えや勉強会の感想、個人的なメモといった事を書く場にしようと思います。(技術関連の話になることは変わりません。)

自分のQiitaのページです。 https://qiita.com/locatw

今後もよろしくお願いします。

VimのフォントをConsolas+Migu1Mにする

githubで表示されるソースコードのフォントが見やすかったのでVimに設定する方法を調べてみました。

環境はWindows7 x64です。

githubのフォントを調べる

githubソースコードのフォントを調べてみるとConsolasみたいですね。

(見た目で判断したので違うかもしれません。)

Primer

早速vimrcに設定してみると、英数字はきちんと表示されますが日本語が文字化けします。

どうもConsolasには日本語用フォントが入ってないみたいです。

日本語の表示に対応する

Windowsのフォントリンクという機能を使うと、Consolasを使いつつ日本語には別のフォントを指定できるようなのでこれを使います。

日本語フォントはMigu 1Mにしました。

フォントリンクの方法はこのページを参考にしました。

http://yutorialudra.blogspot.jp/2013/03/migu-1m-consolas.html(更新:リンク切れ)

設定手順:

  1. レジストリエディタで"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink"を開く
  2. 右クリックして「新規」→「複数行文字列値」を選択する
  3. 名前を「Consolas」、値を「migu-1m-regular.ttf,Migu 1M」に設定する
  4. PCを再起動する

これで無事に日本語も表示されるようになりました。

f:id:LocaQ:20140403234600p:plain

ちょっと日本語が横に伸びてるのが気になりますけど、プログラム書いてる時はコメントくらいしか日本語はないので妥協します。

RakeでC++をビルドする

ちょっとC++ソースコード書きたいときにVisual Studio立ち上げるのが億劫になったので、Vimでさくっと書ける環境を整えてます。

ただ、ビルドするのにmakefileを書きたくなかったので色々調べてたら、RakeでC++をビルドできるみたいなので書いてみました。

環境

Rakefile

一番単純なものはネットで検索すると出てくるんですが、少し物足りなかったので機能を追加しました。

  • ビルド, リビルド, クリーンを実装
  • 中間生成物(オブジェクトファイルなど)はビルド用ディレクトリに格納
  • 依存情報ファイル(.mf)を使ってヘッダファイルの依存関係に対応

rakefile for C++ source build.

解説

使い方は最初にRakefile内の定数を編集して、

CPPFLAGS = %w[]   # コンパイルオプション
LDFLAGS  = %w[]   # リンクオプション
INC_DIRS = []     # インクルードディレクトリ
LIB_DIRS = []     # ライブラリディレクトリ
TARGET   = "app"  # 生成する実行ファイル名

SRC_ROOT = "."    # ソースファイルが格納されているディレクトリ

LIBS = FileList[] # ライブラリファイル

ビルドするときは、

$ rake

生成したファイルを削除したいときは、

$ rake clean   # オブジェクトファイルなどの中間生成物のみ削除する
$ rake clobber # 実行ファイルとビルド用ディレクトリも削除する

リビルドしたいときは、

$ rake rebuild

という感じです。

今回はヘッダーファイルを含めた依存関係を扱いたかったのでその情報を"gcc -MM"でファイルに出力してるんですが、そのファイルの情報を使うときに問題が出て苦労しました。

Rakeにはimportというメソッドがあってこれで出力したファイルを読み込めるんですが、どうもソースファイルとオブジェクトファイルが同じディレクトリにないとうまく動かないようです。
でも今回はオブジェクトファイルなんかのビルド用中間ファイルは別ディレクトリに出力したかったので、自前でファイルを読み込んで依存関係を設定してます。

その設定はオブジェクトファイルの依存ファイルをdependenciesメソッドを呼び出して(154行目)動的に行っています。
dependenciesメソッドでは、

  1. file(depfile).invokeで、対象のオブジェクトファイルと対応する依存情報ファイルとの間に依存関係を設定して解決する。(95行目)
  2. load_depfileメソッドを呼び出して対象のオブジェクトファイルが依存しているファイル名のリストを取得する。(97行目)

という処理をしていて、1で依存情報ファイルを更新する必要があるときはそのファイルのルール(160行目)が呼び出されてファイルが更新される、という仕組みです。

わかると難しくないんですが、Rubyはほとんど書いたことがない上にRakeの仕組みを勉強しつつやってたら1週間くらいかかりました。 おかげでだいぶRubyにもRakeに慣れたんですが、まだまだ腕が足りないですね。がんばります。

参考

Boost.勉強会#14東京に参加してきました

初めましてlocaです。

3/1(土)のBoost.勉強会 #14 東京に参加してきて意識高まったので、ブログを始めて感想をまとめてみました。

Boost.勉強会 #14 東京

今回私は勉強会への参加自体が初だった上に優秀な人達がたくさん参加してたので、自分が行って大丈夫なのか不安でしたがとても楽しめました。

今回勉強会に参加して技術の勉強になった以上に、

  • 優秀な人達は相当な努力している
  • みんなほんとに楽しそうに発表を聞いたりコード書いたりしてる

と感じたのが一番印象深いです。

私は技術書を読んだりネットで技術記事を読んだりは結構してきたつもりですが、アウトプットを全然してませんでした。これを機に手を動かして学んだことをブログにまとめていきたいと思います。

全体の感想は以上で、以下から個々の発表の感想です。

cpprefjpを支える技術

cpprefjpはリファレンス以上の情報もあるのでそういう情報が知りたいときや、日本語でSTLの情報が知りたいときに見てます。

今のcpprefjpはgithubリポジトリにあるMarkdownからHTML生成してGoogle Sitesにアップロードしてるという話で、裏でいろいろ動いてると思ってませんでした。

Google Sitesからデータ持ってきたり、今のGoogle Sitesとの同期の仕組みを作るときの苦労話が聞けて面白かったです。

Boost.Graphの設計と、最短経路アルゴリズムの使い方いろいろ

Boost.Graphは前に少し触ったことがあったんですが、頂点を取るときにメンバ関数じゃなくてフリー関数のvertices()を使うのに違和感がありました。この方法だとBoost.GraphのアルゴリズムにBoost.Graphのコンセプトを満たすいろいろなグラフ型を適用できるようです。すごい。

プロパティマップは複数プロパティを持たせたいときにネストさせるのが好きじゃなかったんですが、バンドルを使うとクラスをプロパティに持たせられると聞いたのであとで調べてみようと思います。

最短経路アルゴリズムdijkstra_shortest_paths()の例ですが、正直この関数の使い方難しいなぁと感じました。 たぶん自分で使ってみたら理解できるのかなという感じです。 それと始点と終点を指定してその最短経路を求める関数がないのはなんででしょう? あったほうが便利な気がする・・・ スライド49ページの話がこれに関係してるかもしれないけれど、そのページの意味を理解できてないのでわかりません。

最短経路の方はあんまり消化できてないんですが、設計の話が勉強になりました。またBoost.Graphを使うときに役立ちそうです。

いつからFIFOがスケールしないと錯覚していた?

Elimination Stackはなんとなく理解はできたんですが、本題のElimination Queueはよく理解できませんでした。 でも発表は一番楽しかった!これ以上ないくらい早口でしたけどネタもあって楽しかったです。 とりあえず魔導書読み返してみます。

ロックフリー「今日はこのへんにしといてやらぁ」

余談ですが、FIFOってファイフォって発音するんですね。 今までフィーフォって言ってました。

glfw3 OpenGLを使ったGUIフレームワーク

OpenGL使ったGUIフレームワーク作ってるよという話でした。 私も簡単な3Dグラフィックスを使うプログラムを書くことがあるので、興味のある話でした。

ただ発表は全体的に言葉や説明が具体的でない感じで、なんだかもやっとしててよくわかりませんでした。 "他のオープンソースGUIとはちょっと違う"という所とか、具体的に比較して説明すると良かったと思います。

私は今までfreeglutを使ったりしてましたがボタンを簡単に配置したりできるフレームワークあるといいなぁと思っていたので今後に期待してます。

データサイエンスワールドからC++を眺めてみる

RとC++が連携できるのを知りました。それなら色々おもしろいことできそうで、とくにQt使ってパラメータをリアルタイムに変えてみるアプリが作れるのはどこかで使えそうだなと思いました。覚えておくと役に立ちそうです。

C++やBoostにはまだ統計処理まわりのライブラリが不足してるみたいですね。 私は統計処理界隈のことは全然わからないんですが、試行錯誤するところはC++よりPythonみたいなスクリプト言語のほうが適してるからな気がします。

パフォーマンスの要求はどうなんでしょう?Pythonで不十分ならC++系のライブラリも増えてくるのかなと思います。

.NETとかが当たり前にやってること、C++だとどうするか

C#関連のことを調べるときにいつもお世話になってるサイトの人でした。 唯一の1時間発表かつハイペースの発表にもかかわらず濃い内容をわかりやすく発表していて、聞くのは大変でしたがとても勉強になりました。 たくさん勉強になったんですが書くと長くなるので1つだけ書くと、yeildの実装の話を聞いて今まであまり理解できていなかったyeildの動作が腑に落ちたのが個人的に1番の収穫でした。

あ、勉強会の時はC#でググっても岩永さんのサイトでなかったんですが、今やったら2番目に出てきました。 かっこいい。

新しい並列for構文のご提案

マルチコア活用するコード書いてなくてすみません。

並列処理ライブラリの話とC++1y向けに提案されている並列拡張の話でした。 ライブラリの方は物自体は知っていましたが、後半のC++並列拡張は初めて聞きました。 STLアルゴリズムに並列処理を行うオーバーロードを追加するもので、第一引数に実行ポリシーを指定するだけで簡単に使えるのがすごくいいと思いました。 まだドラフトで変更されるかもしれないとのことでしたが、これはぜひほしいです。

それと情報をマトリックスにうまく整理できる人はちょっと尊敬します。とてもわかり易かったです。

魔導書発売記念:GPGPUの今からとこれから

GPGPU周りの基本とパフォーマンス/ワットやAPUなんかの最新情報がまとまっていてよかったです。 GPU関係の知識はPCWatchで仕入れてたんですが、知識の整理ができました。 それとAMDのAPUではメモリバンド幅が足りないと聞いて、そういえばそうだなと思う反面CPUとメモリアドレス共有できるので転送しなくてもよい部分もあると思うんですが、どうなんでしょう?実際に測ってみないとわからないですかね。

この記事書いてて思いたんですが、GPGPUってグラフィックスと物理シミュレーション以外だと何に使われてるんでしょう? GPGPUには興味あるんですがこれ以外の用途がないと広く普及するのは難しいんじゃないかなという気がしています。


なんだか思ったより長くなりましたが、今回頑張って参加してよかったなと思います。 技術の知識が増えたことよりモチベーションが高まったり考え方変わったりしたのが大きいです。

こうしてブログを始めるきっかけになったBoost.勉強会に感謝です。

主催者の@cpp_akiraさんと発表者と参加者の方々、お疲れ様でした。そしてありがとう!