mbed(LPC1768)仕様でフォームファクタがArduinoというseeedstudioのArch Proを購入、aitendoの2.6インチ液晶 for Arduino UNO[UNO026LCD7781TP]を接続してみました。
Arch Proのピン配列に少しイラッと（ピン配置のポリシーが理解できない）しながらもタッチパネルまで移植完了。
Arch Pro、TFT液晶どちらも価格の割には満足度は高いかも(^^)
2.6TFT & Arch Pro
タッチパネルテスト用のPaintアプリ
Arduino UNO/Mega 2560で動作する.WAVファイル再生スケッチを作成しました。
.WAVファイルは、フォーマット変換アプリで「8000Hz/8bit/Mono」または「16000Hz/8bit/Mono」形式にして、SDカードにコピーします（サンプルスケッチでは「test0001.wav」です）。
UNOではD3pin、MegaではD9pinから出力されますので簡単なローパスフィルターを通してアンプに接続します。
液晶ディスプレイへの書き込みが気が遠くなるほど遅く、使い物にならないので調べてみました。
最初にポート操作(digitalWrite)の処理速度を確認するために、下記のスケッチでポート操作に必要な時間を計測してみました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
int led = 13; void setup() { Serial.begin(9600); Serial.println("Start"); pinMode(led, OUTPUT); } void loop() { long tt = millis(); for (int i = 0; i <1000; i++) { digitalWrite(led, HIGH); digitalWrite(led, LOW); } tt = millis() - tt; Serial.println(tt); while(1); } |
Arduino UNO(IDE:1.0.5)では、10,000回ループで82msでしたが、Galileo(IDE:1.5.3)では、1,000回で4,778msでした（Galileoでは、10,000回でなく、1,000回ループ）。
UNOが約4usで処理されているところを約2ms以上を要しています、約500倍遅いということになります。
次にポート設定(pinMode)の処理速度が気になったので、ポート設定をループ内部に移動して計測しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
int led = 13; void setup() { Serial.begin(9600); Serial.println("Start"); } void loop() { long tt = millis(); for (int i = 0; i <1000; i++) { pinMode(led, OUTPUT); digitalWrite(led, HIGH); digitalWrite(led, LOW); } tt = millis() - tt; Serial.println(tt); while(1); } |
結果、Arduino UNOでは、10,000回ループで128msでしたが、Galileoでは、1,000回で23,840msでした（Galileoでは、10,000回でなく、1,000回ループ）。
Galileoでは、ポート設定に約10msを要しています。
普通に考えるとポート設定は、初期化の時に１回だけ実行するものと思いますが、実はこのポート設定処理が液晶ライブラリのポート出力を行うときに毎回呼び出されていました。
これが、液晶表示を異様に遅くしている原因のようです。
|
1 2 3 4 5 6 7 8 |
void LiquidCrystal::write4bits(uint8_t value) { for (int i = 0; i < 4; i++) { pinMode(_data_pins[i], OUTPUT); digitalWrite(_data_pins[i], (value >> i) & 0x01); } pulseEnable(); } |
このポート設定をLiquidCrystal::init()に移動して、初期化時に１回だけ設定するように変更すると多少速くなります。
それでも、実用に耐える速度ではありません(-_-;)
|
1 2 3 4 5 6 7 8 9 |
if (fourbitmode) { _displayfunction = LCD_4BITMODE | LCD_1LINE | LCD_5x8DOTS; for (int i = 0; i < 4; i++) pinMode(_data_pins[i], OUTPUT); } else { _displayfunction = LCD_8BITMODE | LCD_1LINE | LCD_5x8DOTS; for (int i = 0; i < 8; i++) pinMode(_data_pins[i], OUTPUT); } |
インテルのGalileoが年末ぎりぎりに届きました。期せずしてArduino MEGA 2560も同じ日に届きました。
早速、お決まりのLチカ動かしてみました。
「スケッチの例：Basics->Blink」を使用して、特に問題無く動作確認完了。
結構互換性高いかもと思いながら、これも定番のキャラクタ液晶をつないでみました。
「スケッチの例：LiquidCrystal->Display」を使用しました。
ハードの結線に合わせて定義文を変更して、コンパイル、ダウンロードしましたが、液晶の表示は全く変化なく、リセットすらされていないようです。
検索したところ、Intel Makers Communityに報告(https://communities.intel.com/thread/45643)がありました。
これによると、ファームウェアのバグのようです、LCD関連の関数を呼び出す前にlcd.init();で初期化を行うことで回避する方法が書かれていました。
取りあえず、「Hello, world!」は表示できましたが、表示速度が遅く（このことも書かれています）、一文字一文字丁寧に書き込まれているのが眼に見えます(-_-;)
設計思想に無理があるのか、エミュレータの出来が今一なのか残念な仕上がりです。今後の改善に期待です。
Galileo & Arduino MEGA 2560
aitendoから発売された液晶with基板（2.4インチforさくら）[LCD024GR-NP]を購入。
aitendoが紹介している「松浦光洋さんの研究開発ページ」から「動作確認用カラーバー」をダウンロードして、Webコンパイラでコンパイルして、GR-SAKURAで動きました。【多謝⇨松浦光洋様】
サンプルコードは液晶にカラーバーを表示するだけのシンプルなものです。
通常マイコンにこのような液晶（VRAMを搭載したスマートディスプレイ）を接続する場合、データ転送するには、転送するデータの他にコントローラとのハンドシェークのために（レジスタの選択や書き込み指示のための）ポート操作が必要で、それなりに煩雑で、手間のかかる処理が必要でしたが、このサンプルコードでは、EXDMAの初期設定後は、ポートに書き込むだけで、データ転送してくれます。【カッコよくて、速い】
サンプルソースは、液晶の表示動作の確認用で、タッチパネルのサンプルは含まれていません。
この液晶に貼り合わせてあるタッチパネルは、今ではちょっと時代遅れの感がある「４線式抵抗膜」仕様のようです。
取りあえず、以前にPICマイコンに接続したタッチパネルの読取りプログラムを参考にしながらコードを書いてみました。
結果、タッチ位置がなかなか安定して読み取れません。 タッチパネルの説明書には、「信号が安定するのを待って読むこと」、「ローパスフィルターが必要」と書かれていますが、具体的な対処は書かれていません。
連続５回読み取って平均値を取るとか、中央値を採用するとか、いくつか思いつくことを試しましたが、良い結果は得られませんでした。
仕方なく、オシロで見ると下図のように波形（ピンクの丸がY座標）が暴れているのが分かります。
コンデンサ無し
暫定対策として、0.01uFのコンデンサをX、Y座標読取り端子に付けてみた結果の波形が下図です。
コンデンサー有り
プログラム的には、コンデンサによって立上りが鈍るので十分に立ち上がるまで（60uS前後）待ってから読み取るようにしています。
波形的には、随分と安定しました（暴れているヒゲが目立たない）。
下は、約5ms置きに読取った電圧を座標変換して、そこを起点として2×2の黄色のBOXを描画してみた画面の写真です。
左がコンデンサ無しで、右がコンデンサ有りの画面です、左の画面にはタッチした場所の周囲に飛び散っている点が多いのが分かります。
メニュー用のボタンを押すぐらいであれば、十分に使えそうです。
また、抵抗膜タッチパネルにつきもののキャリブレーションですが、説明書には「キャリブレーションプログラムを用意すること」と書かれているだけです。
見た感じでは、直線性は悪くなさそうなので、簡単な比率計算で対応できそうです。
ZenWheelsからのデータをダンプしてみた。
（スマホよりも手軽な送信機を作るための情報収集）
リセット
C1 00 81 00 82 00
アクセル前進
82 00
82 01
82 02
..
82 3E
82 3F
アクセル後退
82 00
82 7F
82 7E
..
82 42
82 41
ハンドル右へ
81 00
81 01
81 02
..
81 3E
81 3F
ハンドル左へ
81 00
81 7F
81 7E
..
81 42
81 41
ルームライト
87 01
87 02
83 00 84 00 87 03
83 00 84 00 87 04
87 05
87 00
ヘッドライト
83 02 83 08 84 02 84 08
85 01
83 02 83 08 84 02 84 08
85 02
83 00 84 00
85 00
クラクション
86 01
86 00
右ウインカ
87 00
+繰り返し
+83 00 84 01 84 04
+83 00 84 00
左ウインカ
87 00
+繰り返し
+83 01 83 04 84 00
+83 00 84 00
ハザード
87 00
+繰り返し
+83 01 83 04 84 01 84 04
+83 00 84 00
Bluetooth受信機
CPU:Microchip PIC24FJ64GB002
モータドライバー: TOSHIBA TA7291Px2
制御出力: ブラシモーター(正逆転)×2、サーボ×3、デジタルI/O×1
内部ブロック図
左図（原典：Microchip Technology Inc.）は、Microchip Directで紹介されている、カナダPlantraco社製のMicro Carのブロック図です。
これを見ると、Bluetooth受信機には、Microchip社のRN42NAPL Bluetooth Module、制御には、同社のPIC24HJ128GP204(16-bit, 40 MIPS, 128K Flash MCU)が使われているようです。
受信した制御コマンドで、ステアリング用サーボ、駆動用のモータードライバー、ヘッドライト、ウインカ×2、ハザードランプ、ホーンなどの制御、またラップタ計測用のタグリーダーの読み取りを行なっているようです。
結構贅沢な構成です。
ZenWheels動作確認の様子
スマホで操作できるMicroCarを発注しましたが、次回の入荷はまだ先のようです。 取りあえず、ZenWheelsという操縦アプリをダウンロードして、動作確認。 Bluetoothペアリングして、画面を触るとバイナリデータが送り出されることが確認できました。
このアプリで自作のラジコンカーを動かすことは使用許諾契約違反になるのかなぁ・・(^-^;
電流プローブを発注
 |
Order Date: Friday, 26 July 2013 12:46 Mail Recevied: 2013/7/26 21:46@JST Payment Recevied: 7/26/2013 6:46:10 AM Shipping Method: Expedited お急ぎ便にしてみた・・ 08-01 11:29 SHENZHEN Posting 08/02 22:32 国際交換局に到着 |
