nrf52810 use with KXTJ3-1057 accelerometer

Hello all, 

I hope you are well. I am currently developing a product on the nrf52810 platform. I have a custom board and now have the BLE functional on the board. The next step is to be able to read the data from the accelerometer. I have been following the example in the SDK for the twi_sensor. I uploaded the example to my dev it (nrf52832) and it worked well. I attempted to adapt the example for use with my accelerometer in my main program however I keep running into confusing errors. I have twi and twim as well as their instances turned on in the config file, and I also have the nrfx drivers installed. Would anyone be able to help guide me though the process to setting up the accelerometer for use with the nrf52810? 

Thank you!

Parents
  • Hi,

    I uploaded the example to my dev it (nrf52832) and it worked well.

    That is good, and is a good start.

    I attempted to adapt the example for use with my accelerometer in my main program however I keep running into confusing errors.

    Can you explain which changes you did in order to adapt to your accelerometer, and what errors you are seeing? Please elaborate.

  • Hello Einar,

    Thank you for the response. I already had all of the required defines in order so I do not think that is the issue. I checked the nrfx_twim.c file and there do in fact seem to be no functions which pertain to the nrfx_twim_rx or nrfx_twim_tx functions that the nrf_drv_twi driver uses. My best guess is that they were removed in a recent update due to their deprecation, but I am not sure. It appears that my options are to either use another twim driver (I am using sdk 17) or to use the nrfx_xfer function instead of the original ones, although this is not my preference as there seem to be far more resources centered around the nrfx_twim_tx/rx functions. Could you direct me to a driver that I can use that includes these functions, or if you think nrfx_xfer is the way to go them maybe a more detailed walkthrough of using that instead? I will also include a link to the driver that I am currently using. Thank you!

    Driver: github.com/.../nrfx

  • Hi,

    epice500 said:
    Thank you for the response. I already had all of the required defines in order so I do not think that is the issue.

    Then there is something else, but in any case if you have your project and code and look at the full error messages (build output) it should normally be easy to resolve. I cannot say anything more specifically without that though. If you post it here I might be able to say more.

    epice500 said:
    I checked the nrfx_twim.c file and there do in fact seem to be no functions which pertain to the nrfx_twim_rx or nrfx_twim_tx functions that the nrf_drv_twi driver uses.

    What do you mean? You can refer to <nRF5 SDK>\integration\nrfx\legacy\nrf_drv_twi.h to see the link between the nrf_drv API and the nrfx API for the TWI master.

    epice500 said:
    My best guess is that they were removed in a recent update due to their deprecation

    No, that is not the case. The nrf_drv API is still usable in any nRF5 SDK version and will with all probability remain so for future nRF5 SDK versions, so unless you need some new features which is not available in the old API there is no need to migrate. For SPIM specifically, I do not believe there are any added features that you need to use the nrfx API to use. You are of course free to do so, but you will not gain anything by it. The translation between the "legacy" API and the nrfx driver is handled by a thin wrapper layer, so the result will be almost the same regardless.

    epice500 said:
    Could you direct me to a driver that I can use that includes these functions, or if you think nrfx_xfer is the way to go them maybe a more detailed walkthrough of using that instead?

    I am not aware of any driver for KXTJ3-1057 that is based on nrfx (it might exist, though). Migrating from nrf_drv to nrfx is a quite simple operation though, as the nrfx API is derived from nrf_drv. So you can migrate the driver you already have if you really want to do this (see Migration guide for nrfx drivers). It should not be a big task, but as explained there is normally no good reason to do so. I suggest you instead resolve the issue you are seeing with the driver you are currently using.

Reply
  • Hi,

    epice500 said:
    Thank you for the response. I already had all of the required defines in order so I do not think that is the issue.

    Then there is something else, but in any case if you have your project and code and look at the full error messages (build output) it should normally be easy to resolve. I cannot say anything more specifically without that though. If you post it here I might be able to say more.

    epice500 said:
    I checked the nrfx_twim.c file and there do in fact seem to be no functions which pertain to the nrfx_twim_rx or nrfx_twim_tx functions that the nrf_drv_twi driver uses.

    What do you mean? You can refer to <nRF5 SDK>\integration\nrfx\legacy\nrf_drv_twi.h to see the link between the nrf_drv API and the nrfx API for the TWI master.

    epice500 said:
    My best guess is that they were removed in a recent update due to their deprecation

    No, that is not the case. The nrf_drv API is still usable in any nRF5 SDK version and will with all probability remain so for future nRF5 SDK versions, so unless you need some new features which is not available in the old API there is no need to migrate. For SPIM specifically, I do not believe there are any added features that you need to use the nrfx API to use. You are of course free to do so, but you will not gain anything by it. The translation between the "legacy" API and the nrfx driver is handled by a thin wrapper layer, so the result will be almost the same regardless.

    epice500 said:
    Could you direct me to a driver that I can use that includes these functions, or if you think nrfx_xfer is the way to go them maybe a more detailed walkthrough of using that instead?

    I am not aware of any driver for KXTJ3-1057 that is based on nrfx (it might exist, though). Migrating from nrf_drv to nrfx is a quite simple operation though, as the nrfx API is derived from nrf_drv. So you can migrate the driver you already have if you really want to do this (see Migration guide for nrfx drivers). It should not be a big task, but as explained there is normally no good reason to do so. I suggest you instead resolve the issue you are seeing with the driver you are currently using.

Children
No Data
Related