スケッチリファレンス作りました、ようやく。。

より美味しくRL78/G13をいただけるのですね。
と言うか増えたサポートハードウエアのライブラリを、KURUMIとマージして欲しい。

web コンパイラのテンプレートの数がやたらと多いですが、ボード毎にテンプレートはひとつにして、あとはサンプルプログラムとして分離して欲しいです。

> 裏で別のperlが動いている(内蔵ROMのWAVテーブル生成とか)ため、

WAV 等のバイナリファイルを C の書式に合った 16進数に変換してプログラムの一部とする程度のことであれば、やり様ではバイナリファイルのまゝできないこともないです。

参考:
japan.renesasrulz.com/.../9694

> 裏で別の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() の機能と書式を変更

Fujitaさん、ありがとうございます。wavの追加や削除でユーザー側はどうすればよいのか簡単に説明いただけないでしょうか？
できることならgr_sketch.cppを編集するだけで実現できることがベターかと思っています。

> 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 ライブラリは

• 音声再生中は処理が帰ってこない(バックグラウンド処理できない)
• WAV ファイルに情報として含まれる周波数とサンプリングレートの情報を利用しておらず、複数の音声ファイルをそれぞれの別の設定にしての利用が煩雑
• API が十分にこなれてる気がしない
• ライブラリ中でデバグ用の sprintf() が使用されておりコードサイズが大きい
• 圧縮フォーマットに非対応

以上の問題があると考えており、ライブラリとしての汎用的な利用を考えるならば解決すべき問題があると思います。

> できることなら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他で動作させるというのが良さげな感じですね。

ありがとうございます。ただ、やはりちょっと煩雑になってしまうと思ってまして、メリットを考慮して検討したいです。
>音声再生中は処理が帰ってこない(バックグラウンド処理できない)
これは割込みで停止処理ができます。
>WAV ファイルに情報として含まれる周波数とサンプリングレートの情報を利用しておらず、複数の音声ファイルをそれぞれの別の設定にしての利用が煩雑
これは利用ケースに応じてと思ってます。基本的に内蔵ROM版はWAV生成の際にある程度サイズを気にしつつ、妥当なWAVファイルにする必要があります。
>API が十分にこなれてる気がしない
私はシンプルでよいと思っています。Readmeにある通りMatsuuraさんに作っていただいてますが、ユーザーのご意見あれば反映すべきとは思っています。
>ライブラリ中でデバグ用の sprintf() が使用されておりコードサイズが大きい
了解です。ちょっと時間あるときに削除して見てみます。
>圧縮フォーマットに非対応
これもユーザーのご意見次第かなぁと思ってます。

> >音声再生中は処理が帰ってこない(バックグラウンド処理できない)

> これは割込みで停止処理ができます。

どのような用途に使用した場合としてどのやったら回避できるということでしょうか?

私は例えばしゃべるロボットのような音声を再生しながら動作する用途を想定し、音声を再生してる間は動作が止まるようでは話にならないという認識で上記を問題として捉えています。音声再生以外をタイマー割り込みで回すということですか?

あぁ、なるほど、処理が返ってこないというより、再生しながら次の処理に進むということですね。それは現状無理かもです。

藤田様、こんにちは。

fujita nozomu様wrote: said:

> できることならgr_sketch.cppを編集するだけで実現できることがベターかと思っています。
例えば今回の gr_sketch.cpp と b2ca_file_list.c を、
...略...
のように書けば、.wav ファイルの追加や変更等でも書き換えるのは gr_sketch.cpp のみにできますが、トリッキーであり全然良いとは思わないですね。引用終わり

試していて気付いたのですが、この話は『マクロの中で__farキーワードを使う必要があるけれども__farキーワードがcppファイルでは使えないというGNURL78の制限ゆえに別途cファイルを使わざるを得ない』ということを仰っている、のではないかという気がしたのですが、その認識であっているでしょうか？

試していて気付いたのですが、この話は『マクロの中で__farキーワードを使う必要があるけれども__farキーワードがcppファイルでは使えないというGNURL78の制限ゆえに別途cファイルを使わざるを得ない』ということを仰っている、のではないかという気がしたのですが、その認識であっているでしょうか？

現状のWavp ライブラリを極力改変せず、追加するマクロを簡単なものとする前提では .c の中で __far を使用するのが善策という考えです。マクロを複雑化しても良いという前提では .cpp にテーブルを書くことも可能ですし、Wavp ライブラリを改変する前提ではテーブルそのものを無くすことも可能です。

あぁ、なるほど、処理が返ってこないというより、再生しながら次の処理に進むということですね。それは現状無理かもです。

で、現状の Wavp ライブラリはどういった用途に利用できるというお考えでしょうか?

1. 基本スケッチ
2. スケッチに後から追加できるライブラリ
3. サンプルプログラム

とあったとして、数字の若いものほど汎用性の高いものとして提供されるべきと思います。現状基本スケッチのひとつとして提供されている 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は比にならないくらい多いのですが）

用途に関して、大きくはプロデューサーミーティング時に寄せていただいた意見や作品の応用に利用できるものを組み込んでいきたいと思っています。Wavpもその要望に応えさせていただくものですが、前述のインフラ系事情とのバランスで1, 2, 3を考えてます。

API全般についてのあるべき論はこのスレではちょっと控えさせていただきたいです(プロデューサーミーティングや他の打ち合わせなどでは結論を出すまでやりたいですが)。APIについてはご意見として「こうした方がよい」ということでよいと思います。「こなれている」というのはちょっと基準が分かりません。ライブラリ作成者の意図もあるものと思っています。
>音声再生中は処理が帰ってこない(バックグラウンド処理できない)
これは取りようによって割込みも受け付けられないように思えました。割込みを受け付け、Pauseは行えます。ですので、勘違いと考えていただければと思います。

sprintfに関して、ご提案いただきありがとうございます。そのように修正していきたいと思います。提供側の考慮が抜けている部分は多々存在すると思いますので、今後もよろしくお願いいたします。
サイズが大きくてもsprintfが必要と思っているわけではありません。

API全般についてのあるべき論はこのスレではちょっと控えさせていただきたいです(プロデューサーミーティングや他の打ち合わせなどでは結論を出すまでやりたいですが)。APIについてはご意見として「こうした方がよい」ということでよいと思います。「こなれている」というのはちょっと基準が分かりません。ライブラリ作成者の意図もあるものと思っています。
>音声再生中は処理が帰ってこない(バックグラウンド処理できない)
これは取りようによって割込みも受け付けられないように思えました。割込みを受け付け、Pauseは行えます。ですので、勘違いと考えていただければと思います。

sprintfに関して、ご提案いただきありがとうございます。そのように修正していきたいと思います。提供側の考慮が抜けている部分は多々存在すると思いますので、今後もよろしくお願いいたします。
サイズが大きくてもsprintfが必要と思っているわけではありません。

> サイズが大きくても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 ファイルで確認できます。同様の報告はもう何年も前にしていると思います。

Fujitaさん、ありがとうございます。採用させてください。
2年前ですね。当時はWebコンパイラでのコンパイル時間が問題になっていてアーカイブ版とソース版を分けてテンプレート化した際にバイナリのサイズがアーカイブ版の方が小さく、KPITのご意見箱に不具合改善リクエストしてアクセプトされたのですが、その後修正されなかった・・・というものですね。
以下、Fujitaさんからいただいたものはなるべく取り入れてきたつもりではあるのですが、今後もよろしくお願いいたします。
japan.renesasrulz.com/.../gr-kurumi
japan.renesasrulz.com/.../11247

そう言えば最近、100mbyte制限って無くなっているのかしら。ビビりながらプロジェクト作っていまっす。

はい、Webコンパイラを刷新した2年くらい前に、実情を踏まえて制限を解除しました。
制限を復活する予定は今はないですが、復活するにしても既存プロジェクトを勝手に破棄するようなことはいたしませんので、ビビらなくてもOKです。