Perhaps I can save someone a bit of time.
I have the BNO080 working very well over SPI. Code is in the "old" directory here https://github.com/BBUK/Bell-Boy
, specifically BNO080.h and grabber.c. Whilst the latter file is really specific for my use case (monitoring a rotating tower bell), much of the code will probably be useful for anyone interested in the BNO080. Nonetheless, for the convenience of anyone interested, I have a more generalised version in BNO080-general.c.
For SPI, the PS1 pin should be pulled high and the the PS0/WAKE, HINT and RESET pins should be brought to the PI's GPIO. See the setup() function for more details.
It uses the bcm2835 library for GPIO control and for SPI https://www.airspayce.com/mikem/bcm2835/
Low level communication with the BNO080 is handled by the sendPacket() and collectPacket() functions. These are modified forms of the equivalent functions in the bcm2835 library as my reading of the BNO080 datasheet is that if you are sending a packet over SPI you need to be able to handle receiving a packet (of different, perhaps longer, length) in the same transaction.
Note that the code is under quite active development so will change quite a bit but the low level functions will probably not change.
Note that the BNO080 communicates asynchronously. You set up a "feature report" (eg for the Game Rotation Vector) to be sent at a particular rate. You could also ask for another report (eg Stability Classifier) to be sent at a different rate. When the BNO080 is ready to send something, it will bring HINT low and then the master (i.e. the Pi) will start a SPI transaction. The packet will have to be analysed to work out which report it was for or whether it was for something else (eg an error). Because of this I have had to implement FIFO buffers and rate matching for the reports which added quite a lot of complexity.
Watch one particular thing - if you ask for a report to be sent at a particular rate the BNO080 may indicate (in a "Feature Response" packet that it will actually be sending at a different rate more convenient for it. Different sensors on the IC operate such that the convenient rates don't often coincide. You can't, for example, have both the Game Rotation Vector and the main accelerometer reports at 400 times per second.
I am still exploring the capabilities of this IC but I am really impressed by the quality of the rotation vectors produced.
EDIT: changed filenames