UBX GPS SPI Driver causes huge latency spikes on POSIX

[nicolaerosia]

Hello,

The SPI Linux Kernel driver has no way of knowing there's data to be read (this is a limitation of SPI), hence pool will always return true ( https://github.com/PX4/Firmware/blob/master/src/drivers/gps/gps.cpp#L399 ) , causing long lockups of the SPI bus ( https://github.com/PX4/GpsDrivers/blob/dd275f36cb22a82342bdeadf4f66b4f6af03ef92/src/gps_helper.h#L47 ) reading only 0xFF since the device has no data ready to be sent. Unfortunately on Navio2, the GPS shares the same SPI bus with both IMUs and does NOT expose the data ready pin (EXTPIN), see here for more background info: https://community.emlid.com/t/navio2-sensors-schematics/6360

In my opinion, a solution for this would be the following:

• allow the user to specify the GPS Hz
• calculate the expected payload
• start reading
• try to sync a timer which fires when the GPS device has data ready - this may be difficult, if we just start a dumb 5Hz timer, we may get data which is old (worst case 199.99ms)
• try to read a little more, for situations when the scheduler missed the deadline, so we get a chance the dequeue data from internal GPS buffer, we should always stop when we encounter 0xFF.

Any suggestions are welcomed.

[bkueng]

Since we always use 5Hz and this is a specific HW problem, I'd go for something simple, like a (dynamic) usleep(), but I guess there is no really good solution here. If you come up with something sophisticated that works, it's of course fine with me too.

[PX4BuildBot]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)