search

scottalford75 / Remora

Remora is a free, opensource LinuxCNC component and Programmable Realtime Unit (PRU) firmware to allow LPC176x and STM32F4 micro-controller controller boards to be used in conjunction with a Raspberry Pi to implement a LinuxCNC based CNC controller.
130 stars 33 forks source link

RPi5 Merge plan #69

Open cakeslob opened 1 week ago

cakeslob commented 1 week ago

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 :

cakeslob commented 1 week ago

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 commented 1 week ago

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 https://github.com/scottalford75/Remora/issues/69, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBMVILBZYP4KPSK64HVUZTZ62XVXAVCNFSM6AAAAABRDHWATKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTCNJZHE3DSNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

cakeslob commented 3 days ago

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 commented 3 days ago

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 https://github.com/scottalford75/Remora/issues/69#issuecomment-2469344354, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGBMVIKIDVFVB35TIALVVVL2AFDHDAVCNFSM6AAAAABRDHWATKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRZGM2DIMZVGQ . You are receiving this because you commented.Message ID: @.***>