ports/renesas-ra/boards/VK-RA6M5: Last New Board. #10943

mbedNoobNinja · 2023-03-06T14:55:28Z

In the context of ongoing discussions (#10595) & (#10752) and the mentioned intention for a new ports, this is the 3-rd uPy ready board candidat.

ports/renesas-ra/boards/VK-RA6M5: Adding another new dev board
ports/renesas-ra/boards: Based on new RA6M5 processor
ports/renesas-ra: Part of existing RA family.

Tests.log

iabdalkader · 2023-03-23T21:05:43Z

ports/renesas-ra/Makefile

+CMSIS_MCU_LOW = ra6m5
+CMSIS_MCU_CAP = RA6M5
+USE_FSP_LPM = 1
+EXPECTED_FSP_HASH = 9713f5b5c3d8bea5f0242feb30c1a57c89ae506a lib/fsp (v2.4.0)


Can you please filter this on the series ? So other RA6M5 boards can build ?

Suggested change

EXPECTED_FSP_HASH = 9713f5b5c3d8bea5f0242feb30c1a57c89ae506a lib/fsp (v2.4.0)

ifeq ($(CMSIS_MCU),RA6M5)

EXPECTED_FSP_HASH = 9713f5b5c3d8bea5f0242feb30c1a57c89ae506a lib/fsp (v2.4.0)

Yes that makes sense, It will be fixed.

Note anything that uses CMSIS_MCU needs to be moved after include $(BOARD_DIR)/mpconfigboard.mk

iabdalkader · 2023-03-23T21:14:19Z

ports/renesas-ra/Makefile

@@ -51,6 +51,16 @@ CMSIS_MCU_CAP = RA6M2
 USE_FSP_LPM = 1
 endif

+ifeq ($(BOARD),VK_RA6M5)


I think all of those checks in the Makefile (like ifeq ($(BOARD), some_EK)) should all be removed to simplify the Makefile, all the variables are already there:

BOARD_LOW = $(shell echo $(BOARD) | tr '[:upper:]' '[:lower:]') CMSIS_MCU_CAP = $(CMSIS_MCU) CMSIS_MCU_LOW = $(shell echo $(CMSIS_MCU) | tr '[:upper:]' '[:lower:]') USE_FSP_LPM ?=1 # This should be moved to `mpconfigboard.mk` of each board that needs to set it to 0

Note there's a typo in the clicker board:

ifeq ($(BOARD),RA4M1_CLICKER) BOARD_LOW = ra4m1_ek <- Should be ra4m1_clicker

Well the design of the Makefile is what it is, I am just following it to integrate the VK boards. I don't know if I have the right to alter it. I think Mr. @TakeoTakahashi2020 has the last word here. Ask him why that is.

Yes I understand that it's the existing Makefile, but now is a good time to clean it up. As we add more boards, they will all need to be added to the main Makefile, which is Not good, that's why mpconfigboard.mk files exist. Sure @TakeoTakahashi2020 input would be appreciated.

Great idea, I am welcome to simplify Makefile.
Regarding RA4M1_CLICKER's typo, because it is not official EK board and not included in FSP, EK board's file is just referred instead. However it's same situation as VK board and it should be solved by same way of VK boards. I can check EK board and Clicker together, so please change as you propose.

@TakeoTakahashi2020 I see the issue with RA4M1_CLICKER board, thanks for the insight. Even though RA4M1_CLICKER seems to build without linking board_init.c and board_leds.c, but those sources can still be added like so:

BOARD_LOW ?= $(shell echo $(BOARD) | tr '[:upper:]' '[:lower:]')

Then in boards/RA4M1_CLICKER/mpconfigboard.mk you can just set

BOARD_LOW=ra4m1_ek

I'd suggest a more descriptive name, like FSP_BOARD_NAME

@iabdalkader , Thanks for your great review and suggetion. I did build check quickly. Yes, you are right. The build is successful without board_init.c and board_leds.c. I also think FSP_BOARD_NAME makes sense.
I completely agree with your idea. I am happy to be able to simplify. Thanks.

@TakeoTakahashi2020 Thank you for testing that! I'm happy to help. I will be waiting on those changes then will push support for Portenta C33 after this PR is merged.

iabdalkader · 2023-03-23T21:16:03Z

ports/renesas-ra/Makefile

@@ -328,6 +349,11 @@ SRC_C += \
 	$(BOARD_DIR)/src/hal_entry.c \
 	$(wildcard $(BOARD_DIR)/*.c)

+ifeq ($(BOARD),$(filter $(BOARD),VK_RA4W1 VK_RA6M3 VK_RA6M5))


Can you please filter on the series and in machine_dac.c use something like:

#if MICROPY_HW_ENABLE_DAC machine_dac_init()... #endif

This way other RA6M5 boards can use this without editing the Makefile.

Again DAC is not confirmed it works on all boards, so it will remain ON for those it is tested with.

It will not be on/initialized unless MICROPY_HW_DAC0 or MICROPY_HW_DAC1 is defined in mpconfigboard.h (Note you disabled by default in mpconfigboard_common.h), building the drivers in ra/ should not affect boards that don't use it.

iabdalkader · 2023-03-23T21:21:01Z

ports/renesas-ra/Makefile

@@ -403,6 +431,13 @@ HAL_SRC_C += $(addprefix ra/,\

 endif

+ifeq ($(BOARD),$(filter $(BOARD),VK_RA4W1 VK_RA6M3 VK_RA6M5))


If VK_RA4W1, VK_RA6M3 and VK_RA6M5 all have GPTs and DACs please filter on the series.

I haven't samples of other boards to test with, so I am not sure if it will work on them If it is released for the series. This only @TakeoTakahashi2020 can confirm. Ask him.

Please change it. I can check it on EK_RA4W1 and report if there are any issues.

iabdalkader · 2023-03-24T10:38:13Z

ports/renesas-ra/Makefile

@@ -108,7 +118,11 @@ INC += -I$(BOARD_DIR)/ra_cfg/fsp_cfg/bsp
 INC += -Idebug

 CFLAGS += -D$(CMSIS_MCU)
+ifeq ($(BOARD),$(filter $(BOARD),VK_RA4W1 VK_RA6M3 VK_RA6M5))
+CFLAGS += -DRA_HAL_H='<VK_$(CMSIS_MCU)_hal.h>'


Can you use the existing naming convention for the series ? i.e RA4W1_hal.h, RA6M3_hal.h and RA6M5_hal.h. It seems the only difference between the existing config files and the new ones you're adding is the default SCI debug channel, which can be defined in mpconfigboard.h. Also note that DEBUG_TX_PIN and DEBUG_RX_PIN are never used anywhere so any defaults there (the EK maybe ?) should be fine.

Yes I tried to use the default one hals (*_hal.h) but the default pins of the EK boards are other and even I select the channel in the mpconfigbord.h it is still pointing to the wrong ones. If you have a beter mechanism for same channel to select other alternative pins I am listening ...

If you have a beter mechanism for same channel to select other alternative pins I am listening ...

Well like I said the DEBUG_RX_PIN and DEBUG_TX_PIN pins are not really used anyway (grep and you won't find those defines used anywhere) so I'm not sure why you want to override them, however if you need to override them for some reason it's possible, but for now I think we just need to override the default debug channel.

There's more than one way to do override DEBUG_CH but I think there's a file that exists solely for this purpose, which is ra*_ek_conf.h and for some reason it's not included anywhere, but we can use it. If you just rename vk_ra6m1_conf.h to ra6m5_ek_conf.h and include that file in RA6M5_hal.h then you have the debug channel defined (and of course every RAx_hal.h should include its rax_ek_conf.h). You can also use the same file to define USE_DBG_PRINT when needed.

Yes I do it with a separate file because I was afraid it will break the compile of the existing boards and I hadn't noticed it is not used. OK if you insist to be in 1 file it will be, I will fix it.

OK if you insist to be in 1 file it will be, I will fix it.

Not insisting but IMHO I think it's much cleaner this way, specific board names should Not be in the Makefile I know there were some board names in the Makefile before, but this doesn't mean we can't clean it up. My goal here is to help you make these changes as generic as possible, this will hopefully speed up the merging of this PR and allow others to reuse your work here.

Yes I agree with you. I just finishing something at the moment, I didn't mean to be rude, and I will need a couple of days to "switch the context" and fix all the changes that you want.

Oh no please take your time, I'm currently testing your PR with these suggested changes, and reporting back anything that I think might be helpful ;)

iabdalkader · 2023-03-24T10:43:00Z

ports/renesas-ra/Makefile

@@ -343,10 +369,12 @@ SRC_O += \
 SRC_O += \
 	shared/runtime/gchelper_thumb2.o

+ifneq ($(BOARD),$(filter $(BOARD),VK_RA4W1 VK_RA6M3 VK_RA6M5))


I suggest you use a $(wildcard $(BOARD_DIR)/*.c) here so other boards can have board_init.c files.

Every other bords will have board_init.c and board_led.c, except the VK ones. These files exist only if a given board has a BSP in the FSP, so every board not part of some kind of program or arangment with Renesas will be wiped out with next upgrade of the FSP. It si pointless to add them to all boards unless you are sure that all boards will be included in every next new FSP release.

Sorry didn't notice the ifneq, I think the exception should be the official EK boards (because every new board will Not have those files, so will have to be added to the Makefile) ,so I think the condition should check for official boards not custom boards, or better maybe just ?

FSP_BOARD_DIR = $(HAL_DIR)/ra/board/$(FSP_BOARD_NAME) ifneq ($(wildcard $(TOP)/$(FSP_BOARD_DIR)/.),) HAL_SRC_C += $(addprefix $(FSP_BOARD_DIR)/,\ board_init.c \ board_leds.c \ ) endif

Well I have power over VK boards, for the EK ask @TakeoTakahashi2020.

@mbedNoobNinja , @iabdalkader , I have confirmed that the building of RA4M1_CLICKER is successful with EK_BOARD_DIR and BOARD_LOW before the code edited by @iabdalkader. So FSP_BOARD_DIR and FSP_BOARD_NAME also shoud be OK. I agree with this change.

iabdalkader · 2023-03-24T10:45:18Z

ports/renesas-ra/Makefile

+CURRENT_FSP_HASH = $(patsubst +%,%,$(shell git -C $(TOP) submodule status lib/fsp))
+CHECK_FSP_VER:
+ifneq ($(CURRENT_FSP_HASH),$(EXPECTED_FSP_HASH))
+ifeq ($(BOARD),VK_RA6M5)


Suggested change

ifeq ($(BOARD),VK_RA6M5)

ifeq ($(CMSIS_MCU),RA6M5)

OK that makes sense, It will be fixed.

On second thought, since the boards are tightly coupled to the FSP version used in the e2studio, I have a better suggestion here, maybe just set EXPECTED_FSP_HASH in mpconfigboard.mk ? This way every board can override the default if needed. In the Makefile you can just set the default if it's not defined:

EXPECTED_FSP_HASH ?= $(patsubst +%,%,$(shell git -C ../.. submodule status --cached lib/fsp))

Great Idea I will be happy to fix it that way.

Just noticed that switching between two boards that require two different FSPs with parallel builds (make -j<n>) seems to fail on the first run (only the first run), so it seems that some objects start building before FSP is switched. Making the FSP check an order dependency of $(OBJ) seems to fix it:

$(OBJ): | CHECK_FSP_VER $(GEN_PINS_HDR)

What a great idea! It was a headache for me. Thank you @iabdalkader and @mbedNoobNinja .

mbedNoobNinja · 2023-04-13T10:02:21Z

Hi @iabdalkader and @TakeoTakahashi2020 I finally found time to make the changes you suggested, but I am currently unaware why I am getting check commit message formatting. Any idea?

iabdalkader · 2023-04-13T11:06:32Z

why I am getting check commit message formatting. Any idea?

No idea really, it seems to be complaining about commits not in this PR, you could try rebasing on master.

mbedNoobNinja · 2023-04-13T11:38:53Z

You are right, rebase solves the issue!

iabdalkader · 2023-04-14T18:08:14Z

@mbedNoobNinja This looks really good thanks! I just have a couple of minor comments

You may want remove all of your e2studio project files (.cproject, .project, configuration.xml, makefile.defs etc..) as they're not used in micropython and none of the other boards include them.
You may want to double check your board's RTC clock source in mpconfigboard.h, seems in hal_data.c you set it to RTC_CLOCK_SOURCE_LOCO 🤷🏼‍♂️
None of the boards/<BOARD>/xxx_conf.h files is included, so DEBUG_CH is not set, I'd suggest to just remove all those files and the debug channel can be defined in mpconfigboard.mk with something like CFLAGS+=-DDEBUG_CH=0 if needed.

Now a question for you and @TakeoTakahashi2020 has this been tested on any actual board ? Did you get a working REPL on the UART ? I created a new project, selected the device, configured FSP, set the heap and stack, added LPM, RTC, SCI UART and ICU stacks (set the user_uart_callback, and enabled all 4 IRQs), fixed the linker script, and I get as far as executing friendly repl, but I don't see any repl output on the UART, I wonder if I'm missing something ? What exactly needs to be configured in e2studio to generate a project that works with this port ?

TakeoTakahashi2020 · 2023-04-17T09:47:27Z

@iabdalkader I could build for all EK and CLICKER board without any errors and got the same result of test on the actual board as previous version. Thanks @mbedNoobNinja .

Regarding removing boards/<BOARD>/xxx_conf.h, I agree with your suggestion.

Regarding UART for REPL, are MICROPY_HW_UART_REPL and MICROPY_HW_UART_REPL_BAUD defined in board/<BOARD>/mpconfigboard.h?

iabdalkader · 2023-04-17T09:50:37Z

Regarding UART for REPL, are MICROPY_HW_UART_REPL and MICROPY_HW_UART_REPL_BAUD defined in board/<BOARD>/mpconfigboard.h?

Yes, I have this in the mpconfigboard.h:

#define MICROPY_HW_UART9_TX         (pin_P602)
#define MICROPY_HW_UART9_RX         (pin_P110)

#define MICROPY_HW_UART_REPL        (HW_UART_9)
#define MICROPY_HW_UART_REPL_BAUD   (115200)

And all 4 IRQs are enabled, in the e2studio project:

            [0] = rtc_alarm_periodic_isr, /* RTC ALARM (Alarm interrupt) */
            [1] = rtc_alarm_periodic_isr, /* RTC PERIOD (Periodic interrupt) */
            [2] = rtc_carry_isr, /* RTC CARRY (Carry interrupt) */
            [3] = r_icu_isr, /* ICU IRQ0 (External pin interrupt 0) */
            [4] = sci_uart_rxi_isr, /* SCI9 RXI (Received data full) */
            [5] = sci_uart_txi_isr, /* SCI9 TXI (Transmit data empty) */
            [6] = sci_uart_tei_isr, /* SCI9 TEI (Transmit end) */
            [7] = sci_uart_eri_isr, /* SCI9 ERI (Receive error) */

The callback is set too:

const uart_cfg_t g_uart9_cfg =
{ .channel = 9, .data_bits = UART_DATA_BITS_8, .parity = UART_PARITY_OFF, .stop_bits = UART_STOP_BITS_1, .p_callback = user_uart_callback,

TakeoTakahashi2020 · 2023-04-17T10:19:50Z

LGTM. Other settings for UART9 on e2 studio are as followings (however, please note this is for EK-RA6M2):

iabdalkader · 2023-04-17T10:26:43Z

It seems the IRQs are not working for some reason (ra_sci_isr_tx is never called), if I write directly to the SCI TDR I can see the output. I'm still investigating but it looks like I may be missing something.

iabdalkader · 2023-04-17T11:14:12Z

@TakeoTakahashi2020 It's working fine, the irqs were disabled after jump from the bootloader, main.c should probably re-enable IRQs at some point. Thanks!

mbedNoobNinja · 2023-04-18T07:42:44Z

Hi @iabdalkader. Regarding xxx_conf.h file:

None of the boards//xxx_conf.h files is included, so DEBUG_CH is not set, I'd suggest to just remove all those files and the debug channel can be defined in mpconfigboard.mk with something like CFLAGS+=-DDEBUG_CH=0 if needed.

Earlier, you encourage me to use exactly it to solve the issue with the different debug UART pins for the EK and the VK bords of RA4W1 family.

There's more than one way to do override DEBUG_CH but I think there's a file that exists solely for this purpose, which is ra*_ek_conf.h and for some reason it's not included anywhere, but we can use it.

Which I did in the VK_RA4W1 port (#10595), but now you want to remove it. What is your final wish?
Or you mean, there can stay, but here can disappear. What if a second M5 board appears, like in the W1 situation?

About the other request:

You may want remove all of your e2studio project files (.cproject, .project, configuration.xml, makefile.defs etc..) as they're not used in micropython and none of the other boards include them.

It is a headache for me to make a new e2studio project from scratch, every time I want to debug something in micropython, so I left them for convenience. If they really need to be gone, is it acceptable to be put in git subproject (like the FSP lib), so those files won't be phisically in the micropython's repository, but when checkout they will be there where needed.

About the test:

... has this been tested on any actual board ?

Yes it has, look at the Tests.log at the 1-st post.

iabdalkader · 2023-04-18T08:15:15Z

Which I did in the VK_RA4W1 port (#10595), but now you want to remove it. What is your final wish?
Or you mean, there can stay, but here can disappear. What if a second M5 board appears, like in the W1 situation?

I'm only looking at this PR and in this PR those files are Not included in the Makefile nor the HAL headers, you can leave them if you want I'm just pointing out that they are Not used (so problem wasn't really fixed). Note, I'm not sure why you split the changes between 2 PRs, and the other one has almost the same ? changes, maybe if you want to just add all your changes here, and the other PR can just add the new board.

It is a headache for me to make a new e2studio project from scratch, every time I want to debug something in micropython, so I left them for convenience. If they really need to be gone, is it acceptable to be put in git subproject (like the FSP lib),

I really don't think you should leave them, and they can't be added to the lib/fsp submodule either. You're free to leave them in there of course, and we'll see if they get merged, but here's a suggestion you can create your own repo somewhere under your org or something, and keep the files there, add just add a README.md in your board dir, with a link to that repository.

mbedNoobNinja · 2023-04-18T10:31:01Z

I will fix the RTC source clock.

Note, I'm not sure why you split the changes between 2 PRs

There is no split, every bord is in its own PR, you just mention that there is no need for *_conf.h file in general for all ra boards, because it is not used and I just pointed out that for W1 specifically, it is needed, if #10595 is merged, of course. So are you OK if I remove that file for all else boards and preserve it only in RA4W1_EK and VK_RA4W1 dirs eventually?

I like the idea with the README.md in the board's dir, I will move the project files in a separate repo.

iabdalkader · 2023-04-18T11:37:06Z

So are you OK if I remove that file for all else boards and preserve it only in RA4W1_EK and VK_RA4W1 dirs eventually?

No please keep them and include all of the config files (which is what I initially suggested btw in my comment #10943 (comment)). I only suggested you remove them later, because you didn't include them in the RAxxx_hal.h file (in this PR, I don't know what you're doing/going to do in future PRs :)) so this should be in every RAxxx_hal.h file

#if defined(USE_DBG_PRINT)
#include RA_CFG_H
#endif

I hope it's more clear now. That said, I'm happy with this PR as it is, and making any further changes is up to you.

BTW I have TinyUSB support working for this port (tested with RA6M5) it's based on top of this PR, so will send it after this is merged. CC @TakeoTakahashi2020

mbedNoobNinja · 2023-04-18T14:49:55Z

I changed minor comments that was addressed, I think now all should be fine and everybody is happy. I will fix & rebase the other 2 PRs when this is merged!

dpgeorge · 2023-05-11T06:20:14Z

@mbedNoobNinja can you please rebase this on the latest master, now that the FSP is updated to 4.4.0?

mbedNoobNinja · 2023-05-12T14:13:58Z

Hi @dpgeorge the PR is rebased.

TakeoTakahashi2020 · 2023-05-16T06:36:51Z

Thanks @mbedNoobNinja. I have confirmed that buid for VK-RA6M5, all EKs, CLICKER is fine, and I2C, SPI and so on seems to be working well.

iabdalkader · 2023-05-29T13:41:45Z

Unrelated issue, I'm trying to use UART with baudrate > 115200 (for ESP bluetooth firmware which uses 921600) and noticed that higher baudrates are not supported, so I copied R_SCI_UART_BaudCalculate from FSP and it seems to be working fine (tried 115200, and 921600).

@ everyone What would be the best to go about fixing this ? R_SCI_UART_BaudCalculate seems to be pretty much standalone, can we reuse it somehow ? Link the file that provides it or just add a copy in renesas-ra/ra/ra_sci.c ? CC @dpgeorge

TakeoTakahashi2020 · 2023-05-30T03:14:46Z

@iabdalkader -san, I tried to link the file, however, duplicated symbol error happens for interrupt function. Then I tried SCI_UART_CFG_TX_ENABLE (0)/SCI_UART_CFG_RX_ENABLE (0) configuration but unused-variable error happens. Seems to be needed more consideration and drastic changes to link the file.
If you had obtained the result of R_SCI_UART_BaudCaluclate for bluetooth, we might be able to try to use only the result in ra/ra_sci.c as the first step to keep ROM/RAM size small. However, this is one of idea.

iabdalkader · 2023-05-30T10:10:31Z

If you had obtained the result of R_SCI_UART_BaudCaluclate for bluetooth

I did but I think they are board/clock specific and probably shouldn't be hard-coded. Can we just add a copy of that function to ra/ra_sci.c ? I already have an open PR can just add it there, will format it and remove any unused code.

mbedNoobNinja · 2023-05-30T15:04:48Z

Added SDHI support in machine.SDCard and frozen SDCard module is removed. Regarding the baudrate I think R_SCI_UART_BoudCalculate could be copied in ra_sci.c in some form in the existing function ra_sci_set_baud() and then the existing implementation of the uPy method UART.init(baudrate) should work properly. But that of course conserns all RA bords and probably the fix shuld be in a separate PR.

iabdalkader · 2023-05-30T15:14:17Z

I already copied it, with some minor formatting cleanups and will add it to my open PR later. Note I tested changing the baudrate and everything seems to be working fine.

TakeoTakahashi2020 · 2023-05-31T11:27:48Z

Can we just add a copy of that function to ra/ra_sci.c ?

Thank you for waiting. I was still trying linking the r_sci_uart.c of FSP and calling R_SCI_UART_BaudCalculate() because I am concering about FSP license.

Some modifications for Makefile, ra/ra_sci.c and boards/*/ra_cfg/fsp_cfg/r_sci_uart_cfg.h were needed, but I could support baudrate change and UART.init(baudrate). This increase ROM size of 384 bytes. Now I am cheking and it is planned to open a new PR separately tomorrow (Japan time), so I would be happy if you all could review it.

iabdalkader · 2023-05-31T11:40:57Z

Okay will review and test it, as long as we can change the baudrate it's fine.

dpgeorge · 2023-06-22T13:32:33Z

This PR is looking a lot better now, but I still want to further simplify and reduce the files in each board directory.

See #11590 for the first PR to do this, which is merged.

And see #11846 for the second set of simplifications. I think that will help simplify this PR as well.

dpgeorge · 2023-06-25T08:44:02Z

I have rebased this on latest master and added some commits which:

consolidate the fsp_cfg files, as per previous commits
clean up some minor formatting issues
rename DAC write_mV and read_mV to write_mv and read_mv (we don't use upper case in method/function names)
remove escape codes from error messages, and simplify some messages
change ValueError to OSError for SD card errors

iabdalkader · 2023-06-25T19:22:58Z

Excellent, thank you!

dpgeorge · 2023-06-26T14:48:11Z

Rebased again on latest master, to pick up the improvements to the UART.

From my point of view, this looks OK to merge now (commits will be squashed before merging).

iabdalkader · 2023-06-26T16:10:29Z

From my point of view, this looks OK to merge now (commits will be squashed before merging).

Looks good, I'm probably nitpicking but it would look better split into 2 commits: 1) Add RA6xx series support, 2) Add VKxx board support (just the boards/dir).

dpgeorge · 2023-06-27T01:11:19Z

I'm probably nitpicking but it would look better split into 2 commits

Yes I agree. I'll try to do that.

This commit adds support for a new processor RA6M5. It also adds the following classes to the machine module: PWM, DAC, SDCard. Signed-off-by: mbedNoobNinja <[email protected]>

Signed-off-by: mbedNoobNinja <[email protected]>

dpgeorge · 2023-06-27T02:56:06Z

Thanks @mbedNoobNinja for your work on this.

TakeoTakahashi2020 · 2023-06-27T04:10:34Z

Great work @mbedNoobNinja. I am happy to add new RA board.

mbedNoobNinja · 2023-06-27T08:00:15Z

Thank you all! I'm glad I could help contribute to this project.

mbedNoobNinja force-pushed the VK_RA6M5 branch from 5cc723d to 5487bd5 Compare March 7, 2023 08:55

mbedNoobNinja mentioned this pull request Mar 7, 2023

tests/renesas-ra: Add support for VK-RA4W1, VK_RA6M3 & VK-RA6M5 boards. #10955

Open

mbedNoobNinja force-pushed the VK_RA6M5 branch from 5487bd5 to d95bc27 Compare March 16, 2023 07:58

iabdalkader reviewed Mar 23, 2023

View reviewed changes

iabdalkader reviewed Mar 24, 2023

View reviewed changes

dpgeorge added the port-renesas-ra label Apr 11, 2023

mbedNoobNinja force-pushed the VK_RA6M5 branch from d95bc27 to 12cb5d2 Compare April 13, 2023 09:38

mbedNoobNinja force-pushed the VK_RA6M5 branch from 12cb5d2 to b335cd0 Compare April 13, 2023 11:30

iabdalkader approved these changes Apr 14, 2023

View reviewed changes

mbedNoobNinja force-pushed the VK_RA6M5 branch from b335cd0 to 406d404 Compare April 18, 2023 14:50

iabdalkader approved these changes Apr 18, 2023

View reviewed changes

iabdalkader mentioned this pull request May 3, 2023

ports/renesas-ra: Add support for Portenta C33. #11405

Merged

7 tasks

mbedNoobNinja force-pushed the VK_RA6M5 branch from 406d404 to 5f38ee2 Compare May 12, 2023 14:11

TakeoTakahashi2020 mentioned this pull request May 29, 2023

renesas-ra/boards/make-pins.py: Fix PA/PB pins support. #11653

Merged

mbedNoobNinja force-pushed the VK_RA6M5 branch from 5f38ee2 to fb3d292 Compare May 30, 2023 14:34

TakeoTakahashi2020 mentioned this pull request Jun 1, 2023

renesas-ra: Support changing baudrate for UART. #11680

Merged

dpgeorge force-pushed the VK_RA6M5 branch from fb3d292 to 79dd12c Compare June 25, 2023 08:42

dpgeorge force-pushed the VK_RA6M5 branch from 79dd12c to 1f5e230 Compare June 26, 2023 14:47

mbedNoobNinja added 2 commits June 27, 2023 12:30

renesas-ra: Add support for RA6M5, and add machine PWM, DAC, SDCard.

fae96b1

This commit adds support for a new processor RA6M5. It also adds the following classes to the machine module: PWM, DAC, SDCard. Signed-off-by: mbedNoobNinja <[email protected]>

renesas-ra/boards/VK_RA6M5: Add new board definition.

761d86a

Signed-off-by: mbedNoobNinja <[email protected]>

dpgeorge force-pushed the VK_RA6M5 branch from 1f5e230 to 761d86a Compare June 27, 2023 02:38

dpgeorge merged commit 761d86a into micropython:master Jun 27, 2023

	EXPECTED_FSP_HASH = 9713f5b5c3d8bea5f0242feb30c1a57c89ae506a lib/fsp (v2.4.0)
	ifeq ($(CMSIS_MCU),RA6M5)
	EXPECTED_FSP_HASH = 9713f5b5c3d8bea5f0242feb30c1a57c89ae506a lib/fsp (v2.4.0)

		@@ -403,6 +431,13 @@ HAL_SRC_C += $(addprefix ra/,\

		endif

		ifeq ($(BOARD),$(filter $(BOARD),VK_RA4W1 VK_RA6M3 VK_RA6M5))

Uh oh!

ports/renesas-ra/boards/VK-RA6M5: Last New Board. #10943

ports/renesas-ra/boards/VK-RA6M5: Last New Board. #10943

Uh oh!

Conversation

mbedNoobNinja commented Mar 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iabdalkader Mar 23, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iabdalkader Mar 23, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mbedNoobNinja Mar 24, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mbedNoobNinja Mar 24, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iabdalkader Mar 24, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mbedNoobNinja commented Mar 6, 2023 •

edited

Loading

iabdalkader Mar 23, 2023 •

edited

Loading

iabdalkader Mar 23, 2023 •

edited

Loading

mbedNoobNinja Mar 24, 2023 •

edited

Loading

mbedNoobNinja Mar 24, 2023 •

edited

Loading

iabdalkader Mar 24, 2023 •

edited

Loading

TakeoTakahashi2020 commented Apr 17, 2023 •

edited

Loading

mbedNoobNinja commented Apr 18, 2023 •

edited

Loading

mbedNoobNinja commented Apr 18, 2023 •

edited

Loading