Просмотр полной версии : Мультиинтерфейсник для разъёма "ПУ" Вектора06Ц
Обрисую Девайс в общих чертах. А потом приложу исходники проекта Keil.
На основе борды с stm32f103vet6 собрал своеобразный мультиинтерфейсник, подключаемый к разъёму "ПУ" Вектора. Позволяет грузить программы в Вектор с SD-карты используя протоколы начального загрузчика:
Магнитофон (с борды подключение к магнитофонному входу Вектора);
ПЗУ (Девайс воспринимается как штатное внешнее ПЗУ от 8КБ - до 32КБ);
ЛВС (Девайс воспринимается как контроллер ЛВС);
LPT->ПУ протокол (есть в начальном загрузчике от TIMSoft).
Получая возможность грузить файлы в Вектор с SD-карты, есть возможность загрузить на КвазиДиск сразу весь образ, соответственно загрузив сначала программу - загрузчик образа КвазиДиска.
Ну и сбросить образ на SD-карту соответственно.
Оставил на борде свободными интерфейсы i2c, uart и SPI. Надеялся на скорую руку подцепить к ней или ESP8266, или W5100, и получить возможность грузить в Вектор программы по локальной сети используя UDP.
Но пока с UDP облом :( не могу справиться с самими модулями.
На данный момент к борде подключен TFT 2.4 320x240 с тачем. На модуле дисплея есть гнездо для SD-карты.
Текущая схема Девайса в прицепе в архиве. Обвязки проца на схеме нет, т.к. на основе борды, на разъёмы выведены порты, они и интересны. +3.3 для дисплея и SD-карты берутся с борды.
Схема получилась сумбурная (пытаюсь освоить EAGLE), но должно быть всё понятно.
В текущей версии: uart1 - самодельный контроллер тачскрина, надеюсь заменить на ads7846.
uart2 - связь с компом, отладочный порт.
uart3 - вешаю на него ESP-модуль.
Нагуглил фотки борды и дисплея, шоб было представление о чём тут пишу.
А в чем проблема с UDP? И почему именно UDP?
Очень интересный девайс!
А в чем проблема с UDP? И почему именно UDP?
Очень интересный девайс!
Честно говоря, пока вообще не приходилось пользоваться ни TCP, ни UDP. Соответственно немного почитал, и выяснил, что TCP - это один поток, который нужно будет разбирать на пакеты (если делать протокол обмена командами). А UDP - это отдельные пакеты, при получении, одно считывание буфера - чтение одного целого пакета. Это показалось более заманчивым.
Однако наткнулся на инфу, что в UDP библиотеке Делфи7 есть фатальный глюк, и этой библиотекой не рекомендуют пользоваться :(
Пришлось разбираться с Python-ом, т.к. вроде как UDP на нём реализуется не очень сложно :)
И началась засада, ESP с копра пинговался, а комп с ESP нет. С ESP пакеты UDP улетают, но на компе их не вижу...
А потом я умудрился загнать ESP-модуль в какой-то цикл, без остановки гонит в uart мусор, на команды не реагирует :( Видимо перезаливать прошиву придётся.
Взялся читать про W5100, а его хают. Пишут что в его UDP есть серьёзная проблема, для обхода нужно постоянно сокет открывать/закрывать. Да ещё оказалось, что на мой W5100 не те резисторы воткнули. Вместо 49 Ом поставили 510 Ом - перепаивать нужно :(
UDP работает без установки соединения. Шлю пакет туда-то, а примется-не примется — ничего не знаю. Представляется, что можно сделать так заливку на Вектор, удобно. Только какая-то путаница: если мы заливаем на Вектор, то пакеты на ESP должны ловиться, а не отправляться.
UDP работает без установки соединения. Шлю пакет туда-то, а примется-не примется — ничего не знаю. Представляется, что можно сделать так заливку на Вектор, удобно. Только какая-то путаница: если мы заливаем на Вектор, то пакеты на ESP должны ловиться, а не отправляться.
Приём пакетов на ESP это лишь часть протокола, т.к. желательно иметь подтверждение приёма. Да и я только начал изучать UDP.
Начал с того, что на компе (для проверки) из скачанных примеров сделал "сервер" и "клиент" UDP. Сервер слушает порт и фиксирует адрес отправителя, далее начинается обмен. Между программами (сервер и клиент) на компе проблем нет.
Потом начал на сервер отправлять UDP-пакеты с ESP, а сервер их не видит.
Идея была основана именно на такой связке. Запускаем на компе программу, которая является сервером UDP, она слушает порт. Активируем на Девайсе протокол UDP. Девайс шлёт на сервер пакет инициализации протокола. Сервак его принимает и сообщает о готовности переслать файл.
Но что-то пошло не так. Брендмауэр и отключал и порт в исключения добавлял, не помогло. А потом ещё и модуль накрылся.
По-моему получилось немного заморочно. UDP удобно использовать когда не надо никаких подтверждений. Джойстики всякие, телеметрия. А ты стал сразу FTP сервер делать. Раз ты устанавливаешь соединение, это проще сделать через TCP. Все низкоуровневые заморочки будут обрабатываться на уровне стека, а ты только потоки шли да принимай.
Я немного ковырял сетевой стек из NOOS-SDK для esp8266, он на базе lwIP с хаками. Не знаю за твои ошибки, но не удивлюсь, если там чего-то не работает на уровне SDK. Вообще странно, как в принципе неплохо оно работает при том, какой там в коде фарш.
По-моему получилось немного заморочно. UDP удобно использовать когда не надо никаких подтверждений. Джойстики всякие, телеметрия. А ты стал сразу FTP сервер делать. Раз ты устанавливаешь соединение, это проще сделать через TCP. Все низкоуровневые заморочки будут обрабатываться на уровне стека, а ты только потоки шли да принимай.
Не хотелось из потоков сообщения/команды выковыривать.
Но судя по всему, так и придётся делать.
Я немного ковырял сетевой стек из NOOS-SDK для esp8266, он на базе lwIP с хаками. Не знаю за твои ошибки, но не удивлюсь, если там чего-то не работает на уровне SDK. Вообще странно, как в принципе неплохо оно работает при том, какой там в коде фарш.
Я свой ESP ещё к Девайсу не подключал. Изучал просто подключив к СОМ-порту, АТ-командами с терминала.
Подозреваю, что в роутере может быть включена какая-то защита. Т.к. mail.ru (по IP-шнику) спокойно пинговался с модуля, а комп в локальной сети - ни в какую. Вполне возможно, что роутер и UDP-пакеты на комп не пропускал. Это одна из причин, что стал рассматривать вариант W5100. Как ни как проводная связь, а не WiFi.
Но хотелось именно избавиться от проводного соединения.
Ой, я AT-firmware вообще не трогал. Я думал у тебя код на самой ESP крутится. Может быть у тебя как-то хитро настроены параметры сети в AT-фирмвари, что на mail.ru уходит через шлюз, а внутренние адреса он не считает достойными соединения с роутером.
Взял другой ESP-модуль. С теми-же настройками сразу заработало. Комп пингуется, UDP-пакеты туды-сюды летают... ляпотааа...
Только вот пока не выяснил, можно ли в режиме АТ-команд, пересылать в UDP-пакетах только текст (символы), или данные тоже корректно примет (касается ESP-модуля).
https://github.com/espressif/ESP8266_AT/wiki/CIPMODE
Transparent mode не оно?
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.
И дальше в инструкции написано, что оно может и не сработать :)
Похоже остается только экспериментировать...
Модемная классика: 1сек пауза +++ 1 сек пауза.
Обнаружил на старой материнке сборки резисторов по 33 Ом. Три сборки по расчетам дают 49.5 Ом. Поменял на модуле с W5100 сборку 510 Ом на бутерброд. Можно будет пробовать и его подцепить к девайсу.
Добавил схему в первое сообщение.
Схема на текущий вариант.
Прогнал первую пару (запрос сеанса - подтверждение) UDP-пакетов между Девайсом и компом...
Сначала не мог понять, комп запрос получил, отправил подтверждение, а Девайс зависает намертво в ожидании подтверждения...
Оказалось, что Девайс, пока читает по UART подтверждение об отправке пакета, с компа уже приходит ответ, и он цепляется паровозом (без интервала) к подтверждению об отправке данных. А Девайс ждал отдельной строки с ответом.
В общем, от чего пытался избавиться (от разделения потока инфы на отдельные пакеты), на то и нарвался.
Можно конечно тормознуть сервак, чтобы так быстро не отвечал...
Похоже будет ещё то развлечение...
Без интервала, но отдельным пакетом? Потому что UDP пакеты могут перепутываться местами и вообще не доходить (на локальной сети это вообще вряд ли), но не должны склеиваться. Конечно, в ESP8266 все может случиться.
Без интервала, но отдельным пакетом? Потому что UDP пакеты могут перепутываться местами и вообще не доходить (на локальной сети это вообще вряд ли), но не должны склеиваться. Конечно, в ESP8266 все может случиться.
Я на то и надеялся, что будут отдельные пакеты. Но содержимое входящих пакетов, без запроса, вываливаются по Uart (сразу по поступлению), по которому ещё и выводятся ответы на команды. Отличить можно по префиксу, но поток общий.
Я все время забываю, что ты через 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 не понимает.
Пока остановился на варианте:
while flag == 0:
time.sleep(0)
Но судя по всему, самые большие тормоза, которые я не учёл дают задержки АТ-команд в ESP :(
Хотя, смотреть как заполняются кубики на загрузочной сетке - это Фича, а не Баг :)
Класс! Качает как Шадки :)
Чтобы на Питоне сделать обмен одним потоком без особых заморочек, можно воспользоваться системным вызовом select(). Он блокирует поток до тех пор, пока не станет доступным ввод-вывод по одному из переданных ему файловых дескрипторов.
Мне кажется, что передача данных одним потоком не совсем подходит. Т.к. этот поток всё равно нужно тормозить со стороны Вектора, для защиты от переполнения принимающего буфера.
У меня сейчас Девайс запрашивает очередной пакет данных, а не сообщает отправляющей стороне о состоянии буфера приёма (пуст/заполнен).
Про Питон и select() - совсем не понял, т.к. практически его не знаю.
Про Питон и select() - совсем не понял, т.к. практически его не знаю.
Это древний но эффективный механизм, который уже много десятилетий позволяет ожидающим ввода-вывода программам не занимать 100% процессора. Суть проста: вместо того, чтобы делать цикл с постоянным опросом "а нет ли чего в буфере?", мы делаем цикл с вызовом select(). select() принимает список файловых дескрипторов, которые нас интересуют, и приостанавливает вызвавший его процесс, пока в буферах обмена этих дескрипторов не появятся данные в случае чтения, или пока не опустошится выходной буфер в случае записи.
Наверное статья-другая с примерами никогда не помешает:
https://steelkiwi.com/blog/working-tcp-sockets/
или
https://pymotw.com/2/select/
Я уверен, что и по-русски где-то есть, но мне сходу попались только сразу какие-то слишком навороченные примеры. А прелесть select() в том, что он прост, как схема выключателя.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot