Вектор-06Ц: Эмуляция - Виртуальные контроллеры

[KTSerg]

На всякий случай, открою тему.

И как? Подключил? Мне просто интересно, это был только концепт или что-то реальное?

Это проект на плате с stm32, подключенной к "ПУ".
Один из способов загрузить в Вектор программу (реализованных в этом модуле), это по WiFi.
Сверх-задачи не ставил, просто загрузить с компа программу без подключения проводов между Вектором и РС.

Ничего из перечисленного сейчас не используется. Исключительно JavaScript (а это совсем не Java).

При настройке доступа к сайтам, регулярно сталкиваюсь с сообщениями типа : "на вашем компе ... Актив-Х... " и т.д.
И порой сайты требуют установить на комп Джава.

Ой-ли? Для FTP соединения нужны два канала, и куча команд перед тем, как файл начнёт передаваться (и не забываем анализ ответов на команды). Для HTTP нужно лишь соедениться, выплюнуть GET и если файл найден, он тут-же вернётся по тому-же соединению обратно. Пропустить заголовок ответа сложности не составит.

Надеюсь ни кто не собирается реализовывать сокеты и стек на Векторе. В описании модулей написано, что в них уже реализован UDP, FTP, HTTP, POP, ... и пр. дребедень.

Если есть готовая реализация подключения к интернету, могу добавить её в свой эмуль. Нужно лишь описание и работающий на реале пример программы.

Что-то такое припоминаю. Но способов взаимодействия с внешней программой пока никто не предложил. Наиболее простой вариант - это расширение в виде .dll, которую будет подгружать эмулятор. Нужно лишь договориться об API.

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

В Векторе, оборудование сидит на портах. Логично предположить, что и общение между эмулятором и "виртуальным контроллером" должно быть по аналогичному принципу: "записать" байт - "прочитать" байт.


Чтобы не искать по всей ветке, ссылки на сообщения:
Исходники (проект на Delphi7) виртуального контроллера ЛВС для эмулятора emu.
https://zx-pk.ru/threads/31876-vekto...=1#post1067977
И сам виртуальный контроллер с конфигом для эмулятора emu.
https://zx-pk.ru/threads/31876-vekto...=1#post1066541

[Advertiser]

[KTSerg]

Возможно для связи эмулятора с "виртуальным контроллером" подойдут сокеты.
Но сокет это поток, а в реале могут возникать ситуации, когда данные в порт выдаются, но они не воспринимаются (пропускаются) получателем, по каким-то причинам.
Соответственно, эмуляцию этой ситуации нужно обмозговать.
Возможно эмулятор принимая поток должен просто обновлять инфу в регистре (эмулируемого порта Вектора), а выдавать программе Вектора соответственно текущее значение этого регистра, актуальное на момент чтения порта.

[Improver]

При настройке доступа к сайтам, регулярно сталкиваюсь с сообщениями типа : "на вашем компе ... Актив-Х... " и т.д.
И порой сайты требуют установить на комп Джава.

А что если всё это возложить на внешний контроллер, а он путь выдаёт Вектору уже готовый текст? Насколько это будет возможным для контроллера...

[svofski]

А что если всё это возложить на внешний контроллер, а он путь выдаёт Вектору уже готовый текст? Насколько это будет возможным для контроллера...

На несколько порядков возможней, чем для Вектора. Даже думать о настоящем tcp/ip на Векторе... я не хочу сказать, что это нелепо, учитывая то, чем мы тут вообще занимаемся в этом даже что-то есть, но это непропорциональная для него задача.

На Векторе даже последовательного порта стандартного нет, вот с этого нужно начинать. Прерываний нет, поэтому нужна толстая FIFO на килобайт, иначе без шансов как-то серьезно общаться с внешним миром. Когда есть последовательный порт, к нему можно подключить ESP8266 со стандартной AT прошивкой. Это фактически как модем, только вместо ATDT1234567 мы говорим AT+CIPSTART, получаем CONNECT и чатимся с сервером. Поверх этого можно реализовать на самом примитивном уровне HTTP протокол.

Хотя, если бы это делал я, я бы все проблемы буфера оставил ESP, поскольку в ней его как раз достаточно, а общение с Вектором реализовал бы не последовательным портом, а каким-нибудь чудом-юдом на ПУ, чтобы не заморачиваться слишком сложным подключением. Стандартную AT-прошивку в таком случае пришлось бы выкинуть наверное.

Что до контента, вполне очевидно, что Вектор немного опоздал показывать современный web-content. Проще реализовать свой несложный протокол (назвать это модным словом REST API), который отдает Вектору только то, что тот может без особого труда переварить. Например, если это картотека, то один урл будет для текстового описания карточки, другой для каталога файлов в зипе, третий для запроса конкретного файла.

[KTSerg]

...
На Векторе даже последовательного порта стандартного нет, вот с этого нужно начинать. ...

Жаль, что не сохранилась схема или хотя-бы сама плата контроллера СОМ-порта, а только её фото (низкого какчества).
Можно было-бы хотя-бы представление получить о задумке автора.

Сегодня начну эксперименты с сокетами, на предмет возможности общения (с их помощью) эмулятора и "виртуального контроллера".

[svofski]

По-моему в наше время делать отдельный COM-порт для Вектора это лишняя работа. Для ESP12F и прочих Ардуин проще всего забацать расширитель портов типа MCP23S17, который подключить к ПУ. Преобразование уровней только не забыть между 3V3 и 5V частями. Собственно, та же ESP12F может работать как вайфай-модемом, так и просто логической реализацией ком-порта.

[b2m]

Сегодня начну эксперименты с сокетами, на предмет возможности общения (с их помощью) эмулятора и "виртуального контроллера".

Кстати, СОМ-порт в моём эмуляторе может соединяться с сокетом или ждать соединения. Примеры есть в конфигах Башкирии-2М и Корвета РМП/РМУ.

[svofski]

А можно твой COM-порт подключить к Вектору? Откуда списать конфиг и где найти как его настроить, чтобы он соединялся с сокетом?

- - - Добавлено - - -

Извини, я идиот. Вижу, что "примеры есть в конфигах....". Вечер, понедельник.

[KTSerg]

Очень хотелось избавиться от заморочек с идентификацией данных для разных портов в одном потоке.
Хотелось открыть сокет (порт на сервере) в эмуляторе, в программе контроллера открыть нужное кол-во сокетов (клиентов портов) и подключиться ими к серверу. Надеялся, что сервер сможет идентифицировать каждого клиента как определённый порт (соответствующий порту Вектора). Но для сокетов клиента не могу указать конкретный порт (по умолчанию), каждый раз при подключении порты клиентских сокетов меняются.
Сервер конечно их между собой не путает, но как серверу указать, что конкретный порт, будет соответствовать конкретному порту Вектора?
Если только предусмотреть "рукопожатие" - т.е. после подключения клиент шлёт 2-3 байта-идентификатора, указывающие серверу, к какому порту Вектора привязать данного клиента (данный сокет, порт).
Тогда вполне может получиться.
И будет вполне универсально, контроллер можно настроить на любые адреса Ветора без переделок эмулятора.

[svofski]

Я вот как попробовал:

Программа для Прекрасного + конфиг b2m с двумя компортами на портах $30/tcp:15015 и $32/tcp:15016

https://gist.github.com/svofski/da44...690d6463044820

Там же скриншот с запущенной программой и двумя сокатами. Вроде все на удивление просто.