да, в основном это
Ох, я как то проще делал, статус ошибки запрашиваю тупо.
Dmitriy
Evgeniy
Таймаут recv удалось установить?
Dmitriy
Но дисконект нифига не быстро детектится, даже если нормальное закрытие порта с другой стороны происходит.
Dmitriy
Примеры смотрели?
Evgeniy
через sock options?
Evgeniy
тогда завтра еще раз проверю, наверняка достаточно будет блокирующего варианта + таймаут поставить
Dmitriy
тогда завтра еще раз проверю, наверняка достаточно будет блокирующего варианта + таймаут поставить
Совет - лучше изучайте примеры из коробки. Я так tcp-uart 2 часа делал из которых 1.5 часа пример разбирал.
Dmitriy
Не более 5мс задержка на прохождение пакета туда и обратно. Так что если больше - не правильно настроили сокет.
Evgeniy
А какие настройки кроме TCP_NODELAY влияют еще?
Dmitriy
Не вникал. Скопировал пример - работает.
Evgeniy
ага, оно есть, только с recv разобраться осталосьб
Dmitriy
А что с ним не так?
Dmitriy
Dmitriy
Ну ок, не буду больше скидывать...
Dmitriy
Читай документацию
Evgeniy
Вроде бы как KEEPALIVE достаточно редко отправляется, какой в итоге выбрали период отправки ACK?
Evgeniy
По умолчанию что-то около двух часов
Dmitriy
321
https://habr.com/ru/company/sberdevices/news/t/659555/
Evgeniy
Evgeniy
Вот vTaskDelay(2) в таком решении мне не нравится - зря только проц грузит
Dmitriy
Любопытно, зачем BUF_SIZE - 1 - пережиток от текстового протокола?
Нет, какой максимальный элемент в массиве размером N?
Evgeniy
А как надо?
Вот мне тоже любопытно - как совместить блокировку на recv с надежным детектом дисконнекта
ok-home
Вот vTaskDelay(2) в таком решении мне не нравится - зря только проц грузит
в смысле грузит - оно как раз говорит займитесь в это время своими делами, или ничего не делайте. А зачем дисконект ловить ? Да еще и быстро ? Ну никто не принимает со стороны tcp, ну и ладно - ничего и отправлять не будем. Чтобы не блокировать проц, вроде как много раз писали - uart в своей задаче, tcp в своей. И даже думать не нужно кто где отвалился, никто никого не блокирует
Dmitriy
Вот мне тоже любопытно - как совместить блокировку на recv с надежным детектом дисконнекта
У меня без блокировки работает.
Evgeniy
в смысле грузит - оно как раз говорит займитесь в это время своими делами, или ничего не делайте. А зачем дисконект ловить ? Да еще и быстро ? Ну никто не принимает со стороны tcp, ну и ладно - ничего и отправлять не будем. Чтобы не блокировать проц, вроде как много раз писали - uart в своей задаче, tcp в своей. И даже думать не нужно кто где отвалился, никто никого не блокирует
50 раз в секунду, вместо блокировки, если в сокете ничего нет
Evgeniy
а, ну да, там 2 мс, тогда еще больше грузит 😁
Dmitriy
а, ну да, там 2 мс, тогда еще больше грузит 😁
Он в обе стороны трафик гоняет, если что. И нет, не грузит.
ok-home
50 раз в секунду, вместо блокировки, если в сокете ничего нет
если оно на сокете в блокировке повисло то оно до vtaskdelay и не доберется, там и будет висеть
Evgeniy
в смысле грузит - оно как раз говорит займитесь в это время своими делами, или ничего не делайте. А зачем дисконект ловить ? Да еще и быстро ? Ну никто не принимает со стороны tcp, ну и ладно - ничего и отправлять не будем. Чтобы не блокировать проц, вроде как много раз писали - uart в своей задаче, tcp в своей. И даже думать не нужно кто где отвалился, никто никого не блокирует
Оказалось, что устройство - мост wifi <> uart часто включают и отключают, иногда уходят с ноутбуком/смартфоном за пределы видимости/закрывают ПО и т.п.
Dmitriy
Оказалось, что устройство - мост wifi <> uart часто включают и отключают, иногда уходят с ноутбуком/смартфоном за пределы видимости/закрывают ПО и т.п.
Ну и чего? У меня шикарно все отрабатывается...
Evgeniy
если оно на сокете в блокировке повисло то оно до vtaskdelay и не доберется, там и будет висеть
А там DONT_WAIT стоит - будет всегда добираться до vTaskDelay
Dmitriy
А там DONT_WAIT стоит - будет всегда добираться до vTaskDelay
Если будет блокировка - то ответ не передастся
Evgeniy
Если будет блокировка - то ответ не передастся
у меня для отдельный таск, чтобы ничего не блочить, и StreamBuffer, куда можно грузить, пока буфер пустой - таск спит
Dmitriy
Ток ради чего не понятно. Вы знаете как под капотом эти функции реализованы? По сути, получается тот же самый код, только сложнее. Можно сравнить загрузку проца, если интересно
ok-home
Так я не настаиваю - вы совет спрашиваете - их есть у нас. Но мне 4 трансфера в одном while - да еще и трансферы которые могут в любой момент отвалиться .... не нравится.
Dmitriy
Так я не настаиваю - вы совет спрашиваете - их есть у нас. Но мне 4 трансфера в одном while - да еще и трансферы которые могут в любой момент отвалиться .... не нравится.
Вопрос задержек максимальных. Для mvp вполне себе решение...
Evgeniy
У меня на самом деле проект уперся в то, что устройства клиента работают по протоколу, где важно выдерживать жестко тайминги, а если на уровне прозрачного обмена через TCP из сокета будет считано сразу 2 "команды" - устройство проигнорит вторую и это выглядит как сбой, потому что сделать нормальный парсер разработчик не смог. Такая же фигня у них была через прозрачный мост Bluetooth и иногда приглючивало в связке с USB <> UART, но редко, всё же не радиоканал.
Dmitriy
У меня на самом деле проект уперся в то, что устройства клиента работают по протоколу, где важно выдерживать жестко тайминги, а если на уровне прозрачного обмена через TCP из сокета будет считано сразу 2 "команды" - устройство проигнорит вторую и это выглядит как сбой, потому что сделать нормальный парсер разработчик не смог. Такая же фигня у них была через прозрачный мост Bluetooth и иногда приглючивало в связке с USB <> UART, но редко, всё же не радиоканал.
Поэтому надо брать уже готовые протоколы и их натягивать на задачу)
Evgeniy
В итоге использовал websockets и реализовал протокол обмена с устройством внутри WiFi модуля. Другой архитектуры здесь быть не может. Кстати - на клиентской стороне они не смогли осить правильно сделать обмен через сокеты, потому что не знают как это делать
Evgeniy
Теперь все тайминги выдерживаются правильно, но эти хм... господа, не хотят использовать готовую библиотечку для вебсокетов, а хотят сами дальше возиться с сокетами!
Evgeniy
Поэтому надо брать уже готовые протоколы и их натягивать на задачу)
Ошибки были те, что на stackoverflow постоянно всплывают: за ОДИН вызов recv пытались принять более 73 кб данных. Жаловались, что работает нестабильно.
Evgeniy
Причем в своей документации на оборудование - этот момент с таймингами не указан, с готовым модулем Bluetooth этот вариант также не взлетел - там тоже тайминги по рандому не выдерживались. Модуль естественно, не самодельный)
Dmitriy
Ошибки были те, что на stackoverflow постоянно всплывают: за ОДИН вызов recv пытались принять более 73 кб данных. Жаловались, что работает нестабильно.
Ну люди любят себе в задний проход гантели засовывать, что же, теперь им гантели не продавать?
Evgeniy
Это верно, видимо придется новый костыль изобретать.
Dmitriy
Это верно, видимо придется новый костыль изобретать.
да не, проще нормального заказчика найти
Evgeniy
уже есть, для тех же приборов 😁
ok-home
ну так положить что нужно в очередь, и забирать тогда когда клиент готов забрать по их протоколу. Если вовремя не забрали.... ну значит не готовы или нет связи
Dmitriy
жесть какая то, гонять доли мегабайта с таймингами
Dmitriy
обычно или байты с таймингами или метры со смыслом
Dmitriy
вон в том же SIP пакеты и 200 байт нет
Evgeniy
жесть какая то, гонять доли мегабайта с таймингами
там: загаловок с длиной пакета, payload, CRC16. Можно вообще таймауты не делать. Ждать только загаловок и чистить буфер, если CRC не сошлась, как это везде сделано. Тогда грузи сколько хочешь этих команд - устройство их выполнит. По факту: часть команд не имеют ответов, другая часть будет принята через определенный тайминг, а приемный буфер чистится в любом случае после одной команды
Evgeniy
Еще крутая фишка: на RS485 ответ через 1.6 мкс после СТОП бита команды. И это на 921600. С таким таймингом не справится бОльшая часть серийных мостов.
Dmitriy
есть же mqtt
Dmitriy
по последнему я видео гонял. Карл, видео!!!! и оно работало
Evgeniy
modbus - сложна!)
Evgeniy
на самом деле - для ускорения обмена кастомный протокол такой, то, что готовое оборудование это не переванивает - никого не волнует
Dmitriy
modbus - сложна!)
все хочу закончить, как с modbus и питоном гонять потоковые пакеты в несколько кб с кастомными потрохами на дефолтовой либе
Dmitriy
ну всмысле статью на хабр
Dmitriy
код лежит, наброски лежат, надо добить и выложить.
Evgeniy
мне нравится система регистров - это удобно и расширяемо, как в модбас
Dmitriy
мне нравится система регистров - это удобно и расширяемо, как в модбас
угу, и еще пара сотен свободных кодов кастомных команд
Dmitriy
тебе надо соблюдать только первый 2 байта и последние 2 байта, что внутри - твое дело. И все, ты совместим с модбасом.
Dmitriy
Это mvp и свою задачу выполняет. Это tcp\ip, если вы послали 4 байта то придет 4, а не 3 и потом 1. За это у нас в универе на пересдачу отправляли...
Evgeniy
"minimum viable product" - оно?
Dmitriy
Это пакетная передача, а не поточная.
Dmitriy
Это костыль, что бы можно было скорость при подключение выставлять, потом объект передается в класс, который ждем uart обычный. Да, оно хавает и работает.
Dmitriy
У каждого своя правда
Dmitriy
Ну если хреначить пакетами по 100кб, может оно и не так, а если укладывается во все буфера, то оно так. Покажите контрпример с размером массива до 255 элементов.
Evgeniy
Test как обычно жжет крепким словцом 😁