Модуль счетчика реального времени (Real-time counter, RTC) предоставляет традиционный, экономичный таймер, работающий на низкой частоте тактов (LFCLK).

Рис. 1. Блок-схема RTC.

Модуль RTC содержит 24-разрядный счетчик COUNTER, 12-разрядный (1/X) прескалер, регистры захвата/сравнения (capture/compare) и генератор событий тика для энергоэффективной реализации поведения ОСРВ (tickless RTOS).

Поскольку RTC работает от LFCLK (т. е. 32.768 кГц), то разрешающая способность COUNTER получается 1/32768 = 30.517 мкс. В зависимости от источника, RTC может работать, когда генератор HFCLK выключен, и недоступен PCLK16M. Перед использованием RTC программа должна явно запустить генератор LFCLK. Подробнее про источники тактирования см. [2].

Разрешающая способность, переполнение счетчика. Частота инкремента COUNTER равна:

fRTC [кГц] = 32.768 / (PRESCALER + 1 )

Когда RTC остановлен, регистр PRESCALER доступен на чтение/запись. Когда RTC запущен (была выполнена задача START), PRESCALER доступен только на чтение. Запись в регистр PRESCALER, когда RTC запущен, не дает никакого эффекта.

PRESCALER перезапускается на задачах START, CLEAR и TRIGOVRFLW, т. к. на этих задачах значение прескалера фиксируется во внутреннем регистре (<< PRESC >>).

Регистр COUNTER. Это счетчик, который инкрементируется с частотой LFCLK, когда внутренний регистр PRESCALER (<< PRESC >>) равен 0x00. << PRESC >> перезагружается из регистра PRESCALER. Если разрешено, то событие TICK происходит на каждом инкременте COUNTER. По умолчанию событие TICK запрещено.

Рис. 2. Диаграмма времени COUNTER_PRESCALER_0.

Рис. 3. Диаграмма времени COUNTER_PRESCALER_1.

Событие переполнения (OVRFLW). Задача TRIGOVRFLW установит значение COUNTER в 0xFFFFF0, чтобы можно было программно протестировать состояние переполнения. Произойдет событие OVRFLW, когда COUNTER переполнится, т. е. его значение поменяется с 0xFFFFFF на 0.

Замечание: событие OVRFLW по умолчанию запрещено.

Событие тика (TICK). TICK event позволяет реализовать энергоэффективную "tick-less" схему поведения RTOS, поскольку обеспечивается регулярно срабатывающий источник прерывания для RTOS без необходимости использовать функцию ARM® SysTick.

Использование события тика RTC вместо SysTick позволяет CPU выключаться, сохраняя при активность планировщика RTOS.

Замечание: событие TICK по умолчанию запрещено.

Управление событиями. Для оптимизации энергопотребления RTC, события RTC можно запрещать индивидуально, чтобы предотвратить запросы PCLK16M и HFCLK, когда срабатывают события. Разрешение/запрет событий управляется регистром EVTEN.

Например, если событие TICK для приложения не требуется, то это событие должно быть запрещено, поскольку оно происходит часто, и может увеличить потребление энергии, если иначе генератор HFCLK может быть выключен на долгий период времени.

Это означает, что RTC реализует несколько другую подсистему задач и событий (task и event) по сравнению со стандартной системой, описанной для интерфейса периферийного устройства [3]. RTC task и event system показана на рис. 4.

Рис. 4. Система задач (tasks), событий (events) и прерываний (interrupts) в RTC.

Функция Compare. Имеется несколько регистров сравнения CC, см. далее раздел "Регистры RTC".

Когда установлен регистр сравнения, наблюдается следующее поведение события сравнения (compare event) RTC:

• Если значение регистра CC равно 0, когда установлена задача CLEAR, то событие COMPARE не произойдет, см. рис. 5.
• Если значение регистра CC равно N, и значение COUNTER равно N, когда установлена задача CLEAR, то событие COMPARE не произойдет, см. рис. 6.
• Событие COMPARE произойдет, когда CC = N, и значение COUNTER перешло от N-1 к N (произошло совпадение регистров CC и COUNTER), см. рис. 7.
• Если COUNTER = N, то запись N+2 в регистр CC гарантированно вызовет событие COMPARE в момент COUNTER = N+2, см. рис. 8.
• Если COUNTER = N, то запись N или N+1 в регистр CC может не вызвать событие COMPARE, см. рис. 9.
• Если COUNTER = N, и текущее значение регистра CC равно N+1 или N+2, когда записано новое значение CC, может сработать совпадение на предыдущем значении CC до того, как новое значение CC вступит в действие. Если текущее значение CC больше N+2, то запишется новое значение, и по старому значению CC срабатывание события совпадения не произойдет. См. рис. 10.

Рис. 5. Диаграмма времени COMPARE_CLEAR.

Рис. 6. Диаграмма времени COMPARE_START.

Рис. 7. Диаграмма времени COMPARE.

Рис. 8. Диаграмма времени COMPARE_N+2.

Рис. 9. Диаграмма времени COMPARE_N+1.

Рис. 10. Диаграмма времени COMPARE_N-1.

[Джиттер/задержка TASK и EVENT]

Существует джиттер или задержка синхронизации задач и событий RTC с другими периферийными устройствами, потому что они работают на повышенной частоте тактов PCLK16M, не синхронной с низкой частотой тактов (LFCLK).

Регистры интерфейса периферийных устройств [3], участники домена тактов PCLK16M, снабжены набором зеркальных регистров в домене тактов LFCLK. Например, значение COUNTER, доступное со стороны CPU, находится в домене PCLK16M, и при чтении защелкивается из внутреннего регистра с именем COUNTER, но находящегося в домене LFCLK. Этот COUNTER как раз тот регистр, который в действительности модифицируется на каждом тике RTC. Таким образом, эти две копии регистров должны быть синхронизированы между доменами тактов (PCLK16M и LFCLK).

Таблица 2. Величина джиттера RTC, влияющего на запуск задач.

Таблица 3. Величина джиттера RTC, влияющего на срабатывание событий.

Примечание (1): подразумевается, что RTC постоянно считает между этими событиями. К приведенным значениям добавляется джиттер тактов 32.768 кГц.

Ниже приводится краткое описание джиттера, который существует на срабатывание задач и событий RTC, с поясняющими рисунками.

1. Задачи CLEAR и STOP (и TRIGOVRFLW, что на рис. 11 не показано) будут задержаны до момента, пока периферийное устройство не засинхронизирует свой спад тактов с фронтом LFCLK. Эта задержка будет в интервале между 15.2585 мкс и 45.7755 мкс, что в последующем описании будет для упрощения округлено до 15 мкс и 46 мкс.

Рис. 11. Диаграмма времени DELAY_CLEAR.

Рис. 12. Диаграмма времени DELAY_STOP.

2. Задача START запустит RTC. Если предположить, что такты LFCLK уже запущены и стабильны, то первый инкремент COUNTER (и событие TICK) произойдут после 30.5 +/-15 мкс. В некоторых случаях, в частности если RTC запущен задачей START перед тем, как запустились такты LFCLK, это время может быть порядка ~250 мкс. Поэтому программа должна подождать первого TICK, если необходимо обеспечить рабочее состояние RTC. Отправка задачи TRIGOVRFLW установит значение COUNTER, близкое к переполнению. Однако, поскольку момент обновления COUNTER зависит от стабильности частоты LFCLK, отправка этой задачи, когда такты LFCLK не запустились, запустит LFCLK, но обновление будет задержано на ту же величину времени до ~250 мкс. Рисунки ниже показывают самую маленькую и самую большую задержки задачи START, которая появляется с джиттером +/-15 мкс для первого инкремента COUNTER.

Рис. 13. Диаграмма времени JITTER_START-.

Рис. 14. Диаграмма времени JITTER_START+.

[Чтение регистра COUNTER]

Для чтения регистра COUNTER выполняется захват внутреннего значения << COUNTER >>.

Для гарантии, что << COUNTER >> безопасно захвачен (при чтении может произойти перепад LFCLK), CPU и шина ядра памяти приостанавливаются на 3 такта путем перевода в 0 сигнала готовности ядра (core PREADY). Чтение займет дополнительно 2 такта CPU, так что получится, что чтение COUNTER по длительности займет фиксированные 5 тактов PCLK16M.

Рис. 15. Диаграмма времени COUNTER_READ.

[Регистры RTC]

Таблица 4. Экземпляры RTC.

Таблица 5. Обзор регистров RTC.

[Электрические параметры RTC]

[Ссылки]

1. RTC Real-time counter nRF52832 site:nordicsemi.com.
2. CLOCK Clock control nRF52832 site:nordicsemi.com.
3. nRF52: интерфейс периферийного устройства.
4. nRF52 TIMER.