Remora - Rpi Software Stepping Using External Microcontroller via SPI

Great news JojoS, thanks for this. I'm curious now if it's sleep functions which are causing my attempts with the H743 to stop when using the bootloader and bare metal profile.

Remora uses bare metal profile to remove the RTOS overhead, but I've never really investigated the sleep features. But we have targets that don't play when trying to use the standard bootloaders that come with the boards.

scotta wrote:

A very generous forum member sent me an SKR3 for development. Thanks so much to them!!!
 

Hello! Could you please share current status of SKR3 board regarding Remora?
 

I've been distracted by the DMA step generation work, which now seems to be a waste of time. JojoS has been working on the SDIO for the H743 which looks to be workable for our needs. I've had no luck getting a hello world to work with the boot loader though....

I have worked also more on DMA/cache topics. For simple usage of the SDIO (or SDMMC as in H7) the user should not care about the passed bufferpointer, so the driver has to check the address and add copy from/to an aligned buffer.
Fortunately, there is a function aligned_alloc() in C/C++, unfortunately the support for this function is poor.
GCC has compiled, but the linker has thrown errors about non existing posix_memalign which was used inside aligned_alloc. This was true up to gcc 10.2.1, the current 10.3.1 has fixed this by using mem_aligned_r internally. There is still a flaw because it should be availible in namespace std, but it can be called only without specifiying the namespace. Ok, that is acceptable.
But when you want to use Mbed Studio, the prehistoric ARMC6 compiler doesn't know about this standard function at all.I can try to use also mem_aligned, but that is a poor workaround.
Compiling in VSCode is more fun, but needs some more setup than Mbed Studio.I have just asked in Mbed forum about the compiler status, but I don't really expect a (positive) answer.

A performance test has shown about 16 MB/s reading speed with filesystem. One thing that I learned there was that fread() is very slow (about 2,5 MB/s), the File class in Mbed is much faster beause it calls the FatFS function more direct.

scotta wrote:

 I've had no luck getting a hello world to work with the boot loader though....
 
 

do you have some info about the bootloader? And what have you tried so far, can you publish a test project on github?
I have set the VBUS jumper and connected the board to my PC via USB. Then I connect with a terminal program to the VCOM, but get no response. Is there no firmware installed?

Hi bootloader offset is 0x20000. I do have a hello world which is on my development machine. I'm travelling for work this week and don't have it with me. When using wait instructions the program would stop. So I'm thinking it's something to do with the vector table in RAM which is not being copied / mapped correctly.

thanks, I have found that offset also in the Marlin software, and my board is now also responding to G-codes, I think it was wrong baudrate.
So I will try also a hello world now. The interrupt vector table should be located correctly in RAM, it can be also some ticker stuff.

github.com/Expatria-Technologies/Flexi-HAL

Looks like this guy is cookin something

The only problem is STM32F4. Where do you get them today?

I was just looking into a PCIe to SPI bridge for the Pi Pico (RP2040) so that they may be used in an x86 PC or with an arm64 board.

Heh, I just checked with Digikey and    5,314 In Stock of the STM32F446    $8-11ea

So maybe 

cakeslob wrote:

github.com/Expatria-Technologies/Flexi-HAL

Looks like this guy is cookin something

So cool to have a board developed to use Remora