When VK-RA6M5 is merged, how much will this board have in common with that one, in the ra_cfg and ra_gen and src directories of the board?

I notice that EK_RA4M1 and RA4M1_CLICKER have a large amount of those files in common, so I'm thinking that these files should not be in the board directories but rather in a directory that is for MCUs, eg ports/renesas-ra/mcu/ra4m1 etc (similar to samd). Then all boards using the same MCU can share those files.

how much will this board have in common with that one, in the ra_cfg and ra_gen and src directories of the board?

That depends on how similar the project configs are, all of those files are auto-generated based on the chip, package, project settings, enabled stacks/peripherals etc.. I guess maybe one very generic project per chip/series can be generated, and shared, but somehow it must enable/support everything that could be needed by all boards that use it.

See #11590 for a start at reducing the amount of code in the board directories. I would like to simplify things a lot more before adding support for new boards, so those new boards can be much simpler.

See #11590 for a start at reducing the amount of code in the board directories. I would like to simplify things a lot more before adding support for new boards, so those new boards can be much simpler.

That's okay I'm still waiting on all of the deps above (updated), and btw I'm going to add networking support in this PR for this board/port via lwip, it's going to use raw eth <-> esp.

Adding #11680 as a dependency, because it's needed for bluetooth (which is working now btw) and now I'm working on WiFi.

Note this PR is outdated, will update it once the main deps are merged.

Do we need to wait for TinyUSB support for this board?

Do we need to wait for TinyUSB support for this board?

Yes, will ping them to merge the support, update the submodule and rebase this PR, then it will be ready for a review. Note this PR is Very outdated (been working in my fork).

Codecov Report

Merging #11405 (174bb28) into master (397697a) will not change coverage.
Report is 15 commits behind head on master.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #11405   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         158      158           
  Lines       20940    20940           
=======================================
  Hits        20602    20602           
  Misses        338      338           

@dpgeorge This is now rebased and updated, it can be reviewed & merged, and the board can be added to the build script later when the TinyUSB PR is merged, or it can wait.

Any idea why code-formatting fails ? I can't understand the error output.

Bluetooth tests:

./run-multitests.py -i pyb:a0 -i pyb:a1 multi_bluetooth/*py

18 tests performed
14 tests passed
2 tests skipped: multi_bluetooth/ble_deepsleep.py multi_bluetooth/stress_log_filesystem.py
2 tests failed: multi_bluetooth/ble_l2cap.py multi_bluetooth/perf_l2cap.py

./run-multitests.py -i pyb:a1 -i pyb:a0 multi_bluetooth/*py
18 tests performed
14 tests passed
2 tests skipped: multi_bluetooth/ble_deepsleep.py multi_bluetooth/stress_log_filesystem.py
2 tests failed: multi_bluetooth/ble_l2cap.py multi_bluetooth/perf_l2cap.py

Networking tests:

./run-multitests.py -i pyb:a0 -i pyb:a1 multi_net/*
20 tests performed
16 tests passed
2 tests skipped: multi_net/asyncio_tcp_client_rst.py multi_net/tcp_client_rst.py
2 tests failed: multi_net/asyncio_tcp_readall.py multi_net/udp_data.py

./run-multitests.py -i pyb:a1 -i pyb:a0 multi_net/*
20 tests performed
16 tests passed
2 tests skipped: multi_net/asyncio_tcp_client_rst.py multi_net/tcp_client_rst.py
2 tests failed: multi_net/ssl_cert_rsa.py multi_net/udp_data.py

CC @robert-hh you may find this new ESP32 "hosted" driver/firmware interesting.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +8 +0.002% TEENSY40[incl -8(data)]
        rp2:  +524 +0.160% RPI_PICO[incl -12(bss)]
       samd:   +44 +0.017% ADAFRUIT_ITSYBITSY_M4_EXPRESS[incl -8(data) -16(bss)]

Any idea why code-formatting fails ? I can't understand the error output.

That can happen when the code formatter gets confused by # macro indenting. You can try running ./tools/codeformat.py on a subset of the files to narrow down which one it's failing one.

That can happen when the code formatter gets confused by # macro indenting. You can try running ./tools/codeformat.py on a subset of the files to narrow down which one it's failing one.

I think I ran it on all files before sending the PR, also it tends to print out a lot of errors/warnings when I run it on my local machine, so I'm never sure if it's actually working or failing.

@dpgeorge I ran the code formatter again on all files, and disabled format checking for the 2 auto-generated protobuf files (which were already formatted) and it's not passing the format check not sure what else to do, otherwise it's ready for review.

@iabdalkader I'm about to merge this and have force pushed it with some minor changes. But I just noticed that the ports/renesas-ra/boards/ARDUINO_PORTENTA_C33/script/fsp.ld file seems to be unused, and no other renesas-ra board has this file. Can this file be removed?

If yes I will remove it during the merge, so please just let me know either way.

But I just noticed that the ports/renesas-ra/boards/ARDUINO_PORTENTA_C33/script/fsp.ld file seems to be unused, and no other renesas-ra board has this file. Can this file be removed?

Yes it's definitely not used.

But I just noticed that the ports/renesas-ra/boards/ARDUINO_PORTENTA_C33/script/fsp.ld file seems to be unused, and no other renesas-ra board has this file. Can this file be removed?

Yes it's definitely not used.

OK, thanks for confirming. I have removed it.

@iabdalkader Just tried to build that firmware, which fails with a problem of the protobuf compiler, which seems not to be built. Any hint?

protoc-c --proto_path=../../drivers/esp-hosted/ --c_out=build-ARDUINO_PORTENTA_C33/extmod/ ../../drivers/esp-hosted/esp_hosted.proto
make: protoc-c: Datei oder Verzeichnis nicht gefunden

It does not find protoc-c, which according to the README is created.

Edit: There is a command protoc on the system. Calling build with PROTOC=protoc runs into anotehr error:

protoc --proto_path=../../drivers/esp-hosted/ --c_out=build-ARDUINO_PORTENTA_C33/extmod/ ../../drivers/esp-hosted/esp_hosted.proto
protoc-gen-c: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--c_out: protoc-gen-c: Plugin failed with status code 1.

Edit 2: In addition to protobuf-compiler I had to install protobuf-codegen.

@robert-hh I have no problem building here on Arch, this command is echo'd:

protoc-c --proto_path=../../drivers/esp-hosted/ --c_out=build-ARDUINO_PORTENTA_C33/extmod/ ../../drivers/esp-hosted/esp_hosted.proto

Also the autobuild seems to be working https://micropython.org/download/ARDUINO_PORTENTA_C33/

However, for renesas-ra it seems to be missing the *.bin CC @dpgeorge

After adding protobuf-generator, protoc-c is available as well, which is linked to protoc-gen-c.
Edit: I run a debian machine.

Out of interest, I combined the esp-hosted MicroPython firmware and a ESP32 with NINA firmware. BLE works, not much better that with the NINAW10 MicroPython firmware, but consistent. Test coverage is still low, but consistent. Interestingly, stress_log_filesystem.py passes all the time.
That indicates that it is the newer esp-idf version which improves BLE with the ESP32 module.

However, for renesas-ra it seems to be missing the *.bin CC @dpgeorge

Fixed by b0e03b3

That indicates that it is the newer esp-idf version which improves BLE with the ESP32 module.

Unfortunately updating the Nina firmware to a newer IDF is not that easy.

@iabdalkader Yesterday I tested again the esp_hosted based WiFi/BLE support for the SAMD port after having rebased the respective PR when needed. But now it refuses to work properly. The TCP test is slow and error-prone. Webrepl works only if started in foreground mode. UDP tests are fine.
Since the adaption for esp-hosted is almost the same as in the renesas port, could you please check for the renesas port if WiFi still works fine and Webrepl can be regulary started.

Yes I can test it later today and get back to you.

The Portenta C33 firmware no longer works. It seems that the last working firmware is micropython-1.22.1.

CC @dpgeorge

@robert-hh managed to get 1.24 working again and ran the tests again. Note NTP is set and all .der files are copied to FS.

multi_net/tcp_data.py on ttyACM0|micropython: pass
multi_net/udp_data.py on ttyACM0|micropython: pass
24 tests performed
20 tests passed
1 tests skipped: multi_net/sslcontext_getpeercert.py
3 tests failed: multi_net/asyncio_tcp_client_rst.py multi_net/sslcontext_server_client_files.py multi_net/tcp_client_rst.py

And

multi_net/tcp_data.py on micropython|ttyACM0: pass
multi_net/udp_data.py on micropython|ttyACM0: pass
24 tests performed
20 tests passed
3 tests skipped: multi_net/asyncio_tcp_client_rst.py multi_net/sslcontext_getpeercert.py multi_net/tcp_client_rst.py
1 tests failed: multi_net/ssl_cert_rsa.py

Thank you for the feedback. What are the transfer rates in a test with iperf3. What I observed is a huge drop in transfer speed for TCP. UDP still works fine.

I can't find the old number but they look in line with what I remember.

@iabdalkader Thanks. I managed to get it back to speed. It was a test version of the esp_hosted firmware, which was rebased to the current master. So maybe better not use it.
Edit: The transfer rates now much yours.