Remora - Rpi Software Stepping Using External Microcontroller via SPI

yeah, thats what I was trying to say with the software pin thing, I dont see it listed in the datasheet as an actual spi pin,  its an SDIO pin, but not SPI cs,  SPI3 cs is either on pin PA_15, or on PA_4 (same as spi1cs), as an alternate pin function 

I did compile a version with this change after I read about the interrupt vector table, but I didnt make a difference so I there theres more I would have had to do, or it only works on SPI1




yes, the joy of new boards I am 0/4 so far lol , I honestly though it would be easier once the framework was in place and it makes me appreciate all the hard work that went into it even more.

cakeslob wrote:

ok, not working yet, but closer. your patience and help is appreciated as always.
Like you said, SD card, so I read through sdblock, and theres some difference between sdsc and sdhc, so I loaded it and it can mount the file system with the sdhc. so something about my other sd card, it can load the firmware properly but no mount the file system.

So, what I have going now,
it reads the config file, finishes setup, then start, then goes into idle.
when I hit estop , in linuxcnc terminal i get bad spi payload=0 (or 32303a30 depending on what I set my spi1_clk_divsor to) and it goes back into estop.
in remora uart it reloads the setup and goes back into idle, here is the log when i hit estop here is my pinout also
 

File Attachment:

File Name: log.txt
File Size:2.52 KB

 

I shifted the pru reset over to the next pin , which is btn_en2 aka PE_8, because the pin I would use, SPI1_DET aka PB_11 looks tied to vcap1 and since idk whats going on there, I just changed it to btn_en2.

Great news that you have got this far. The SPI comms with the RPi should be straight forward now as it is using the same SPI as the SKR2 board (the board used for STM32 porting). For starters, do not connect the reset pin so as not to trigger an unwanted board reset. If the board resets after too many bad SPI packets then I would look at wiring issues. Try to use as short as practical ribbon cable for the connection between the RPi and the controller board.

cakeslob wrote:

yeah, thats what I was trying to say with the software pin thing, I dont see it listed in the datasheet as an actual spi pin,  its an SDIO pin, but not SPI cs,  SPI3 cs is either on pin PA_15, or on PA_4 (same as spi1cs), as an alternate pin function 

I did compile a version with this change after I read about the interrupt vector table, but I didnt make a difference so I there theres more I would have had to do, or it only works on SPI1

Code:

else if (this->interruptPin == PC_9) { // interrupt pin is not the NSS pin, ie the board shares the SPI bus with the SD card // configure the SPI in software NSS mode and always on sharedSPI = true; HAL_NVIC_SetPriority(EXTI9_5_IRQn , 5, 0); yes, the joy of new boards I am 0/4 so far lol , I honestly though it would be easier once the framework was in place and it makes me appreciate all the hard work that went into it even more.

Hmm, so how is the CS being handled then. I'll need to look into the API to see if it's rolling back to having the CS always low and software NSS configured.

The code snippet is from the RemoraComms and will have no effect on the SD SPI card config.

so, preface, Im using the same 4"/100mm cable i use for all my remora setups, but ill change over to a 2"/50mm one and see what happens. with no reset pin, it never goes idle and resets every 2 estop clicks.

for the software/hardware cs pin, i figured it would be the same as the mks robin config because looking at all the pin stuff, They both use the same spi1 for main comms , and both use SDblock with software nss, the only difference i see is robin is on spi2 and monster8 is spi3

The way you have it setup looks proper, in sdblock its using dynamic pin mode

shortest cable didnt fix it, just changed the the bad spi payload values

unrelated, what was the steps for setting the the thread speeds in the config.txt? ive been playing with the hal divider but I cant find where the info was posted

It was in the other topic on the 1.0rc

forum.linuxcnc.org/18-computer/43988-rem...ting?start=30#224743

loadrt remora chip_type=STM SPI_clk_div=16 PRU_base_freq=40000

BTW as a minimum for the Monster 8 as it's the same MCU as the SKR2