GR-SAKURA
GR-KURUMI
GR-COTTON
GR-CITRUS
GR-PEACH
GR-KAEDE
GR-ADZUKI
GR-LYCHEE
GR-ROSE
GR-MANGO(*)
SNShield
Web Compiler
IDE for GR
TOPPERS関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
がじぇるね岡宮です。
製品リリースから1か月以上も経ってしまいましたが、スケッチリファレンスを作りました。
KURUMIからの相違点といえば、SPI2、SD2、INT2の追加、LED制御の違いぐらいです。モーターやセンサー回りの使い方は特設ページで使い方を増やしていこうと思っています。
ちなみに英語版はもう作ってありますが、製品ページ+特設3ページの英訳が終わり次第、公開いたします。
> 裏で別のperlが動いている(内蔵ROMのWAVテーブル生成とか)ため、
GR-KURUMI_WAVPROM_V1.13.zip と GR-KURUMI_Sketch_V1.13.zip の差分部分を小変更し、perl 等使用することなくビルドできるようしてみました。
GR-KURUMI_Sketch_V1.13.zip から新規作成したプロジェクトにアップロードするだけで ビルドできます。
同様のことは GR-SAKURA_MP3_WAVROM_V2.13.zip 等でも可能と思います。web コンパイラのテンプレートの数がやたらと多いですが、ボード毎にテンプレートはひとつにして、あとはサンプルプログラムとして分離して欲しいです。
(次の投稿のものに差し替え)
バイナリファイルを読み込むマクロ LoadBinFile() の機能と書式を変更
> wavの追加や削除でユーザー側はどうすればよいのか簡単に説明いただけないでしょうか?
若干整理しました。
ファイルを追加したい場合には .wav ファイルをプロジェクトにアップロードで追加し、b2ca_file_list.c に
LoadWavFile("se_maoudamashii_jingle01.wav"/*ファイル名*/, jingle01/*シンボル名*/);
を追加、b2ca_file_list[] の要素に
{"jingle01.wav"/*参照用ファイル名*/, jingle01/*シンボル名*/},
を追加します。
呼び出す場合には gr_sketch.cpp などの中から
wavp.play("jingle01.wav"/*参照用ファイル名*/);
とするだけです。
現状 Wavp ライブラリは
以上の問題があると考えており、ライブラリとしての汎用的な利用を考えるならば解決すべき問題があると思います。
> できることならgr_sketch.cppを編集するだけで実現できることがベターかと思っています。
例えば今回の gr_sketch.cpp と b2ca_file_list.c を、
gr_sketch.cpp: #ifdef __cplusplus #include #include //#define WAVDATA_8BIT Wavp wavp(16000); void setup() { } void loop() { wavp.play("sound24.wav"); delay(1000); } #else #include #include "loadwavfile.h" LoadWavFile("sound24.wav", sound24); const struct b2ca_file b2ca_file_list[] = { {"sound24.wav", sound24}, {"", 0} }; #endif
b2ca_file_list.c: #include "gr_sketch.cpp"
のように書けば、.wav ファイルの追加や変更等でも書き換えるのは gr_sketch.cpp のみにできますが、トリッキーであり全然良いとは思わないですね。
> ・圧縮フォーマットに非対応
ルネサスでは RL78 用に『M3S-S2-Tiny for the RL78 Family』(https://www.renesas.com/ja-jp/products/software-tools/software-os-middleware-driver/renesas-software-library/m3s-s2-tiny.html)というものがあるようなので、これの GCC 版(恐らくはサポートの関係かなんかで国内では非公開であろう)を持ってきて GR-KURUMI他で動作させるというのが良さげな感じですね。
> >音声再生中は処理が帰ってこない(バックグラウンド処理できない)
> これは割込みで停止処理ができます。
どのような用途に使用した場合としてどのやったら回避できるということでしょうか?
私は例えばしゃべるロボットのような音声を再生しながら動作する用途を想定し、音声を再生してる間は動作が止まるようでは話にならないという認識で上記を問題として捉えています。音声再生以外をタイマー割り込みで回すということですか?
藤田様、こんにちは。
fujita nozomu様wrote: said:> できることならgr_sketch.cppを編集するだけで実現できることがベターかと思っています。例えば今回の gr_sketch.cpp と b2ca_file_list.c を、...略... のように書けば、.wav ファイルの追加や変更等でも書き換えるのは gr_sketch.cpp のみにできますが、トリッキーであり全然良いとは思わないですね。引用終わり
試していて気付いたのですが、この話は『マクロの中で__farキーワードを使う必要があるけれども__farキーワードがcppファイルでは使えないというGNURL78の制限ゆえに別途cファイルを使わざるを得ない』ということを仰っている、のではないかという気がしたのですが、その認識であっているでしょうか?
現状のWavp ライブラリを極力改変せず、追加するマクロを簡単なものとする前提では .c の中で __far を使用するのが善策という考えです。マクロを複雑化しても良いという前提では .cpp にテーブルを書くことも可能ですし、Wavp ライブラリを改変する前提ではテーブルそのものを無くすことも可能です。
あぁ、なるほど、処理が返ってこないというより、再生しながら次の処理に進むということですね。それは現状無理かもです。
で、現状の Wavp ライブラリはどういった用途に利用できるというお考えでしょうか?
とあったとして、数字の若いものほど汎用性の高いものとして提供されるべきと思います。現状基本スケッチのひとつとして提供されている Wavp ライブラリが相応しい気はしません。
>API が十分にこなれてる気がしない
私はシンプルでよいと思っています。
再生周波数をコンストラクタで一律に指定する API がこなれてますか? 先の音声再生中は処理が帰ってこない件での理解もそうですが内容を見ていない様見受けられます。
>ライブラリ中でデバグ用の sprintf() が使用されておりコードサイズが大きい
了解です。ちょっと時間あるときに削除して見てみます。
sprintf() は wavp_play.c の中の wavp_play() でのみ使用されており、その関数の手前とかで
#define sprintf(...)
等追加すれば削除の作業は不要です。kurumi_sketch.bin のサイズが約 40kB 減ります。
>圧縮フォーマットに非対応
これもユーザーのご意見次第かなぁと思ってます。
「基本的に内蔵ROM版はWAV生成の際にある程度サイズを気にしつつ、妥当なWAVファイルにする必要があります」と、サイズについて厳しい条件であることは理解されてるのにユーザーからのご意見待ちで現状保留というのは、ユーザーに使われるものを率先して提供しようという気はないということですかね。
Wavpは2で考えてます。 現状スタンダードとしているGR-xxxxxx_Sketch_Vx.xxにはWavpは含めてません。Arduinoスタンダードに含まれていないほか、ファイルもやや多くコンパイル時間やWebコンパイラのサーバー容量も考えるべきだからです。(とはいえGR-PEACHは比にならないくらい多いのですが)
では標準のテンプレートからは外してライブラリとして提供するべきでは?
コンパイル時間やサーバ容量も考慮するならば .wav ファイルを元ファイルの 3倍超となる C のソースに一旦変換などせずバイナリファイルを直接インクルードする .c ファイルとそれを参照する .h を自動生成するという方が良策でしょう。Wev コンパイラでテンプレートによっては特別なスクリプトを用意しているということは、それは要は Web コンパイラに不足している機能があるということでしょう。テンプレート毎に対症療法的な対策をするのではなく、特定の拡張子のファイルに対してはそれをインクルードする仕組みが用意されれば良いのではないかと思います。
用途に関して、大きくはプロデューサーミーティング時に寄せていただいた意見や作品の応用に利用できるものを組み込んでいきたいと思っています。Wavpもその要望に応えさせていただくものですが、前述のインフラ系事情とのバランスで1, 2, 3を考えてます。
現状の音声再生中は処理が帰ってこない Wavp の仕様でどれだけ応用がされるかは甚だ疑問に思います。潜在的な要望が拾えてるとは思えませんし、要望という形でそれを出す人がそもそもどれだけいるかが疑問です。
> サイズが大きくてもsprintfが必要と思っているわけではありません。
GR-KURUMI 初期の頃からの既知の不具合である不要な関数がリンクされて ROM や RAM が無駄に使われる問題は対処されないのでしょうか?
今回テンプレート GR-KURUMI_Sketch_V1.13.zip で確認しましたが makefile の
rom: $(OBJS) $(MAKEFILE) $(LNK) $(OBJS) $(LFLAGS) -o ./gr_build/$(TARGET).x $(CNVB) ./gr_build/$(TARGET).x $(TARGET).bin $(CNVS) ./gr_build/$(TARGET).x ./gr_build/$(TARGET).mot rm -f *.o
の部分を
rom: $(OBJS) $(MAKEFILE) $(AR) objfiles.a $(filter-out ./gr_common/RLduino78/portable/e2studio/RL78/reset_program.o ./gr_common/RLduino78/portable/e2studio/RL78/vector_table.o, $(OBJFILES)) $(LNK) ./gr_common/RLduino78/portable/e2studio/RL78/reset_program.o ./gr_common/RLduino78/portable/e2studio/RL78/vector_table.o objfiles.a $(LIBFILES) $(LFLAGS) -o ./gr_build/$(TARGET).x $(CNVB) ./gr_build/$(TARGET).x $(TARGET).bin $(CNVS) ./gr_build/$(TARGET).x ./gr_build/$(TARGET).mot rm -f objfiles.a *.o
と書き換えるだけで生成される kurumi_sketch.bin のサイズが 45174バイト → 27682バイト となり 17kB ほどの縮小がされ、不要な関数がリンクされなくなることで ROM と RAM の使用量が減っていることが .map ファイルで確認できます。同様の報告はもう何年も前にしていると思います。