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

[Zhuk72]

[uquote="jcxz",url="/forum/viewtopic.php?p=3883898#p3883898"]Я прочитал раз 10. Но так и не понял - о чём речь??? Причём тут какие-то микросекунды? И откуда вы знаете сколько мкс нужно автору на чтение RTC-чипа в его системе?[/uquote]
Подумаешь, бином Ньютона (с)
В этой DS3234 SPI работает вплоть до 4 МГц. Соответственно требуется 2 мкс на байт (я это, кстати, выше писал уже). Часы/минуты/секунды - это 3 байта, хотя по вашим словам читать надо всю память. ОК, 26 байт * 2 = 52 мкс, это не считая времени на сохранение в памяти результатов в случае отсутствия DMA. После этого надо сформировать данные для дисплея.

[uquote="jcxz",url="/forum/viewtopic.php?p=3883898#p3883898"]Если читать для того чтобы прочитанное отображать на индикаторе, то 1 секунда здесь - слишком большой интервал. Выглядеть будет ужасно. Попробуйте как-нить сделать так сами - поймёте почему.[/uquote]
У меня нет 6-разрядного индикатора, да и не вижу ничего страшного в обновлении показаний ВРЕМЕНИ раз в секунду.
Естественно, речь не идет о периоде динамической индикации, а именно об обновлении информации.

[jcxz]

[uquote="Zhuk72",url="/forum/viewtopic.php?p=3883921#p3883921"]В этой DS3234 SPI работает вплоть до 4 МГц. Соответственно требуется 2 мкс на байт[/uquote]А теперь вспоминаем что SPI - это шина. На которой может сидеть множество устройств. А это значит, что не всегда возможно начать обмен с нужным слэйвом на ней сразу же, как только захотел. А нужно подождать до завершения текущей транзакции с другим слэйвом. А значит - длительность от момента "хочу узнать время" до момента "время получено" будет зависеть от длительности максимальной транзакции с любым устройством на шине и от приоритета доступа RTC-драйвера к шине.
Когда я писал про максимальное время чтения RTC в моей системе, я как раз имел в виду эти моменты. Так как например у меня на одной шине с часами сидит 5 шт. разных чипов-слэйвов.

[uquote="Zhuk72",url="/forum/viewtopic.php?p=3883921#p3883921"]У меня нет 6-разрядного индикатора, да и не вижу ничего страшного в обновлении показаний ВРЕМЕНИ раз в секунду.[/uquote]Индикатор подойдёт любой. Ну если трудно догадаться что за проблемы возникнут, то разжую подробно:
Как только окажется, что момент чтения времени из RTC-чипа оказывается где-то близко к границе смены секунды в RTC, то, из-за того что в МК-системе всегда есть какой-то джиттер (транзакций чтения на шине), то этот самый момент он начинает случаться то с одной стороны от границы смены секунды, то с другой. И тогда читаемый результат будет например: 0, 1, 2, 2, 4, 5, 6, 7, 8, 8, 10, 11, ....; т.е. - то залипание на 2 секунды показаний, то перескок через одну. И выглядит на глаз это очень погано.
Если же читать 10 раз в секунду - то индикация на глаз уже равномерная.
Чем больше устройств на шине - тем больше джиттер; чем больше задач в системе (и обработчиков прерываний) - тем больше джиттер. Также увеличивает эту нестабильность например работа SNTP-службы (если имеется, у меня есть).

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

[BOB51]

Все зависит от задачи.
Цеплять RTC с практически постоянным доступом на одну шину с множеством других устройств не слишком рационально.
Другое дело - ежли опрос однократный с дальнейшей работой по прерываниям.
Да и программную реализацию обмена "ногодрыгом" всегда можно сделать.
Это уже конкретика в каждом случае - ТВОРЧЕСТВО.

[Zhuk72]

[uquote="jcxz",url="/forum/viewtopic.php?p=3884005#p3884005"]И тогда читаемый результат будет например: 0, 1, 2, 2, 4, 5, 6, 7, 8, 8, 10, 11, ....; т.е. - то залипание на 2 секунды показаний, то перескок через одну. И выглядит на глаз это очень погано.
Если же читать 10 раз в секунду - то индикация на глаз уже равномерная. [/uquote]
Я сейчас не буду углубляться. Но надеюсь я получу заказанный более 3-х месяцев назад 8-разрядный индикатор с 74HC595, никогда не имел дела с такими регистрами, хочется поиграться. Тогда я надеюсь слеплю часы с секундным обновлением показаний и выложу видео (если опять не наступит кризис интереса).
У меня, правда, есть в наличии МАХ7219, но возвращаться к старой игрушке не хочется.

[jcxz]

[uquote="BOB51",url="/forum/viewtopic.php?p=3884255#p3884255"]Цеплять RTC с практически постоянным доступом на одну шину с множеством других устройств не слишком рационально.[/uquote]Про постоянный доступ - это Вы загнули. Я замерил за какое время программные часы на МК накапливают ошибку >=1сек, это время составило насколько помню - около 4 часов. Поэтому поставил период подсинхронизации программных часов с RTC таким, чтобы к этому моменту накопилась ошибка <200мсек. В таком случае можно рассчитать довольно точно время когда надо начинать периодическое (10Гц) чтение RTC таким образом, чтобы найти точку перехода через границу секунды за минимальное число чтений RTC. На практике у меня получается на поиск перехода границы секунды до 10-11 чтений нужно только при старте программы, а последующие подсинхронизации - обычно не более 2-3 чтений. И делается это раз в несколько десятков минут.
Так что - до постоянного доступа тут очень далеко.
Ну и конечно ограничил длительность транзакций для других слэйвов. Это касается в первую очередь I2C FRAM - ограничил размер непрерывной транзакции с ней 512-ю байтами. Т.е.: 512*9/(300000...400000) = 0.01536...0.01152 сек. Такая задержка на доступ к шине нисколько не мешает чтению RTC.

[uquote="BOB51",url="/forum/viewtopic.php?p=3884255#p3884255"]Да и программную реализацию обмена "ногодрыгом" всегда можно сделать.[/uquote]Это последнее что стоит делать. Лучше 10 слэйвов на нормальном аппаратном I2C с DMA чем ногодрыжный колхоз.
Да и свободных ног у МК в этом проекте уже почти не осталось. Там и так - 5 слэйвов на I2C, 2 слэйва на одном SPI и 2 слэйва - на другом.