Рулим светодиодом по UDP и ESP8266

[aladkoi]

Esp серия обычно программируется через среду esp-idf в vscode. Еще можно использовать спец. графическую среду без "ручного" такого написания кода. Да использование устаревшего 8266 не самое удачное решение. Есть мини платы esp32c6 , например, с поддержкой зигби. Это более интересное решение.

[randomsimplenumber]

Ну это же демка.

Но тема необычно высоких скоростей передачи по UDP не раскрыта. Где бенчмарки? Где сравнение с TCP? Может, в этой конфигурации (esp8266 + Android) и нет никакой разницы?

[Danchkin_Sab]

Возможности esp32c6 я ещё не изучал, хотя идея хорошая, под рукой оказалась только esp8266 с которой уже имел опыт работы

[Danchkin_Sab]

Это идея для следующий статьи, поскольку опыт работы с tcp и даже http я имею - сделаю сравнение

[dmitryrf]

Хорошее демо!

Мне в этой схеме вот что кажется неудобным: IP адрес жестко прошит и никак не настраивается. Плюс нужно отключаться от сети с доступом в интернет чтобы воспользоваться устройством. Было бы здорово, если бы устройство подключалось к домашней сети как клиент, а приложение искало бы его через mdns

[Danchkin_Sab]

Можно и так, никаких проблем: настраиваем esp на работу в роли клиента, задаём ей статичный ip и также обмениваемся данными. Нюанс просто в том что не везде может быть собственная wifi сеть

[Vilos]

Хабр - торт :)

Не очень понятно почему UDP? Чем TCP хуже? Но в целом работа интересная...есть внутри потенциал для мыслей на подумать. Однозначно плюс за работу.

[Danchkin_Sab]

Здесь udp является более целесообразно, поскольку он быстрее и мы передаём большие объёмы данных, чтобы беспокоиться об их целостности:)

[Vilos]

Очень сильно бы поспорил UDP и TCP точно не быстрее ни тот ни другой, скорость передачи вообще никак с этим не связана с протоколом связности, то что вы передаёте "большие объемы данных" - это вообще смешно...это просто крохи трафика. То что обычно при передачи потоков мультимедиа (аудио, видео) как правило используется UDP, это исторически сложившийся факт по причине того что когда будет перезапрошен "поврежденный" пакет в TCP - актуальность сборки этого пакета пропадет, поскольку нужна новая картинка (условно)....проще сделать пропуск звука или кадра чем нагружать сеть уже ненужным пакетом. В вашем же случае потоков актуальных быстро-"протухающих" данных нет, смело на мой взляд можно было использовать TCP. Другой вопрос что эти данные не являются критичными к целосности, ну возможно да....в следущем пакете придут новые данные.