Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 3862

General • Re: Is SPI Slave (on Pico2) still fubar'ed?

$
0
0
P.S. I got my phases and polarities sorted out (both using polarity 1 and phase 1 now) and could perform a load test of data over SPI (Pi4 <----> Pico, jumper cables of 10 cm lengh). Each test involved 1000 transmissions of a buffer sized 128 bytes. The bus master sent buffers of repeating "AB" and the peripheral slave sent buffers of repeating "ab". Both were C programs. The master used "pigpio" and lived in happy ignorance of the CS pin (but I have used a logic analyzer before and I know that "pigpio" raises the line before starting to transmit, but doesn't toggle the line up and down repeatedly, as far as I can remember). The peripheral was aware of the CS line via issuing:

Code:

bi_decl(bi_4pins_with_func(PICO_DEFAULT_SPI_RX_PIN, PICO_DEFAULT_SPI_TX_PIN, PICO_DEFAULT_SPI_SCK_PIN, PICO_DEFAULT_SPI_CSN_PIN, GPIO_FUNC_SPI));
Results:
- I had the program classify buffers into good ("ab"), shifted ("ba"), bad (something else) and ugly (incorrect size)
- the peripheral (Pico) hears the master considerably better than the master (Pi4) hears the peripheral
- up to 500 000 Hz, near perfect reception was ruined only by going out of sync, that is, receiving "ba" instead of "ab"
- at 4 000 000 Hz, approximately 50% of buffers were garbled in ways unforeseen
- remarkably, at no time did I receive a buffer of incorrect size

Numeric results:

Code:

speed 32 000:master rx: GOOD 1000  SHIFTED 0  BAD 0  UGLY 0slave rx: GOOD 1  SHIFTED 997  BAD 2  UGLY 0speed 100 000:master rx: GOOD 10  SHIFTED 979  BAD 1  UGLY 0slave rx: GOOD 990  SHIFTED 8  BAD 2  UGLY 0speed 500 000:master rx: GOOD 10  SHIFTED 979  BAD 1  UGLY 0slave rx: GOOD 990  SHIFTED 8  BAD 2  UGLY 0speed 1 000 000:master rx: GOOD 651  SHIFTED 291  BAD 38  UGLY 0slave rx: GOOD 307  SHIFTED 581  BAD 112  UGLY 0speed 2 000 000:master rx: GOOD 614  SHIFTED 271  BAD 75  UGLY 0slave rx: GOOD 307  SHIFTED 543  BAD 150  UGLY 0speed 4 000 000:master rx: GOOD 508  SHIFTED 233  BAD 169  UGLY 0slave rx: GOOD 67  SHIFTED 435  BAD 498  UGLY 0
My current plan is for the code to search for a start marker in actual data buffers (once I get around to sending actual data), thus circumventing the "loss of sync" effect that I'm seeing. Or maybe going back to using the UART.

Statistics: Posted by diastrikos — Tue Aug 20, 2024 10:53 pm



Viewing all articles
Browse latest Browse all 3862

Trending Articles