Как правильно получать доли секунд от RTC STM32? Опции

[AHTOXA]

Понадобилось мне время поточнее.

В новом RTC у тех STM-ок, что поновее (вроде бы у всех, кроме F1) есть специальный регистр для этого - SSR.
Также есть два предделителя: синхронный и асинхронный.
Делаю такую инициализацию:

Код

    static constexpr unsigned quartzFreqHz = 32768;  // частота кварца
    static constexpr unsigned asyncPrediv = 0x1F;      // асинхронный предделитель
    static constexpr unsigned syncPrediv = quartzFreqHz / (asyncPrediv + 1) - 1;  // синхронный предделитель
.....
    RTC->PRER = syncPrediv;
    RTC->PRER |= asyncPrediv << 16;

После этого я ожидаю, что в регистре SSR будут значения от 0 до 32768/(asyncPrediv+1) = 1024. Однако, запустив цикл вывода значений SSR на печать, я наблюдаю там числа от 0 до 1055(!). Возможно и более, я не очень долго смотрел.

Внимание, вопрос: почему так? Что я сделал не так? Кто-нибудь сталкивался с таким?

[jcxz]

Внимание, вопрос: почему так? Что я сделал не так? Кто-нибудь сталкивался с таким?

как то странно пытаться использовать внутренний RTC для быстрого чтения времени....
Не знаю как точно это устроено в STM32, но в других МК, в которых я работал с внутренним RTC, он находится в отдельном домене питания и связь этого домена с системным доменом - последовательная. Т.е. RTC считает в своём домене, а при запросах чтения/записи IO-регистров RTC данные от него/к нему передаются через последовательный канал, что приводит к выставлению сигнала HALT ядру до момента завершения передачи. И передача может достигать нескольких сотен системных тиков (в зависимости от частоты ядра). Соответственно и время выполнения такой команды.
Так сделано по-крайней мере в МК Infenion и Tiva и сиё подробно расписано в даташитах. Сильно подозреваю что в STM32 дела обстоят аналогично.
Если действительно нужно быстро читать из часов реального времени, то можно задействовать любой general purpose timer, засинхронизировать его по edge секундного прерывания от RTC и работать уже с его счётчиком. Периодически подсинхронизируя этот таймер с RTC методом ФАПЧ.
Тогда и доли секунд и даже микросекунды реально будет получить без всяких задержек.

[AHTOXA]

Неужели никто не сталкивался с таким?

[Baser]

Неужели никто не сталкивался с таким?

Не применял дробную часть, нужды не было.
Сейчас под отладчиком посмотрел что в STM32L1 в SSR при стандартных делителях 128+256: как и ожидалось, диапазон от 0 до 0xFF. Так что может у вас, действительно, асинхронный делитель на 31 делит?

Кстати, а есть ли смысл в чтении дробной части? С "теневыми регистрами" вроде смысла нет. Если их отключить (BYPSHAD=1), то все равно читать нужно минимум дважды для исключения попадания на фронт клока, когда читаться будет лабуда. Точности нет...

как то странно пытаться использовать внутренний RTC для быстрого чтения времени....
Не знаю как точно это устроено в STM32, но в других МК, в которых я работал с внутренним RTC, он находится в отдельном домене питания и связь этого домена с системным доменом - последовательная. Т.е. RTC считает в своём домене, а при запросах чтения/записи IO-регистров RTC данные от него/к нему передаются через последовательный канал, что приводит к выставлению сигнала HALT ядру до момента завершения передачи. И передача может достигать нескольких сотен системных тиков (в зависимости от частоты ядра). Соответственно и время выполнения такой команды.
Так сделано по-крайней мере в МК Infenion и Tiva и сиё подробно расписано в даташитах. Сильно подозреваю что в STM32 дела обстоят аналогично.

В STM32 домены питания тоже разные, но шина между ними параллельная. Читается быстрее, но тоже есть ограничение на частоты доменов, присутствуют "теневые регистры", куда периодически копируется синхронная копия даты/времени, которая у них сбоит - errata , разные флаги синхронизации. Т.е. тоже - не подарок...