Mbed is announced end of life in 2026, ARm already ceased dev and support

[bschwand]

Are there any plans to move the code base to another build environment, or is remora just going to die ?
Personally, I think it would be better to make it a baremetal gcc-arm based build.
Or based on cmsis/etc, etc.

Any ideas ?

[cakeslob]

Theres a discussion in another issue thread, but I suppose we can just keep it contained here. Mbed made cross platform pretty easy. At the moment, the discussion revolves around something similar to how grblHAL organizes their multiplatform toolchains

[scottalford75]

With the STM32H7 development nearly complete using STM32CubeIDE, the plan was to use this as a test platform to move to a PlatformIO based development environment. Remora already has a level of HAL abstraction so move to a sub module approach like grbHAL was the though. Of course we're open to other ideas. Remora is running on LPC, STM32, i.MX RT1052 and RP2040 with basically the same code structure. Some using Mbed and others using the IDE's with their HALs.

[cakeslob]

I dont think its gonna be fun. Browsing across other RTOS and platfromIO, I see similar issues as with MBED and not having up to date libraries, that seem to be specifically problematic regarding the H7, as this seems to be a painful MCU to work with software wise

[scottalford75]

You may be right, the H7 has been painful. One minute I think the cache stuff is working ok, make some code changes... it's broken again. I've had to disable D Cache now just to get the JSON file to load....

[cakeslob]

the guys working on Mbed-ce (with our friend jojo) have done extensive work on the H7 specifically the SPI DMA,
https://github.com/mbed-ce/mbed-os
reading through some of their old issue reports related to H7, SPI DMA, and dcache, it seems complicated and tedious

[bschwand]

With the STM32H7 development nearly complete using STM32CubeIDE, the plan was to use this as a test platform to move to a PlatformIO based development environment. Remora already has a level of HAL abstraction so move to a sub module approach like grbHAL was the though. Of course we're open to other ideas. Remora is running on LPC, STM32, i.MX RT1052 and RP2040 with basically the same code structure. Some using Mbed and others using the IDE's with their HALs.

that would be great. Not specially a fan of PlatformIO but it works well and they have command line tools. It is also much easier to create a self-contained source build including all dependencies and basically go bare-metal if needed.

I am still puzzled by remora code organization. I only realized now that there are separate repos for different uC/boards... At first I was just looking at the main remora repo, and was confused because I was not finding any of the ethernet enabled boards.

Is there any plan to converge all those various repositories into one again ? I just see tons of code duplication and wonder where the most up to date development is.

I am interested because I have a bunch of boards with stm32F429ZI that I would like to repurpose, and add ethernet so they can be used with a regular PC linuxCNC controller.

[bschwand]

BTW, I posted here because I did not know any more appropriate place to ask, but maybe enabling github discussions on this repository would help ?

[scottalford75]

Great idea. Just enabled discussions.

[cakeslob]

"I am interested because I have a bunch of boards with stm32F429ZI that I would like to repurpose, and add ethernet so they can be used with a regular PC linuxCNC controller."

For that you can try playing with one of the older STM32F4 NVEM repos, im fairly sure that used PHY
Otherwise, you can do ethernet using a W5500 ethernet module, I have it working on the f429 right now,.