04-02-2022 01:12 AM
I am trying to communicate BNO055 breakout board directly(without arduino) with cRIO-9074, using I2C protocol. For interfacing bno055 we are using NI-9402 module (DIO0-SCL and DIO1-SDA). I have written a program for both writing data to the slave and reading data from the slave. I have taken care of all the I2C protocols as per I2C specification sheet by NXP semiconductor UM10204. www.nxp.com/documents/user_manual/UM10204.pdf. These are the steps that I have followed for multiple byte write/ read sequence.
1) Start sequence (2) i2c address of BNO055(x28)+w with ack at the 9th clock pulse (3) Internal register address + data (4) Restart the sequence (5) i2c address +R (6) Read Data byte (quaternion registers) (7) Stop sequence
Here is the link for BNO055
https://cdn-shop.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf
Now the issue is, cRIO is not communicating with BNO055.
what to do?
04-03-2022 04:59 AM
@dasabhijit wrote:
Now the issue is, cRIO is not communicating with BNO055.
what to do?
Debug your program. If it doesn't work, something is not as perfect as you claim it to be. Me and most likely anyone else on this board is not going to analyze that code byte for byte to determine if there might be something off.
Another alternative is to actually look for an already implemented solution. NI does have reference designs for I2C and SPI communication for their cRIO models. A little Google foo with a search term like "LabVIEW cRIO I2C" should have turned up for instance this as first result:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019VSSSA2
which links to this page to let you download the examples. It uses VI Package Manager to actually download the package.
"LabVIEW cRIO I2C reference design" brings you to this page:
In there they talk about the I2C standard and also mention in the end "Using NI Reconfigurable Hardware and LabVIEW FPGA with I2C Devices" which points to this:
https://forums.ni.com/t5/Examples-and-IP-for-Software/I2C-IP/ta-p/3491271
and gives you also a link to that VI Package Manager package download.
Now this is a reference design, highly configurable and while tested there are still many ways you can go wrong, but it is a design that has already worked (I have used it in somewhat modified form myself in the past) so you can concentrate a bit more on the actual task.
But from my experience, building such an interface even if you have this already existing library, without a good digital oscilloscope to capture the actual signal lines and analyze them for exact right form, is similar to trying to find an easter egg in a big forest with your eyes blindfolded. 😀
So if you haven't the right hardware to debug this, you might first have to consider how to actually make a test setup that lets you proof that you are generating the signal that you believe to generate in your code (and that the logic levels are right, the slopes correct, the timing accurate, etc. etc.)