power optimal twi tx/rx

RE: power optimal twi tx/rx

Simonr — Fri, 09 Aug 2019 10:29:10 GMT

What SDK version are you using? If you're using a very old one (before SDK v.14.x) I'd suggest you update it due to implementations of various bug fixes, as well as more and updated example projects.

An address/data nack should not cause any issues in our TWI examples, you'll just have to resend the transfer. You can take a look at this thread, where a power optimization method is proposed by using the app_timer.

Best regards,

Simon

RE: power optimal twi tx/rx

rookie — Thu, 08 Aug 2019 21:23:20 GMT

I am referring to twi _sensor where a twi_handler callback is used. The example there has a while wait loop until "m_xfer_done" is set . So it becomes a busy loop. Is there a better way to implement it without busy-looping? Also, what would happen if I get an address nack or data nack. Things start getting messier once I start having a flag for each state(like rx/tx /addr nack/ data nack).

I think the SDK I am using doesn't yet have the twi manager.

RE: power optimal twi tx/rx

Simonr — Wed, 07 Aug 2019 09:04:29 GMT

What example is your application based on? Do you have an event handler that the callback goes to after you've called a TWI event? If you do have a callback, you can just wait for that using the idle_state_handle() function, similar to what's done in many of our examples. If this callback is in another file than your main.c file, you can forward it to main.c in order to make it easier.

Best regards,

Simon

RE: power optimal twi tx/rx

rookie — Mon, 05 Aug 2019 17:49:48 GMT

Thanks awneil.

I have expanded on my question in my reply to simonr. My example is simple where I want to read a register. So What would be my options instead of waiting(using delay) for the twi handler to return an event to indicate a successful read.

RE: power optimal twi tx/rx

rookie — Mon, 05 Aug 2019 17:30:58 GMT

I know there is an idle state handler in most examples. May I frame my question slightly differently.

If I understand correctly the nrf_drv_twi_tx/nrf_drv_twi_rx calls are non-blocking since a twi handler gets a callback when a tx or rx event is complete. So let's say when I want to read a register, so we do a tx and then an rx. Now until I receive the rx event in the handler I haven't actually received the value correctly. If I want to write an API to read a register where I pass a value that will be filled with the register value, I will have to jump to the twi handler and then back or just simply waitusing a delay which is not efficient. So my question would be do you have any suggestion to write this effectively?

RE: power optimal twi tx/rx

awneil — Tue, 30 Jul 2019 12:30:29 GMT

[quote userid="72833" url="~/f/nordic-q-a/50368/power-optimal-twi-tx-rx/201061"]Not sure what other factors may be involved? [/quote]

Common things include:

You might need some things to stay active/responsive while you sleep;
The more you shut down, the more you have to wake up again to get back into "normal operation";
The deeper you sleep, the longer it takes to wake again;
Deeper sleep options often have more limited wakeup options;
etc, etc, ...

As Simonr says, many (most?) of the SDK examples illustrate sleeping while waiting for events ...

RE: power optimal twi tx/rx

Simonr — Tue, 30 Jul 2019 12:19:49 GMT

Yes, you can use _WFE(). But we recommend using the idle_state_handle() function which flushes the NRF_LOG and runs nrf_pwr_mgmt_run(). Please see the ...\nRF5_SDK_15.0.0_a53641a\examples\ble_central\ble_app_blinky_c example for reference.

Best regards,

Simon

RE: power optimal twi tx/rx

rookie — Mon, 29 Jul 2019 17:21:32 GMT

Yes, I mean minimal. Not sure what other factors may be involved? In this case it is really about minimizing current draw.

I agree busy loop is not optimal. How do I let it sleep until I get an event, say a NRF_DRV_TWI_XFER_TX or NRF_DRV_TWI_XFER_RX? Do I use _WFE() ?

RE: power optimal twi tx/rx

awneil — Mon, 29 Jul 2019 16:57:59 GMT

By "optimal" do you really mean "minimum" - or do you also have other factors to consider ?

Just spinning in a busy loop is never going to be low-power - as it requires the CPU to be running at full speed, without letting it do anything useful.

Could you not let it sleep, and wake on the "finished" event?