• 'store data you want to print in some variable or array and print it at a later point'

    That is in fact what I am doing, an array and indexer, adding only one line of code to Gordon's #8. On CD low set array index to zero, inc when clocking in bits with second setWatch(). I print to the console on/after raised CS detection.


    And now the really bizarre . . . . One can not make this stuff up!!

    Using Gordon's #15 and adding a setInterval() as explained in #21

    I sent a bit stream at a one second interval that has an easy to detect bit inversions in the stream:

    const CMD = 0xD6;    // 1101 0110
    const DAT = 0x37;    // 0011 0111
    
        spi.write([CMD,DAT]);
    

    Endless stream of these repeating pairs: (as expected)

    Got 214
    Got 55
    

    Walked away for a half hour to run an errand.

    Upon return, without any intervention by me, the WebIDE is now reporting instead:

    Endless stream of these repeating pairs: (incorrect)

    Got 190
    Got 177
    

    Quickly checked PulseView and it is reporting 0xD6 0x37 (as it should)

    Rechecked with new runs two more times!! Master is sending correctly as PulseView reveals this to be true.

    The slave is suspect as the data is now not being decoded correctly, and mirrors what I observed over the weekend with different #8 code snippet and setWatch.

    What is being sent and originally decoded
    
    11010110    0xD6   214
    00110111    0x37    55
    
    What now is being detected
    
    10111110    0xBE   190
    10110001    0xB1   177
    

    It is this inconsistency that is driving me nuts and making coding this a chore. A one second pause to 200usec of data duty cycle shouldn't have an effect.

    Could setWatch() have an internal counter that eventually rolls over in the middle of parsing bits. Say at count 65530 the seventh bit inclusion resets and then starts at zero rather than continuing for the seventh and eighth bits?


    Speculation anyone???

About

Avatar for Robin @Robin started