Remora - Rpi Software Stepping Using External Microcontroller via SPI

is j3 the extruder or one of the rotary joints/axis?

jairobbo wrote:

scotta thank you so much!

the challenges I face that are left are:

1) homing -> I tried wiring to GND and 3.3v but joint.0.home (maybe it's called different) is never TRUE, I tried using halcmd show pin for that while linuxcnc was running and also live testing the home axis.

Code:

[code]27  bit   OUT         FALSE  remora.input.00 ==> X-home    27  bit   OUT         FALSE  remora.input.01 ==> Y-home    27  bit   OUT         FALSE  remora.input.02 ==> Z-home    27  bit   OUT         FALSE  remora.input.03 ==> A-home [code]I think it's weird that all my inputs are listed as OUT.... 2) maybe related maybe unrelated: my A axis (joint3) is continuing to have follow joint problems. I thought maybe the motor or the driver went bad, but I swapped both. I tried several stepgen_maxaccel settings and fooled around with other settings as well. Of course I appreciate the help so far and yes it's close to working, I was already very happy to see my XYZ axes moving!!!! :)  

[/code][/code]

Hi, the inputs are "outputs" from the remora-spi component. The way I would approach this is the use halshow to confirm the the inputs are working.

1. ensure you have the inputs in your config.txt file
2. LinuxCNC has come out of eStop so comms are up. You will not see any input state changes unless you are out of eStop
3. Use halshow to monitor your inputs
4. Manually trigger the inputs and that they change state in halshow
5. setup you hal config

Hi,

Not sure if this is the correct place to post, as I'm actually not a Remora user but someone trying to use the source code for a LCNC to TMC5160 communication module.

I downloaded the latest official RPi 5 image and could not get a SPI communication with my TMC5160 drivers. I had to force the "rp1" variable to "true" in the code and then found out that my device-tree doesn't have the "soc" folder the script was looking for, but a "soc@107c000000". It seems like there are 2 different dtb files available, the bcm2712d0-rpi-5-b.dtb and the bcm2712-rpi-5-b.dtb. Can someone explain me the difference?

I also had a look in the new spix driver that hm2 component uses, and it reads /proc/device-tree/compatible to detect the board type. Might it be a bit more robust to dtb files changes?
hm2.spix.c:

// Read the 'compatible' string-list from the device-tree
    buflen = spix_read_file("/proc/device-tree/compatible", buf, sizeof(buf));
    if(buflen < 0) {
        LL_ERR("Failed to read platform identity.\n");
        return buflen;    // negative errno from read_file()
    }

    // Decompose the device-tree buffer into a string-list with the pointers to
    // each string in dtcs. Don't go beyond the buffer's size.
    memset(dtcs, 0, sizeof(dtcs));
    for(i = 0, cptr = buf; i < DTC_MAX && cptr; i++) {
        dtcs = cptr;
        j = strlen(cptr);
        if((cptr - buf) + j + 1 < buflen)
            cptr += j + 1;
        else
            cptr = NULL;
    }

spix_rpi5.c:

for(i = 0; dtcs != NULL; i++) {
        if(!strcmp(dtcs, DTC_RPI_MODEL_5B) || !strcmp(dtcs, DTC_RPI_MODEL_5CM)) {
            break;    // Found our supported board
        }
    }

Thanks for your help.

Thanks for sharing. I did investigate reading the device tree when working on the RP1 driver but took the easy path so as to focus on the DesignWare SPI side of things. Looks like I'll need to rework the board detection. At least the Mesa code will be a great starting point.

I just tested this at the beginning of rt_peripheral_init and it compiles and works on my RPi5 and RPi400 if you include the attached dtcboards.h:

int rt_peripheral_init(void)
{
    FILE *fp;
    int i, j;
    char buf[256];
    ssize_t buflen;
    char *cptr;
    const int DTC_MAX = 8;
    const char *dtcs[DTC_MAX + 1];
    
    // assume were only running on >RPi3
    
    if ((fp = fopen("/proc/device-tree/compatible" , "rb"))){

        // Read the 'compatible' string-list from the device-tree
        buflen = fread(buf, 1, sizeof(buf), fp);
        if(buflen < 0) {
            rtapi_print_msg(RTAPI_MSG_ERR,"Failed to read platform identity.\n");
            return -1;
        }

        // Decompose the device-tree buffer into a string-list with the pointers to
        // each string in dtcs. Don't go beyond the buffer's size.
        memset(dtcs, 0, sizeof(dtcs));
        for(i = 0, cptr = buf; i < DTC_MAX && cptr; i++) {
            dtcs = cptr;
            j = strlen(cptr);
            if((cptr - buf) + j + 1 < buflen)
                cptr += j + 1;
            else
                cptr = NULL;
        }

        for(i = 0; dtcs != NULL; i++) {
            if(        !strcmp(dtcs, DTC_RPI_MODEL_4B)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_4CM)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_400)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3BP)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3AP)
                ||    !strcmp(dtcs, DTC_RPI_MODEL_3B)) {
                rtapi_print_msg(RTAPI_MSG_ERR, "Raspberry Pi 3 or 4, using BCM2835 driver\n");
                bcm = true;
                break;    // Found our supported board
            }else if(!strcmp(dtcs, DTC_RPI_MODEL_5B) || !strcmp(dtcs, DTC_RPI_MODEL_5CM)) {
                rtapi_print_msg(RTAPI_MSG_ERR, "Raspberry Pi 5, using rp1 driver\n");
                rp1 = true;
                break;    // Found our supported board
            }else{
                rtapi_print_msg(RTAPI_MSG_ERR, "Error, RPi not detected\n");
                return -1;
            }
        }
        fclose(fp);
    }else{
        rtapi_print_msg(RTAPI_MSG_ERR,"Cannot open '/proc/device-tree/compatible' for read.\n");
    }    
    
    if (bcm == true){
...

scotta wrote:

Thanks for sharing. I did investigate reading the device tree when working on the RP1 driver but took the easy path so as to focus on the DesignWare SPI side of things. Looks like I'll need to rework the board detection. At least the Mesa code will be a great starting point.
 

You actually did an amazing job on the DesignWare SPI and I can't thank you enough for it!