qgmap 開発メモ – 設定ファイルとかスレッドとか

あ、ザウルスでGoogleMapですが、勝手に qgmap と名付けました。とりあえず。

一応地図は表示できるようになったものの、地図データのパスを指定したり、パスを設定ファイルに保存したりしなくちゃいけない。

zaurus 内を覗いてみると、~/Settings に設定ファイルが集まっているようだ。設定ファイルのフォーマットは Windows の INI ファイルみたいに、

[セクション名]
アイテム名 = 設定値

といったフォーマットになってる。これって各アプリ自前でパースしてんのかな?? 結構手間だなぁ。

なんて思いながらググっていると、Configというクラスを使えば簡単に読み書きできることが分かった。(→参考ページ

なるほど、簡単にアクセスできるクラスがあるんだね。ちなみに、Qt3 では QSettings というクラスでできるようだ。これらを#ifdef で切り替えれば x86 でも zaurus でも動くように作れそう。

あと Qtopia-1.6 のリファレンス も発見。zaurus では Qtopia-1.5 らしいけど、Trolltechのページには1.5は見つからなかった。まぁこれで十分。

軽くクラス一覧を見てみると、QThread が無いらしい。これもググってみると、zaurus では QThread は使えないので pthread を使えと書いてある。(→参考ページ)

地図スクロール時の引っかかるような感じは、地図画像の読み込&拡大処理が終わるまで表示が待たされるために起こるので、これらの処理を別スレッドで動かそうかと思ってたんだけどなぁ。ちょっと面倒らしい。シングルスレッドでできる方法も考えてみるか。

PCのライン入力でオシロスコープもどき

PICで赤外線リモコンの続きです。

以前、パソコンのライン入力・マイク入力でオシロスコープもどきをやってる人がいると聞いたことがあったのを思い出してググってみました。

確かに、それっぽいことを書いてる人はいるものの、回路図とか詳しい情報は見つけられず。

マイク端子はプラグインパワーなので、自前の信号を入力するのはちょっと面倒そう。というか、電源ラインを変化させるってどうやるんだ?? 流れる電流を変化させればいいのかな??

マイク入力はよくわからないので、ライン入力で試すことにした。が、ライン入力ってどれくらいのレベルを入れればいいの?? 

Wikipediaのページによると、民生機では-10dBV程度らしい。-10dBVって?? dBVでぐぐると、

dBV = 20log10(V)

らしいので、計算すると0.316V。安全に見積もって50mV程度入力すればいいか。

赤外線リモコン受信モジュール CRVP1738
手持ちのパーツに赤外線受光モジュール CRVP1738 があったので、これで受信した信号を分圧してPCに取り込んでみる。

このモジュールは 7,8 年位前に学習リモコンを作ろうとして秋月で買った物で、もちろん、開封されたことすらない。あっかんべー

このモジュールは、38kHzのキャリアを復調してTTLレベルで 0, 1 を負論理で出力してくれる。これを100kΩと1kΩで分圧。出力インピーダンスが100kΩと大きいので、実際は5V出力が1/200程度になり、25mVくらいが入力される計算。

パソコンの方では、ハンディ・オシロスコープという、音声入力を2chオシロスコープとして使うためのそのものズバリのフリーソフトがあったのでこれを使ってみた。

リモコン波形
ハンディ・オシロスコープでキャプチャした波形

使い方に癖があるものの、手軽に波形が取れるのは便利。数kHz程度までの低周波信号ならこれで十分だな。いいこと知った笑顔

負論理出力なので、反転した波形なのに注意。実際は、リモコンのボタンを押すと同じ波形が2回送信される模様。この画像はその1つ目の波形。

NECフォーマットより、リーダのON期間が短いみたい。解析してみたところ、

リーダ(ON 4.5ms, OFF 4.5ms)、カスタムコード(8bit)、カスタムコード反転(8bit)、データ1(8bit)、データ1反転(8bit)、データ2(8bit)、データ2反転(8bit)、ストップビット

というフォーマットになっているようだ。カスタムコードは 0xB2 固定となっている。

いくつかのパターンを調べてみたが、とりあえず電源OFFは、データ1=0x7B, データ2=0xE0 らしい。

今日はここまで。

PICで赤外線リモコン

osziFOX
必要に駆られてPICで赤外線リモコンを作成することにしました。

FUTABAさんのページで赤外線リモコンの基礎をお勉強。フムフム。1がONで0がOFFみたいな単純な物ではないのね。しかも38kHzで点滅か。結構面倒そう・・。

とりあえず、コピーしたいリモコンを分解して、赤外線LEDの両端の電圧をへなちょこオシロosziFoxで観測。リーダ辺りのフォーマットはNECフォーマットに似ていそう。

でも、さすがにへなちょこosziFoxでは128サンプルしか取れないので、信号全体を観測することは不可能。 全体で200ms近くの信号のようでした。

話は脱線して、osziFoxですが、昔秋月で9000円くらいで売っていた超簡易ペン型オシロスコープです。今では販売されてないようです。というか、Witting Technologies社のHPすら見つからず・・・。倒産してしまったのでしょうか・・・?

リモコンフォーマットをググってみると、学習リモコンの制作系のページをいくつか発見。私は東芝のエアコンの制御をしたいのですが、さすがに東芝エアコンそのものずばりのフォーマットは見つけられませんでした。

こういうときにオシロとかロジアナとかが欲しくなるなぁ。 高いし置く場所無いから買えないけど・・。

 

ザウルスでGoogleMap その2

zaurus で GoogleMap もどきがやっとこさ動いてきました。

GM_Liteで切り出した地図を表示して、拡大縮小、スクロールができるようになりました。

 

 

ただ、致命的な不具合としては、アプリの切り替えができません。悲しい

なぜかわかりませんが、OSごと落ちます叫ぶ

この辺が解消されたら、やっと動いた版として公開しようかなと思います。

長い目でみてやってください。

ubuntu で Qt/E 開発 その2

昨日の続きです。

4. x86環境の構築

昨日の冒頭でも書きましたが、gcc-4.x では x86上で Qt/E アプリをデバッグするためのシミュレータ(?)環境である qvfb 用のバイナリが、コンパイルできませんでした。

おそらく、gcc-2.9x の環境を作ればコンパイルできるのでしょうが、ちょっと手間なので、別の方向で逃げることにしました。

それは、Qt3アプリとして作ってしまうことです。

zaurusのQt2とQt3は上位互換ですが、Qt4からは互換性がないらしいので、Qt 3アプリとしてホスト上である程度作ってしまい、Qt/E用にビルドするときは一部のクラスをQt/E用のクラスに入れ替える方法を取りました。

Qt 環境と Qt/E 環境は細かい所は違うのかもしれませんが、Qt の QApplication を QPEApplication に置き換えれば大体は動くようです。というか、QApplication と QPEApplication を入れ替えれば動くように作ります。

最終段階では qvfb が使えた方がいいのでしょうが、それはその時に考えることにします。あっかんべー

ということで Qt3の環境を整えます。

どれから入れたかは忘れてしまいましたが、今現在Qt3 関係で入っているパッケージは以下のとおりです。

  • libqt3-compat-headers
  • libqt3-headers
  • libqt3-i18n
  • libqt3-mt
  • libqt3-mt-dev
  • qt3-apps-dev
  • qt3-designer
  • qt3-dev-tools
  • qt3-dev-tools-compat
  • qt3-dev-tools-embedded
  • qt3-doc
  • qt3-examples

aptでいくつかインストールすれば依存関係でほとんどインストールされてしまうと思います。

これでQt3アプリをビルドする環境が整いました。

5. x86(Qt3), ARM(Qt/E) 共通のソースで開発

Qt3 と Qt/E ではコンパイラもMakefileも異なるので、プロジェクトファイル (*.pro ファイル) を分けることで切り替えます。

例えば、hoge というディレクトリにソース一式が入っており、 hoge というアプリを作るとします。

このとき、Qt3 用には、

$ qmake-qt3 -project
$ qmake-qt3
$ make

で プロジェクトファイル hoge.pro、メイクファイル Makefile を作成し、ビルドします。

ARM環境では、プロジェクトファイルの作成に progen、Makefile の作成に tmakeを使います。

$ progen -o hoge-arm.pro
$ tmake -o Makefile.arm hoge-arm.pro
$ make -f Makefile.arm

これでプロジェクトファイル hoge-arm.pro、メイクファイル Makefile.arm が作成され、ビルド時には make に -f オプションを指定することで、Makefile.arm を使ってビルドします。

実際には、progen で作成した pro ファイルに、

DESTDIR = ./
INCLUDEPATH += $(QTDIR)/library
DEPENDPATH += $(QTDIR)/library
TARGET = hoge
LIBS += -lqpe

を追加する必要がありますが、流れは上記の通りです。

QApplication と QPEApplication は #ifdef で切り替えます。

Qt/E用のビルドでは QWS が define されるようなので、#ifdef QWS で Qt/E と Qt3 を判断します。

こんな感じで

#ifdef QWS
#include <qpe/qpeapplication.h>
#else
#include <qapplication.h>
#endif
#include "gmap.h"
int main(int argc, char **argv)
{
#ifdef QWS
QPEApplication app(argc, argv);
GMap *win = new GMap();
app.showMainWidget(win);
#else
QApplication app(argc, argv);
GMap *win = new GMap();
app.setMainWidget(win);
win->show();
#endif
return app.exec();
}

当分はこの方法で開発を進めてみようと思います。