This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

easyDMA and TWI(_app)

Hello everyone

I was not able to find any explicit statement regarding the use of the TWI_APP with easyDMA on the nRF52 series and SDK13.0.0.

I checked the examples linked here (direct link to examples GitHub folder), which are based on the SDK11.0.0.

I want to read two sensors via TWI without the use of the CPU, i.e. I would like to have a GPIOTE from one sensor, which triggers the readout via TWI of both sensors with easyDMA thanks to the PPI. Thus, apart from having another (newer) SDK as starting point and having more than one sensor, my situation is fairly similar to the one shown in the example /nrf5-mpu-examples-master/nrf52-mpu-easydma-using-gpiote-and-registers/.

I see that one has to "manually" set up the TWI. Also, the HW address is bound to the TWI instance

NRF_TWIM0->ADDRESS = MPU_ADDRESS;

Also, I read this thread, but I still do not have all information I am looking for. Also, in the proposed solution it is suggested to use the nrf_drw_twi directly, and not the app_twi, but I would prefer to be able to stick with the app_twi as what I have done so far for my setup uses this library.

So I have the following questions:

  1. How does the TWI_APP fit into this picture? Is there any relation between app_twi_schedule() and interrupt-based TWI?

  2. Can you use easyDMA alongside the TWI_APP? If so, is there any example I missed?

  3. If I have to follow the example of which above and set up the TWI manually, i.e. step by step by setting all registers myself without the aid of auxiliary wrapper functions, is there a way of reading multiple sensors using only one TWI instance or do I need to use more than one TWI instance?

  4. If you use the approach described here, how do you decide on the RAM address? Can you choose any of the valid without considering anything else?

Thank you in advance for your help!

Ale

Parents
  • Hi,

    Most of this seems to be answered in the thread you linked to.

    1. app_twi_schedule() puts the transaction into a queue, which is processed and eventually the actual TWI transfer is executed by a call to nrf_drv_twi_xfer().
    2. Yes, as described in the thread you linked EasyDMA will be used if the address is in RAM. You should be able to get it working by doing the changes as described in the thread.
    3. It would be possible to change the address, but this will have to be done in software, meaning you loose part of the advantage of EasyDMA. You can aslo check out this example, which use the driver and timers.
    4. Check out the links in this answer.

    Best regards,

    Jørgen

  • Thank you Jørgen for your reply!

    Now things are clearer! My test software works now even with easyDMA enabled.

    One more question: I am currently scheduling the TWI transaction on GPIOTE event (sensor interrupt) and I do not tie the GPIOTE to the scheduling via PPI. Does this mean that I am still using the CPU for scheduling the TWI transaction and that further optimisation can be done or am I already exploiting the system's maximum capabilities? How can I verify if the CPU is working during the transactions or not?

    Thank you again! Ale

Reply
  • Thank you Jørgen for your reply!

    Now things are clearer! My test software works now even with easyDMA enabled.

    One more question: I am currently scheduling the TWI transaction on GPIOTE event (sensor interrupt) and I do not tie the GPIOTE to the scheduling via PPI. Does this mean that I am still using the CPU for scheduling the TWI transaction and that further optimisation can be done or am I already exploiting the system's maximum capabilities? How can I verify if the CPU is working during the transactions or not?

    Thank you again! Ale

Children
No Data
Related