RPi5 Merge plan

[cakeslob]

Hey Scott, lets just put together a plan for this because its starting to get messy. I think because we have been merging eachothers repos, I can no longer revert some of the newer commits, to a pre rpi5 state in the main branch.

either way, we have hit a divergent point with this new one. if you can give me some feedback on this, that would be appreciated

Here is my idea for the plan :

• stash all older stuff into another repo. I made a branch based off pre rpi5 commits, so it can preserve the old bin files and components/configs : https://github.com/cakeslob/Remora/tree/pre-rpi5
• if you are fine with the changes in /stepgen_testing , we need to merge those before we compile firmware / release component, because these changes break previous versions and the config files need to be changed
• think of a name or version number or something, because we need to relabel everything so there is a clear distinction between older versions
• delete all old files pre divergence, modify all configs, update docs

[cakeslob]

Im going to assume you are fine with the changes from stepgen_testing, so I have merged those changes with the rpi5 changes, and updated all configs accordingly and compiled bins for the main boards.

I could not revert the changes made using git, so I have branched off everything new into branch rpi5, and branched as well as branching off the main branch to a commit before the rpi5 stuff. I had to branch it based on my fork, because the timeline of the merged commits made it difficult to branch off yours.

The workflow is as follows

main (my main, pre-rpi5) -> stepgen_testing(scotts) -> stepgen_testing(cakeslobs, recently merged) -> rpi5 -> main

https://github.com/cakeslob/Remora/tree/rpi5

[scottalford75]

Hi Cakeslob, I think this is a good time to clean-up all the Remora repos. I'd like your thoughts again on how to future proof the remora code base. With the end of life being announced for Mbed and Mbed studio it will be inevitable to change. I've been looking at how grblHal has been setup to support multiple platforms with a common core and IDE specific portions. I'd be tempted to go down this path as CubeIDE and MCUXpresso debug capabilities have been invaluable. It was the only way I could get the H743 to boot using the standard boot loader. This would require reworking all the targets in CubeIDE, but the F407 is already basically there with the original NVEM firmware. Thoughts? Thanks Scott

…

On Mon, Nov 4, 2024 at 11:38 AM cakeslob ***@***.***> wrote: Hey Scott, lets just put together a plan for this because its starting to get messy. I think because we have been merging eachothers repos, I can no longer revert some of the newer commits, to a pre rpi5 state in the main branch. either way, we have hit a divergent point with this new one. if you can give me some feedback on this, that would be appreciated Here is my idea for the plan : - stash all older stuff into another repo. I made a branch based off pre rpi5 commits, so it can preserve the old bin files and components/configs : https://github.com/cakeslob/Remora/tree/pre-rpi5 - if you are fine with the changes in /stepgen_testing , we need to merge those before we compile firmware / release component, because these changes break previous versions and the config files need to be changed - think of a name or version number or something, because we need to relabel everything so there is a clear distinction between older versions - delete all old files pre divergence, modify all configs, update docs — Reply to this email directly, view it on GitHub <#69>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBMVILBZYP4KPSK64HVUZTZ62XVXAVCNFSM6AAAAABRDHWATKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTCNJZHE3DSNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cakeslob]

Hey Scott, yeah the countdown is on until mbed is over, may 2026 I think.

Before you start getting to heavy into the cubeIDE, which is honestly a pain, treje and grblHal have migrated to using platformIO for most things. Its using the STM32cube libraries, and cubeMX projects can be imported/converted to platformIO if needed. It is much more user friendly than using all different IDE';s and you can still generate board stuff from cubeMX. Im not 100% cleard on the MCUXpresso part, but there is some path for the NXP chips also.

Drew's W5500 firmware is based on grblHal to a degree, but he didnt split the stack because he developed it for 1 board. I added support for several other STM32F4 chips pretty seamlessly. Im gonna strongly suggest starting there, it is pretty userfriendly, and the board specific firmware branch can be compartmentalized into whole stm32 series. it will also be easier to borrow code from grblhal (which we did on the w5500 firmware)

If you would like to check it out, I think it might make a good jump off point for spliting the remora from the MCU

https://github.com/cakeslob/Remora-STM32F4xx-W5500/tree/f429
https://github.com/cakeslob/Remora-STM32F4xx-W5500/tree/bp2

[scottalford75]

Hi Cakeslob, Thanks for sharing your thoughts. It's been years since I last used PlatformIO. It was the development platform which Remora was originally developed on. I moved to Mbed when PlatformIO broke stuff. I'll take another look and get my head around the multi target build environment. I do like the debug capabilities of the Eclipse based IDE's but they are beasts to understand. I nearly lost my whole development work and history with a failed partition resizing on my PC! Lucky it was all in a separate logical drive which I could mount and recover. So I've been spending the last week rebuilding the PC.... Scott

…

On Tue, Nov 12, 2024 at 11:25 AM cakeslob ***@***.***> wrote: Hey Scott, yeah the countdown is on until mbed is over, may 2026 I think. Before you start getting to heavy into the cubeIDE, which is honestly a pain, treje and grblHal have migrated to using platformIO for most things. Its using the STM32cube libraries, and cubeMX projects can be imported/converted to platformIO if needed. It is much more user friendly than using all different IDE';s and you can still generate board stuff from cubeMX. Im not 100% cleard on the MCUXpresso part, but there is some path for the NXP chips also. Drew's W5500 firmware is based on grblHal to a degree, but he didnt split the stack because he developed it for 1 board. I added support for several other STM32F4 chips pretty seamlessly. Im gonna strongly suggest starting there, it is pretty userfriendly, and the board specific firmware branch can be compartmentalized into whole stm32 series. it will also be easier to borrow code from grblhal (which we did on the w5500 firmware) If you would like to check it out, I think it might make a good jump off point for spliting the remora from the MCU https://github.com/cakeslob/Remora-STM32F4xx-W5500/tree/f429 https://github.com/cakeslob/Remora-STM32F4xx-W5500/tree/bp2 — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBMVIKIDVFVB35TIALVVVL2AFDHDAVCNFSM6AAAAABRDHWATKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRZGM2DIMZVGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[cakeslob]

Hey Scott, I stashed all the old stuff in another branch, but I dont know how to pull request a whole branch.

I did a pull for the Rpi5 clean up stuff, where I deleted a bunch of old stuff. Make sure it stays deleted. Looks like theres a merger issue with one of the bins thought
I also did a pull for the changes Ive been working on with the docs, they now include RPi5 info, but I might have broke things, so we will find out