How to get a base of time from an ISR and preserve the low power consumption.

[ReneDelgado]

Hi,

Currently, we work on a project that uses:

    nRF9160
     Zyphre OS
     Segger Embedded Studio for  Arm (Nordic Edition) V5.10d
     SDK v1.4

This is our situation.

We want to measure the pulse width that enters a digital input of the nrf9160. After the above, we will publish it on a server with MQTT.

We hope that the sources of the tick or method that you suggest allow us to keep the low current consumption of the SoC.

Here are our questions:

    1) What method should we use to obtain the ticks within a digital input ISR?

    2) Is the clock source for that tick available during low power states?

    3) What is the resolution that we can expect with this method?

Basically, we want to know the best way that the Nordic team recommends to implement and get the time source mentioned in this Nordic post. 

And preserve the low power consumption. And if it is possible with the lowest latency possible.

As always, we appreciate the excellent support you have given us so far.

René D.

[Øyvind]

Hello René,

It sounds that you should look at the Real Time Counter in the nRF9160 and the Distributed Programmable Peripheral Interconnect (DPPI).

  1) What method should we use to obtain the ticks within a digital input ISR?

 Have a look at our PPI sample which uses DPPI and RTC to trace hardware events on GPIO pins.

   2) Is the clock source for that tick available during low power states?

 Yes, it should. By using k_sleep, part of the Zephyr scheduling and Power Management the application can put the thread where it is called into low power mode. Have a look at this thread about the sleep modes.

  3) What is the resolution that we can expect with this method?

 What resolution do you need? The counter API includes a function counter_ticks_to_us() which may be a starting point.

 

As always, we appreciate the excellent support you have given us so far.

 Thank you! We do our best to support our customer the best we can :) 

Let me know if you need more information. 

Kind regards,
Øyvind

[ReneDelgado]

Hello Øyvind,

Thanks for the prompt response,  I took a look at RTC — Real-time counter and the Distributed Programmable Peripheral Interconnect (DPPI) and it is very interesting but in this case, it is not that I need.

We think found what we need in a Zephyr example "c:\...\zephyr\samples\basic\button". But we still have some concerns, would you help us to solve them?

    1) From the example (we attached an image),  "button_pressed(...)"  function is in ISR context?

     2) It is safe call "k_cycle_get_32()" from an isr context?

    3) "__get_IPSR()" is in the nrf9160 available to validate if some functions is in an ISR context?

And the last extra question,

    4) "date_time_now(...)" use some socket to get the UTC and is "date_time_now(...)" safe to use in ISR context?

Thanks a lot and kind regards,
René D.

[Øyvind]

Hi René, 

 

ReneDelgado said:

1) From the example (we attached an image),  "button_pressed(...)"  function is in ISR context?

 The function button_pressed() is called by the gpio callback. You can find more information about callbacks here. 

More information on the Zephyr ISR can be found here. 

Remember that NCS is using Zephyr OS to enable more complex applications with Scheduling, Interrupts, and Synchronization, introducing amongst other Threads to offload ISR.

ReneDelgado said:

   2) It is safe call "k_cycle_get_32()" from an isr context?

/**
 * @brief Read the hardware clock.
 *
 * This routine returns the current time, as measured by the system's hardware
 * clock.
 *
 * @return Current hardware clock up-counter (in cycles).
 */
static inline uint32_t k_cycle_get_32(void)
{
	return arch_k_cycle_get_32();
}

 

This should be safe. This function is called using threads, offloading the ISR. The intent is that this counter represents the fastest cycle counter that the operating system is able to present to the user (for example, a CPU cycle counter) and that the read operation is very fast.

ReneDelgado said:

3) "__get_IPSR()" is in the nrf9160 available to validate if some functions is in an ISR context?

 This is a function from Arm CMSIS

  \brief   Get IPSR Register
  \details Returns the content of the IPSR Register.
  \return               IPSR Register value
 */
__STATIC_INLINE uint32_t __get_IPSR(void)
{
  register uint32_t __regIPSR          __ASM("ipsr");
  return(__regIPSR);
}

I'm afraid I don't have a complete overview of this part. You might find more information from this page

ReneDelgado said:

4) "date_time_now(...)" use some socket to get the UTC and is "date_time_now(...)" safe to use in ISR context?

I would recommend using the Zephyr OS scheduling for this usage. There is more information about Date and Time here. We have some samples which use this e.g. AWS IoT sample

Hope this answers your questions. Let me know if anything is unclear

-Øyvind

[ReneDelgado]

Hi Øyvind,


It was clear enough to solve our doubts.


Thanks a lot,

René D.