Я чего-то недопонял, или действительно так :


Допустим в программе во многих местах нужно знать время. Время хранится в какой-то глобальной переменной.
Очевидно что каждую секунду нужно читать из RTC новое время . Но вот-тут загвоздка.
Никакого прерывания происходящего точно в момент изменения секунды в RTC нет.
Остаётся читать время из RTC в прерываниях RTC_Wakup или в прерываниях любого другого таймера.
Но тогда изменения секунд в переменной будут не синхронизированы с тиканьем реальных секунд в RTC , или нужно читать RTC очень часто.

Читать непосредственно в момент когда время понадобилось то же неудобно, потому как что бы прочитать время нужно сбросить флаг RTC_ISR_RSF того что дата и время скопированы в буферный регистр, и ждать пока он выставится.

Явное неудобство

Решение навскидку:
Читать значение RTC в прерывании какого-то таймера (частоту прерывания выставить в соответствии с необходимой точностью обнаружения момента изменения RTC).
По обнаружению изменения значения RTC, перепрограммировать частоту на период немного меньше секунды.
После получения этого прерывания, опять установить большую частоту прерывания до изменения RTC. и так далее. Надеюсь идея ясна.

Или решение проще: перейти на LPC - там в RTC есть все необходимые прерывания

А будильника там тоже нет?

Есть



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

А просто - когда нужно узнать время - залезть в RTC и узнать?
О, вижу, топикстартер уже отверг эту идею. В начальной редакции вопроса этого не было.

Нехватки каких ресурсов?

Много прерываний одновременно, из-за это что-нибудь не успеет обработаться и т.п.

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

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

Да, пожалуй.
Но и это кривовато. Что бы завести будильник надо отключить защиту, подождать пока какой-то бит установится.

Не понимаю, зачем столько защиты от записи в RTC ? Если случайно не то запишется в регистры любой другой периферии это точно так же приведёт к краху программы.

ртц то небось на внешнем кварце, это просто синхронизация 2 клоковых доменов... наверное

было у меня устройство с часиками внешними, как раз по такому принципу, ставило себе будильник на 5 секунд вперед, и засыпало сном младенца. По будильнику вставала, делало все свои дела, заводило будильник и спать...

Мне вот что не понятно, если у вас устройство не спит, нафига с РТЦ то мучиться, заведите таймер на милисекундный- секундный тик, и работайте по нему. РТЦ ИМХО для чего то более длительного, по нему можно что-то уточнять раз в минуту, част, день, но ни долбить его как интервальный таймер. ИМХО

устройство не вещь в себе, а как-то взаимодействует с окружающим миром, и момент изменения секунд именно в RTC принципиален.

На вопрос "всё ли я верно понимаю ? " я ответ получил. Тему можно закрывать.

Вы сами, исходя из частоты CPU, его загрузки, кол-ва прочих прерываний и пр. должны определить частоту для таймера, которая не помешает остальным ISR.
Иначе, следуя вашей логике, вообще никакие прерывания (асинхронные одно относительно другого) нельзя использовать, так как они могут
наложиться и "что-нибудь не успеет обработаться"

не совсем понятно почему просто не использовать секундные прерывания от RTC_wakeup?

Разобрался. RTC Alarm можно настроить так что бы оно срабатывало каждую секунду, без перенастроек заново