Как Получить точное синхронное время в миллисекундах на множествах девайсах от rtc?
Добрый день.
На базе stm32f446ret6, пытаюсь реализовать приложение с помощью MBED-OS 5.
По хардам узнаю esp8266 каждые 400мс, обмен по http1.0 в течении 320мс. Этим управляет поток.
Второй поток занят выводом на lcd0802.
Есть три кнопки старт, стоп, вкл/выкл.
Требуется чтобы таймер мог синхронизироваться, и знать время до миллисекунд. Тоесть если на таймер приходит значение старт столько то, то таймер начинает отсчёт, при нажатии на кнопку стоп таймер просто в передаче говорит время нажатия кнопки.
Проблема такая, RTC возвращают время в секундах. И достаточно точно ходят.
Таймер плывет ужасно за 10 минут одна миллисекундах.
Пока реализовано так:
Запустил прерывание по тикеру, тикер перезапускает таймер, в итоге почему-то поплыл RTC.
В общем пожалуйста кто знает mbed os,
Помогите советом. Как правильно
Получать и синхронизировать время rtc в mbed-os с точностью до МС.
Одна милисекунда - очень маленькое время для не реал-тайм программирования.
Банально слайсы времени для разных процессов выделяются десятками милисекунд, в результате даже сработавший таймер может выдать информацию с задержкой.
Saboteur, вот про слайсы я не понял. Если бы виной было то что конфликт во время чтения или записи, то имело бы место ошибка в определенном временном промежутке, в последующую секунду по идее это бы ликвидировалось.
В проекте еще идет сразу по двум юартам, может быть так что вызываемые ими прерывания как то влияют на формирование значения возвращаемое time()?
Еще не совсем мне ясно но все же:
Есть такие SysTick-и как я понял они взаимодействуют с тактированием процессора а не с тактирования RTC, отсюда и вопросы о том что как взять все таки значение долей секунд, ведь разрешение RTC на STM32 это позволяет сделать.
Сергей Кордубин, Нужно читать как реализована многозадачность в Mbed и как работает процесс шедулер, который распределяет CPU время между процессами. В Linux разделение идет по slice, каждый из которых может быть разной продолжительности (обычно десятки миллисекунд)
Раз речь идет о сетевых устройствах, то вам, видимо, нужна реализация NTP для вашего девайса и ОС. Посмотрите RFC 5905, может найдете, что-то готовое или реализуете сами. Собственно, возможно, реализовывать придется только транспортную часть, т.к. логику можно взять из уже существующего ПО.
Время приема и отправки от 300 до 400 мс, иногда может быть задержка более 3500мс .
если бы я мог видеть что разница между одтнаковыми пакетами не более 10мс то можно было бы конечно же вести подобие этой реализации, но вопрос в том что если просто взять реализовать все то же без мс, то времч начинает плыть только спустч часа три не меньше а то и больше, и тут как я понимаю виноваты скорее всего некачественные квакрцы.
но как только я делаю что то в прерывании например я сравниваю не будет ли текущий счетчик +1 больше 999, если не больше то +1 и вешаю юарт все куда то плывет.
Возможно кто нибудь сталкивался с необходимостью реализовать два независимых устройства которые синхронно считают в МС?
Сергей Кордубин, ntp протокол устойчив к задержкам передачи, т.е. не важно как долго сигнал идет от источника времени до устройства, достаточно сделать несколько последовательных измерений и компенсировать задержку
NTP, основанный на алгоритме Марзулло, использует для своей работы протокол UDP и учитывает время передачи. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи. В версии 4 способен достигать точности 10 мс (1/100 с) при работе через Интернет, и до 0,2 мс (1/5000 с) и лучше внутри локальных сетей[2].
