Вид для печати
Смотрел уже в эту сторону. Смущает выход из этого режима -Цитата:
Сообщение от svofski
И дальше в инструкции написано, что оно может и не сработать :)Цитата:
When receiving a packet that contains only “+++”, the UART-WiFi passthrough
transmission process will be stopped.
Похоже остается только экспериментировать...
Модемная классика: 1сек пауза +++ 1 сек пауза.
Обнаружил на старой материнке сборки резисторов по 33 Ом. Три сборки по расчетам дают 49.5 Ом. Поменял на модуле с W5100 сборку 510 Ом на бутерброд. Можно будет пробовать и его подцепить к девайсу.
Добавил схему в первое сообщение.
Схема на текущий вариант.
Прогнал первую пару (запрос сеанса - подтверждение) UDP-пакетов между Девайсом и компом...
Сначала не мог понять, комп запрос получил, отправил подтверждение, а Девайс зависает намертво в ожидании подтверждения...
Оказалось, что Девайс, пока читает по UART подтверждение об отправке пакета, с компа уже приходит ответ, и он цепляется паровозом (без интервала) к подтверждению об отправке данных. А Девайс ждал отдельной строки с ответом.
В общем, от чего пытался избавиться (от разделения потока инфы на отдельные пакеты), на то и нарвался.
Можно конечно тормознуть сервак, чтобы так быстро не отвечал...
Похоже будет ещё то развлечение...
Без интервала, но отдельным пакетом? Потому что UDP пакеты могут перепутываться местами и вообще не доходить (на локальной сети это вообще вряд ли), но не должны склеиваться. Конечно, в ESP8266 все может случиться.
Я на то и надеялся, что будут отдельные пакеты. Но содержимое входящих пакетов, без запроса, вываливаются по Uart (сразу по поступлению), по которому ещё и выводятся ответы на команды. Отличить можно по префиксу, но поток общий.Цитата:
Сообщение от svofski
Я все время забываю, что ты через AT работаешь.
Тогда по-моему проще всего сделать каждую посылку цельной строкой, чтобы именно строка. И да, например, префикс - это вид посылки, а дальше уже в зависимости от вида. Придется сделать ограничение на длину строки, но зато они будут гарантированно целые. Какая тогда останется разница, как приходят пакеты?
Добился таки загрузки программы в Вектор с РС по WiFi... :)
Пока грузится очень медленно. Выводится в порты и на дисплей отладочная инфа, хотя её вывод не должен особо тормозить.
На фотках экраны Девайса:
При старте - выбор источника: карточка или WiFi.
Вложение 70674
После выбора WiFi - экран с проверками: наличия ESP (отклик по uart), настроек ESP на связь с роутером, и собственно подключения к роутеру. "Облако" - начало загрузки файла.
Вложение 70675
При выборе карточки - запускается файловый менеджер.
Вложение 70676
После выбора файла в менеджере - экран с выбором интерфейса (забыл сфоткать, на нём WiFi и Квазидиск пока не реализованы).
Вложение 70677
Ещё скриншот окна проги на Python которая собственно выгружает файл.
Вложение 70678
Ещё подключил к Девайсу стандартный для Ардуины кейпад (как альтернатива тачу, но пока не реализовал опрос).
Удалось значительно сократить время загрузки... 18КБ файла аж до 27 секунд :)
Python тремя потоками грузит мой комп на 100% :(
Первый поток - интерфейс, второй - сокет на приём, третий - сокет на отправку.
Основная проблема тормозов в пустом цикле "while flag==0:" - ожидание запроса в отвечающем потоке.
Использовал вариант:
думал это тормозит. Попробовал:Код:while flag == 0:
time.sleep(0.005)
Стало в несколько раз медленнее...Код:while flag == 0:
flag2 = flag2
А пустой while - без оператора, Python не понимает.
Пока остановился на варианте:
Но судя по всему, самые большие тормоза, которые я не учёл дают задержки АТ-команд в ESP :(Код:while flag == 0:
time.sleep(0)
Хотя, смотреть как заполняются кубики на загрузочной сетке - это Фича, а не Баг :)