arduinoコミュのadafruit の RGB Matrix 表示器 + SDカード読み出し

追記ですが、メモリがオーバーフローしてるかどうかですが、次のような方法で調べることが出来ます。

設定
環境設定→より詳細な情報を表示する→コンパイルにtick

build
ウィンドウにbuildが行われてるテンポラリフォルダが表示されるので　コマンドプロンプトを起動してそのフォルダに移動

"avr-size *.elf"　で そのフォルダをコンパイルに使ったスケッチすべてのメモリ使用サイズが表示される。

dataというのは初期化されるRAMの使用量でBSSが初期化されないRAM
つまりdata+BSSがRAMの総使用量でこれが使用するArduinoを超えていればスタックが壊れてハングする事になります。

それにしてもエラーではじく事は出来なかったんでしょうかね、、、

>>[8]
このパネルのライブラリはmalloc()でヒープ領域にメモリを確保するので、それだけだとわからないです。
ライブラリ見るとmallocに失敗しても何もしていないので、RGBmatrixPanel.cppの97行目
if(NULL == (matrixbuff[0] = (uint8_t *)malloc(allocsize))) return;
このreturnの直前に何かエラーを出力するような処理を入れればわかるかもしれません。


ちなみに最近のIDEではコンパイル後にRAMの使用量も表示してくれるので便利になりました。もしそのようなバージョンをお使いであれば、mallocで32×16×3=1536バイトの確保されるようなので、コンパイル後に表示される空き領域が最低1536byte（+スタックに必用な領域）が無いとだめです。

なるほどたしかにヒープとスタックはリポートに上がってこないんでどんな場合でもコードから予測しなきゃ駄目ですね。

早速 arduino mega 2560 で試してみました。

結論から言うと、うまくいきました。ばっちりと
ＳＤカードの読み書きをしながら、RGB Matrix
の駆動（とはいってもサンプルそのまま）に
成功しています。プログラムはピン番号くらい
しか変えていないので、やはり uno の 2kB
のＲＡＭでは足りなかったというのが結論の
ようです。

次はいよいよ、SD カードに記録した BMP
ファイルを読み出して LED に表示させる
部分の作成に入ります。

忘備録：結線表
uno　用シールド　- mega 2560

RGB Matrix
(D2) 2 - 24 (PA2)
(D3) 3 - 25 (PA3)
(D4) 4 - 26 (PA4)
(D5) 5 - 27 (PA5)
(D6) 6 - 28 (PA6)
(D7) 7 - 29 (PA7)
(D11) 11 - 11 (PB5)
(A0) A0 - A0 (PF0)
(A1) A1 - A1 (PF1)
(A2) A2 - A2 (PF2)
(A3) A3 - A3 (PF3)

SD Shield　(CS = D10)
(D10) 10 - 53 (PB0)
(D11) 11 - 51 (PB2)
(D12) 12 - 50 (PB3)
(D13) 13 - 52 (PB1)

でもこれ、RGB Matrix のライブラリが 4bit カラー (1ピクセル２バイト）なら
uno でも多分動いただろうに、惜しいなあという気がします。

SD部分のライブラリをCで書かれた fatfsのRead　onlyの軽量バージョン petit-FATfsに置き換えれば　RAMの使用量は４４バイト＋スタックの分だけで済むのでUNOでも十分動くかもしれませんね。

http://elm-chan.org/fsw/ff/00index_p.html

レジスタを直接触る最下層は使用するチップに合わせて改造しないといけないですが、基本的にAVRマイコン用なのでサンプルプロジェクトを参考にすればわかりやすいと思います。

これを使えば8ピンのATTinyシリーズでSDオーディオプレーヤーを動かすことができるそうです。

http://elm-chan.org/works/sd8p/report_j.html

参考まで。

なんと、そんなステキプロダクトが・・・ arduino で使うにはちょっと
ひと手間いりそうですが検討の価値はありそうです。
とりあえず、手早く mega で動かしてみて、問題なさそうなら
petit-FATfs に置き換えて uno 化を検討してみます。

というわけで、ＳＤカードから読みだして描画する方法を実行してみました。
機種は arduino mega 2560 で実施。

プログラムが手抜きで、24bit bmp 32x16 pix 以外は読めませんが一応
ＳＤカードに収めた bmp フォーマットの画像を表示する事に成功しました。
左側の写真が実働、右側が表示しているデータ（を２倍してＪＰＥＧに
したもの）です。色合いの問題はさておき、きちんと表示されてます。

しかし、描画速度は非常に遅く、ノーウェイトで画面を書き換えても５ＦＰＳ
出るかでないかといったレベルです。一枚の画像の描画に、０．２〜０．３
秒ほどかかっており、ピクセルの書き換えシーンが目視でわかるレベル
です。

それでも、シリアル経由で送信したファイル名を画面に表示し、動的に
切り替えられているのでひとまず mega 2560 版はＯＫとします。
次は、PetitFATfs 使って uno で動くようにしたいところ。

>>[16]
素晴らしいですね。わたしはRaspberry Piに逃げてしまったのですが（だってそこにあったんだもん）、arduinoでもここまでできるのですね。

Petit-FATfs を arduino で使うためのサンプルがあったので
以下のＵＲＬを参考にして uno で実装試験してみました。
http://forum.arduino.cc/index.php/topic,37604.0.html

結果、こちらでも RGB Matrix を表示しながら SDカードの
データの読み出し処理に成功しました。読み出しができたと
いうだけで、まだ一切のＳＤカードコントロールはできてない
ので、これから解析になりますが、うまくいったら mega 2560
だけではなく uno (ATmega328P) でも bmp 画像を表示できる
ようになります。それができれば、mega 2560 より遥かに敷居
が下がって、一気に用途に弾みがつきそうで楽しみです。

shigさん
Raspberrypi のプロジェクト見ました。うーん、本当はこのくらい
スムーズにスクロールさせたいのですよね、arduino でも。
しかし、adafruit の標準ライブラリを使う限りでは、どうしても
毎秒４〜５回の画面書き換えが限界でちょっと残念がってます。

できれば RGB Matrix のデータシートにタイミングチャートとか
掲載されていれば、自分でコントロール部分作ってでももう少し
スムーズなアニメーションをしたいと思ってるのですが・・・

とりあえず、ＮＴ金沢２０１４に持って行く一つの目玉はできそうです。

ファイルシステムに Petit-FATfs を使うことで、なんとか
arduino uno で動かすことに成功しました。mega に比べて
敷居は非常に低くなったと思います。
描画の速度は相変わらず激遅で毎秒２枚程度です。
adafruit のライブラリを経由せず、直接 VRAM ? にデータを
書き込めればもう少しは早いのかなと思われますが。
あとで回路図とプログラムをどこかにアップします。

お、順調ですね。

非常に遅いということなんですが、どこがボトルネックになってるのか気になります。この前ライブラリをちょっとのぞいたときは、動作速度を上げるために、わざわざものすごく汚い書き方（割り込みハンドラの中でクロックのポートを２つの変数にコピーして、それぞれにクロック０と１をマージして、交互に元のポートにコピー）までして速度に気を使ってたみたいなので。

自宅には環境がないので昼休みとか時間があったら興味があるんでちょくちょく追っかけてみようかと思います。

理論上は16x32ピクセルに３色分を数回に分けて書き込むだけなので１６MHZならそこまで遅くならないような気もするのですが。

あと検索してたら　軽くリバースエンジニアリングしてアセンブラのドライバを書いてる人のページ見つけたので貼っておきますね。

http://www.rayslogic.com/propeller/programming/AdafruitRGB/AdafruitRGB.htm

ねこ蔵 さん
ちょっと気になったのでチェックしてみたところ、どうも SD カードのルートに
大量(300近く)の無関係なファイルを置いたせいで、ファイルを open するのに
時間を取られていたようです。新品の microSD に 6ファイルだけにしたところ
１画面描くのに 120ms ほどに短縮できました。

１画面を描くのには、Petit-FATfs で地味に時間がかかっているようで、
１行96バイト分のデータをＳＤから読み出すのに 4ms ほどかかっていて、
１画面１６行 = 64msec、＋ bmp ヘッダの読み出しにも 4ms として
68msec はどうしても最低のコストとして必要なようです。

さらに、その描画している走査線が画面の下から上へ走っている所が見えて
しまいます。

現在は１ラインずつSDからデータを取得していますが、２ラインづつ取得
することで少しは早くできないか検討してみたいです・・・が、すでにもう
ＲＡＭカツカツだろうなぁ。

リバースエンジニアのページは、後で拝見します。

ラッパーを使われてるのでしたらSPIはハードなので問題ないと思います。
SPIの速度デフォルトのCLK/4で使っているのであれば、SPIX2というビットを立てれば速度が倍になるはずです。

具体的には　SPSR　|= BV(SPI2X) ; を追加する感じです。

あとはメモリに貯めて書き込むよりも、せっかくpeti-fatfsなのでストリームモードで直接関数に流し込めばバッファも不要ですしバーストで読み出していけるはずなのでいいんじゃないかと思います。昔音楽再生の実験をやるのに使ったことがあるていどなのでうろ覚えですが、関数のポインタをどっかでセットしたりとちょっとややこしかった覚えがありますが。

愛の渇き。 さん
１．バッファの拡大は帰ったら試してみますが、すでにＲＡＭはカツカツです。
　　uno の RAM 2kB に対して、adafruit のライブラリが 1536B 消費します。
　　データの最適化は、BMP フォーマットをそのまま読み出すのが絶対条件
　　なのでナシの方向で。

２．SD へのアクセスは Petit-FATfs というシステムのラッパを使っており、
　　内部の解析は行ってないのでどうとも言えませんが、ここが怪しいです。

３．ルートにファイルが多かったのは原因の一つでしたので、減らす事で改善
　　しました。が、FAT領域の読み込みでやっぱ時間食ってますね。

ねこ蔵さん
　SPIX2 ビットですか、簡単な処理で倍速化できるなら試さない手はないですね、
　今日帰宅したら早速試してみます。
　ストリームモードは非常に興味ありますが、bmp の生データをそのままライブラリ
　に引き渡すのは難しい（色順序の変更＆ビットまるめ処理が必須）ですね。
　wav ファイルみたいに、本当にそのまま流すのであればいいのですが。
　ラッパにストリームモードありましたっけ・・・？英語あまり得意でないので
　結構難儀してます。

ちなみに現時点でのソースです。

#include <petit_fatfs.h>
#define SDCS 10
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library
#define CLK 8 // MUST be on PORTB! (Use pin 11 on Mega)
#define LAT A3
#define OE 9
#define A A0
#define B A1
#define C A2
RGBmatrixPanel matrix(A, B, C, CLK, LAT, OE, false);
#define FLENGTH 16
#define READBUF 96 // SD の読み出し用バッファ
char filename[FLENGTH] ;
byte namePos ;
#define SCREEN_W 32 // 画面のサイズ
#define SCREEN_H 16
signed long img_w ; // BMP ファイルの イメージ幅
signed long img_h ; // BMP ファイルの イメージ高
signed long img_b ; // 横サイズの 4 バイトバウンダリ値

// -----------------------------------------------
void setup() {
Serial.begin(9600);

// SD カード用バッファメモリ確報
char * s = (char*)calloc(READBUF+1, sizeof(char));
namePos = 0 ;
for (byte i=0 ; i<FLENGTH ; i++) filename[i] = 0 ;

// spi INIT
digitalWrite(SDCS, HIGH);
pinMode(SDCS, OUTPUT);
digitalWrite(SDCS, LOW);
digitalWrite(SDCS, HIGH);

pinMode(10, OUTPUT);
pinMode(11, OUTPUT);
pinMode(12, INPUT);
pinMode(13, OUTPUT);
SPCR = _BV(MSTR) | _BV(SPE); // Master mode, SPI enable, clock speed MCU_XTAL/4

matrix.begin();
matrix.fillScreen(matrix.Color333(0, 0, 0));
PFFS.begin(SDCS, rx, tx);
strcpy(filename,"0.BMP") ;
fileReadTest(PFFS.open_file(filename), filename);

}
// -----------------------------------------------
void fileReadTest(int err, char * fp) {
if (err == 0) {
char * s = (char*)calloc((READBUF+1), sizeof(char));
int bytes_read;
int bytes_cnt = 0;

PFFS.lseek_file(18) ;
PFFS.read_file(s, 12, &bytes_read);

img_w = (s[3]<<24)|(s[2]<<16)|(s[1]<<8)|s[0] ;
img_h = (s[7]<<24)|(s[6]<<16)|(s[5]<<8)|s[4] ;
word bw = (s[11]<<8)|s[10] ;
img_b = img_w * 3 ; // 1ピクセル3バイト
if ((img_b & 3) != 0) { // 4バイトのバウンダリ
img_b &= ~3 ;
img_b += 4 ;
}
if (bw != 24) return ; // 24 bit Color 以外無効
PFFS.lseek_file(54) ; // イメージデータの先頭へシーク
byte r,g,b ;
for (char y=img_h ; y>=0 ; --y) {
Serial.println(millis());
PFFS.read_file(s, img_b, &bytes_read) ; // 画素データ読み込み
Serial.println(millis());
for (char x=0 ; x<img_w ; x++) {
r = s[x*3+0]>>4 ;
g = s[x*3+1]>>4 ;
b = s[x*3+2]>>4 ;
matrix.drawPixel(x, y-1, matrix.Color444(b, g, r));
}
}
free(s);
}
else {
Serial.print("Error code ");
Serial.print(err);
Serial.print(" while opening ");
Serial.println(fp);
}
}
// -----------------------------------------------
void loop(){
strcpy(filename,"2.BMP") ;
fileReadTest(PFFS.open_file(filename), filename);
strcpy(filename,"3.BMP") ;
fileReadTest(PFFS.open_file(filename), filename);
}
// -----------------------------------------------
byte rx() {
SPDR = 0xFF;
loop_until_bit_is_set(SPSR, SPIF);
return SPDR;
}
// -----------------------------------------------
void tx(byte d) {
SPDR = d;
loop_until_bit_is_set(SPSR, SPIF);
}

ラッパにもストリームモードは付いてますね。ただ速度が必要なら直接petit Fatfsの関数をさわるほうが確実な気もします。

ストリームモードは読み出した値を渡す関数を作っておいて、関数のポインタで呼び出すような構造になってたはずですので、関数の先頭でデータを加工してから表示パネルのライブラリに渡すような感じになると思います。さわってた当時は完全に理解してたのですがすっかり忘れてしまってて（笑

大丈夫だとは思いますが、SPIの設定で　SPCRレジスタも最速（ｆ/4）になってますよね？x2とあわせ技で8MHzになるはずです。初期化時は400KHz以下に設定するのがｍｍｃの仕様なので、もしラッパの中でさわってて400KHzのままになってないかちょっと心配でした。　 PFFS.beginの後で再度設定しなおしておくと安心かと思います。

今ソースみました。ひょっとしてシリアルで時間結構食ってませんか？
高さのピクセル分ループする中に serial.printでmillisを表示する評価用ルーチンが2回も入ってますよね。

たしかAdruinoのシリアル送信は割り込み使わずに終わるまで待つ仕様だったはずだったと思うので、SD読み込みの前後の2箇所のmillisの表示時刻の差分はSDの実行時間だけではなく最初のシリアル送信にかかった時間を追加した物になってしまいませんか？だとすれば文字数-1*1mSぐらい余分な時間になりますよね。

仮に電源オンしたばかりでmillisがまだ4桁ぐらいだとしても改行コード入れたら6文字（？）。これを2回ずつ縦の16ピクセル分出力するわけですから、それだけでmillisの桁数にもよりますがシリアル実行時間だけで軽百mSぐらいになってしまうのでは？

実行時コメントにされてるならいいのですが、ソース見ててふと気づいた物で。

>>[28] 　シリアル送信は、Arduino IDE 1.0以降から割り込みを使った動作になってます。送信バッファが満タンになると待つ事になりますが。

＃送信後にパワーダウンするようなスケッチが1.0以降動かなくなって焦った経験者。

取り急ぎ、ねこ蔵さん
SPSR　|= BV(SPI2X) ; で、体感的に倍速になりました！
この速度ならまあ実用・・にはまだちょっと遅い感じですね。
特に描画途中の様子が見えてしまうのが厳しいです。
それでも１０ＦＰＳ以上は出るようになりました。
今日は別件でじっくり作業ができないので、また明日以降
確認してみます。まずはお礼まで。

>Arduino IDE 1.0以降から割り込みを使った動作になってます。

あ、そうなんですか。それは知りませんでした。(一応ライブラリを覗こうかと思ったんですがさぼりました）　ただそうなると割り込みがじゃんじゃんかかるのでそれはそれでオーバーヘッドがでかくなりそうですね。ちょっと計算しないと直観的にはわかりませんが。となると何でしょうね？
・

あとラッパで気になったのですが、元のプロジェクトの人はSPIを4MHzに設定してからbeginでSDの初期化かけてるように見えるんですが、最近のSDは400KHzにしなくても初期化動いちゃったりするんでしょうかね？　自分はdisk_nitializationの前に250KHzぐらいにして、初期化終わってから8MHzに戻して使ってましたが。

それ以外にラッパで気になったのが、arduinoだから汎用的に書くためには仕方ないんでしょうけどCSの上げ下げにいちいちくそ遅いdigitalWrite使ってるのでポート直接叩くように改変すれば100クロック分の時間が丸々削れますね。まあバーストである程度の量を読むような場合にはあまり大きな差はないのかもしれませんが。

>SPSR　|= BV(SPI2X) ; で、体感的に倍速になりました！

お、改善されたようでよかったです。
ってことはやっぱSD読み出しで手間取ってるんですかねえ？

パネルのドライバも確か書き込み字に割り込み使ってたと思うので、シリアルを取っ払って一度試されてはどうでしょう？シリアルの割り込みが文字数の回数入ることになるのでスタックしたり戻したりでかなり時間食われるそうな気がします。

なるほど。MMCモードでオープンドレインのピンがあるからっていうのが理由だったんですね。内部を初期化したりする都合なのかな？と思ってました。お恥ずかしい。

おはようございます。

ゆうべの実験結果ですが、

１）SPSR　|= _BV(SPI2X) ; の定義で体感的な描画速度は倍。

２）SD 用のバッファを2ライン分(192byte)にして、微妙に描画速アップ？

３）Matrix ライブラリの digitalWrite() を PORT を直接叩くように修正、体感は「？」

４）ファイル名を短くしてみた。気休め？

この４つを追加実施して、なんとかアニメーションに耐えられるレベルの
画面更新速度を確保できたかな、という感じです。
次はアニメーションパターンを作って実際にアニメーションした上で
最終的な評価をしてみます。ご意見ご協力、ありがとうございます。

シリアル通信は、外部からの指示で描画変更が必須のため外せません。

>シリアル通信は、外部からの指示で描画変更が必須のため外せません。

シリアル自体はいいので、メモリから読んで書き込みしてる所のmillis()をシリアルしてる所だけでもとっぱらったらかわりませんか？

上記、とっぱらってみました。計測上、ほとんど変化なかったです。

そもそも、drawPixel()が内部で1ビットずつ処理しているので、これに時間がかかりそう。

あらかじめPCで書き込んでおいたBMPファイルを表示する…という事であれば、ちょっと違反かもしれないけど、PCや別のスケッチで事前にBMPから「1画面分のdrawPixelによって作成されるバッファの中味」そのものに変換したものをSDに保存しておけば、結構高速化できるかもしれませんね。

あと思ったのが、Color444() でr,g,bの値を一旦16ビットに合成してからdrawPixcelの中でr,g,bの値にバラすってのがちょっと無駄かなと思いました。

実際のところ、１ピクセル転送しているところで時間がかかってるのは事実です。
動画苦手でアップできないんですが、目視でも書き換えている走査線の位置が
認識できてしまう程度には遅いのが現状です。

多分その　「最終的にＶＲＡＭに格納される形でＳＤに収録されたベタデータを転送するだけ」　が
一番効率がいいと思います・・・が、残念ながら知識不足でして、

１）ＳＲＡＭに保存されているベタデータの形
２）ＳＤから読みだしたベタデータをＶＲＡＭにダイレクトに転送するプログラム

がサクっと出てこないのが悔しいところです。

ここまできたら、ベタデータの形がわかるようなら、Windows 側、あるいは arduino の中で
bmp をベタフォーマットに変換するプログラムを作ってしまってもいいかもしれません。

ＳＤカードには bmp ファイルを書き込んで、ブート時やシリアルコマンドで bmp ファイルを
ベタファイルに変換して SD に書き込んでおき、表示する時はそのファイルを使う、みたいな。
電源ＯＮで少し変換時間を食うかもしれませんが、Raspberrypi のブートに比べれば
圧倒的に高速でしょうし。

>>[40]
ライブラリ見ると、まさにデータを直接読み書きするための仕組みが準備されてますね。
その前にまず訂正、以前に「mallocで32×16×3=1536バイト確保される」と書きましたが、これはバッファを2面確保した場合で（描画用と表示用を分け、描画が終わったら切り替えるという使い方）、1面だけであればその半分の768バイトでした。

で、backBuffer()というメソッドでバッファの先頭アドレスが得られるので、1画面分の描画を終えてから、例えば標準のSDカードのライブラリを利用して、
uint8_t *buff;
buff = matrix.backBuffer();
file.write(buff,768); // file はSD.open() で得られるインスタンス
とすればSDカードに書き込むことができると思います（すみません、試してませんが。UNOだとメモリ不足かな）。

読み出しはPetit-FATfsを使うとして、
PFFS.read_file(buff, 768, &size);
って感じに、SDカードから直接バッファに書き込めるかと思います。

ちなみに、dumpMatrix() というメソッドもあり、これを使うとバッファの内容がCのソースの形式でシリアルに出力されるようです。これをスケッチにコピペすれば、画像データをスケッチに簡単に埋め込むことができそうです。

>>[43]
まだ使ってないので回答になってませんが、最新βのVer1.5.7ではフォルダ名にハイフンがあっても使用できるようになっています。（たぶんこれが原因ではないと思いますが）

はじめまして！ 自分は秋月でRGBマトリクス表示器を買ってテストプログラムを動かして遊んでいるのですが、パソコンに入っている画像を表示器に表示したいなと思っております。 そこで、表示させるためのプログラムなんですが、サッパリ分からなくて詰んでます。 どなたかお力をお借りできませんか？ arduino unoを使用してます。

続きですが、ASCIIの文字はテストプログラムで動きますが漢字やひらがななどはどうやったら出せるのか聞きたいのですが