Go Down

Topic: ESP8266 SPI WiFi Shield ("nice to have") (Read 5461 times) previous topic - next topic

bilekj

Unfortunately, such errors happen. And their probability increases with the bus speed.
There is no relevant documentation to SPI registers in ESP8266 so it is hard to find out the timing errors.
Nevertheless, the protocol implemented over the SPI layer should be robust enough to survive the faults. The bad thing is that ESP8266 may lose incoming SPI message in some cases, one hypothesis is that the inner SPI controller misses the beginning of the transmission. I added a delay between SS down and start of the CLK but it doesn't cover all cases. See also: https://github.com/esp8266/Arduino/issues/5921

ameliaamelia

New test.

espspi_proxy.h:     delayMicroseconds(20); -> delayMicroseconds(xx);

8Mhz
delayMicroseconds(30);
Start:   No errors
Traffic: No errors
10Mhz
delayMicroseconds(30);
Start:   No errors
Traffic: No errors
delayMicroseconds(40);
Start:   No errors
Traffic: No errors
12Mhz
delayMicroseconds(30);
Start:   Some errors
Traffic: No errors
delayMicroseconds(40);
Start:   Some errors
Traffic: No errors
delayMicroseconds(50);
Start:   No errors
Traffic: No errors

The measured response time variations are negligible, so I will use 10Mhz with 50us.

ameliaamelia

ameliaamelia

There are messages:
[espspi_proxy.h: 329] W: Slave tx is not ready, status 0

module espspi_proxy.h:
the _status after line 327 is 0x10.
Temporarily I changed the value of line 72 from 3000 to 50 to avoid a 3s timeout, my applications have a 100ms timeout.

ameliaamelia

Go Up