Posts: 25
Joined: Sun Sep 24, 2017 1:38 pm

BNO080 Integration (Hillcrest FSM300)

Fri Oct 27, 2017 4:28 pm

I have recently purchased one of these MCUs:

Communicating with it over the I2C bus seems challenging. The documentation discusses a layers of protocol (SH-2 and SHTP) which run over the top of I2C, but for now I just want to be able to read the information provided at boot time.

I can see the device boot and assert the INTN signal as expected. I can then do a normal read which returns 0x14. I haven't found a register that is accessible either. The following statement in the user guide is probably the reason this isn't working.
Repeated starts to the I2C address of an SHTP-enabled hub are not supported. Each SHTP transfer must end with a STOP condition.
Does anyone have any experience with this or anything simiar?

Failing that, how can I read more than one byte at a time from an I2C address?

Posts: 25
Joined: Sun Sep 24, 2017 1:38 pm

Re: BNO080 Integration (Hillcrest FSM300)

Mon Oct 30, 2017 1:24 pm

Update: I have successfully mastered the read from i2C thanks to this post: ... user-land/

The solution was to use the basic "read" command on the file handle returned by ioctl.

To explain why the likes of wiringPi and other code were not working I'll make reference to ... c-protocol and ... s-protocol

The pattern I need to generate to successfully read from this chip was:
S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P

However, the smbus commands to read multiple bytes always have a write first, without an intervening STOP (P) bit
S Addr Wr [A] Comm [A] S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P

Posts: 1
Joined: Thu Sep 06, 2018 7:00 pm

Re: BNO080 Integration (Hillcrest FSM300)

Thu Sep 06, 2018 7:03 pm

-Hi, How did you use the i2c-protocol to write to an specific register? Or to read from an specific resgister? I'm also working with the BNO080, but i still can't communicate with it.

Posts: 2
Joined: Wed Nov 07, 2018 3:08 pm

Re: BNO080 Integration (Hillcrest FSM300)

Tue Nov 20, 2018 10:35 am


I'm also trying to interface with the BNO080 and thought I'd share what I've learned so far.

Seeing that I'm also having trouble communicating with the sensor, I contacted Hillcrest's technical support and they told me that:
Unfortunately, Raspberry Pi kernel doesn’t support I2C clock stretching, which is required for BNO080 in I2C mode operation. More information is available in ( ... c-bug.html). You can use BNO080 in other modes, UART-SHTP or SPI.

In addition to it, they suggested I have a look at and, where they have a demo source code interfacing with an STM32F4xx board (SH2 being the special communication protocol from Hillcrest).

What is to be done is write our own sh2_hal.c that will implement 5 functions: open/close comms with the device, read/write and a microsecond counter (more details in sh2_hal.h). In the 1st Github link I shared they provide examples for the Nucleo board through I²C, SPI and UART, and I'm currently trying to implement my own for the 3 B+. If anyone has also tried to do so, please let me know! :)

Posts: 141
Joined: Tue Dec 18, 2012 10:34 am

Re: BNO080 Integration (Hillcrest FSM300)

Wed Nov 21, 2018 3:20 pm

Hi all.

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, 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

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.

Have fun


EDIT: changed filenames

Posts: 10
Joined: Thu Sep 24, 2015 12:31 pm

Re: BNO080 Integration (Hillcrest FSM300)

Tue Apr 09, 2019 3:41 pm

Regarding problems with the I2C I have use the software i2c with the BNO055 without problems. Take a look here ... to see how to activate it. For use it I've used wiringpi as interface with i2c

Now I'm looking to use BNO080, can you tell me your experience?

Return to “Interfacing (DSI, CSI, I2C, etc.)”