I have the following capture.zip (full capture attached) which was analyzed with the SPI analyzer using CPOL=0 and CPHA=0:
I marked in red the rising edges, which would equate to: 11010001 = 0xD1, but the analyser shows 0xE8 == 11101000 which could be happening if it would sample one bit before the first rising edge, while MOSI is already pulled high. The following analysed bytes seem to be shifted by one bit per byte analyzed before them.
(starting on the 9th clock I get: 10101011 == 0xAB, the analyzer shows 0xEA == 11 101010 (no idea where the second 1 at the beginning comes from, I would just expect one extra one since its missing from the previous byte) after that the analyzer shows 0xE0 (11100000, which again has an extra 1 I cannot explain), i.e. if you shift it by two we get to 10101011 == 0xAB)
The actual bytes that were sent (in the first transaction) are 0xD1, 0xAB 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEE, 0x7F
Used version, running on Windows:
(as downloaded from the Releases)
Hi,
I have the following capture.zip (full capture attached) which was analyzed with the SPI analyzer using CPOL=0 and CPHA=0:
I marked in red the rising edges, which would equate to: 11010001 = 0xD1, but the analyser shows 0xE8 == 11101000 which could be happening if it would sample one bit before the first rising edge, while MOSI is already pulled high. The following analysed bytes seem to be shifted by one bit per byte analyzed before them.
(starting on the 9th clock I get: 10101011 == 0xAB, the analyzer shows 0xEA == 11 101010 (no idea where the second 1 at the beginning comes from, I would just expect one extra one since its missing from the previous byte) after that the analyzer shows 0xE0 (11100000, which again has an extra 1 I cannot explain), i.e. if you shift it by two we get to 10101011 == 0xAB)
The actual bytes that were sent (in the first transaction) are 0xD1, 0xAB 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEE, 0x7F
Used version, running on Windows: (as downloaded from the Releases)