Тем более странно как ваш первый ответ связан с моим вопросом. Но это все лирика, покажите реализацию NTP_Answer_check(), NTP_Answer_Read(), разбор пакета можно опустить (знаем, плавали), интересен и send, ну да шут с ним. Блокирует ли ваш код основной цикл не понятно ни-ко-му. А он блокирует, сдается мне, для перечисленных вами задач это более чем приемлемо (за исключением точного времени)
А с чего он должен блокировать? Отправил - вывалился. Пришел пакет, в loop() - NTP_Answer_Check() возвращает истину. в NTP_Answer_Read() считываем и разбираем пакет. Откуда тут могут быть блокировки.
А пример для ESP8266 или ESP32? Что-то я не нашел AsyncUDP.h для ESP8266. Мой первый ответ связан с асинхронностью в принципе. Вся асинхронность на МК довольно таки своеобразная штука, мягко говоря. Вот и хотел проверить, посмотрев, когда вызывается функция приема.
От куда угодно. Нет вифи, бабки не заплатил, провайдер глюкнул, роскомнадзор перекурил, сервак не ответил, помехи на линии, роутер захотел поспать и т.д. Я не вижу обработки ситуаций, и тем более не вижу (самое главное) ожидание ответа. "Бла-бла я могу" это не ответ, или вы не знаете как реализованы функции которыми пользуетесь. Это ничего не меняет. Та самая AsyncUDP работает для esp32. Ссылка на библу которую я привел, работает с esp8266 / 32. А это значит, что просто кто-то плохо ищет, или оно никому не надо. Да и только не нужно просвещать меня про асинхронность, она везде одинаковая, на любом процессоре.
да, что в этом сложного? в чем проблема-то? Ты серьезно спрашиваешь или прикалываешься? вот тебе функция NNTP запроса из библиотеки Код (C++): bool NTPClient::forceUpdate() { #ifdef DEBUG_NTPClient Serial.println("Update from NTP Server"); #endif // flush any existing packets while(this->_udp->parsePacket() != 0) this->_udp->flush(); this->sendNTPPacket(); //<<<<<<<<<<< cut here >>>>>>>>>>>> // Wait till data is there or timeout... byte timeout = 0; int cb = 0; do { delay ( 10 ); cb = this->_udp->parsePacket(); if (timeout > 100) return false; // timeout after 1000 ms timeout++; } while (cb == 0); this->_lastUpdate = millis() - (10 * (timeout + 1)); // Account for delay in reading the time this->_udp->read(this->_packetBuffer, NTP_PACKET_SIZE); unsigned long highWord = word(this->_packetBuffer[40], this->_packetBuffer[41]); unsigned long lowWord = word(this->_packetBuffer[42], this->_packetBuffer[43]); // combine the four bytes (two words) into a long integer // this is NTP time (seconds since Jan 1 1900): unsigned long secsSince1900 = highWord << 16 | lowWord; this->_currentEpoc = secsSince1900 - SEVENZYYEARS; return true; // return true after successful update } в том месте, где я поставил метку <<<<<<<<<<< cut here >>>>>>>>>>>> делишь ее на две. Верхняя - функция отсылки запроса, нижняя - получения ответа. Блокирующий цикл do {}while выкидываем, вместо него пишем проверку парсе-пакет и выход. Получаем неблокирующую реализацию. Чтобы сразу пресечь вопросы - функция _udp->parsePacket() неблокирующая, я посмотрел в соответвующей либе. Что тебе тут непонятно? Если есть претензии - обоснуй, иначе отвечать не буду. глум мне надоел На тему "что такое блокирующая реализация" - подумай сам. У меня впечатление, что ты не очень это понимаешь.
Ошибка будет с точностью единиц секунд... думаю этого вполне достаточно. Получаете заголовок HTML ответа от любого сайта. И в нём дата и время. Даже ответ сайта типа: "такой страницы не существует" в заголовке имеют дату и время этого сайта. Сам этим пользуюсь давно.
т.е. delay(10), тебя вообще не смущает... ладно... а как на счет надписи "Wait till data is there or timeout..." тоже норм? А в курсе почему там delay(10), и до скольки может происходить этот свободолюбимый делэй? И ты говоришь что нет блокировки? После того, что увидел этот самый делэй(10) в ЦИКЛЕ?
я для кого написал "цикл do{}while выкидываем"? Нет его уже и делея нет Я убедился. что ты код вообще не понимаешь и мыслить программно не умеешь... Тебе надо все до буквы написать - и ты и тогда не поймешь. прости, но готовый код я пишу только за деньги либо если собеседник мне симпатичен...
Да не, я в целом вопрос решил. Ну сам посуди, ntp как-то серьезней. Тем более что конечное устройство ориентировано на не на нас))) имхо. указать на веб-страничке источник времени - да легко, тем более что есть дефолт
ОК, ладно, развлекайся сам. Очевидно, что вообще не понял то, что мы Сергеем пытались обьяснить. Кстати. может потом тебе пригодится тот факт, что наши с ним реализации совпадают почти на 100%. Я честно пытался... В личку мне, пожалуйста, не пиши, а то я тебя в игнор поставлю. Отписываюсь.
Может оно и так, ntp он для того и сделан. В моём случае я не всегда получал доступ... точнее все мои компы/устройства/сервера. Потому и решил так. Точности до 10 секунд в моём случае нормально, потому и сделал скрипт... который при запуске (или время от времени) делает запрос на яндекс и получая ответ корректирует системные часы. Оговорюсь - все упомянутые мной устройства на основе Linux. В вашем случае (для вашего устройства) надо парсить ответ, но в нём точно есть дата и время. ЗЫ: ntp у меня что-то не надёжно в плане связи... может прокси не пущает? Вот чего не скажу, того не скажу.
Распарсить можно, опыт есть, Да я-то вопрос решил, время точнее чем на ноуте. (Кстати с хрена ли) В общем все норм, ntp крутится - задачи мутятся ))) Пробовал и народный pool и cloudflare короче норм все. пока что))