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

[cakeslob]

Hey Scott, more people use the old boards than expected. Im gonna try and update it for the rpi5

I will update the firmware for the LPC to the new stepgen stuff, but can you help me with the component part? I am not sure how to do the rp1 thing. I dont think it ive done this part right (0,txData.txBuffer[i]);

if (chip == LPC) { for (int i = 0; i < SPIBUFSIZE; i++) if (bcm == true) { rxData.rxBuffer[i] = bcm2835_spi_transfer(txData.txBuffer[i]); } else if (rp1 == true) { rxData.rxBuffer[i] = rp1spi_transfer(0,txData.txBuffer[i]); }

[cakeslob]

Also, how do you feel about putting the RPI driver debug to be just a rtapi_print and only show up in the terminal?

Also, thought on changing the SPI bad payload error to be a rtapi_print_msg(RTAPI_MSG_ERR, popup?

I ask, because the conversation goes like this every time, and I would like to stream line it.

"my remora wont come out of estop"
"what does the terminal output say?"
" I dont know, how do i see that"
then the explanation about how to open up lcnc in terminal

[scottalford75]

Hi Cakeslob,

Yes, the LPC needs the CS to toggle for each byte. I have not implemented a single write read function that returns the read value. But transferring one byte at a time with the existing function should work.

rp1spi_transfer(0, txData.txBuffer[i], rxData.rxBuffer[i], 1);

Yes, those debugging comments should only show up in the terminal. And moving the bad SPI data to a true error pop up makes sense.

I need to spend some more time checking the RPi 5 SPI comms. I saw some ugly packets during the STM32H7 testing and switched back over to a RPi 4 to rule out comms issues during development.

[cakeslob]

Scott, thoughts on harmonizing some of the signal names between the eth and spi drivers? Specifically
remora.enable
remora.reset
remora.status

This way, there is essentially only 1 entry in hal that needs to be changed between the 2 drivers, and hal files can be basically the same across remora .

Also Re: RPi5 comms, It appears to not be shutting down correctly or something. For my board with shared SPI SD card, the RPi SPI appears to be jamming up the STM32 SPI after linuxcnc closes. If i need to reset the STM32, the SPI SD card can never reconnect (causing a bootloop) unless I hard reset the RPi5, or toggle the SPI on/off in RPi config.

[scottalford75]

Hi Cakeslob,

I'll need to check, but those signals should be the same between the two components.

Thanks for the feedback on the RPi5 SPI, I'll have a look. I've been using the RPi4 for dev work at the moment as I was not happy with some of the SPI packets from the 5, they looked a bit strange...