I found this on a google site
Some new update after a day, the code r = spi.xfer2([1,(8+adcnum)<<4,0])
could be altered like this r = spi.xfer2(
- ,speed_hz,delay_usecs,bits_per_word) if you put 0 for delay_usecs nothing happens it still 220us delay
if i put 1000 in delay_usecs the delay is 1220us.
This means that the pi is deciding when SPI get to communicate. Howe to work around this i still don't know
So I tried it and it and xfer2() does accept these arguments.
Whether they are doing anything or not is anothe matter.
I tested my setup which is getting 12 bytes of data from the Arduino along with a one byte checksum
Here are the results for % errors at different speeds using a small sample of 100 tries each
speed 150,000 14.5 %
speed 250,000 12.2 %
speed 1,000,000 20.0 %
Here are the results using a speed of 250,00hz and different udelay
udelay 220 12.2 %
udelay 440 10.7 %
udelay 880 16.6 %
The figures look to be nearly the same within the experimantal error of the test (eg doing the 880 delay again I got 13.9%)
So unless anybody can tell me how to reduce the error rate I will live with it and get on with life.