arduino 2560 и таймер

loginex
Offline
Зарегистрирован: 19.02.2012

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

Время синхронизирую через один из serial портов. Одно устройство на другое высылает то, что возвращает функция millis(), другое устройство сравнивает его со своим выводом millis(), высчитывает дельту.

И вот на этом моменте я заметил, что раз в 3 секунды эта дельта изменяется на 3-5 (т.е. на ~0.004с). Контроллеры находятся рядом, подключены непосредственно через одну пару проводов, так что среду передачи можно исключить. Пробовал менять местами ардуино(т.е. прошивать на них противоположенные скетчи), в итоге все равно таймер убегал один от другого, только уже в противоположенную сторону(т.е. если раньше дельта уменьшалась, то теперть увеличивалась).

Собственно у меня две arduino 2560r2, купленные в одном месте, тактовый генератор у них НЕ кварцевый.

Можно на нее посмотреть тут http://arduino.cc/en/uploads/Main/ArduinoMega2560_r2_front.jpg, хотя на моей схеме так же есть место и под него.

 

loginex
Offline
Зарегистрирован: 19.02.2012

вот еще тут обсуждалось

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1215338347

Portik
Offline
Зарегистрирован: 22.03.2011

 Немного в сторону, но с помощью GPS модуля, можно синхронизировать время по спутникам.  Сам правда не делал такого. Но я так понимаю это стандартная фича GPS

loginex
Offline
Зарегистрирован: 19.02.2012

Так, во первых я опечатался, я там выше писал про 16кгц, я имел ввиду конечно же 16мгц.

С помощью gps можно синхронизировать время, но это будет явно не проще, чем между двумя ардуино, которые стоят сейчас рядом. Дело в том, что один из таймеров на этих двух ардуино относительно другого идет немного быстрее.. ну примерно с разницей на 0.005%.

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

Portik
Offline
Зарегистрирован: 22.03.2011

 Ну может если они рядом, то сделать дополнительную линию, по которой первая ардуино у второй будет дерагать внешнее прерывание, вторая будет фиксировать время этого прерывания по ее таймеру. Затем получать по serial от первой время, когда та дернула согласно ее таймеру и делать корректировку. Задержка будет минимальной.

zhuki
Offline
Зарегистрирован: 12.10.2011

Зачем вы синхронизуруетесь по СОМ порту? Мне кажется из этого ничего не выйдет. Я бы на вашем месте соединил 1,4 ,а лучше 8 выводов на двух контроллерах. Создал своего рода шину данных и гонял бы там ,что нужно. Я считаю это по надёжнее. Тем более у вас портов масса. 

loginex
Offline
Зарегистрирован: 19.02.2012

Рядом это они пока стоят, потом будут удаленно через serial общаться. И чтобы показания снимались точно - надо чтобы и время шло точно, а у них часы с разной скоростью идут.

zhuki
Offline
Зарегистрирован: 12.10.2011

Всё равно тактирование вам необходимо. СОМ порт не сможет вам выдать такое ,там задержки, ошибки. Да и по длинне тоже ограничение есть. Ещё могу предложить тактировать внешними импульсами(независимый генератор).Можно синхронизировать оба контроллера и они одновременно будут снимать ваши данные.

 

loginex
Offline
Зарегистрирован: 19.02.2012

передавать можно много данных, я их посимвольно считываю, а отправлять мне за раз более unsigned long не надо.

Ошибки, задержки и прочее - это понятно, но это ТЕЛЕМЕТРИЯ, да еще и на таких расстояниях, что мне проще по оптике serial сделать, хотя на самом деле будет радио... НО!!! пока часы будут убегать - нельзя говорить  ни о какой точности совместных измерений... Хоть 10 раз пересинхранизируйся, со временем полученный результат будет все дальше от истинного.

В общем какая точность получится - это еще надо будет эксперемент проводить(и уже разрабатывать нужные алгоритмы и методы синхронизации), пока лишь голова болит по поводу убегающих часов =(

zhuki
Offline
Зарегистрирован: 12.10.2011

Часы то как построены? Программные или аппаратные?

loginex
Offline
Зарегистрирован: 19.02.2012

ну я про millis(). На одном из двух устройств он идет быстрее относительного другого.

carduino.ru
Offline
Зарегистрирован: 06.12.2011

А кварцы перепаять? 

loginex
Offline
Зарегистрирован: 19.02.2012

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

step962
Offline
Зарегистрирован: 23.05.2011

loginex пишет:

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

Читаю я эту ветку и никак в толк взять не могу - почему вы хотите реализовать вариант именно с двумя синхронными и одновременно независимыми часами? Чем вас не устраивает вариант с одними-единственными часами? При точ точности, что вас устраивает (сотые доли секунды) что вариант с часами на микроконтроллере-приемнике данных, что вариант с часами на микроконтроллере-сборщике/передатчике данных реализуется без проблем:

Эти единственные часы идут с доступной им точностью, в нужные моменты времени обладатель часов отправляет в COM-линию команду на выполнение соответствующих действий, другое устройство отрабатывает эту команду даже не зная о том, "а который сейчас час?". Даже на скорости 9600 бит/с на передачу пакета из 10 символов требуется всего та самая 1/100 доля секунды... Пакет данных у вас длиннее? Так введите соответствующее упреждение в алгоритм.

Где необходимость в двух независимо идущих часах? Что заставляет запускать процесс сбора и отправки данных по своим собственным часам, а не по "сигналам точного времени" от микроконтроллера-регистратора? Или что мешает в пакете передаваемых данных телеметрии дополнительно отправлять и информацию о времени, например "ччммсс,ххх", где ххх - микросекунды? 

Не понимаю...

loginex
Offline
Зарегистрирован: 19.02.2012

>Даже на скорости 9600 бит/с на передачу пакета из 10 символов требуется всего та самая 1/100 доля секунды...

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

если не понимаете зачем это надо, то вот я напрямую напишу условия.

есть объект А и объект Б, между которыми некоторое большое расстояние(например 500м). Нужно вычислить время между срабатыванием триггера на А и триггера на Б с точностью до сотых или лучше тысячных секунды.

Как такое реализовать, учитывая что объект А и объект Б связаны между собой весьма ненадежной средой передачи данных(радио) ? Мне видится так: 1) синхронизируются часы 2) на объекте А или Б отсылается время срабатывание триггера на противоположенный объект 3) там оно сравнивается со временем срабатывания локального триггера и получаем результат.

loginex
Offline
Зарегистрирован: 19.02.2012

Ужас... перешел с арудино-021 на арудино-1.0 - и теперь часы идут точно.... никто никуда не убегает

step962
Offline
Зарегистрирован: 23.05.2011

loginex пишет:

>Даже на скорости 9600 бит/с на передачу пакета из 10 символов требуется всего та самая 1/100 доля секунды...

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

Наличие или отсутсвие синхронизированных часов на надежность связи никак не влияет. Данные могут потеряться даже при отсутствии  разбега часов в пункте А и пункте Б.

Цитата:

есть объект А и объект Б, между которыми некоторое большое расстояние(например 500м). Нужно вычислить время между срабатыванием триггера на А и триггера на Б с точностью до сотых или лучше тысячных секунды.

Как такое реализовать, учитывая что объект А и объект Б связаны между собой весьма ненадежной средой передачи данных(радио) ? Мне видится так: 1) синхронизируются часы 2) на объекте А или Б отсылается время срабатывание триггера на противоположенный объект 3) там оно сравнивается со временем срабатывания локального триггера и получаем результат.

Мне видится так:

- выбирается главный микроконтроллер

- главный микроконтроллер следит за своим триггером и при его срабатывании запоминает время А по своим неточным часам. Кроме того он слушает радиоканал и при получении пакета информации также запоминает момент его прихода Б (для большого пакета - начало приема). разница между временем А и временем Б и есть, то, что вы ищете

- вспомогательный контроллер не имеет часов (не следит за ними) вообще. Он лишь следит за своим триггером и в момент его срабатывания формирует и отправляет пакет телеметрии.

- если при передаче/приеме произошел сбой, то делаем то же самое, что и в варианте с двумя суперхронометрами - горюем об упущенной возможности рассчитать время между моментами А и Б.

В моем методе есть постоянная погрешность -  1,7 микросекунды. Это время прохождения светом (радиоволной) расстояния в пятьсот метров между микроконтроллером Б к микроконтроллером А. Но эту погрешность можно элементарно учесть в программе.

step962
Offline
Зарегистрирован: 23.05.2011

loginex пишет:

Ужас... перешел с арудино-021 на арудино-1.0 - и теперь часы идут точно.... никто никуда не убегает

Совершенно случайно это совпало с изменением температуры одного из микроконтроллеров (=резонаторов) на пару градусов, что привело к соответствующему уходу (в вашем случае - скорее приходу) частоты.

О чем это я? Завтра проблема может появиться вновь, даже при условии работы в Arduino 1.0 - уж больно высока нестабильность керамических резонаторов (в том числе и температурная).

loginex
Offline
Зарегистрирован: 19.02.2012

Наличие или отсутсвие синхронизированных часов на надежность связи никак не влияет. Данные могут потеряться даже при отсутствии разбега часов в пункте А и пункте Б.

Вы забываете, что потерянные данные можно переотправить снова через промежуток времени и это не так критично.

- если при передаче/приеме произошел сбой, то делаем то же самое, что и в варианте с двумя суперхронометрами - горюем об упущенной возможности рассчитать время между моментами А и Б.

А вот это уже недопустимо, иначе не стоит даже и браться.

В моем методе есть постоянная погрешность - 1,7 микросекунды. Это время прохождения света (радиоволны) от микроконтроллера Б к микроконтроллеру А. Но эту погрешность можно элементарно учесть в программе.

Это скорее в теории, на практике все зависит от среды и помех.

loginex
Offline
Зарегистрирован: 19.02.2012

step962 пишет:

loginex пишет:

Ужас... перешел с арудино-021 на арудино-1.0 - и теперь часы идут точно.... никто никуда не убегает

Совершенно случайно это совпало с изменением температуры одного из микроконтроллеров (=резонаторов) на пару градусов, что привело к соответствующему уходу (в вашем случае - скорее приходу) частоты.

О чем это я? Завтра проблема может появиться вновь, даже при условии работы в Arduino 1.0 - уж больно высока нестабильность керамических резонаторов (в том числе и температурная).

Может и действительно так, а может и не совсем. Как бы были и раньше проблемы в версии 11, насколько я помню, с вызовом millis() и системой прерываний, что в итоге часы сбивались(ссылка выше). Хотя не знаю как IDE там на компиляцию повлияла.

rndvip
Offline
Зарегистрирован: 04.03.2012

Наткнулся на данную тему, судя по всему делаю тоже самое что и топикстартер.

Имею теже самые проблемы.

loginex как с Вами можно связаться, хотелось бы задать несколько вопросов.

 

loginex
Offline
Зарегистрирован: 19.02.2012

Можно спрашивать здесь, я слежу за темой. Проблема пока еще не решена, но кое-какие мысли есть.

rndvip
Offline
Зарегистрирован: 04.03.2012

Что у меня есть и что пробывал...

Две платы, два переходника(шилда) для XBee, один переходник usb XBee, ну и три XBee PSO S1

Один XBee сидит на ноуте и является базой, слушая и общаясь с 2 "воротами" (плата+шилд+XBee)

Сразу после процедуры синхронизации удается добиться точности +-1 мс, я не могу сделать ее гарантированно(как не крути радио сигнал) равной нулю. Да в большинстве случаем некоторое время "часы" на обоих воротах идут одинаково... но потом появляется некая погрешность...

Время на базу от платя получаю двумя способами:

1 - отправляя запрос на то чтоб ворота выслали мне время

2 - срабатывание на внешние события подавая на 12 пин +5в(срабатывает внешние 12В реле от пересечения ик луча)

При первом варианте ситуация как у Вас...

Пробывал питать платы от юсб, от акб безперебойника. При питании от 12В АКБ плата нагревается и разность температуры генератора на плате питающейся от юсб и акб составляет 7-8 градусов. Думал в этом причина, менял способы питания - ситуация не меняется...

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

Но меня больше напрягает ситуация номер два - в независимости от того как четко удалось синхронизировать время, время возвращаемое платами, при пересечении луча (срабатывает реле) составляет около до 2 мс, причем эта виличина гуляющая  и никакими экспириментами и танцами с бубном не удается определить почему и от чего...

Это рас)))

Теперь два - я так онял Вы сделали некое подобие гарантированной доставки "пакета" содержащего время срабатывание на внешние событие - как Вы определяете что данные "потерялись", те не дощли до базы?

ababak
Offline
Зарегистрирован: 09.01.2012

 А что мешает удаленному датчику отправлять пакет в момент срабатывания датчика без привязки ко времени? С каждым пакетом можно передавать только разницу во времени между срабатыванием датчика и самой посылкой (на случай ошибки в передаче в первый раз)? Таким образом точность будет не зависеть от синхронизации часов.

ababak
Offline
Зарегистрирован: 09.01.2012

rndvip пишет:

Теперь два - я так онял Вы сделали некое подобие гарантированной доставки "пакета" содержащего время срабатывание на внешние событие - как Вы определяете что данные "потерялись", те не дощли до базы?

Это можно реализовать как в пульте ДУ: сразу посылать несколько пакетов, содержащих разницу во времени между временем отправки и временем срабатывания датчика. Принимающая сторона может считать среднее время среди всех полученных пакетов.

rndvip
Offline
Зарегистрирован: 04.03.2012

Я получаю от первых ворот пакет в которм содержится unsignet long (как вы  предлогаете время между срабатывание датчика и отправкой пакета), время сигнала в пути я не знаю, получая пакет на компе я отнимаю то велечину которая пришла и получаю некоторое значения времени, то в которое сработало событие, НО без учета времени на пересылку повоздуху, которая не постоянна(((

А ситуация еще и усугубляется тем что есть еще одини "ворота", они находятся на другом растоянии - и время в пути другое.. получая дельту по времени  я складываю ошибки , тем самым терея точность еще

rndvip
Offline
Зарегистрирован: 04.03.2012

Видимо уже поздно и я плохо воспринимаю...не пойму где связь с гарантированной доставкой...

Тепросто слать например по 3 пакета, с надеждой что хотябы оди дойдет...

Или отсылать пакет до тех пор, пока база не подтвердит что данные приняты - во как))

ЗЫ

Время между срабатывание датчки и временем отправки пакета измеряется 2-3 мс, а так называемый пинг при 9600 по воздуху у меня получился около 75 мс (туда обратно)

loginex
Offline
Зарегистрирован: 19.02.2012

что касается доставки сообщений:

во первых надо контрольную сумму пакета держать, т.к. данные иногда доходят с ошибками, во вторых удостоверяться в получении пакета, иначе же отправлять еще. Это получается почти протокол tcp over serial какой-то, но иначе будут ошибки. Кстати tcp так же вычисляет задержку(т.е. время передачи сообщения от адресатанта до адресата).

я вообще вычисления все провожу без компа, все делается на arduino.

 

 

leshak
Offline
Зарегистрирован: 29.09.2011

 Полагатся на millis(), Imho  не стоит. Слишком оно от кварца зависит, температуры, качества питания и т.п.

Лучше использовать внешнюю микросхему часов. Что-то типа DS1307. Возможно даже получится как-то что-бы оба контроллера опрашивали одну и туже микросхему тогда отпадет вопрос "синхронизации" (но встанет вопрос "а как пробросить I2C по радио каналу").

Если время "ОЧЕНЬ критично", то конечно GPS это лучшие что можно получить в бытовых условиях (если бюджет позволяет).

Возможно "протокол синхронизации" не стоит "изобретать", а попробоватьт разобратся с ru.wikipedia.org/wiki/NTP и упростить его для конкретного случая. Сильно не вникал в него, но по описанию похоже что он призван решать именно такие задачи (по крайней мере, возможно идеи из него почерпнуть получится).

 

 

loginex
Offline
Зарегистрирован: 19.02.2012

leshak речь идет о миллисекундах, даже почти о сотых микросекунд. Всякие RTC дают лишь секунды. Тем Более ваша фраза "Слишком оно от кварца зависит, температуры, качества питания и т.п." справедлива вообще для всех видов часов на основе микроэлектроники, в том числе и DS1307, который тоже тактуется кварцем.

NTP нельзя просто взять и упростить, это вам не функция - а целый протокол. Это все равно как взять за основу модель автомобиля и поставить его на рельсы.

Проще с нуля разработать протокол. Конечно же он будет опираться на те же принципы, что и NTP, без этого никак.

leshak
Offline
Зарегистрирован: 29.09.2011

 

loginex пишет:

leshak речь идет о миллисекундах, даже почти о сотых микросекунд. Всякие RTC дают лишь секунды. Тем Более ваша фраза "Слишком оно от кварца зависит, температуры, качества питания и т.п." справедлива вообще для всех видов часов на основе микроэлектроники, в том числе и DS1307, который тоже тактуется кварцем.

Наверное вы правы. Я предположил что "специальное устройство" будет более точным чем универсальное. Не обратил внимание что она дает только секунды. Но возможно получится найти более точные аналоги. Все-таки потребность  в точном хронометре, хоть и экзотика, но не такая уже и редкая. Возможно, все-таки, есть более специализированые решения в которых эти недостатки учтены. По крайней мере термокомпенсированные - точно есть.

loginex пишет:

Проще с нуля разработать протокол. Конечно же он будет опираться на те же принципы, что и NTP, без этого никак.

Возможно я плохо выразился. Я именно это и имел ввиду. Подсмотреть "принципы", "архитектурные решения", "математику", "примерную структуру пакетов данных" и т.п. Создание NTP-совместимого устройства, конечно, в данном случае не требуется (хотя теоретически возможно, непонятно зачем :) ).

rndvip
Offline
Зарегистрирован: 04.03.2012

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

"удостоверяться в получении пакета" - каким именно сопособ вы это делаете? Я вижу только один способ - посать пакет на базу до тех пор пока база не подтвердит его прием...но возможно же что и от базы будут потери(пакет подтверждения приема)...

Я не считаю задержку передачи сигнала каждый раз, есть ли в этом необходимость?

Я использую комп - так как намного наглядней, удобней (для меня) , экспорты в эксель резалтов и тд.

leshak
Offline
Зарегистрирован: 29.09.2011

А можно применить такой подход: Взять две  DS3231 (высокоточные, с тепмостабилизированным кварцем, предназначенные для телеметрии), засихронайзить их "когда они рядом". Потом, когда они будут далеко "друг-от друга", брать с них "начало секунды", а ее доли отсчитывать уже по millis(). Или даже взять с них-же "выход прямоугольного сигнала с программируемой частотой" завести его на ногу контроллера и повесить на нее прерывание. Тогда даже "доли секунды" не будут зависить от температуры и питания.

ababak
Offline
Зарегистрирован: 09.01.2012

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

rndvip
Offline
Зарегистрирован: 04.03.2012

 Для тех мероприятий, для которых планируется использовать данную систему, впринципе будет достаточно 0.01 сек (1/100) и основываясь на сотнях проведенных экспириментов, пусть и не особо опытного микроэлектроншика - этот параметр достежим. 

Но всегда хочется иметь запас "прочности", над эти сейчас и видется работа.

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

Останется только побороть разность в показания в millis, происходящие со временем (что сегодня мне вроде удалось)

loginex
Offline
Зарегистрирован: 19.02.2012

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

rndvip
Offline
Зарегистрирован: 04.03.2012

Не понял...те если на одном постоянно срабатывает внешнее событие и он ее обрабатывае - то милс не считаются? 

leshak
Offline
Зарегистрирован: 29.09.2011

rndvip]</p> <p> Для тех мероприятий, для которых планируется использовать данную систему, впринципе будет достаточно 0.01 сек (1/100) и основываясь на сотнях проведенных экспириментов, пусть и не особо опытного микроэлектроншика - этот параметр достежим. </p> <p>[quote=rndvip пишет:

Но всегда хочется иметь запас "прочности", над эти сейчас и видется работа.

Ну поэтому "внешнее специализированное" и предлагал. Которые и задуманны что-бы "сохрянть точность" при изменяющейся температуре и питании.

rndvip пишет:

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

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

rndvip пишет:

Останется только побороть разность в показания в millis, происходящие со временем (что сегодня мне вроде удалось)

Я бы не боролся, а взял, все-таки внешний сигнал. Более стабильный чем кварц самой ардуины. Если "удалось побороть миллис" - расскажите. Поставленная задача,  очень интерестная. Хотя и я скептический отношусь к возможности Даже если  millis() будет работать синхронно рядом, то не факт что он опять не вылезет когда платы будут "в разных условиях". И самое плохое, что это "не так просто заметить". Но даже с ограничением на "нужны одинаковые условия" - решение будет полезно.

 

leshak
Offline
Зарегистрирован: 29.09.2011

так millis-то и не нужен при использовании прерываний. Заводите собственный счетчик и его обновляете во время прерывания.

Как вы думаете работает сама миллис? Точно также. Только прерывание беретеся не с ноги, а от внутреннего timer0 (который, в итоге, опирается на кварц ардуины).

Разница получается только в стабильности этого сигнала. Внешний  можно сделать более стабильным. Возможно путем курения мануалов, получится даже сам timer0 заставить срабатывать не от внутреннего таймера, а от внешнего сигнала. Тогда даже millis(), на MyMillis() менять не прийдется.

rndvip
Offline
Зарегистрирован: 04.03.2012

leshak пишет:

Разница получается только в стабильности этого сигнала. Внешний  можно сделать более стабильным. Возможно путем курения мануалов, получится даже сам timer0 заставить срабатывать не от внутреннего таймера, а от внешнего сигнала. Тогда даже millis(), на MyMillis() менять не прийдется.

Это было бы очень круто... надо курнуть на досуге, жаль что я в микроэлектронике дубовый(((тока начинаю осваивать.

leshak
Offline
Зарегистрирован: 29.09.2011

leshak пишет:

Возможно путем курения мануалов, получится даже сам timer0 заставить срабатывать не от внутреннего таймера, а от внешнего сигнала. Тогда даже millis(), на MyMillis() менять не прийдется.

Похоже это возможно. Шаманством с Fuse битами, при пришивке, можно указать что использовать в качестве clock source. Внутрений осцилятор (не рекомендуется), внешний осцилятор (как и сделанно в заводских ардуинах) или внешний clock source (какой-то стабильный источник тиков). То есть, получается нужно "поправить" (или завести еще один раздел) FUSE биты в файле boards.txt для вашей платы.

В этом случае вы получите что все millis(), delay(),pwm и проч. - работает "как родное", только стабильней (если внешний источник стабильней чем дефолтный кристал).

Лично я, наверное, при игре с FUSE битами, вначале попробовал бы это не на самой ардуине, а взял-бы "внешний кристал" и прошил-бы его на макетке по туториалу ArduinoISP (нижние картинки, только брал-бы не от кристала сигнал, а от DS3231 . Попробовал-бы "как оно ведет себя" с разными clock source. И уж потом, убедившись что все нормально, менял FUSE для платы. Ошибится с ними очень легко, а при ошибке потом "достучаться до кристала" может оказатся довольно проблематичным.

 

rndvip
Offline
Зарегистрирован: 04.03.2012

leshak пишет:

Я бы не боролся, а взял, все-таки внешний сигнал. Более стабильный чем кварц самой ардуины. Если "удалось побороть миллис" - расскажите. Поставленная задача,  очень интерестная. Хотя и я скептический отношусь к возможности Даже если  millis() будет работать синхронно рядом, то не факт что он опять не вылезет когда платы будут "в разных условиях". И самое плохое, что это "не так просто заметить". Но даже с ограничением на "нужны одинаковые условия" - решение будет полезно.

Ну сначала попробую выжать из этого все что получится...

"Поборол" громко звучит наверно, но выглядит так. После процедуры синхронизации времени, отправляю запрос к каждой плате на то чтоб она выслала мне свое время. В 70% случаях возвращается идентичные значения, в 30% +-1мс. 

Каждые 10 мин отправляю запрос на получения времени. Собрав статистику, получил что вторая плата приблизительно каждые 150 сек отстает на 1мс, соответственно к главно цикле проверяю, не прошло ли это время с момента последней корректировки, если прошло- то накидываю 1 мс. И вот за последний час приблизительна все таже статистика 70/30, те отставание нивилировано.

Возможно эти 30 процентов, когда пакет от базы до одного контроллера идет быстрее/медленние до другого...как это решить эту проблему - я пока не знаю, возможно стоит как-то использовать идею с посылкой задержки как в tcp и как предлогает loginex

 

leshak
Offline
Зарегистрирован: 29.09.2011

 >вторая плата приблизительно каждые 150 сек отстает на 1мс

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

rndvip
Offline
Зарегистрирован: 04.03.2012

Я не претендую на то, что я делаю истина в первой инстанции))

Вчера одна плата питалась от АКБ 12в другая от USB, в независимости от того какая от чего питалась, вторая всегда отставала. Я замерял разность температур кварца (+8 +9 градусов относительно той что питается от usb).

Сейчас тест идет при питании обоих от usb, позже попробую оставив тоже "поправочный коэффициент"  но питать одну плату от акб 12в вторую все также от usb, потом поменять. 

Прошел час и 10 мин - разница пока 0.

rndvip
Offline
Зарегистрирован: 04.03.2012

 оффтоп

я почитал про pullup регисторы, и то как они включаются. одна из двух имеющихся у меня плат не реагирует на

pinMode(inPin, INPUT);  
digitalWrite(inPin, HIGH);

а другая, наоборот, без чего либо на пустом не подключенном ни к чему пину имеет HIGH...

Хотелось бы чтоб обе платы работали "одинаково"

rndvip
Offline
Зарегистрирован: 04.03.2012

 

Что-то типа такого - внешнее устройство для получения сигнала тиков...

leshak
Offline
Зарегистрирован: 29.09.2011

rndvip пишет:

Я не претендую на то, что я делаю истина в первой инстанции))

Нет. Ну что-вы. Никто вас в этом не обвинял.

Мой вопрос подразумевал скорее "а изменяется ли это отставание при изменении внешних условий?". Сейчас у вас обе платы, работают фактически в одних условиях, которые, к тому же стабильны. А если в боевых условиях это будет не так? Будет ли сохранятся эта разнца "150 сек отстает на 1мс"?

Так же интерестно, что будет если на какой-то продолжительный кусок времени запретить все прерывания (врочем это я могу и сам проверить :)  ) собъются показалия millis() или нет? (а долгий запрет, может возникнуть, например, внутри какой-то сторонней библиотеки.

А вообще, хочу сказать спасибо топикстартеру. Лично для меня это был самый интерестный вопрос/задача за последний месяц. Бесконечные "два абзаца про свое чайниковство, а потом вопрос про подключение кнопки к ардуине" - немного утомили :)

leshak
Offline
Зарегистрирован: 29.09.2011

rndvip пишет:

 оффтоп. я почитал про pullup регисторы

Наверное лучше заведите отдельную тему. А то "потеряемся", а тут можете дать ссылку на нее. Что-бы "заинтересованные" могли мигрировать :)

 

rndvip
Offline
Зарегистрирован: 04.03.2012

leshak пишет:

Нет. Ну что-вы. Никто вас в этом не обвинял.

Мой вопрос подразумевал скорее "а изменяется ли это отставание при изменении внешних условий?". Сейчас у вас обе платы, работают фактически в одних условиях, которые, к тому же стабильны. А если в боевых условиях это будет не так? Будет ли сохранятся эта разнца "150 сек отстает на 1мс"?


Думаю скорее всего нет...но если разброс останется +-1 мс, я буду считать что задача от части выполнена (при не использовании чего либо еще)

leshak пишет:

Так же интерестно, что будет если на какой-то продолжительный кусок времени запретить все прерывания (врочем это я могу и сам проверить :)  ) собъются показалия millis() или нет? (а долгий запрет, может возникнуть, например, внутри какой-то сторонней библиотеки.

Можно поподробней, про запрет прерываний, что это такое и почему миллис должны сбиться? Спасибо.

leshak
Offline
Зарегистрирован: 29.09.2011

 

Цитата:

Можно поподробней, про запрет прерываний, что это такое и почему миллис должны сбиться? Спасибо.

Нет. Сам представляю в "общих чертах". Поэтому и сказал не "миллис должно сбится", а "интерестно проверить". Увеличивает он счетчик "аппаратно" или все-таки есть функция которая висит на прерывании и меняет его програмно.

В общем виде cli() - запретить все прерывания, sei() - разрешить.  Можно тоже-самое сделать и через прямую работу с портом SREG. Обычно ими обрамляют критичный кусок кода. В момент выполнение которого "никакая падла не должна вмешатся" (временной задержкой, поменять какую-то переменную и т.п.). Так же ими часто пользуются внутри функции обработки прерывания. Что-бы гарантировать, если прерывание происходит слишком часто, что она "доработает до конца" и не будет, в свою очередь, прервана.

cli() и sei() это вообщем-то из мира "взрослого прогарммирования микроконтроллеров". Есть их ардуино-аналоги noInterrupts(),interrupts() . Но отличаются ли они чем-то кроме имени - я не вникал. Да и примеров что-бы кто-то их использовал в реальных скетчках - пока не видел. 

 

leshak
Offline
Зарегистрирован: 29.09.2011

leshak пишет:

cli() и sei() это вообщем-то из мира "взрослого прогарммирования микроконтроллеров". Есть их ардуино-аналоги noInterrupts(),interrupts() . Но отличаются ли они чем-то кроме имени - я не вникал. 

Посмотрел их реализцию. Это полные аналоги cli() и sei(). Просто более читаемые синонимы.

rndvip пишет:

Что-то типа такого - внешнее устройство для получения сигнала тиков...

Да оно может быть и таким. Если у него есть выход тиков, а не только "время по i2c шине сообщать". К тому же нужно смотреть что там за микросхема и насколько она стабильней ардуиновского кварца.