PiTFTを使ってみた
部屋の電気のスイッチに液晶つけて、操作パネル表示させたら面白いかなと思ってこれを買ってみた。タッチに対応してる。
https://learn.adafruit.com/adafruit-pitft-28-inch-resistive-touchscreen-display-raspberry-pi
セットアップ
セットアップ方法もリンク先に書いてある。
ただ開発に使ってるRaspberry Piではうまくセットアップできなかったので、新しくSDカードにOSをインストールしてからセットアップした。
Raspberry Piに接続するPiTFTって液晶買ってひと通りセットアップしたんだけど画面が真っ白でGUIが表示できない。一筋縄じゃいかないのか。
— loca (@locatw) 2015, 1月 10
PiTFT、OS再インストールしてセットアップしたらGUI表示されるようになったな。でも開発環境だから再インストール前の状態で使えるようにしたい。
— loca (@locatw) 2015, 1月 11
既存のRaspberry Piの環境へのPiTFTのインストールがうまくいかないから、結局新しくOSインストールしてPiTFT使うことにした。
— loca (@locatw) 2015, 1月 11
既存の環境はwin32diskimagerを使ってバックアップした。
読み込みと書き込みに少し時間かかるけど、新しいデバイスのセットアップする時にやるくらいならあまり手間にならない。
[Raspberry Pi]SDカードのディスクイメージを複製する – o24ブログ
GUIを表示してみる
セットアップができたのでwxPythonでボタンを表示してみた。
ようやくここまで出来た。ボタンをタッチすると"点灯"に変わる。GUIはwxPython使った。 https://t.co/A48JoidFfN
— loca (@locatw) 2015, 1月 11
スイッチ代わりだから大きめのボタンを表示したんだけど、どうも描画が遅くてちらつきが目立つ感じだった。
Raspberry PiでwxPython使ってトグルボタン表示させてるんだけど、どうもフリッカーが発生する。ダブルバッファリングもしてるのに。320x240のボタンだから描画に時間かかるんだろうか。
— loca (@locatw) 2015, 1月 12
Raspberry PiだとX windowは重いらしい。OpenGL使うとかしないと改善はなさそうだ。
— loca (@locatw) 2015, 1月 12
CPUで描画して遅いならGPU使えばいいじゃんと思って色々調べたら、Raspberry PiはOpenGLES2に対応してるらしい。
なのでOpenGLで描画してくれるGUIライブラリを探したらKivyというPythonのライブラリを見つけた。
Kivy: Cross-platform Python Framework for NUI Development
kivyっていうpythonのライブラリがいい感じでGUI書けそう。まだRaspberry Piでビルド終わってないからWindowsで試してるけど。
— loca (@locatw) 2015, 1月 12
でもRaspberry Piだとうまく動かなくて、また色々調べた結果、SPI接続のディスプレイにはGPUを使って描画ができないということだった。
Raspberry Piでkivyがうまく動かないな。exampleにあるやつを起動しても起動プロセスの途中で止まっちゃう。
— loca (@locatw) 2015, 1月 12
HDMIでディスプレイに繋いだらRaspberry Piでkivyの3DRenderingのexample動いた。さっき動かなかった時はHDMI繋がずにPiTFTで表示してたんだけど原因が分からん。エラー出してたわけでもないし。
— loca (@locatw) 2015, 1月 12
Raspberry PiとPiTFTでkivyが起動できない問題、やっと結論出た。PiTFTはSPIで接続してるからOpenGLES使うkivyは動かせないということらしい。HDMIでディスプレイに接続した時は動いたからあってるっぽい。https://t.co/Ad2Trut3d1
— loca (@locatw) 2015, 1月 13
結局操作パネルとして使うのは今回は見送ることにした。
はぁ、Raspberry PiでwxPython使うと描画が遅くてOpenGLES使おうとするとPiTFTだと動かせないとは。うまくいかないねぇ。
— loca (@locatw) 2015, 1月 13
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みたいですね。
(見た目で判断したので違うかもしれません。)
早速vimrcに設定してみると、英数字はきちんと表示されますが日本語が文字化けします。
どうもConsolasには日本語用フォントが入ってないみたいです。
日本語の表示に対応する
Windowsのフォントリンクという機能を使うと、Consolasを使いつつ日本語には別のフォントを指定できるようなのでこれを使います。
日本語フォントはMigu 1Mにしました。
フォントリンクの方法はこのページを参考にしました。
http://yutorialudra.blogspot.jp/2013/03/migu-1m-consolas.html(更新:リンク切れ)
設定手順:
- レジストリエディタで"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink"を開く
- 右クリックして「新規」→「複数行文字列値」を選択する
- 名前を「Consolas」、値を「migu-1m-regular.ttf,Migu 1M」に設定する
- PCを再起動する
これで無事に日本語も表示されるようになりました。
ちょっと日本語が横に伸びてるのが気になりますけど、プログラム書いてる時はコメントくらいしか日本語はないので妥協します。
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メソッドでは、
- file(depfile).invokeで、対象のオブジェクトファイルと対応する依存情報ファイルとの間に依存関係を設定して解決する。(95行目)
- load_depfileメソッドを呼び出して対象のオブジェクトファイルが依存しているファイル名のリストを取得する。(97行目)
という処理をしていて、1で依存情報ファイルを更新する必要があるときはそのファイルのルール(160行目)が呼び出されてファイルが更新される、という仕組みです。
わかると難しくないんですが、Rubyはほとんど書いたことがない上にRakeの仕組みを勉強しつつやってたら1週間くらいかかりました。 おかげでだいぶRubyにもRakeに慣れたんですが、まだまだ腕が足りないですね。がんばります。
参考
Boost.勉強会#14東京に参加してきました
初めましてlocaです。
3/1(土)の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さんと発表者と参加者の方々、お疲れ様でした。そしてありがとう!