Ntp client

Тем более странно как ваш первый ответ связан с моим вопросом. Но это все лирика, покажите реализацию 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 короче норм все. пока что))

 

тыкни пинг на pool.ntp.org с ключом -t. чисто понаблюдать, но думаю тут не в этом проблема, хотя хз