app_timer with scheduler

[bgarrood]

I want to use nested app_timer instances:  I am gathering data on a repeating app_timer (app_timer_1) which fires say every 10ms.  One of my sensors providing the data requires some time delay between requesting the data and it being ready, so I want to use a second app_timer (app_timer_2) to provide a low-power delay function. The delay can be of the order of 5ms.

Since app_timer_2 is being stated from app_timer_1 it isnt running because they have the same interrupt priority but timer_2 is running in the context of timer_1.  I believe the way to get around this is to use the scheduler.  However despite spending some time searching I cant find any examples of how to do this.  Documentation seems a bit sparse, and in places confusing.

For example, app_timer use in scheduler example here: https://devzone.nordicsemi.com/tutorials/b/software-development-kit/posts/scheduler-tutorial uses deprecated functions: app_timer_appsh no longer exists (I am using SDK 14.2).

Any help much appreciated!

[haakonsh]

Hey Barnaby,

It sounds like you need to start app_timer_2 from app_timer_1s event handler. You do not need to use the scheduler at all. 

Cheers,

Håkon.

[bgarrood]

Hey Hakon,

That is what I am doing, but app_timer_2 event never fires.  Reading around it, I though that was because it is running in context of app_timer_1, and since they have same priority it will never work.  Did I get it wrong?

I can try making a simple example to see if problem is elsewhere.

Thanks again!

Barney

[haakonsh]

Why do you start another delay after the first one, can't you just use one? 

[bgarrood]

Ideally not.  The first I am using to schedule measurements.  Second is to give time for measurement to take place in a particular sensor- in some cases the order of events within each measurement cycle can change, which impacts how much time the sensor has to take the measurement - measurement request from previous cycle could happen late in that cycle, resulting in a need to delay requesting the data.

Is there any way to do this?  I can come up with something else if not.

[haakonsh]

There are probably better ways to do this. Do you have a datasheet for you sensor, or more information on how you interface with the sensor? 

The reason I ask is that you might not want to use the app_timer, or at least not in a blocking mode, depending on the sensor interface.

[bgarrood]

Thank you.

I agree there are probably better ways. 

Interface is i2C.  I send a message asking to start measurement.  This takes 4.5ms to complete (depends on resolution) - if I request data before that I just get garbage.  I am running on a 10ms cycle time;  each cycle I read data then request new measurement.  I am doing other stuff within the cycle that could change from cycle to cycle, thus changing the timing of events.  I therefore want to be sure I am waiting the 4.5ms between request of previous cycle and read of current.

So bottom line, is what I am asking just not possible?  Or not advisable?

[haakonsh]

It is definitely possible. I suggest you use RTC2 with the RTC HAL and driver to start a Two Wire master interface (TWI/TWIM) transfer via the PPI — Programmable peripheral interconnect system. Also see thePPI HAL and driver API documentation.

The goal is to set up an RTC to trigger the NRF_TWIM_TASK_STARTTX task every 10ms. The TWIM will then transmit whatever is present in its TX buffer. You need to set up the sensor command beforehand with a call to nrf_twim_tx_buffer_set. 

You must also setup up the RTC to trigger the NRF_TWIM_TASK_STARTRX task every 4.5ms. 

When the RTC triggers the start TX event you need to also trigger a NRF_RTC_TASK_CLEAR . This will restart the RTC and create an endless loop of sensor sampling. 

See the RTC, TWIM, and PPI  examples in the SDK for implementation details.