SPI communication sometimes takes too much time for reading sensor thread
iluxa opened this issue · comments
This code slows down
_receiveEvents(now);
_processSPIRequests();
It seems separate thread for SPI needed or async SPI API
@begodev Since send to SPI can require 17ms, is it not hard to implement async communication with SPI? For example send, then poll time to time whether it sent?
@begodev Since send to SPI can require 17ms, is it not hard to implement async communication with SPI? For example send, then poll time to time whether it sent?
Yes it is possible, but please note that "send" actually performs a full transfer sequence: send request and wait for response.
And "receive" just returns the buffered answer from the board.
During whole transfer sequence it is necessary to provide a SPI clock on the bus. Then poll function should be responsible for SPI clock. Also the CS should be released at the end of the transfer. It is all done inside the "send" atm
PR: #64
neet to test whether button works after this change
neet to test whether button works after this change
Which button do you mean?
What communication speed should be normal?
Which button do you mean?
button state wich received from json event je>
What communication speed should be normal?
shouldn't no be any information skip (without burst and without resampling) - 48K samples/s
@begodev got pretty strange behavior on testing - pressing button leads to laggy led after that. looks like button creates issue here - plz ping me for further clarification and testing
@IngoKaiser Set of m_upd_tspan_mS was rolled back. Possibly it was a reason of laggy led.
Control of delays after switching LED modes will be improved along with NewMenuStructure.
The new firmware is flashed @ 10.0.0.8