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関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
がじぇるね岡宮です。
RL78/G13のボードとしてGR-KURUMI、GR-COTTON、GR-ADZUKIの3つがありますが、これらのライブラリをマージしようと思います。
★3/13を目途にご要望や修正点などを締め切り、その後検証して3月末にWebコンパイラに反映、順次IDE for GRへ適用したいと思います。
■概要
ライブラリについて、これまで多くのご意見やご提案があり、それぞれを独立してライブラリアップデートを図っていましたが、マージすることでメンテナンス性の向上と、見やすさ・分かりやすさを向上するために、ファイル構成変更をArduinoや既存のGR-SAKURAと同様にしたいと思います。
・マージについて
__RL78_G13__ をRL78/G13のGRボード共通マクロとして定義。コンパイルオプションで指定。ちなみにArduinoでは__AVR_ATmega1280__という感じ。
ボードごとにGRKURUMI, GRADZUKIなどコンパイルオプションを付加することで、切り分けを行う。(テスト版ではまだ付加しておらず、GR-ADZUKIで動作確認してます)
・ファイル構成変更
・GR-SAKURAと同様に以下の構成に変更
Arduino\cores\
\libraries (階層変更なし)
\rl78\ (portableフォルダを廃止してrl78直下に変更)
・主な変更
・RLduino78_mcu_depend.hや、RLduino78_basic.cpp、RLduino78_timer.cなど、独自にArduinoライブラリが形成されていたものを以下のファイルに移植。
ただし、関数の中身変更は改善事項を除いて基本的に実施しません。比較的RL78ライブラリは安定しているためです。(microsの検証ですごい苦労したのがトラウマです)
\Arduino.h (標準ライブラリに広くインクルードされるヘッダ)
\pins_arduino.h (ボードごとのピンに関するヘッダ)
\wiring_private.h (wiring**や、W**などのArduino基本ライブラリから参照されるヘッダ)
\wiring.c (millis()やdelay())
\wiring_digital.c (digital系)
\wiring_analog.c (analog系)
\wiring_pulse.c (pulse系)
\wiring_shift.c (shift系)
\WMath.cpp (算数)
\WInterrupts.c (外部割込み)
\Tone.cpp (Tone関係)
\utilities.cpp (GRで独自のもの。例えば省電力やattachIntervalTimerとか)
\rl78\specific_instructions.h (Fujitaさんが作ってくれた高速化やお役立ち)
■その他
・標準以外のArduinoのライブラリでよく使われるdigitalPinToPortなどを実装
・RTOS用の記述は削除(動作検証できておらず、あまり使用した事例もみないため。)
・attachMicroIntervalTimer、MsTimer2の時間ずれ不具合は反映しました(Fujitaさんありがとうございます!)
・makeでarによるアーカイブ化してから、リンクするとなぜか不要なものがリンクされてしまうため、適用保留としてます。
■テストファイル
・makefile
※make用ですが、ActivePerlを組み込んでC:\Program Files (x86)\KPITにGNURL78v14.03-ELFをコピーし、コマンドプロンプトでbuild実行してもOKです。ちなみに.batを実行してもOKで、これがWebコンパイラのビルド実体でもあります。
・e2studio用
インポートしてビルドできます。
■ご意見、要望などまとめ
-mcpu=g13 -mmul=noneを指定
以下で分ける
#if __RL78__ /* 全ボード全RL78共通 */ #if GRKURUMI /* GR-KURUMI 固有 */ #elif GRCOTTON /* GR-COTTON 固有 */ #elif GRADZUKI /* GR-ADZUKI 固有 */ #endif #if __RL78_G13__ /* RL78/G13 固有 */ #elif __RL78_G14__ /* RL78/G14 固有 */ #elif __RL78_G10__ /* RL78/G10 固有 */ #endif #endif
MsTimer2は標準ではないので、librariesフォルダに入れる
GR-KURUMI, COTTON, ADZUKI のライブラリ V2.00 の web コンパイラが生成する makefile でターゲットが clean の箇所が
clean: $(OBJS) $(MAKEFILE) rm -f $(OBJFILES) rm -f ./gr_build/$(TARGET).x rm -f $(TARGET).bin rm -f ./gr_build/$(TARGET).mot rm -f ./gr_build/$(TARGET).map
となっていますが `clean:' の後のソースが不要です。
ソースに $(OBJS) があるために make clean した後に再度 make clean をすると $(OBJS) にある .o を一旦生成した後に削除するという動作となってしまいます。
> Fujitaさんは音をどのように出力していますか?
テスト用のデータは
japan.renesasrulz.com/.../22580
に添付されている .wav ファイルをダウンロードし、マイクロ SD カードに格納して使用しています。
> binの動作確認はダウンロードして行いました(さすがに自分で自分が信じられなくなったので)。
公開したものの検証はやって当たり前のことであり、それを行わなかった結果が
japan.renesasrulz.com/.../22957
だと思います。
> SDを私のものにしたら現象が再現し、Fujitaさんのものにしたら不再現ということで、バグはSDに依存性があり、SPIのアクセスタイミングに起因しているのではないかというところまできましたね。
microSD の違いによる現象の可能性の確認は https://japan.renesasrulz.com/gr_user_forum_japanese/f/gr-kurumi/4005/rl78-g13/22583#22583 でしておりますね。
未だ状況がよくわかっていないのですが、問題の microSD カードを使用して、
ということで合っているでしょうか?
> その後6/26にGNURL78サポートへv14.03と最新版で-fno-cprop-registerでの変更点を聞いているのですが、まだ返信がないです。
以上のどちらかが原因と思いますが、microSD カードに拠っては現象がでないようなので前者の可能性が高い気がします。`-fno-cprop-register' での変更を問い合わせても正解にたどり着ける可能性は低いと思われます。
問題の microSDカードとコンパイラの組み合わせで `-fno-cprop-register' の指定あり/なし で現象が確認される箇所を特定し、コード内容を吟味しない限り問題は解決しないと思います。
> ひとまずGNURL78サポートの回答を待とうと考えてます。
私の近々の問い合わせですと、
https://gcc-renesas.com/ja/my-support-requests/tickettrackingsystem/ticketdetail/122 (優先順位: Normal)
2017年5月31日 不具合報告 → 2017年6月5日 次期アップデートで修正すると回答
https://gcc-renesas.com/ja/my-support-requests/tickettrackingsystem/ticketdetail/124 (優先順位: Low)2017年6月2日 要望提出 → 2017年6月20日 次期アップデートで対応すると回答
https://gcc-renesas.com/ja/my-support-requests/tickettrackingsystem/ticketdetail/131 (優先順位: Normal)2017年6月26日 要望提出 → 2017年7月3日 次期リリースでの対応を検討と回答
https://gcc-renesas.com/ja/my-support-requests/tickettrackingsystem/ticketdetail/133 (優先順位: Normal)2017年6月28日 不具合報告 → 2017年7月6日 今後のリリースで修正したいと回答
問題が解決するかは兎も角として、優先順位が Normal であれば 1週間程度で一応の回答は得られる印象なのですが、そちらの相談はその後どうなっているでしょうか?
> 本件は、微妙な実行タイミングの影響と思いますが、調査がどれくらいかかるか分からないことと、改善したとしても今後のGCC変更によって再発する可能性があります。
現在わかっていることが
以上の組わせで WAVP(SD) ライブラリでの音声再生に不具合が確認できるというだけあり、これがツールチェーン 14.03 の不具合によるものかはいまだに不明です。WAVP(SD) ライブラリに microSD アクセスに関する問題があって `-fno-cprop-register' を指定することでコードの実行効率が非効率的になり「たまたま」問題の現象が現れていない可能性も考えられます。
今後の GCC 変更も考慮の内とするならば、なんか問題が出なくなるからという理由で `-fno-cprop-register' を付加する対処療法的な方法を採るのではなく、問題の原因
以上のどちらか、あるいはまた別の原因かを特定し、もし WAVP(SD) ライブラリの不具合であるならばそれを修正する方向で進めないとどうしようもないと思いますね。
> どちらにしてもコンパイラを介在(アセンブル直書きは抜きにして)する場合、実行タイミングに起因する問題の解決は難しいと考えてます。
ソフトウェアでタイミングを取るべき部分であれば必要に応じて NOP() やインラインアセンブラ、タイマーを利用する等での必要クロック数分の待ちを入れることは普通のことでは?
> `-fno-cprop-register' の付加は対処療法ですが、ユーザーが開発する一つの系において、使用要件を満たした評価でOKであればよいと思います。
ツールチェーンの問題なのか、そうでないかを切り分けることはツールの利用に当たっては必要なことと思います。
ルネサスさんは(国内向けには積極的でないとしろ) GNU ツールを自社のマイコン製品の開発用のひとつとして挙げているのだし、
https://www.renesas.com/ja-jp/products/software-tools/tools/ide/e2studio.html
> ルネサス製ツールの他、 GNUツールやパートナーツールを含めた、複数のコンパイラ、デバッグツールを選択できます。
それらの利用に関することは直接の担当業務ではないとしても一定の責任はあるのではないですか。
4年も前にツールチェーンの不具合に対して行った対症療法的な方法を、別の現象の問題の原因を明らかにせずにいまだに続けてるという状況は異常と思います。
https://japan.renesasrulz.com/gr_rl78_p/f/c69c33cc-3af4-4c51-b31e-1a42582adcb5/460/sd-class-file-class/2509#2509