[dmitrykhom 0]

Продолжаю писать под этот мк, вот добрался до ERTC (часы реального времени). Пришлось хлебнуть несладко, есть интересные тонкости.

(Например, если ввести в режим инициализации (ERTC->IMEN), ERTC->IMF поднимется, и в этом режиме выполнить рестарт мк, то ERTC->IMF сбросится, а часы будут стоять. Поэтому узнать, идут ли часы реально, можно только дождавшись, пока они тикнут или нет.) Но речь сейчас не о том...

Вот код, который мне нужен, но мне он не нравится:

        ERTC->time = stime.time;                                                    // Время

        ERTC->date = sdate.date;                                                    // Дата

        ERTC->ctrl_bit.hm = ERTC_HOUR_MODE_24;                       

Разумеется, режим доступа в область pwr включен (и не выключаю), защита записи ERTC отключена (и не включаю), и перед этим была команда ввода в режим инициализации - здесь все проверено.

Так вот. Регистры пишутся, часы корректируются. НО каждая из этих команд глухо вешает процессор приблизительно на 100 мкс! Это чересчур - у меня прерывание раз в 10 мкс, мне так нельзя.

Вопрос: как этого избежать? Подскажите, пожалуйста  Если не подскажете, то мне ничего не останется, как не трогать ERTC, и делать это только при сигнале отключения питания.

(Кстати, команды вкл/откл режима доступа в pwr тоже вешают где-то на 200 мкс, снятие/установка защиты от записи в ERTC тоже порядка 20 мкс, поэтому от них пришлось отказаться.)

Изменено 22 декабря, 2023 пользователем dmitrykhom

[jcxz 187]

8 часов назад, dmitrykhom сказал:

Так вот. Регистры пишутся, часы корректируются. НО каждая из этих команд глухо вешает процессор приблизительно на 100 мкс! Это чересчур - у меня прерывание раз в 10 мкс, мне так нельзя.

И что? Обычное дело. Видимо RTC находится в отдельном домене питания и тактирования. Связь с которым идёт через последовательный интерфейс. Так реализовано во многих микроконтроллерах. В мануале вашего это должно быть описано.

8 часов назад, dmitrykhom сказал:

Вопрос: как этого избежать? Подскажите, пожалуйста  Если не подскажете, то мне ничего не останется, как не трогать ERTC, и делать это только при сигнале отключения питания.

Не писать туда часто, вот и всё. Зачем вы туда так часто пишете?

8 часов назад, dmitrykhom сказал:

(Кстати, команды вкл/откл режима доступа в pwr тоже вешают где-то на 200 мкс, снятие/установка защиты от записи в ERTC тоже порядка 20 мкс, поэтому от них пришлось отказаться.)

Правильно. Так и должно быть. Так как эти биты должны находиться в домене RTC.

[dmitrykhom 0]

21 час назад, jcxz сказал:

... В мануале вашего это должно быть описано.

Не писать туда часто, вот и всё. Зачем вы туда так часто пишете?

Может быть, плохо искал, но в мануале этого не нашел.

Хотел писать часто, так как ERTC даёт возможность получать точные метки времени, притом кварц 33768 более термостабилен, чем кварц процессора на 8 МГц. Но когда устройству приходит точное время, и оно точнее получаемых меток от ERTC, то хочется в ERTC обновить время.

В принципе, я могу отказаться от термостабильного кварца, а в моей задаче можно обойтись EMAC_PTP.

[dmitrykhom 0]

Интересно, если к этим регистрам сделать DMA, то получится работа или нет?! Проверю в следующем году.

И, если получится будут ли тормоза

Изменено 25 декабря, 2023 пользователем dmitrykhom

[jcxz 187]

2 часа назад, dmitrykhom сказал:

Интересно, если к этим регистрам сделать DMA, то получится работа или нет?! Проверю в следующем году.

И, если получится будут ли тормоза

Естественно будут. У DMA-контроллера. А также возможно и у процессора. Иначе - зачем бы вообще там эта задержка возникала? Просто задумайтесь: Зачем разработчик МК ввёл эти задержки модификации RTC?

 

PS: Не понимаю - зачем упорно пытаться сделать через одно известное место??? Вместо того, чтобы включить голову и подумать - как реализовать алгоритм подстройки часов без частых записей в RTC?  

Очевидное и простейшее решение: Когда приходит извне точное время, просто вычислить дельту между ним и текущим значением  RTC. А текущее время всегда получать как сумму = RTC + дельта.

Ведь чтение RTC происходит быстро, без задержек? Или тоже с задержкой?

[dmitrykhom 0]

4 часа назад, jcxz сказал:

Очевидное и простейшее решение: Когда приходит извне точное время, просто вычислить дельту между ним и текущим значением  RTC. А текущее время всегда получать как сумму = RTC + дельта.

Ведь чтение RTC происходит быстро, без задержек? Или тоже с задержкой?

Момент перехода в другие сутки тогда придется вычислять, хотя это тоже можно при желании. За дельту спасибо, простое решение. Действительно, уперся в эту синхронизацию...

Читается без задержек, но для точности результата приходится ждать перехода регистра подсекунд на следующее значение (до 4 мс задержка), но там ничего не вешается.

Спасибо!

[VladislavS 29]

В 22.12.2023 в 17:03, dmitrykhom сказал:

Это чересчур - у меня прерывание раз в 10 мкс, мне так нельзя.

Прерыванию выше приоритет поставить?

[jcxz 187]

2 часа назад, dmitrykhom сказал:

Момент перехода в другие сутки тогда придется вычислять

Ведите все времена в виде простого счётчика секунд с фиксированной даты. Счётчик секунд + счётчик мили или микросекунд. И математика станет намного проще.

2 часа назад, dmitrykhom сказал:

Читается без задержек, но для точности результата приходится ждать перехода регистра подсекунд на следующее значение (до 4 мс задержка)

Тут не очень понятно - в чём проблема?. Но можно вообще почти без чтения RTC обойтись - завести таймер (от генератора CPU) с разрешением например =1мкс и периодом =1сек. А RTC читать только при старте, а также - завести периодические прерывания от RTC раз в секунду, в которых считывать счётчик таймера и корректировать по нему дельту. Тогда чтение RTC будет однократным - только при старте ПО. А для вычисления точного текущего времени - читать регистр таймера, тикающий с разрешением 1мкс и не имеющий задержки на чтение.

У вашего МК есть 32-битные таймеры? Впрочем, даже если нет, наверняка можно 2 сконкатенировать.

2 часа назад, VladislavS сказал:

Прерыванию выше приоритет поставить?

С учётом того, что запись в RTC у ТС занимает 100мкс, то такое вообще повешает CPU если ТС вздумает часто писать. Да даже с любым приоритетом в программе ТС должно приходиться туго всем обработчикам прерываний, требующим быстрой реакции.

Просто не надо писать в этот RTC. Лучше никогда.

[dmitrykhom 0]

В 25.12.2023 в 20:22, jcxz сказал:

Тут не очень понятно - в чём проблема?. Но можно вообще почти без чтения RTC обойтись - завести таймер (от генератора CPU) с разрешением например =1мкс и периодом =1сек. А RTC читать только при старте, а также - завести периодические прерывания от RTC раз в секунду, в которых считывать счётчик таймера и корректировать по нему дельту. Тогда чтение RTC будет однократным - только при старте ПО. А для вычисления точного текущего времени - читать регистр таймера, тикающий с разрешением 1мкс и не имеющий задержки на чтение.

У вашего МК есть 32-битные таймеры? Впрочем, даже если нет, наверняка можно 2 сконкатенировать.

Проблема в том, что этот 32x таймер работает от кварца 25 МГц, который на всем диапазоне температур, что я испытывал (-20+65), дает нестабильность до 20 ppm, а это много. У кварца 32768 эта нестабильность в разы меньше. Устройство будет стоять на холоде включенным без синхронизации, и за сутки отстанет/набежит больше положенной 0,5 секунды.

Есть лучше - таймер EMAC_PTP, которому еще и дисперсию задавать можно. И корректировать, просто занеся в специальный регистр разницу. Но он работает от AHB, который, в свою очередь, то 25 МГц.

В 25.12.2023 в 20:22, jcxz сказал:

С учётом того, что запись в RTC у ТС занимает 100мкс, то такое вообще повешает CPU если ТС вздумает часто писать. Да даже с любым приоритетом в программе ТС должно приходиться туго всем обработчикам прерываний, требующим быстрой реакции.

Просто не надо писать в этот RTC. Лучше никогда.

Никакие приоритеты здесь не помогают, все виснет глухо.

[jcxz 187]

2 часа назад, dmitrykhom сказал:

Проблема в том, что этот 32x таймер работает от кварца 25 МГц, который на всем диапазоне температур, что я испытывал (-20+65), дает нестабильность до 20 ppm, а это много.

Много для чего?

2 часа назад, dmitrykhom сказал:

У кварца 32768 эта нестабильность в разы меньше. Устройство будет стоять на холоде включенным без синхронизации, и за сутки отстанет/набежит больше положенной 0,5 секунды.

Не очень понятно - что именно вас не устраивает? Мгновенная нестабильность больше чем на N ppm? Или уход часов за какое-то время более чем на N сек?

Если 2-е, то я вам выше описал способ решения. Похоже что вы ничего не поняли. Советую ещё раз внимательно перечитать. Какая разница - какая нестабильность у 25МГц кварца, если вам важен только уход часов за долгое время?

Если важно 1-е, то тогда только тактировать CPU от качественного (термостатированного или термостабилизированного кварца или генератора), а не от чего попало.

2 часа назад, dmitrykhom сказал:

Никакие приоритеты здесь не помогают, все виснет глухо.

Ну это вроде как - само собой разумеется.