ST7735 ライブラリは公式（https://github.com/adafruit/Adafruit-ST7735-Library）レベルで ESP8266 に対応していますので、サンプルなどのピン番号を適当に変えてやれば何事もなくコンパイルが通り Arduino 同様に動作します。
ただ、ESP8266 用に高速化されたらしいものがあるみたいです。
https://github.com/nzmichaelh/Adafruit-ST7735-Library
Adafruit の ST7735 とは URL が違う点に注意。github のしくみよくわかってないのであえて言いますが 8266 最適化版とか高速版とか、名前を変えてほしかったですねー。そうすれば何も考えずにライブラリフォルダに投げられたのにねい…（※ Arduino nano 互換機 ( 328P-AU ) で試してみましたがそちらでは元のライブラリと全く変わりなく使えます）。
Download Zip して h、cpp ファイルを得ます。ライブラリフォルダを置き換えてもいいかもしれませんが、Arduino IDE の起動時アップデート確認をオンにしておくとこのライブラリを常にアップデート可能と判断しますので置き換えるのは賢明ではありません。よって #include "*.h" にてインクルードしてローカル使いします（スケッチファイルと同じパスに投げておきます）。深い意味を考えずにこちらの泥臭い方法を使うことにします。
※理由は分かりませんが、ものぐさで一時的にライブラリフォルダのファイルを入れ替える方法を試してみたのですが、ESP-WROOM-02 が無限に再起動し続けるのでダメでした。
ピンについて
どうやら ESP8266 のすべての GPIO ピンで動くわけではないようです。次のようにすると動作するので無難です。どうしてもそのピンが使えない場合は調べる必要があります。
ST7735 (別名) - 328P -> ESP8266
DC (A0) - D8 → GPIO4
RST - D9 → GPIO5
CS - D10 → GPIO16
MOSI (SDA) - D11 → GPIO13
SCLK - D13 → GPIO14
画面がおかしい時は正しい画面サイズで初期化されているかを確認します。
※無難といえば ESP-WROOM-02 のデフォルトピンを使うのが一番だとは思います。
この図はどこかから切り出したんでしょうか、出どころが不明です。一応、こちらのサイトからコピーした画像です。
<170322>
なんと！ ST7735 の CS ピンは こちら によると GND（Lo）で良いんだそうです！ ST7735s ですが動作確認しました。便利！
余談：こちら によるとディスプレイドライバによってはクロックで同期をとるのでなんでもかんでも CS を Lo にできるわけではないということは頭の隅においておきたいです。
<170324> ベンチマーク
Arduino (328P) ではすごく遅かった ST7735。ESP-WROOM-02 による速さを見てみたくて、テキトーなベンチマークっぽいのをやってみました。このサイトだと表示が味気ないですが一応コードも添えておきます。
#include <Adafruit_ST7735.h>
#include <Adafruit_GFX.h>
#include <SPI.h>#define TFT_DC 4
#define TFT_RST 5
#define TFT_CS 16
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_RST);
// #define TFT_MOSI 13
// #define TFT_SCLK 14
int tftRectWidth; // 128
int tftRectHeight;// 160
int boxSize= 1;
int nextTime, drawcnt= 0;
void setup(void) {
Serial.begin( 115200 );
tft.initR(INITR_BLACKTAB); // 正しく表示できれば何でもよい（良くはない）
tft.fillScreen(ST7735_BLACK);
tftRectWidth = tft.width() /*128*/- boxSize;
tftRectHeight= tft.height()/*160*/- boxSize;
nextTime= millis()+ 1000;
}
void loop() {
int x= random( 0,tftRectWidth );
int y= random( 0,tftRectHeight);
int c= random(65535);
tft.fillRect( x,y,boxSize,boxSize, c );
drawcnt++;
if (nextTime< millis() ) {
nextTime= millis()+ 1000;
Serial.println( "FPS: "+ String(drawcnt)+ " @boxSize= "+ String(boxSize) );
drawcnt= 0;
boxSize+= boxSize;
if (boxSize>64) { boxSize= 1; }
tftRectWidth = tft.width() /*128*/- boxSize;
tftRectHeight= tft.height()/*160*/- boxSize;
}
}
random の計算にかかる時間とかめんどくさい事言うとキリ無いのでこういうもの！として進めますね。
まず通常の ST7735 ライブラリによる速度を見てみましょう。
FPS: 13729 @boxSize= 1
FPS: 11278 @boxSize= 2
FPS: 6583 @boxSize= 4FPS: 2472 @boxSize= 8
FPS: 707 @boxSize= 16
FPS: 184 @boxSize= 32
FPS: 47 @boxSize= 64
次にこれを最適化版 ST7735 ライブラリで実行してみます。
FPS: 19641 @boxSize= 1
FPS: 17364 @boxSize= 2
FPS: 11908 @boxSize= 4FPS: 4002 @boxSize= 8
FPS: 1570 @boxSize= 16
FPS: 458 @boxSize= 32
FPS: 120 @boxSize= 64
最適化がすばらしいですね。使った関数は fillRect だけですが、目に見えて速くなってますよね。ベンチマークの数値自体が本当かどうかはわかりませんが同じコードでこれだけ差が出たのは事実です。
問題
ランダム座標にぺたぺた正方形を張り付けるサンプルなので見えにくいですが、同じ座標に表示し続けるようにするとものすごくチラツキ（ピクセルが崩れ）が起こります。実用的なアニメーションを表示するためには、もっと壮大な工夫が必要みたいです。
0コメント