rw6cm писал(а): ↑21.03.2020{, 06:55}
Эта цифра ровным счетом не о чем не говорит
Ув. Владимир, цитируемая Вами вступительная часть моего сообщения не является вопросом, а констатацией факта. Конечно же эта цифра ни о чём не говорит, кроме как вскрывает качественную оценку нашего форума как технического, т.е. для целевой аудитории и Ваш ответ подтверждает это, как и то, что из 228 страниц списков зарегистрированных пользователей форума (11364 человек) только 1993 что-то, когда-то сообщили/спросили и то не факт что по-делу. Несомненную пользу "мёртвых душ" описал ещё Н.В.Гоголь, но я ведь и не спорю, правда? Да, я понимаю, что нехорошо, провокативно-манипулятивной частью своей фразы привлекать внимание к проблемам компетентных специалистов, рискуя при этом похоронить чужую тему высказываниями многосамоуважающих себя и себе подобных плюсователей-хотюнов - стратегов развития, гуманитариев занимающихся лингвистическими, этическими, межнациональными аспектами общения и прочих поучателей жизни не свойственные технарям. Но мне повезло и я общаюсь с Вами- технарём и по аналогии с нашим предыдущим общением, есть большая вероятность извлечь практическую пользу не только мне и пользователям, но и надеюсь Ув. автору, который анонсировал предстоящую редакцию функциональных блоков программы и надеюсь Вам лично. Нет, я не пытаюсь навязать свою точку зрения, не собираюсь спорить,- я хочу разобраться со свой проблемой, которой раньше не существовало и которая возможно имеет общее с проблемой ув. ТС.
Извините за длинное вступление, разрешите обосновать свою точку зрения по данной теме и внести конкретное предложение.
Итак, что происходит если два параллельно протекающих независимых процесса пытаються получить одновременно доступ к определённым регистрам данных в однопоточной системе. Предполагаю, что процесс с меньшим приоритетом будет проигнорирован или, при наличии механизма, поставлен в очередь. А если в процессе находящемся в очереди произойдут события в этот момент (изменятся данные, поступит отличная от предыдущей команда и т.п.)? В обоих случаях, опять же при отсутствии определённого механизма обработки, произойдёт потеря данных,- т.е. ошибка, которая к тому-же будет накапливаться. Теперь предположение на логику. Какому процессу из двух взаимозависимых периодических будет присвоен более высокий приоритет. Очевидно тому, который должен происходить реже. Но вот ожидаемо более редкий процесс начинает чаще слать запросы, чем было предусмотрено внутренней структурой устройства и назначенными приоритетами. Потому я озадачился вопросом: зачем забирать данные с регистров RTC 4 раза, которые меняются 1 раз в секунду, увеличивая этим вероятность пропуска при одновременном обращении к памяти (RAM) процессов считывания и инкремента\записи текущего времени из\в регистры хранения? Мы хотим облегчить код\освободить ресурсы МК, которые во проштудированных мной библиотеках занимаются самостоятельным расчётом секунд и только раз в минуту синхронизуются с RTC? Но ведь тогда нагружается шина данных I2C и связанные с ней процессы, а также нагрузка на RAM микросхемы RTC. По сравнению с упомянутой мной библиотекой iarduino.h нагрузка на шину возросла в 240 раз или 4 раза в секунду напротив 1 раза в минуту, но при синхронизация с ПК при установке времени заметно возросла точность установки! В некоторых других биб-ках опрос делают 1 раз/сек.
Теперь предложение: вместо определения сумы стартового времени + периода в каждом цикле и сравнения с текущим значением ф-и millis(), единожды при выполнении условия определять эту суму и сравнивать в каждом цикле с готовым результатом в базовой ф-и для таймеров, генераторов, блоков RTC … bool _isTimer(unsigned long startTime, unsigned long period )
Т.Е. вместо строк:
if (currentTime>= startTime) {
return (currentTime>=(startTime + period));
startTime = millis();}
записать
if (millis()>=startTime) {
*startTime = millis()+period;
return true;
}else return false;
Другими словами сохранять вместо прошедшей точки отсчета и суммирования в каждом цикле с потерей результата, единожды определённое значение ожидаемого времени.
Что касается ув. TS, приняв во внимание:
KostiK2009IT писал(а): ↑14.03.2020{, 11:33}
взял ds3231 из другого проекта, в котором они точно работали
KostiK2009IT писал(а): ↑17.03.2020{, 17:01}
убегание времени может случаться из-за частого опроса часов
rw6cm писал(а): ↑21.03.2020{, 06:55}
подумал что Автор в новой версии что то изменил
Да изменил!
Потому можно для эксперимента
1. Синхронизовать RTC c ПК, дать модулю передышку на несколько дней без внешнего питания (только батарейное) без подключения к Ардуино и спустя проверить разницу с ПК. В принципе это же предлагает ув.Владимир.
2. Вручную изменить в скомпилированном проекте строку кода if (!(_isTimer ((timeStruct ->startTime), 250))) на if (!(_isTimer ((timeStruct ->startTime), 24000))) например и не обращая на уплывшие на дисплее секунды вывести данные в монитор порта и сравнивать их с ПК при обновлении данных.
3. -Удалил- фигня всё это.
У меня всё, свою проблему решу сам, в помощи не нуждаюсь! Указываю
ИСТОЧНИК моих разбушевавшихся фантазий.
.
. За время от моего крайнего сообщения в этой теме 22 марта (синхронизация) мои RTC DS1307 до 17 апреля опаздывают на 29 сек без подключения и внешнего питания. За двое суток прогона в Вашем проекте (не уследил за разрядом аккумулятора внешнего питания) отставания вообще 0 (при опросе 4раза/сек. ) если "это" вообще нельзя назвать статистикой