nRF52 implementation

[robcazzaro]

Reminder that I need to publish what I did in my Github repository. But needs a bit of cleanup. I'm not sure when I'll get to create a clean project I can upload, though. If you want to get started, here's

I used the bhy2. files unchanged. Then I used the common.c/h files in https://github.com/BoschSensortec/BHY2-Sensor-API/tree/master/examples/common as a starting point and only had to implemented the following functions (I use only SPI) bhy2_spi_read() to use the nRF SPI functions to read a register bhy2_spi_write() to write register bhy_delay_us() to call nrf_delay_us() with the same value

Lastly I used the euler.c example to load the firmware and get familiar with the libraries. Euler.c uses a loop checking the status of an interrupt pin (lines 184-189). I did not implement it that way, I used the nRF GPIOTE functionality to call bhy2_get_and_process_fifo() when data is available, loading the values into my variables for use by the rest of my code

[dariosortino]

Hello @robcazzaro, that's exactly what I am trying to do. What SDK are you using in your project?

[robcazzaro]

I'm using the nRF5 SDK 17.1.0 on a fully custom board with a BHI260 and BMM150. BHI260 is connected to the BMM150 using I2C, and the nRF52840 speaks with the BHI260 via SPI, If you can wait a few days, I should be able to clean things up and post it.

Out of curiosity, what board do you use?

[dariosortino]

Until now we used nRF52840 (nRF5 SDK 15) in custom boards, we are currently thinking of switching to nRF5340 (nRF Connect SDK) for WiFi connectivity. In the custom board, we will connect the BHI and the BMM as you are doing, using as a reference the shuttle board.

So far, I've tried to port the libraries using nRF Connect SDK and I'm facing some trouble, but any reference also for nRF5 SDK is actually good since we have already knowledge of that SDK.

Anyway, no hurry!

[robcazzaro]

We can't move to the Zephyr-based SDK because it doesn't support ANT/ANT+ yet (not sure why Nordic has deprioritized that, it's used by quite a lot of OEMs)

I made good progress today separating the generic code from our proprietary one. To be clear: the Bosch IMU has been working fine for a long time, but all the code was integrated into our proprietary code and I cannot share that. So I need to build a version that can still run on our platform, but cleanly isolates the Bosch libraries and sample code. I can only test on our platform, and that requires a lot of code to get the board to boot and behave properly.

Should be done tomorrow or the day after

[robcazzaro]

I'm done, should work...

I realized that it would have been better to fork the Bosch repository instead of creating a new one from scratch. Please refer to https://github.com/robcazzaro/nRF52-BHY2-Sensor-API.

I tested euler.c the best I could, and it's working well on my board. If you find any problem, please open an issue on that repository. I'd love to hear your feedback on how it's working (or not :) for you

Sooner of later I will delete this repository, so please use the new one for everything

[dariosortino]

Thank you @robcazzaro, great work!

I'm glad that I was stuck on something that also you seem to have worked around:

struct bhy2_dev bhy2;
uint8_t work_buffer[WORK_BUFFER_SIZE];

These two init under the main caused me to hw-fault the micro, and I solved the issue by setting them as static variables. Any reason for you to set them as global?

Anyway, I think it was much simpler to implement the i2c communication. I just followed your steps and created a fork by myself. You can have a look it here: https://github.com/dariosortino/nRFConnect-BHY2-Sensor-API

[one-giant-leap]

Another thank you from me too, @robcazzaro!

I'm using the nRF52832 and found that I needed to reduce #define MAX_READ_WRITE_LEN down to 44 (or thereabouts) to get it to work when using the blink example (pca10040/s132) as a starting point.

[robcazzaro]

@one-giant-leap glad it was helpful, and thanks for letting me know! If you want to open an issue or a discussion in the other repository with your sample project, other people would benefit from a fully working sample for the PCA10040.

[robcazzaro]

@dariosortino cool to see your repository as well. I linked it from my readme, just in case anyone using nRF Connect SDK looking for the nRF52 code finds my repository instead. If you do the same, any Nordic user will have an easier time finding the right one

As for why I made those variables global, I was just thinking of euler.c as a standalone file, so static or global made no real difference for sample code. Your way is better, now that you made me think of it :)