Update pmw3360 driver after reading the datasheet top to bottom. Fix some outdated refs.

[uqs]

Update pmw3360 comments to match the datasheet better, fix delays.

We should de-assert NCS after waiting for tSCLK-NCS, so move spi_stop()
around a little. This was missed in PR#11519.

I'm less certain about adding the (quite long) tSRAD delay, but the
datasheet clearly indicates so. Not sure how this worked before, but we
don't actually use the read function, but read_burst instead. Only the
init phase and get_cpi() would be affected, and no one uses get_cpi,
only set_cpi, of course.

Also use the more natual spi_read() to discard the observation data,
this also saves 2 bytes in the firmware :)

Remove references to the no longer existing pmw_set_cpi, and use
pointing_device_set_cpi like in all other pointing devices

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[uqs]

@Alabastard-64 ping! Curious to know what you think of the tSRAD sleep as well as ordering fixes (and because it also relates to you pmw3389 driver)

[uqs]

I'm actually curious and want to do some timing tests to see if spi_read() happens to somehow wait for all bits to arrive.

hid_listen doesn't quite work on FreeBSD though and I'm not sure how accurate I can print timers on the console, but give me a week or so to verify.

I'm also curious what the possible rate of updates is for this sensor. Not that I'm gonna use it for gaming, but I do wonder if 1ms USB polling even makes sense for it (and they actually call it a "gaming sensor") ...

[drashna]

Can confirm that it works and doesn't break anything.

[uqs]

Soooo, good news / bad news. I did some testing w/o the 160us delay, and the read then often returns garbage, e.g. 9700 cpi instead of the 100 cpi I was setting before:

(this is with me still using TCNT0, so 1ms resolution):

uuget_cpi took: 0 ms 1 ticks: cpi uis 100
get_cpi took: 0 ms 1 ticks: cpi is 100
get_cpi took: 0 ms 0 ticks: uucpi is 100
get_cpi took: 0 ms 1 uticks: cpi is 100
get_cpi took: u1 ms 1 ticks: cpi is 9700
get_cpi took: 0 ms 1 ticks: cpi is 6500
uget_cpi took: 0 ms 1 ticks: cpi uis 9700
get_cpi took: 1 ms 1 ticks: cpi is 100
uget_cpi took: 0 ms 1 ticks: cpi uis 100
get_cpi took: 0 ms 1 tickus: cpi is 100
get_cpi took: 0 msu 0 ticks: cpi is 100
get_cpi took: 0 ms 1 ticks: cpi is 100
uget_cpi took: 0 ms 1 ticks: cpi uis 100
get_cpi took: 0 ms 1 tickus: cpi is 100
get_cpi took: 0 ms 1 ticks: cpi is 100
uget_cpi took: 0 ms 1 ticks: cpi uis 100
get_cpi took: 0 ms 1 tickus: cpi is 100
get_cpi took: 0 ms 0 ticks: cpi uis 9700

ignore the stray us in there, that's the key that triggers a get_cpi call.

Then I started using the TCNT3 timer with a 64 scaler, so I think that should work out to 4us per tick (16MHz controller). The no-delay read then takes about 13 or 14 ticks.
And the read with 160us delay takes about 53-54 ticks, but it always returns the correct value, so that's plus! :)
Anyway, that's a delay of 40 ticks, which matches my 4us per tick delay to come up with the 160us sleep. I think the math is sound here.

The bad news? I'm pretty sure the ADNS9800 driver also does this wrong, but I have no hardware to test this on.