Подключил я DS3234 к микроконтроллеру...

[Shuspano]

И не знаю что дальше делать. Нет, не о том как прочитать-записать, регистры-биты - из даташита все понятно.
Поскольку время тикает внутри этой микрухи, и она никак не сообщает о смене показаний, надо как-то его узнавать, но как - не могу решить. Есть у меня два варианта:
1 вариант. микросхема генерирует импульсы с частотой 1гц (она умеет), эти импульсы вызывают прерывание МК, обработчик прерывания читает показания через SPI, кладет их в память, дальше там чего-то происходит, и это выводится на индикатор. Все красиво, но я лишаюсь прерывания от будильника, т.к вывод INT/SQW совмещен.
2 вариант. Микроконтроллер крутится в цикле, и ожидая смены показаний, постоянно опрашивает микруху. Так как тактовые генераторы часов и контроллера не синхронизированы, МК будет время от времени будет пропускать момент смены показаний. Значит, частота опроса должна быть высокой. Микроконтроллер загружен этим циклом, втискивать в этот цикл какие-то функции - сложно.
В общем, стою как буриданов осёл, пытаюсь догнать чего делать. А как бы это сделали вы?

[Ivanoff-iv]

заведи ему таймер, так, чтобы прерывание давал 5-500Гц (5-10 для статики или лсд дисплея со своим контроллером, а 400-500 для 7сегментной динамической индикации)
и отплясывай от этого такта (ставь от него свои программные счётчики)-
например часовую микросхему нет смысла опрашивать чаще 10Гц
кнопки тоже 5-10 Гц за глаза...
а вот для дин. индикации надо хотябы 100Гц на оборот дисплея, если в нём 5 разрядов (4 цифры и двоеточие) то дисплей приэётся переключать 500 раз в секунду.
и.т.д...

[Novice user]

Сделать будильники в программе,а не в DS-ке

[Ser60]

Ещё вариант запрограммировать один из алармов DS-ки на прерывание каждую секунду (или минуту), а другой - на будильник. При генерации прерывания на выводе IRQ читать регистр статуса DS-ки, чтобы узнать что произошло.

[Shuspano]

Забыл сказать что динамической индикации, по крайней мере, на МК - не будет. Рещил применять всем известную плату "LED&KEY" - там индикатор, там кнопки, а аппаратность происходящего там снимает задачу по вкорячиванию динамической индикации в программу. Плюс, я пару лет назад написал к ней библиотеку подпрограмм. Огорчает только несовместимость с аппаратным SPI контроллера STC12C5A60S2
Насчет того чтоб читать флаг будильника из регистра DS-ки, а не обрабатывать его как событие - да, вполне нормальная идея.

[jcxz]

Shuspano писал(а):

В общем, стою как буриданов осёл, пытаюсь догнать чего делать. А как бы это сделали вы?

Веду программные часы (32-битный счётчик инкрементируемый каждую секунду), где и храню текущее время. А при старте ПО синхронизирую эти программные часы с RTC-чипом, для чего читаю этот чип 10 раз в секунду пока не обнаружу момент смены показаний.
Также периодически (раз в несколько десятков минут) выполняю ресинхронизацию программных часов с RTC-чипом (так как RTC-чип имеет бОльшую точность, чем кварц МК). Ресинхронизация - таким же способом, как начальная синхронизация при старте ПО.

Shuspano писал(а):

Микроконтроллер загружен этим циклом, втискивать в этот цикл какие-то функции - сложно.

Я читал через каждые 100 мс. А за это время (100 мс) много чего можно сделать…

[Zhuk72]

А в чем смысл чтения из DS чаще, чем раз в секунду?

[jcxz]

Zhuk72 писал(а):

А в чем смысл чтения из DS чаще, чем раз в секунду?

Смысл очевиден - узнать момент перехода времени через границу секунды. Т.е. - узнать время с точностью выше 1сек.

[BOB51]

Для такого случая RTC ставить смысла нет - вполне внутренние программные справятся (с предзагрузкой данных из RTC при включении питания).
А будильник все равно только с дискретом в секунду выставляется - так что опроса раз в секунду вполне достаточно будет.

[Zhuk72]

jcxz писал(а):

узнать время с точностью выше 1сек.

Это понятно. Смысл непонятен.
Что автор собирается отсчитывать с такой точностью. Сам МК тоже может секунды считать, а погрешности будут примерно сравнимыми с задержками, полученными в процессе получения информации от часов и распаковке данных.

BOB51 писал(а):

Для такого случая RTC ставить смысла нет - вполне внутренние программные справятся (с предзагрузкой данных из RTC при включении питания).

Если плевать на перескоки секундного отсчёта, то да - "смысла нет". При выводе отсчёта секунд на дисплей заметны перескоки… а при чтении хотя бы раз в 100 мс, перескоков не наблюдается, секунды «тикают» ровно.

[BOB51]

Многое от программы зависит...
Интервал между чтением пакета и выводом на индикацию может весьма различаться...

[jcxz]

BOB51 писал(а):

Для такого случая RTC ставить смысла нет - вполне внутренние программные справятся (с предзагрузкой данных из RTC при включении питания).

Прочитайте выше - я как раз так и делаю: веду программные часы (по клоку МК) периодически подсинхронизируя их с RTC (ну и при старте ПО конечно тоже).

Добавлено after 5 minutes 2 seconds:

Zhuk72 писал(а):

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

Сравнимыми?? Да ладно? Даже у меня по I2C часы читаются за какие-то максимум <20 мсек (с учётом арбитража шины, так как на шине висит ещё несколько слэйвов), а у автора - SPI, там ещё быстрее. А время распаковки/преобразования вообще тут не при делах.

[Zhuk72]

jcxz писал(а):

Даже у меня по I2C часы читаются за какие-то максимум <20 мсек (с учётом арбитража шины, так как на шине висит ещё несколько слэйвов), а у автора - SPI, там ещё быстрее. А время распаковки/преобразования вообще тут не при делах.

PIC16F18446 (хотя это и не имеет значения), работающий от внутреннего генератора без дополнительной калибровки. Под спойлером - диаграмма, снятая с мигающего каждые 500 мс светодиода по прерыванию таймера.

Спойлер

Как видите на каждую секунду погрешность всего 60 мкс.
Время, затраченное 4 МГц-вым SPI, на считывание хотя бы только 3-х байт текущего времени составит 6 мкс минимум.
Итак, МК

читает показания через SPI, кладет их в память, дальше там чего-то происходит, и это выводится на индикатор

"Чего-то там", т.е. преобразование данных BCD в формат индикатора (предполагаю, что это что-то типа ТМ1637/1638), вы почему-то не учитываете, а это тоже время и вы не сможете сказать, во что это выльется у автора вопроса.
И что же, какие-то пара-тройка десятков +/- микросекунд в каждой секунде стоят того, чтобы городить огород со считыванием показаний 10 раз в секунду для БЫТОВЫХ часов?
Я не говорю, что поправка не нужна. Раз в секунду вполне достаточно для обновления памяти часов в МК, а вывод секунд на индикатор вполне можно поручить тикалке самого МК.

[BOB51]

В принципе реакция глаза не обнаружит отклонение менее 0,02 секунды (+/- задержка развертки одной строки динамической индикации).
Кроме прочего - зачем каждый раз ВСЕ содержимое считывать то?
Выбираем соответствующий "критичный" регистр и его вычитываем.
Обработка содержит исключительно минимум необходимого и всегда одинакова по длительности.

[Shuspano]

Хочется, чтоб точность часов ограничивалась только точностью кварца. Но для этого, видимо, надо на логике собирать.

BOB51 писал(а):

Обработка содержит исключительно минимум необходимого и всегда одинакова по длительности.

Нет, надо читать все, что есть в ртц, и в каждом цикле все это одинаково обрабатывать, чтоб все подпрограммы завершались за детерминированное время. Тогда ошибка станет постоянной.

[jcxz]

Zhuk72 писал(а):

И что же, какие-то пара-тройка десятков +/- микросекунд в каждой секунде стоят того, чтобы городить огород со считыванием показаний 10 раз в секунду для БЫТОВЫХ часов?

Какие микросекунды? Вы о чём вообще??? У меня чтение производится по I2C, а не по SPI и занимает - я выше писал сколько времени.

Zhuk72 писал(а):

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

Что такое "раз в секунду"? Что делать "раз в секунду"? Не понимаю Вас....
Если Вы про синхронизацию, то я её выполняю не раз в секунду, а гораздо реже - раз в несколько минут. Этого достаточно - кварц в МК достаточно точен чтобы не успеть сильно отклониться от времени RTC за эти несколько минут.
А сама синхронизация (выполняемая раз в несколько минут) выполняется многократным чтением (с частотой 10Гц) содержимого RTC. Чтение выплняется до тех пор, пока не будет найден момент прехода через границу секунды.

Добавлено after 5 minutes 58 seconds:

BOB51 писал(а):

Кроме прочего - зачем каждый раз ВСЕ содержимое считывать то?

Это Вы о ком? Кто читает "всё"? Автор? Он вроде не писал про это... Да может и читает. А какой смысл читать один регистр, а потом отдельно - остальные? Чтобы код усложнить?
Если можно читать сразу все регистры времени часов - лучше так и делать, единой транзакцией. Но надо ещё посмотреть - позволяет ли так делать RTC-чип.

BOB51 писал(а):

Выбираем соответствующий "критичный" регистр и его вычитываем.

А если такого регистра нет? Что прикажете читать?

[Zhuk72]

jcxz писал(а):

Какие микросекунды? Вы о чём вообще???

Вы или невнимательно прочитали написанное мной или не вникли в прочитанное. Писать по второму кругу у меня желания нет.
Если вкратце, то я говорил о мизерной разнице (пара-тройка десятков микросекунд) между секундным интервалом, полученным тикалкой МК и секундой, полученной от DS.

jcxz писал(а):

Что делать "раз в секунду"? Не понимаю Вас....

Читать данные из DS.

[jcxz]

Zhuk72 писал(а):

Вы или невнимательно прочитали написанное мной или не вникли в прочитанное.

Я прочитал раз 10. Но так и не понял - о чём речь??? Причём тут какие-то микросекунды? И откуда вы знаете сколько мкс нужно автору на чтение RTC-чипа в его системе?

Изначально я говорил о своём алгоритме работы с часами (5-е сообщение в теме). И предложил ТСу делать аналогично. только и всего....

Добавлено after 2 minutes 1 second:

Zhuk72 писал(а):

Читать данные из DS.

Если читать для того чтобы прочитанное отображать на индикаторе, то 1 секунда здесь - слишком большой интервал. Выглядеть будет ужасно. Попробуйте как-нить сделать так сами - поймёте почему.