NoMaY-jp’s ポイント | Open Source Tools for Renesas

NoMaY-jp’s ポイント

NoMaY-jp 201 ポイント.

フォロー

NoMaY-jp's ポイント

Total 201

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

+10

5月 3, 2021 Answered LLVM support for Code Generator or Smart Configurator for RL78/G14

+2

4月 30, 2021 Asked Does LLVM-RL78 use the hardware multiplication/division peripheral unit of RL78/G13 or not?

+1

4月 30, 2021 Commented Hello support team, Thank you very much for your investigation and your conclusion. So, Frank's project has to be modified like the following. > This means that a library containing the definition of a function should appear after any source files or object files which use it. Best regards, NoMaY

+2

4月 30, 2021 Asked Where is the document of LLVM-RL78 ABI

+10

1月 27, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+10

1月 26, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+10

1月 26, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+10

1月 26, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+10

1月 26, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+10

1月 26, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+1

1月 26, 2021 Commented Hello moderators, I think that there is a misunderstanding between us and you. Frank and I discussed about 'total' warnings. I notice just now that we discussed about ''total' warnings. (But Frank may use something linker option which changes warnings to errors.) And moreover, I remember that I almost ignored such warnings (unsolved warnings) until I ported Amazon FreeRTOS to Renesas RX (GNURX version). But, on the case, I thought that such warnings aren't welcomed by AWS users. And I checked newlib source code then noticed assert() issue. For example, I get following 'warnings' form the code that is posted by moderators. 'rx-elf-gcc -O0 -ffunction-sections -fdata-sections -fdiagnostics-parseable-fixits -g2 -Wstack-usage=100 -mcpu=rx64m -misa=v2 -mlittle-endian-data -I"C:/Renesas/GitHubDesktop/workspaces/workspace_e2v780/TestGUNRXprintf/generate" -Wa,-adlnh="TestGUNRXprintf.lst" -MMD -MP -MF"src/TestGUNRXprintf.d" -MT"src/TestGUNRXprintf.o" "../src/TestGUNRXprintf.c" -c -o "src/TestGUNRXprintf.o"' 'rx-elf-gcc -O0 -ffunction-sections -fdata-sections -fdiagnostics-parseable-fixits -g2 -Wstack-usage=100 -mcpu=rx64m -misa=v2 -mlittle-endian-data -o "TestGUNRXprintf.elf" ./src/TestGUNRXprintf.o ./generate/hwinit.o ./generate/inthandler.o ./generate/start.o ./generate/vects.o -T "C:/Renesas/GitHubDesktop/workspaces/workspace_e2v780/TestGUNRXprintf/generate/linker_script.ld" -Wl,--start-group -lm -lc -lgcc -Wl,--end-group -nostartfiles -Wl,-e_PowerON_Reset -Wl,-M=TestGUNRXprintf.map' rx-elf-gcc @"TestGUNRXprintf.elf.in" c:/renesas/gcc/redhat/gnurx-elf/8.3.0.202004/rx-elf/rx-elf/bin/../lib/gcc/rx-elf/8.3.0.202004-GNURX/../../../../rx-elf/lib/rxv2\libc.a(lib_a-closer.o): In function `_close_r': (.text._close_r+0x10): warning: _close is not implemented and will always fail c:/renesas/gcc/redhat/gnurx-elf/8.3.0.202004/rx-elf/rx-elf/bin/../lib/gcc/rx-elf/8.3.0.202004-GNURX/../../../../rx-elf/lib/rxv2\libc.a(lib_a-fstatr.o): In function `_fstat_r': (.text._fstat_r+0x12): warning: _fstat is not implemented and will always fail c:/renesas/gcc/redhat/gnurx-elf/8.3.0.202004/rx-elf/rx-elf/bin/../lib/gcc/rx-elf/8.3.0.202004-GNURX/../../../../rx-elf/lib/rxv2\libc.a(lib_a-isattyr.o): In function `_isatty_r': (.text._isatty_r+0x10): warning: _isatty is not implemented and will always fail c:/renesas/gcc/redhat/gnurx-elf/8.3.0.202004/rx-elf/rx-elf/bin/../lib/gcc/rx-elf/8.3.0.202004-GNURX/../../../../rx-elf/lib/rxv2\libc.a(lib_a-lseekr.o): In function `_lseek_r': (.text._lseek_r+0x14): warning: _lseek is not implemented and will always fail c:/renesas/gcc/redhat/gnurx-elf/8.3.0.202004/rx-elf/rx-elf/bin/../lib/gcc/rx-elf/8.3.0.202004-GNURX/../../../../rx-elf/lib/rxv2\libc.a(lib_a-readr.o): In function `_read_r': (.text._read_r+0x14): warning: _read is not implemented and will always fail rx-elf-objcopy "TestGUNRXprintf.elf" -O srec -I elf32-rx-be-ns "TestGUNRXprintf.mot" rx-elf-size --format=berkeley "TestGUNRXprintf.elf" text data bss dec hex filename 23504 2596 64 26164 6634 TestGUNRXprintf.elf Best regards, NoMaY

+10

1月 25, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+10

1月 25, 2021 Answered printf() usage in RX toolchain 20.04 change when optimisation change

+1

10月 9, 2020 Commented Hello Oliver, > I can’t use the RX Smart Configurator because it is grayed out The reason of this behavior is that the RX Smart Configurator doesn't support old devices such as RX62N, RX63N, RX210, and so on. You can check the list of supported devices on the Renesas web site. Best regards, NoMaY

+1

10月 7, 2020 Commented Hello Oliver, I'm sorry that I didn't mind your target device. The followings are generated source code of sbrk.c and sbrk.h by RX Smart Configurator and these source code include sbrk() and related definitions/declarations/variables. I think that heap implementation of newlib doesn't depend on target devices. https://github.com/renesas/rx-driver-package/blob/153ad87/source/r_bsp/r_bsp_vx.xx/r_bsp/mcu/all/sbrk.c https://github.com/renesas/rx-driver-package/blob/153ad87/source/r_bsp/r_bsp_vx.xx/r_bsp/mcu/all/sbrk.h You don't have to modify your linker script to use this sbrk() because the 's_heap_area' variable used in this sbrk() isn't a special variable but is a normal bss variable. Best regards, NoMaY

+1

10月 7, 2020 Commented Hello Oliver, Your understanding of the stack region and the stack growth is right. For another question, I think that using e2 studio's built-in RX Smart Configurator is good. Using the GUI of the RX Smart Configurator, you can select stack usage type (only I stack or both I/U stacks) and you can set stack size of I/U stacks and heap size. (Until few year ago, the RX Smart Configurator couldn't generate source code for GNURX, but recently it was improved to generate source code for GNURX.) By the way, sbrk() is implemented in the generated src/smc_gen/r_bsp/mcu/all/sbrk.c and its implementation uses union variable 's_heap_area' including 'heap[BSP_CFG_HEAP_BYTES]' member. Unfortunately please note that heap size has to be larger than 4K bytes due to the current newlib implementation to avoid strange malloc() fail depending on the allocation address of the heap[BSP_CFG_HEAP_BYTES]. I think that this issue has to be improved for GNURX in the future. (I think that '4K bytes' comes from the page size of the x86 processor's MMU.) Best regards, NoMaY

+1

10月 3, 2020 Commented Hello, I think that this problem is due to the stack overflow. Would you modify your linker script as follows: .ustack 0x800: AT(0x800) ← Here! { _ustack = .; } > RAM .istack 0x400: AT(0x400) ← Here! { _istack = .; } > RAM .data 0x804: AT(_mdata) ← Here! { Best regards, NoMaY

+10

7月 22, 2020 Answered RX111でmallocに失敗する

+10

7月 22, 2020 Answered RX111でmallocに失敗する

+1

5月 21, 2020 Commented Hello, Thank you for the reply. That is good to know! Best regards, NoMaY

« 前へ 1 2 3 4 次へ »

サポート