Remora - Rpi Software Stepping Using External Microcontroller via SPI

While waiting for the EC300 to arrive I've put the SKR3 back on the bench. JojoS has done some work for the SDIO driver for Mbed, which I have not been able to get working. Mbed is also not working when trying to use the standard bootloader and I've past trying to figure this out. Cakeslob has had issues with the bootloader on other boards and it appears to be something deep in the Mbed code which is affecting clock settings or something. I also saw this for the F103 which ran sloooow.

So back to STM32cubeIDE which plays nicely with the bootloader. I've managed to mount the SD card, but now trying to figure out why transfers to the card hang. JojoS seemed to have the same issue so hopefully his insights can help.

Success, SKR3 SDIO SD read and write working with DMA and cache maintenance.

Now to get DMA SPI working....

Awesome, are you doing it all on stm32cube now?

it appears to be something deep in the Mbed code

thats the maddening part. Seems to be chip specific also, considering 407 firmware works on 446, but 446 firmware doesnt work on 446

Yes, the work on the SKR3 STM32H743 is on STM32CubeIDE. Debug capability has been so handy.

I'm thinking once with SKR3 is up and running to circle back to the other boards to move them to CubeIDE also. We'd lose the single code base (unless someone knowledgeable has a good method) but at least we don't have the unknown code in play. Mbed was handy for the handy API's but with the NVEM and EC500 work we have IO and PWM sorted, would just need to rework the analogue for the thermistor inputs.

Remora, would end up like Marlin etc with board / MCU specific versions.

Thoughts?

We are using mbed for our remora build and it kind of sucks. CubeIDE or PlatformIO (which includes the cubeide API) would be preferable and make it easier to port to different architectures without relying on MBED support which doesn't appear to always be timely or consistent.

While it might not be an immediate thing, one way to architect the project might be to adopt the repo structure of GRBLHAL. In that project, the core and plugin repositories are brought into driver repos as submodules (the hardware is abstracted via function pointers) and that is where hardware specific code is located. It can be intimidating at first, but I find it much preferable to Marlin since you are not wading through vast amounts of code that is irrelevant to a particular MCU.

github.com/grblHAL

While it is not without flaws, this structure has very quickly allowed the project to be ported to nearly every 32-bit MCU architecture on the market:
github.com/grblHAL/drivers

Just presenting it as an alternative to the Marlin approach in the hopes it might be interesting.

Thanks for sharing and quite impressively organised! I need to understand the submodule approach but planning ahead will be important when moving away from Mbed.

I'll get the SKR3 running with CubeIDE and maybe take some advice on how to move forward if that's ok.

My 2 cents, with the understanding its worth less

From a low-end user point of view I find mbed to be easy enough to add new targets with a decent success ratio.

For me from a pragmatic standpoint, if bootloader is the only issue, IMO that doesnt seem like a big deal (to me at least) as long as the original is supplied. The USB DFU has made it easy to reload it, and most new boards support usb dfu. Ive just been writing over them if they dont work first shot since I got burned the last time with the octopus. While I am admittedly having trouble with mbed and getting my custom targets to work, it appears to be related to me, as I find no one else having these issues. Upon review of the bootloader issues I noticed we use some outdated methods for vector table relocation in the system_clock file. Im going to test out later.

With that said, I have no other frame of reference except mbed. While I enjoy its simplicity, if it is holding back the project as a whole....

You gotta do what you gotta do.....

drewnabobber wrote:

We are using mbed for our remora build and it kind of sucks.

Hey drew, first I just want to say, your remora board is looking pretty slick. and Canadian homegrown to boot. I just noticed it was avaiable for sale, so I will pick one of those up tonight.

What issues are you having with your board and remora? I can assume bootloader, but are you having other issues?

I am very interested in how you will be implementing the I2C eeprom. Considering that you are tapped into the RPI i2c, are you planning on sending it via I2C from RPI to EEPROM?

Most of our changes are around making remora work with a static config.  Since we control the board design, we don't need to dynamically load configuration.  An input is always an input and an output is always an output, the stepgens are always connected to the differential stepper drivers etc.  Of course it might be nice to change the config in future on some things, like allowing the encoder to be used as generic inputs or the stepper pins to be general outputs, but that's not really critical for our initial release.  In such a situation we could look at storing the configuration in the eeprom and loading it when the MCU starts up, but I don't think this is a priority.

The other things we have done is implemented a bunch of the recent updates from Scott to improve the step rate.  I think this is something we are going to continue to work on as I think that the work using DMA shows promise.

Right now I don't think we have any issues with Remora.  The board ships with our UF2 bootloader implementation so that it is easy for people to update the firmware for GRBLHAL, but currently we program Remora in-system from the Pi using DFU over UART so there are no bootloader issues.  This is also why we don't really need dynamic configuration, because we can always just compile a new build with a different configuration and flash it directly.  Dynamic config would be handy as described above, but it isn't critical for an initial release.

On our board Remora does not use the I2C eeprom.  This is currently used to store GRBLHAL configuration settings which is handy because you are able to switch back and forth between GRBLHAL and Remora and not lose the config.  In future, we may use the eeprom to store the GRBLHAL tool table (again, so that it is persistent and tied to the controller) and/or an odometer to track machine usage.  The eeprom is addressable from the Pi, so any eeprom or I2C functionality in LinuxCNC would not need to go through the Remora component.

Possible $6 or $8 option for Remora on a RISC-V board:
linuxgizmos.com/ox64-sbc-powered-by-dual-risc-v-processors/

www.pine64.org/2022/10/15/october-update-an-ox-no-bull/

IF it actually becomes readily available.

Hi- I just discovered Remora and have been trying to read through the 60 pages.... I have been a RepRapFirmware user on LPC and STM, so I am quite eager to try Remora with LinuxCNC. I will try to use it on a tabletop router/engraver.

A couple of thoughts and questions-

1. Has anyone tried using a 32bit GRBL board that uses an STM chip? I have one coming and am hopeful it might have the right pins accessible.
a.co/1WLVZhO
There is a 2x5 header for an offline controller. The pinout on the product page does not label the pins, and I am hoping to reverse pin-out them.

I have not found any documentation at all yet.

2. The RRF for LPC/STM folks have some boards that might be of interest.
teamgloomy.github.io/
is the documentation for
Fly-Mellow
mellow.aliexpress.us/store/group/FLY-Boa..._10000001215764.html
and here is an example of a 5 axis STM32F4 board with an integrated ESP8266
www.aliexpress.us/item/3256802186437082.html

What would happen to things that are not supported- for example the ESP8266? Its basically a daughterboard to provide WiFi and host controller to feed the controller gcode.

sinneD