Shop OBEX P1 Docs P2 Docs Learn Events
Multimode SPI Implementation (SPIN2 + PASM) — Parallax Forums

Multimode SPI Implementation (SPIN2 + PASM)

Hi All,

I've written some SPIN2+PASM code (see file links below) for handling SPI communication for a wide variety of devices. I found SPI mode 3 communication (required for the AD71240-8 adc chip of interest) to be difficult using smart pin implementations so I began development using SPIN2+PASM code primarily derived from Jon "JonnyMac" McPhalen's work. My code was written with the Propeller Tool Version 2.5.3.

A new object file 'gp_asm_spi.spin2' was used to communicate with both the P2 Edge's internal serial
flash chip (using SPI mode 0 or 3) and an external AD71240-8 adc chip (using SPI mode 3) simultaneously. Two object instances of 'gp_asm_spi' were used (spi & spi2) as different i/o pins were needed by the two SPI devices.

Code Use Examples:

 SPI.start(pMISO, pMOSI, pSCK, pSPI_MODE, pSCK_KHZ)   'initialize SPI interface

 SPI.shiftout_msbf( value, 8)       'send 8-bit command, MSB first
 result := SPI.shiftin_msbf(8)      'receive 8-bit reply, MSB first

 SPI.shiftout(spi.MSBFIRST, value, 32)      'send 32-bit command, MSB first
 result := SPI.shiftin(spi.MSBFIRST, 32)    'receive 32-bit reply, MSB first

'gp_asm_spi.spin2' should support all 4 SPI modes.

Please test & provide feedback to confirm correct operation under all SPI modes.
Also please suggest code improvements. Thanks.

«13

Comments

  • Hello Greg,

    I've been working with a round 1.28 inch IPS screen (from Waveshare), driven by a GC9A01A controller via SPI. I've been converting their Arduino driver to spin2. Then for the communication via SPI, I started out with JonnyMac's 'jm_ez_spi.spin2', then went to Diez "deets" Roggisch 'deets_spi.spin2', and it seemed like the mode 3 was needed, but I could not get it to work at all, just a black screen. So I turned back to Arduino again and got it working on a ESP-12E NodeMCU (ESP8266), but no success on the P2 Eval RevB board I was running.. then I found this post, and man, was I happy :smile:

    The driver converted from Arduino works now, with this 'gp_asm_spi.spin' for the SPI communication, I was trying to get some good video of the screen in action, but the camera looses focus all the time due to the screen's backlight beeing faded in and out using JonnyMac's 'jm_led.spi', then I guess I dropped something on the Eval board in the middle of this, It now makes a hissing noice, and the left part of the chip is getting hot as soon as I power it up.. The red diode (warning triangle) lights up etc.. Ordered a new one (Rev C) from Mouser, hope it arrives soon, don't know how fast the ship to Sweden, hopefully soon, this was fun stuff to play around with !

    Thank you for publishing this code, It helped alot, awesome !

    The only question I have is about max speed for clock frequence :
    khz is clock frequence in kilohertz (1000 = 1MHz)

    If I run the spin code with:
    CLK_FREQ = 200_000_000 ' system freq as a constant

    What might be the max speed this object/drive might handle, with regards of it using assembly and smart pin etc, if just shuffling out bytes directly from memory?

    Some references if someone wants to use a round 1.28 inch screen with GC9A01A:
    https://www.waveshare.com/1.28inch-lcd-module.htm
    https://www.waveshare.com/wiki/File:LCD_Module_code.zip

    I used this image converter to convert images to the R5G6B5 format:
    https://lcd-image-converter.riuson.com/en/about/

    Many thanks to JonnyMac and Parallax also.

    Best Regards,
    M.E.S.H

  • Kundan_jhaKundan_jha Posts: 17
    edited 2022-09-26 12:27

    Hii, Is it possible to send/Receive 1MByte or 2 MByte of data using SPI protocol with in millisecond? if yes, can anyone help me.

  • @Kundan_jha said:
    Hii, Is it possible to send/Receive 1MByte or 2 MByte of data using SPI protocol with in millisecond? if yes, can anyone help me.

    The data rate needed to move 1 million bytes in 1 thousandth of a second is 1 billion bytes per second (8Gb/s) and this makes no allowance for overhead (commands and addressing)
    Even using 8 lanes in parallel (OPI), this is beyond the capability of the interface you are asking about.

  • evanhevanh Posts: 15,126
    edited 2022-09-26 22:56

    And with only 512 kByte of hubRAM there is limited space to fit such a fast burst too. The two are somewhat linked.

  • Kundan_jhaKundan_jha Posts: 17
    edited 2022-09-27 08:42

    @AJL said:

    @Kundan_jha said:
    Hii, Is it possible to send/Receive 1MByte or 2 MByte of data using SPI protocol with in millisecond? if yes, can anyone help me.

    The data rate needed to move 1 million bytes in 1 thousandth of a second is 1 billion bytes per second (8Gb/s) and this makes no allowance for overhead (commands and addressing)
    Even using 8 lanes in parallel (OPI), this is beyond the capability of the interface you are asking about.

    @AJL said:

    @Kundan_jha said:
    Hii, Is it possible to send/Receive 1MByte or 2 MByte of data using SPI protocol with in millisecond? if yes, can anyone help me.

    The data rate needed to move 1 million bytes in 1 thousandth of a second is 1 billion bytes per second (8Gb/s) and this makes no allowance for overhead (commands and addressing)
    Even using 8 lanes in parallel (OPI), this is beyond the capability of the interface you are asking about.

    OK thanks @AJL @evanh ,
    In my case it is not working properly. May be i am doing some mistake So please once go through my code. I am new in propeller 2 and i don't know spin2 development. So doing my development using C programing. I have taken also help from discussion (https://forums.parallax.com/discussion/174747/spi-communication-between-parallax-p2-and-raspberry-pi#latest).

    #include "spi-c.h"
    
    #define CS 32
    #define CLK 33
    #define MOSI 34
    #define MISO 35
    
    unsigned char data[4096];
    enum { _clkfreq = 200000000 };
    
    
    int my_shift_in(void)
    {
        int count = 0;                                              // bytes received
        while(_pinr(CS) == 1);                                      // wait while CS high
        _pinl(MOSI);                                                // enable smart pin SPI RX
        while(_pinr(CS) == 0) {                                     // while CS is low
            if (_pinr(MOSI))                                        // if byte waiting
                data[count++] = _rev(_rdpin(MOSI));                  //  read, fix MSB, save to array
        }
        _pinf(MOSI);                                                // disable/reset SPI RX
       return count;
    }
    void main() {
        DIRA = 0;
        int m = 0, x = 0, ret = 0;
        DIRA |= MOSI ;
        _pinclear(CS);
        m = P_SYNC_RX;
        m |= ((CLK-MOSI) & 0b111) << 24;
        x = 0b0_00000 | (8-1);
        _pinstart(MOSI, m, x, 0);
        while(1){
                ret = 0;
                ret = my_shift_in();
                if(ret>0)
                        for(int i = 0; i<ret; i++){
                             printf("%d ",data[i]);
                                }
        }
    } 
    
    
  • evanhevanh Posts: 15,126
    edited 2022-09-27 10:48

    Ah, yes, there was a pending unanswered question for you in that topic. What is the desired SPI clock mode (CPOL/CPHA) of the RPi?

    If you don't know then it probably also still need set at that end.

  • @evanh said:

    Ah, yes, there was a pending unanswered question for you in that topic. What is the desired SPI clock mode (CPOL/CPHA) of the RPi?

    If you don't know then it probably also still need set at that end.

    Hi @evanh ,
    In Rpi side, we are using default spi clock mode 0. (CPOL = 0, CPHA = 0) but in P2 we don't know how to set SPI clock modes using smart pin.

  • evanhevanh Posts: 15,126
    edited 2022-09-28 10:37

    Good. That's what the smartpin expects by default. Receiving should just work.
    I should setup something here myself. I've not tried to connect a Prop2 as a slave device.

    PS: Did you ever try my last posted source code?

    PPS: I'm assuming the RPi has real hardware controller for SPI. As in it shifts data out on falling edge in mode 0 above. That's how a master normally functions. It's the slave that's expected to shift in on rising edge. Just there isn't any hard standard that says the master must do that.

  • @evanh said:
    Good. That's what the smartpin expects by default. Receiving should just work.
    I should setup something here myself. I've not tried to connect a Prop2 as a slave device.

    PS: Did you ever try my last posted source code?

    PPS: I'm assuming the RPi has real hardware controller for SPI. As in it shifts data out on falling edge in mode 0 above. That's how a master normally functions. It's the slave that's expected to shift in on rising edge. Just there isn't any hard standard that says the master must do that.

    Yes i've tried your shared source code with our setup. We are getting garbage data. I have printed the returning value of count you can see in below mentioned code. The count value varies every time.

    For example,
    I have sent a buffer of 256 Bytes from Rpi. sometimes getting count value = 256 but most of time getting different count value at a time. you can see in attached image.
    And when i am increasing the buffer size to 512Bytes and more, then every time getting different count values.

    #include <stdio.h>
    #include "spi-c.h"
    
    enum {
        // _xinfreq = 20_000_000,
        _xtlfreq = 20_000_000,
        _clkfreq = 350_000_000,
        DOWNLOAD_BAUD = 200_000,
        DEBUG_BAUD = DOWNLOAD_BAUD,
    
    };
    unsigned char data[4096];
    
    int my_shift_in(unsigned char *addr)
    {
        int data, count = 0;    // bytes received
    
        __asm volatile { // no optimising and enforces Fcache use - Needed to free up the FIFO
            fltl    #MOSI    // disable/reset SPI RX
    .wait1
            testp   #CS   wc
        if_nc   jmp #.wait1    // wait while CS low
    
            wrfast  #0, addr    // setup the hubRAM FIFO hardware for sequencial writes
            dirh    #MOSI    // enable smart pin SPI RX
    .wait2
            testp   #CS   wc
        if_c    jmp #.wait2    // wait while CS high
    
            rep @.rend, #0    // loop forever
    
            testp   #CS   wz
            testp   #MOSI   wc
    if_nc_and_z jmp #.rend    // break loop if CS high
        if_c    rdpin   data, #MOSI   // collect the received byte
        if_c    rev data
        if_c    wfbyte  data          // write to FIFO (hubRAM)
        if_c    add count, #1
    .rend
    
            dirl    #MOSI    // disable/reset SPI RX
        } // returning from Fcache (cogexec) issues an implicit RDFAST (flushing the FIFO to hubRAM)
    
        //return count;
        printf("%d\n",count);
    }
    
    
    void main() {
        _waitms(200);
        printf( "\n   clkfreq = %d   clkmode = 0x%x\n", _clockfreq(), _clockmode() );
    
        DIRA = 0;
        int m = 0, x = 0, ret = 0;
        DIRA |= MOSI;
        _pinclear(CS);
        m = P_SYNC_RX;
        m |= ((CLK-MOSI) & 0b111) << 24;
        x = 0b0_00000 | (8-1);
        _pinstart(MOSI, m, x, 0);
        while(1){
                ret = 0;
                ret = my_shift_in(data);
               // if(ret>0)
                 //       for(int i = 0; i<ret; i++){
                 //            printf("%d\n",data[i]);
                  //      }
        }
    }
    
  • evanhevanh Posts: 15,126
    edited 2022-09-28 12:47

    Dunno, I guess I have to set up a test ...

  • @evanh said:
    Dunno, I guess I have to set up a test ...

    Thanks @evanh, This will be really helpful for me because I'm stuck right now.

  • evanhevanh Posts: 15,126
    edited 2022-09-29 12:35

    I've written software for SPI master now but my second micro USB cable is at customer site, as is the soldering station and oscilloscope ...

    EDIT: Testing on self, using two cogs, is working as expected. I've reused part of my recent PSRAM work to produce an ideal SPI mode0 output signal. Whereas a smartpin's Sync TX mode is known to phase lag by a few sysclocks.

       clkfreq = 4000000   clkmode = 0x10005eb
     Byte count = 404
    02 00 0b 44 90 8f 8e 8d 8c 8b 8a 89 88 87 86 85 84 83 82 81 80 7f 7e 7d 7c 7b 7a 79 78 77 76 75 74 73 72 71 70 6f 6e 6d 6c 6b 6a 69 68 67 66 65 64 63 62 61 60 5f 5e 5d 5c 5b 5a 59 58 57 56 55 54 53 52 51 50 4f 4e 4d 4c 4b 4a 49 48 47 46 45 44 43 42 41 40 3f 3e 3d 3c 3b 3a 39 38 37 36 35 34 33 32 31 30 2f 2e 2d 2c 2b 2a 29 28 27 26 25 24 23 22 21 20 1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0 ef ee ed ec eb ea e9 e8 e7 e6 e5 e4 e3 e2 e1 e0 df de dd dc db da d9 d8 d7 d6 d5 d4 d3 d2 d1 d0 cf ce cd cc cb ca c9 c8 c7 c6 c5 c4 c3 c2 c1 c0 bf be bd bc bb ba b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 af ae ad ac ab aa a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 9f 9e 9d 9c 9b 9a 99 98 97 96 95 94 93 92 91 90 8f 8e 8d 8c 8b 8a 89 88 87 86 85 84 83 82 81 80 7f 7e 7d 7c 7b 7a 79 78 77 76 75 74 73 72 71 70 6f 6e 6d 6c 6b 6a 69 68 67 66 65 64 63 62 61 60 5f 5e 5d 5c 5b 5a 59 58 57 56 55 54 53 52 51 50 4f 4e 4d 4c 4b 4a 49 48 47 46 45 44 43 42 41 40 3f 3e 3d 3c 3b 3a 39 38 37 36 35 34 33 32 31 30 2f 2e 2d 2c 2b 2a 29 28 27 26 25 24 23 22 21 20 1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 
    
  • evanhevanh Posts: 15,126

    I guess I should advise same as with Chintan, it's possible I didn't need to do this demo. You may just need to update to newest Flex compiler - https://forums.parallax.com/discussion/comment/1543685/#Comment_1543685

  • @evanh said:
    I've written software for SPI master now but my second micro USB cable is at customer site, as is the soldering station and oscilloscope ...

    EDIT: Testing on self, using two cogs, is working as expected. I've reused part of my recent PSRAM work to produce an ideal SPI mode0 output signal. Whereas a smartpin's Sync TX mode is known to phase lag by a few sysclocks.

       clkfreq = 4000000   clkmode = 0x10005eb
     Byte count = 404
    02 00 0b 44 90 8f 8e 8d 8c 8b 8a 89 88 87 86 85 84 83 82 81 80 7f 7e 7d 7c 7b 7a 79 78 77 76 75 74 73 72 71 70 6f 6e 6d 6c 6b 6a 69 68 67 66 65 64 63 62 61 60 5f 5e 5d 5c 5b 5a 59 58 57 56 55 54 53 52 51 50 4f 4e 4d 4c 4b 4a 49 48 47 46 45 44 43 42 41 40 3f 3e 3d 3c 3b 3a 39 38 37 36 35 34 33 32 31 30 2f 2e 2d 2c 2b 2a 29 28 27 26 25 24 23 22 21 20 1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0 ef ee ed ec eb ea e9 e8 e7 e6 e5 e4 e3 e2 e1 e0 df de dd dc db da d9 d8 d7 d6 d5 d4 d3 d2 d1 d0 cf ce cd cc cb ca c9 c8 c7 c6 c5 c4 c3 c2 c1 c0 bf be bd bc bb ba b9 b8 b7 b6 b5 b4 b3 b2 b1 b0 af ae ad ac ab aa a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 9f 9e 9d 9c 9b 9a 99 98 97 96 95 94 93 92 91 90 8f 8e 8d 8c 8b 8a 89 88 87 86 85 84 83 82 81 80 7f 7e 7d 7c 7b 7a 79 78 77 76 75 74 73 72 71 70 6f 6e 6d 6c 6b 6a 69 68 67 66 65 64 63 62 61 60 5f 5e 5d 5c 5b 5a 59 58 57 56 55 54 53 52 51 50 4f 4e 4d 4c 4b 4a 49 48 47 46 45 44 43 42 41 40 3f 3e 3d 3c 3b 3a 39 38 37 36 35 34 33 32 31 30 2f 2e 2d 2c 2b 2a 29 28 27 26 25 24 23 22 21 20 1f 1e 1d 1c 1b 1a 19 18 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 
    

    Hii @evanh ,
    I have tested this code with our Rpi and P2 setup in flexProp (version 5.9.17).
    I am seeing that, when i am changing the frequency of Rpi (Previously was 5Mhz) to 1Mhz and buffer size set to 256 bytes where P2 frequency is 4Mhz then sometimes I'm getting correct data and if i increasing the buffer more then 256 bytes (ex: 512Bytes, 1024 Bytes .. ) then data getting mismatched . I have also tried with different frequency ranges but result getting same.

  • evanhevanh Posts: 15,126
    edited 2022-09-30 09:40

    The RPi might be the problem then.

    PS: I'm planning on testing with two independent boards with different clock sources using a short SPI link between them tomorrow, ~12 hours time.

  • evanhevanh Posts: 15,126
    edited 2022-09-30 10:21

    Here's another test self edition that is doing a 4000 byte block copy using random data over 1-bit SPI at 25 MHz SPI clock rate, then comparing each byte (longwords more accurately) between the copies.

       clkfreq = 200000000   clkmode = 0x10009fb
     Byte count = 4004    Mismatch count = 0
    
  • evanhevanh Posts: 15,126

    Oh, there is a streamer limit of 64 k transfer cycles per command. That means current max block transmit length is 8 kbytes.

  • evanhevanh Posts: 15,126
    edited 2022-10-01 03:11

    Okey-dokey, it's amazing how different the behaviour is when linking two boards! Noise looms large! First attempt was almost like random data, but not quite. The incrementing count data did show through a little.

    First fix was to switch on registered I/O ... bam! perfect outcome. It felt too good to be whole answer though. It's gotta be telling ... Clearly a sampling aliasing thingy. So, on that note, next angle is to engage the debounce hardware circuits ... and the built-in Schmitt Trigger circuits too ... oh, yeah, Schmitt Triggers are the big fix.

    So, ground bounce is likely your big problem. The hard digital edges are so strong the cable can't hold a steady ground reference. Lowering the pin drive strength could be an improvement ... Another approach is go differential pairs. That removes the pin drivers from inducing ground bounce.

    I've tested both now. Prop2 can do either without any interfacing chips. Longer cables will require differential wiring. Shorter cables can get away with just Schmitt Trigger.

  • evanhevanh Posts: 15,126
    edited 2022-10-01 08:52

    Here's the RX programs. You'll need to modify them or your TX program to suit the pinout and compare function. My TX program adds four bytes to the start of the data block.

    EDIT: Err, I've got a smartpin repetitive sequencing problem I think ...
    EDIT2: Intriguing, seems I'm getting some sort of clocking issues when RX sysclock is at or above 300 MHz. Doesn't matter what I do with input filtering. Not sure ...
    EDIT3: Grr, the streamer/FIFO in my TX program is doing something very unexplainable but very repeatable ...

    EDIT4: Working around the streamer issue for the moment - Schmitt inputs are definitely far faster than comparator inputs. I've gone to 100 Mbit/s with Schmitt inputs - Nyquist aliasing limit is rearing up above this rate. Differential input signalling using comparator inputs fades into noise above 35 Mbit/s. Which means my above assertion about Prop2 being natively good for differential inputs is not correct.

    EDIT5: Bah! It is the RX smartpin sequencing after all. Enabling it early is glitchy on first data. It's reliable afterwards though since that was my workaround - repeat the same packet.

  • jmgjmg Posts: 15,140

    @evanh said:
    So, ground bounce is likely your big problem. The hard digital edges are so strong the cable can't hold a steady ground reference. Lowering the pin drive strength could be an improvement ... Another approach is go differential pairs. That removes the pin drivers from inducing ground bounce.

    I've tested both now. Prop2 can do either without any interfacing chips. Longer cables will require differential wiring. Shorter cables can get away with just Schmitt Trigger.

    I've found a series ~120R drive side resistor can help push up workable cable lengths, as the Pi-side will likely lack fine driver strength control.

    Maybe this thread can be split, as the OP posted example code in 2021 then another poster asked a Rpi specific use question ?
    I'm not sure if the poster in the other thread, is the same as this one ?

  • evanhevanh Posts: 15,126
    edited 2022-10-01 10:28

    Right, took some troubleshooting but got it robust now. I've had to revert to the original late enable of the smartpin. It's too easy for the smartpin to collect spurious clock pulses otherwise. As a result I've now engaged the use of SE4 event source to minimise the time between CS falling and the smartpin getting enabled.

    Enjoy

    EDIT: Got an idea already :) ... use the A/B logic on the clock input ... nope, that didn't work. %FFF logic function doesn't carry to other smartpins. duh.

    PS: At 300 MHz sysclock, and as a guess, this current approach probably needs about 10 ns between CS falling and first rising clock. If the RPi is quicker than that then it'll be a mess due to the smartpin being disabled during the first SPI clock pulse.

  • evanhevanh Posts: 15,126

    @jmg said:
    I've found a series ~120R drive side resistor can help push up workable cable lengths, as the Pi-side will likely lack fine driver strength control.

    You reminded me to double check my earlier finding ... turns out none of the those noise reduction fixes are actually needed. I'll keep them in place though.

    Everything comes back to the TX pin initialising conditions. The RX program could pick up spurious clocks which resulted bytes being offset. Because earlier I was only testing a single block per compile/run meant I was getting good and bad results in varying amounts. Had me chasing my tail. :( Things only came together after I was looping the TX rpogram to send multiple data blocks.

    Doesn't clearly explain why shorter blocks tended to have better outcomes but I do know shorter wasn't any guarantee of a pass.

  • evanhevanh Posts: 15,126
    edited 2022-10-02 00:36

    Got an update that should handle the tightest clock start on CS falling. It requires building flexspin from today's bug fix though - https://forums.parallax.com/discussion/comment/1543804/#Comment_1543804

    EDIT: Extra comments in source

  • @evanh said:
    Got an update that should handle the tightest clock start on CS falling. It requires building flexspin from today's bug fix though - https://forums.parallax.com/discussion/comment/1543804/#Comment_1543804

    EDIT: Extra comments in source

    @evanh said:
    Got an update that should handle the tightest clock start on CS falling. It requires building flexspin from today's bug fix though - https://forums.parallax.com/discussion/comment/1543804/#Comment_1543804

    EDIT: Extra comments in source

    Hii @evanh ,
    I have testing this source code. Here, I'm not getting count value. This spi_shift_in() function not returning count . I have also checked my hardware (may be issue in wiring) and from old code I'm getting the count value(not correct).

  • evanhevanh Posts: 15,126
    edited 2022-10-04 12:01

    I gather that means you've compiled Flexspin yourself? If not then that program will be buggy. It'll do random things as it is truly crashing from the JSE2/JNSE1 instructions branching off to unknown addresses.

    You'll need to check over the ENUMs. I've not tried to follow your setup so the pins won't suit.

    The file posted a few posts back named "spi_shiftin_Schmitt.c" is limited to minimum clock delay of 33 ns after CS falling edge, not the guessed 10 ns I'd posted with it.

    The newer "spi_shiftin.c" handles at least down to 5 ns. That's the fastest I tested (100 Mbit/s), just completed now, with a crafted streamer data pattern containing all three pins to control those timings. It should be fine even at 0 ns.

  • evanhevanh Posts: 15,126
    edited 2022-10-04 12:26

    What the latter program won't handle is a pre-ambled continuous clock leading CS falling. At least not at speed. I don't think proper SPI controllers ever do that though.

  • evanhevanh Posts: 15,126

    Here's a patched version of the latter program that compiles correctly with the unfixed Flexspin:

  • evanhevanh Posts: 15,126
    edited 2022-10-08 14:29

    Grr, that's still not reliable with tight start timing. It can miss the start CS low edge somehow, I'll try using level event instead of edge event ...

    EDIT: Okay, looks like it's more about the CLK event getting tied up on fast toggling before the CS event can get a leg in. I've replaced the SE2 event with a PAT event instead. It's behaving correctly now with the more substantial testing today. Have to say, SETPAT is a little messy to use though.

    EDIT2: Added the partnering tx shiftout.c that produces the tight timings of full SPI Master hardware, and the patched rx shiftin.c that compiles correctly with current release of Flexspin.

  • evanhevanh Posts: 15,126

    Man, it's a lot of detail to manage that single state change in a timely manner. I never imagined handling SPI Slave operation would need such attention using a smartpin. I've learnt now that a bit-shifter without a reset input fails the minimum SPI requirement. In hindsight, no wonder it didn't work initially.

  • evanhevanh Posts: 15,126
    edited 2022-10-09 13:36

    The weirdest thing ... I can't replicate the mishandled CLK glitches any longer. I've gone back to post #24 and removed the deglitcher code. So now it just simply waits for CS low to start. It works nice and clean.

    Must be the tx program working better maybe ... yep, an intentionally inserted CLK glitch during CS high does the job of fooling the rx code when the deglitcher is missing.

Sign In or Register to comment.