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 を一旦生成した後に削除するという動作となってしまいます。
いやー、前回添付したのがそれのはずなのですけどね。以下は私のローカルPCで出力したbinですが、Fujitaさんの環境で音がそうなるか試してみていただけませんか?
先ず http://japan.renesasrulz.com/gr_user_forum_japanese/f/gr-kurumi/4005/rl78-g13/22905#22905 に添付の kurumi_sketch.zip に格納された kurumi_sketch/HardwareDebug/kurumi_sketch.bin と http://japan.renesasrulz.com/gr_user_forum_japanese/f/gr-kurumi/4005/rl78-g13/22957#22957 に添付の kurumi_sketch.bin はファイルサイズからして異なる別の内容です。
$ ls -l kurumi_sketch.bin kurumi_sketch/HardwareDebug/kurumi_sketch.bin -rwx------+ 1 fujita なし 113863 Jun 15 22:12 kurumi_sketch.bin -rw-r--r-- 1 fujita なし 127678 Jun 14 14:39 kurumi_sketch/HardwareDebug/kurumi_sketch.bin
どちらも GR-KURUMI に書き込んで動作を確認してみましたが問題の現象は見られませんでした。
そちらでも同等の確認をされた上で、問題の現象の確認できるプロジェクトを公開して下さい。
Fujitaさん、何度もすみません。さきほど添付したbinはコンパイラを最新にしたものでした。コンパイラを14.03にして出力したbinを添付いたします。前回添付したプロジェクトのbinのサイズが同じことを確認しました。
そちらで現象が発生することと添付されたファイルが正しいかは別の話です。実際 japan.renesasrulz.com/.../22957 は明らかに間違ったものを添付されています。 そちらで japan.renesasrulz.com/.../22905 japan.renesasrulz.com/.../22957 japan.renesasrulz.com/.../22961 に添付されたファイルをそれぞれ GR-KURUMI で動作確認された上で仰って下さい。こちらはそれを行ったうえで発言しています。
確認内容が明記されていませんがどのような確認をされましたか?
このスレッドだけで
以上のミスが発生しており「こちらで確認した」と言われたところでそれを受け取ることはできません。
こちらは確認で行った内容は説明しているつもりです。同等程度の説明を求めます。
>japan.renesasrulz.com/.../22905 に添付の kurumi_sketch.zip に格納されたkurumi_sketch/HardwareDebug/kurumi_sketch.bin と >japan.renesasrulz.com/.../22961 に添付の 2570.kurumi_sketch.bin は同一の内容であり、再度 GR-KURUMI に書き込んで動作を確認しましたが(3回目)問題の現象は見られませんでした。
>上記に関してはこちらで確認した上で言ってます。
上記の確認は、binをGR-KURUMIに書き込み、音の乱れを聞きました。
以下のハードウェアをブレッドボード、ワイヤーを介して接続しています。なお、GR-ADZUKIでも発生するため、ブレッドボード、ワイヤー部分などの配線部分は音の乱れに影響はないものと考えています。
・GR-KURUMI
・マイクロSD DIP化キット
・マイクロSD
・ステレオミニジャックDIP化キット
・taotoronics スピーカー
Fujitaさんは音をどのように出力していますか?
> 上記の確認は、binをGR-KURUMIに書き込み、音の乱れを聞きました。
.binファイルはこのスレッドに投稿されたものをダウンロードした上で確認されていますか?
> Fujitaさんは音をどのように出力していますか?
以上の装置にて出力しています。PC に同じイヤホンを接続して https://www.youtube.com/watch?v=tPd4Le_YLtA の動画の音の違いは認識できており、装置に問題はないものと考えています。
> 14.03から15.01の以下の改善ですかね。
以前 `-fno-cprop-registers' を付加する原因となった不具合は 13.02 で修正されたようです。
http://japan.renesasrulz.com/gr_rl78_p/f/c69c33cc-3af4-4c51-b31e-1a42582adcb5/460/sd-class-file-class/9970#9970
現在 https://gcc-renesas.com/ からダウンロードできる GNURL78 Toolchain は 13.01 の次が 13.02 の修正版の 13.02(MP1) となっており肝心の 13.02 がなく、リリースノートに記載があるかは確認できません。
13.01 と 13.02(MP) と 14.03 でこの不具合を再度検証してみましたが 13.02(MP) と 14.03 で修正されていることを確認しました。
$ cat -n test.cpp 1 signed char func(long var0, signed char var1) 2 { 3 return (var0 >> 1) & (var1 - 1); 4 } $ /c/Renesas/e2studio/GNURL78v13.01-ELF/rl78-elf/bin/rl78-elf-g++ -Os test.cpp -S -o - r8 = 0xffef0 r16 = 0xffee8 r24 = 0xffee0 r9 = 0xffef1 r17 = 0xffee9 r25 = 0xffee1 r10 = 0xffef2 r18 = 0xffeea r26 = 0xffee2 r11 = 0xffef3 r19 = 0xffeeb r27 = 0xffee3 r12 = 0xffef4 r20 = 0xffeec r28 = 0xffee4 r13 = 0xffef5 r21 = 0xffeed r29 = 0xffee5 r14 = 0xffef6 r22 = 0xffeee r30 = 0xffee6 r15 = 0xffef7 r23 = 0xffeef r31 = 0xffee7 .text .global __Z4funcla .type __Z4funcla, @function __Z4funcla: mov a, [sp+8] dec a movw ax,[sp+6] @ sarw ax,1 @ movw r10,ax @ mov a,[sp+5] @ rorc a,1 @ mov r9,a @ mov a,[sp+4] @ rorc a,1 @ mov r8,a and a, r8 mov r8, a ret .size __Z4funcla, .-__Z4funcla .ident "GCC: (GNU) 4.8-GNURL78_v13.01 20121219 (experimental) (Red Hat/devo) [trunk revision 194496]" $ /c/Renesas/e2studio/GNURL78v13.02-ELF/rl78-elf/bin/rl78-elf-g++ -Os test.cpp -S -o - r8 = 0xffef0 r16 = 0xffee8 r24 = 0xffee0 r9 = 0xffef1 r17 = 0xffee9 r25 = 0xffee1 r10 = 0xffef2 r18 = 0xffeea r26 = 0xffee2 r11 = 0xffef3 r19 = 0xffeeb r27 = 0xffee3 r12 = 0xffef4 r20 = 0xffeec r28 = 0xffee4 r13 = 0xffef5 r21 = 0xffeed r29 = 0xffee5 r14 = 0xffef6 r22 = 0xffeee r30 = 0xffee6 r15 = 0xffef7 r23 = 0xffeef r31 = 0xffee7 .text .global __Z4funcla .type __Z4funcla, @function __Z4funcla: mov a, [sp+8] dec a mov r12, a movw ax,[sp+6] @ sarw ax,1 @ movw r10,ax @ mov a,[sp+5] @ rorc a,1 @ mov r9,a @ mov a,[sp+4] @ rorc a,1 @ mov r8,a mov a, r12 and a, r8 mov r8, a ret .size __Z4funcla, .-__Z4funcla .ident "GCC: (GNU) 4.8-GNURL78_v13.02 20131003 (MP1) (Red Hat/devo) [trunk revision 194496]" $ /c/Renesas/e2studio/GNURL78v14.03-ELF/rl78-elf/bin/rl78-elf-g++ -Os test.cpp -S -o - r8 = 0xffef0 r16 = 0xffee8 r24 = 0xffee0 r9 = 0xffef1 r17 = 0xffee9 r25 = 0xffee1 r10 = 0xffef2 r18 = 0xffeea r26 = 0xffee2 r11 = 0xffef3 r19 = 0xffeeb r27 = 0xffee3 r12 = 0xffef4 r20 = 0xffeec r28 = 0xffee4 r13 = 0xffef5 r21 = 0xffeed r29 = 0xffee5 r14 = 0xffef6 r22 = 0xffeee r30 = 0xffee6 r15 = 0xffef7 r23 = 0xffeef r31 = 0xffee7 .text .global __Z4funcla .type __Z4funcla, @function __Z4funcla: mov a, [sp+8] dec a mov r12, a movw ax,[sp+6] @ sarw ax,1 @ movw r10,ax @ mov a,[sp+5] @ rorc a,1 @ mov r9,a @ mov a,[sp+4] @ rorc a,1 @ mov r8,a mov a, r12 and a, r8 mov r8, a ret .size __Z4funcla, .-__Z4funcla .ident "GCC: (GCC_Build_1.08) 4.8-GNURL78_v14.03 20140402 (prerelease (renesas-13r1-16)) (GNUPro 12r1) (Based on: GCC 4.8.1 GDB 7.7.1 Binutils 2.23 Newlib 2.0)" $
14.03 を使用して Wavp(SD) ライブラリに不具合が出たということであれば上とは別の不具合である可能性が考えられるので確認の必要があります。
テスト用のデータは
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