Мультиинтерфейсник для разъёма "ПУ" Вектора06Ц

[KTSerg]

https://github.com/espressif/ESP8266_AT/wiki/CIPMODE
Transparent mode не оно?

Смотрел уже в эту сторону. Смущает выход из этого режима -

When receiving a packet that contains only “+++”, the UART-WiFi passthrough
transmission process will be stopped.

И дальше в инструкции написано, что оно может и не сработать
Похоже остается только экспериментировать...

[svofski]

Модемная классика: 1сек пауза +++ 1 сек пауза.

[KTSerg]

Обнаружил на старой материнке сборки резисторов по 33 Ом. Три сборки по расчетам дают 49.5 Ом. Поменял на модуле с W5100 сборку 510 Ом на бутерброд. Можно будет пробовать и его подцепить к девайсу.

[KTSerg]

Добавил схему в первое сообщение.
Схема на текущий вариант.

[KTSerg]

Прогнал первую пару (запрос сеанса - подтверждение) UDP-пакетов между Девайсом и компом...
Сначала не мог понять, комп запрос получил, отправил подтверждение, а Девайс зависает намертво в ожидании подтверждения...
Оказалось, что Девайс, пока читает по UART подтверждение об отправке пакета, с компа уже приходит ответ, и он цепляется паровозом (без интервала) к подтверждению об отправке данных. А Девайс ждал отдельной строки с ответом.
В общем, от чего пытался избавиться (от разделения потока инфы на отдельные пакеты), на то и нарвался.
Можно конечно тормознуть сервак, чтобы так быстро не отвечал...
Похоже будет ещё то развлечение...

[svofski]

Без интервала, но отдельным пакетом? Потому что UDP пакеты могут перепутываться местами и вообще не доходить (на локальной сети это вообще вряд ли), но не должны склеиваться. Конечно, в ESP8266 все может случиться.

[Advertiser]

[KTSerg]

Без интервала, но отдельным пакетом? Потому что UDP пакеты могут перепутываться местами и вообще не доходить (на локальной сети это вообще вряд ли), но не должны склеиваться. Конечно, в ESP8266 все может случиться.

Я на то и надеялся, что будут отдельные пакеты. Но содержимое входящих пакетов, без запроса, вываливаются по Uart (сразу по поступлению), по которому ещё и выводятся ответы на команды. Отличить можно по префиксу, но поток общий.

[svofski]

Я все время забываю, что ты через AT работаешь.

Тогда по-моему проще всего сделать каждую посылку цельной строкой, чтобы именно строка. И да, например, префикс - это вид посылки, а дальше уже в зависимости от вида. Придется сделать ограничение на длину строки, но зато они будут гарантированно целые. Какая тогда останется разница, как приходят пакеты?

[KTSerg]

Добился таки загрузки программы в Вектор с РС по WiFi...
Пока грузится очень медленно. Выводится в порты и на дисплей отладочная инфа, хотя её вывод не должен особо тормозить.

На фотках экраны Девайса:
При старте - выбор источника: карточка или WiFi.

После выбора WiFi - экран с проверками: наличия ESP (отклик по uart), настроек ESP на связь с роутером, и собственно подключения к роутеру. "Облако" - начало загрузки файла.

При выборе карточки - запускается файловый менеджер.

После выбора файла в менеджере - экран с выбором интерфейса (забыл сфоткать, на нём WiFi и Квазидиск пока не реализованы).

Ещё скриншот окна проги на Python которая собственно выгружает файл.


Ещё подключил к Девайсу стандартный для Ардуины кейпад (как альтернатива тачу, но пока не реализовал опрос).

[KTSerg]

Удалось значительно сократить время загрузки... 18КБ файла аж до 27 секунд
Python тремя потоками грузит мой комп на 100%
Первый поток - интерфейс, второй - сокет на приём, третий - сокет на отправку.
Основная проблема тормозов в пустом цикле "while flag==0:" - ожидание запроса в отвечающем потоке.
Использовал вариант:

while flag == 0:
    time.sleep(0.005)

думал это тормозит. Попробовал:

while flag == 0:
    flag2 = flag2

Стало в несколько раз медленнее...
А пустой while - без оператора, Python не понимает.
Пока остановился на варианте:

while flag == 0:
    time.sleep(0)

Но судя по всему, самые большие тормоза, которые я не учёл дают задержки АТ-команд в ESP

Хотя, смотреть как заполняются кубики на загрузочной сетке - это Фича, а не Баг