"вывод отладочной информации по UART" производится процедурой printf() и подобными (os_sprintf(), os_sprintf_plus(), ets_sprintf(), ... относятся к закрытой части китайского-SDK, а в проекте используют только часть - см. esp8266web/os_printf.c at master · pvvx/esp8266web · GitHub )
Это понятно, меня интересует в каком месте исходников задано данное значение по умолчанию.
@pvvx, большое спасибо!
На ESP8266 первые сообщения при старте идут из его ROM на скорости 78800 baud и это не поменять. Далее стартует SDK, в моем проекте MinEspSDK (meSDK). Там можно поменять скорости вывода его сообщений или вообще отключить, а далее уже само приложение... esp8266web/sdk_config.h at master · pvvx/esp8266web · GitHub
Только IP.
Не предусматривалось - не было в этом нужды и сейчас не видно.
Возьмите модуль поновее c большей RAM и на простых сокетах это решается в пару строк СИ/С++, включая Arduino. Т.е. кроме как ради “спортивного интереса” изгаляться в реализации описанных вами вопросах на ESP8266 нет смысла, т.к. выйдет себе дороже, дольше, усеченней и глючнее.
Это просто было не нужно, или там какие-то ограничения есть для использования имени хоста, а не адреса?
У меня тоже в таком нужды не было, пока не оказалось, что не везде и не всегда есть белые IP, и проще попасть наружу, чем вовнутрь.
Да оно сейчас на этапе оценки общего объема переделок, и там такой ворох изменений, что проще ставить для поделок с ESP отдельный роутер и поднимать на нем VPN наружу.
Надо допиливать и дописывать, а смысла в этом нет на ESP8266.
Т.е. вы ещё надеетесь, что ESP8266 можно сделать что-то надежное в описанных рамках?
У меня она именно в том виде, как и задумано - простой переходник TCP-UART с удобной веб-мордой. Не более.
С выводом отладочной информации пробовали прошивку? Может чего в отладке будет видно.
Для этого есть сигналы RTS/CTS. WiFi имеет помехи и в WiFi сети работает множество устройств... Гарантии по времени доставки или большого буфера в RAM ESP8266 нет. Арбитраж сети (канала), кто и когда передает-принимает осуществляется в WiFi AP. Помехи, коллизии и пропуски beacon всегда есть и передать весь стек TCP за 6 ms (beacon по умолчанию и тот 100 ms) не имеет никакой гарантии.
Там работает запрет приема по ограничению размера окна TCP стека. Если ваш код, на внешнем клиенте отсылает пакеты не по стандартам TCP и не сморит ничего, то это ваша беда, а не iOs или ещё какой оси... Драйвер стека TCP не угомониться пока не передаст все байты, но может послать вас, если вы в него пихаете ещё и у него кончился буфер (вернет флаг занятости и выкинет ваш блок данных в запросе передачи - у него тоже буфера не резиновые, если вы игнорируете что конечное устройство занято и прием у него временно закрыт).
Вы наверное не так поняли. Со стороны клиента отправка работает у меня вообще без сбоев, любого размера пакет.
Значит гарантии передачи никакой нет и никаких разговоров быть не может.
Не может такого быть. Там буфер для более 2-х пакетов TCP, а это значит что и 3 килобайта сожрет за раз, если до этого всё передал.
Нет - когда нет места в буфере передачи в TCP то выставится RTS (запрос на отправку). Далее, после выставления сигнала RTS дается возможность запихать десяток байт, пока передающее в RX устройство сообразит и поймет что выставлен сигнал занятости. Ведь скорость передачи может быть и 10 Mbaud...
Передадут сразу Гегобайт дровам в стек TCP и думают, что ось справиться и не пошлет их, а обязана где-то это хранить по мере передачи через узкое горлышко UART в конце пути . понял, спасибо, буду пробовать
При более менее чистом эфире WiFi ESP8266 тянет практически линейный (редкие RTS/CTS) односторонний поток в 3 Mbit/s UART, при дуплексе к 1 Mbit/s в обе стороны. Более не хватает производительности CPU ESP8266 с работой без DMA с UART - будут частые RTS/CTS. Всё это без каких либо потерь данных.
у меня уарт настроен на 4мбита, вроде с этим проблем нет.