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ページの英訳が終わり次第、公開いたします。
試していて気付いたのですが、この話は『マクロの中で__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 ファイルで確認できます。同様の報告はもう何年も前にしていると思います。