Разговоры на тему Коммуникаций и Ориона

[alx32]

Error404, я тут мучаю одну очень интересную штуку, ESP8266 называется...
И возникла у меня мысля... А не прикрутить ли её к Ориону?
С прошивкой nodemcu есть возможность прикрутить не только ethernet через wifi, но и побаловаться с интернетом. Там есть всё для этого, и стек tcp, и http сервер/клиент, и udp...
А связь с ней держать через uart, правда он 3-х вольтовый, но это не проблема...

[Advertiser]

[Error404]

Да, я присматриваюсь к разработке от HackerVBI и Ко для EvoTSConf, про нее мы по касательной беседовали на соседнем форуме , вкратце - я не в восторге (т.к. работа с контроллером через RS-232 это видится как решение от какой-то безысходности - ввиду того что нет нормального подключения как контроллеру на шине через порт), но решение в принципе на мой взгляд имеет право на жизнь, как имеет право на жизнь и Спектранет на Визнете с его максимум четырьмя сокетами. Это если образно: "стеки не осилили, так хоть как-то так". В-общем, пока нет решения где сделано красиво и системно (как начинал делать я но бросил, т.к. себе все доказал что реализуемо, а больше никому не надо), я бы пользовался и таким.

Очень мельком читал про nodemcu и ее ужасную LUA. Сложилось устойчивое мнение, что все это заточено под управление чем-то типа утюга с доступом к ESP по WIFI из какого-нить Андроид-приложения. Из этого вытекает, что чтобы в Орион подать сигнал (или в утюг) через ножку GPIO - это просто и легко, как просто и легко работает утилита управления этим безобразием внутри ESP на web-сервере с выводом опять же наружу по WIFI (ненуачо ему не работать, для сервера ресурсов никаких не надо - оно у меня и на Орионе работало на RTL8019 если помните). А вот чтобы работало в обратном направлении (хогда инициатор - Орион, а ESP-target) сделано чуть меньше чем ничего, только тот самый несчатсный RS-232, который в-общем то не для того создателями планировался - а для дебажной консольки и перепрошивки, и соответственно и реализован - по остаточному принципу (АТ команды, это даже не смешно ).

Более того, валяется у меня несколько ESP12E, т.е. из последних (взял на Али по случаю), так что дело за малым - заинтересоваться этим. Пока что даже не подключал.

[alx32]

Вот к стати на этих последних есть HSPI, со скоростью до 80МГц. Тоже интерфейс, и не затрагивающий UART. Нужно только сваять схему распараллеливания данных на мелочи...
С другой стороны, через UART можно управлять ESP-хой с Ориона, используя командную строку LUA, загружать, изменять, запускать скрипты разного назначения, а затем использовать этот же UART для передачи данных...

[Error404]

Вообще, был период когда руки на тему ESP немного чесались (тогда и заказал ее с Али), но все уперлось в то, что как оно в моем понимании должно быть, готового решения не было, а быть первопроходцем там где еще и сам контроллер надо изучать - это слишком муторно. Вот на Орионе оно как: преодолел лень (самое сложное) - сваял программу (платформа известна, изучать не требуется, время экономится) - получил эндорфинчики (удовольствие от работы). Мы же обезъянки: если впереди не маячат эндорфинчики хрен попу от дивана оторвем. Причем, очень важен временной лаг от приложения усилия и получения в кровь гормончика: если оно через чур большое (тем паче если результат в следующих поколениях), заставить безволосую макаку этим заниматься почти невозможно - только палками. Через это же и СССР развалился - работать за идею не хотели, зато каждый хотел быть господарем, теперь пашем чтобы с голоду не сдохнуть.

Ну и возвращаясь к баранам. Когда ESP приехали, я посвятил день прочесыванию Инета на предмет готовых реализаций для портирования. И не нашел ни одной, где бы используя ножки GPIO (а их в ревизии 12E/12F дюжина штук - т.е. достаточно для параллельной 8-битной шины) был сделан нормальный сетевой контроллер. Т.е. получился бы некий функциональный аналог Визнета, но с количеством сокетов нормальным (более 4), открытым ПО евойного микрокода, ну и WIFI в качестве среды (что в принципе пофиг, меня и провод бы устроил).

Тут необходимо сделать отступление в терминологию.
Итак, есть:
- Хост (РС, Орион, ...) - это тот компьютер, который итерактивно взаимодействует с пользователем посредством выполняющейся на нем операционной системы ОС.
- на этом хосте есть NIC (контроллер сетевого интерфейса). Пользователю нужно в Инет, он что-то там нажал, Хост нажатие интерпретировал и выдал NIC команду отправить некий пакет на некий сетевой адрес, получить оттуда ответ, о готовности результата доложить. После того обратная интерпретация и вывод ответа пользователю. Так построена работа почти везде, распластывается это на несколько уровней стека TCP/IP (в зависимости от понижения уровня абстракции: от хотелки пользователя к железячным возможностям NIC и сети).
- MCU - это тупо микроконтроллер, который позволяет одним корпусом МСХ закрыть довольно существенный кусок логики компа. Т.е. чип отвечающий за RS-232 - это MCU, NIC - это тоже MCU, да и Орион строго говоря, тоже можно абстрагируясь представить как MCU.
- target/initiator - это тупо кто рулит процессом, от какого из работающих вместе MCU происходит инициатива какой пакет куда послать инициируя обмен, откуда что запросить.

Так вот в моем понимании (и большинстве реализаций начиная с середины прошлого века), сетевые дела делаются по схеме:
Хост (Орион) initiator - NIC target (а точнее - таргеты сидят в сети, а NIC некий промежуточный таргет).

У ESP сейчас:
Некий удаленный хост в сети initiator -> ESP (не то как NIC для того удаленного компа, не то как удаленный MCU с доступом по Инет) -> Орион как target (причем, не сетевой объект, а субъект управления с интеллектом утюга, светодиод припаянный к ножке ESP).

Чтобы это побороть что ты, что HackerVBI предлагаете схему:
Орион как инициатор - MCU - MCU - MCU - ESP тоже инициатор (т.к. на базе ее существующих прошивок).
И вот эти вот "MCU - MCU - MCU", призванные компенсировать первоначальную косячность структуры, меня как системотехника по первому образованию, и корябают за душу. Плюс конечно лишняя работа по этих MCU обтачиванию (см. первый абзац) при все равно в-общем не сильно красивом итоге.

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

[alx32]

Насчёт "MCU - MCU - MCU", то тут нужно привлекать к теме Denn'а, т.к. у него есть готовая реализация UART на 16550 и 8251 (а скоро будет и у меня). Не считая моей на ATtiny2313. Так что со средним MCU можно сказать вопрос решён.

Осталось решить вопрос с Орионом...
Нужна терминальная программа для связи с ESP.

[Denn]

тут нужно привлекать к теме Denn'а, т.к. у него есть готовая реализация UART на 16550 и 8251 (а скоро будет и у меня)

Добавил инфу по программированию (внизу соотв. постов):

82C51 (COM1) - http://zx-pk.ru/threads/21984-dsdos-...l=1#post876239

16C550 (COM2) - http://zx-pk.ru/threads/21984-dsdos-...l=1#post876066

[Error404]

Нужна терминальная программа для связи с ESP.

А вот и терминал в данном архиве во вложении - QTERM v4.2g, сегодня нарыл на каком-то CP/M-ресурсе и настроил на твой вариант RS232 (Альтаир-ДОС, ATTINY2313 на портах F764, F765) ибо другие варианты RS-232 эмулятор не умеет. Изначально оно было для Commodore-128 (экземпляр что брал я), а до того для Xerox, TRS и еще кучи машин. Благо программа универсальная (это ж CP/M, за это и вся борьба) и есть описание как настраивать - я там прямо в тексте "инструкции по патчу" делал пометки, по ним можно настроить под другие типы периферийных плат RS-232. Терминал умеет эмулировать VT100, передавать файлы по Kermit и XModem, выполнять скрипты, и кучу еще всякого - в описании прочитаете. В эмуляторе работает, я проверил выборочно - посылает текст в обе стороны в/из эмулятора из/в виндовозный HyperTerm. Режим 8-N-2. Скорость QTERM тоже умеет выставлять, но я кнопки егошние не выучил (там все режимы включаются через Esc-клавиша) и выставлял скорость предварительно запуская xget.

Терминал Kermit для ATTINY2313 на портах F764, F765 я лет пять назад тут постил. В этом образе диска.
Но Кермит - "вещь в себе", для тупо передачи буковок лучше VT100.

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

Какой однако клевый терминал. Читаю доку, пробую.
Файлы принимает и шлет по протоколам Кермит, Xmodem, Ymodem (я проверил прием по Ymodem - принимает и имя принимаемого корректно берет) в т.ч. декларировано и в пакетном режиме (множество файлов по маске), чатик можно делать - окно делится на 2 области в одной набираешь ты, в другой видно ответы (изначально при старте и своё и ответы одной простыней, правда инверсией все же выделяется), можно указать файл и в виде текста выпулить его получателю, а можно аналогично выпулить в порт скрипт (файл с параметрами как у BAT/SUBMIT файлов) - то что надо для посылки AT-команд в контроллер (например указывая скрипт WGET с параметром URL-адресом)

Картинки:

Скрытый текст

1.
http://savepic.ru/10415553.gif

2.
http://savepic.ru/10417601.gif

3.
http://savepic.ru/10404289.gif

4.
http://savepic.ru/10398145.gif

[свернуть]

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

Добавил инфу по программированию (внизу соотв. постов):

82C51 (COM1) - http://zx-pk.ru/threads/21984-dsdos-...l=1#post876239

16C550 (COM2) - http://zx-pk.ru/threads/21984-dsdos-...l=1#post876066

alx32, теперь твоя очередь поучаствовать.

[Error404]

Как я уже упоминал, в QTERM есть механизм скриптования (операторы-аналоги всех итерактивных команд, плюс переменные в т.ч. и передаваемые как параметры скрипта, над которыми можно делать простые действия, метки, условия выполнения блоков - досконально я не разбирался). Это называется QCHAT (собственно выполнение скрипта) и служит для автоматизации общения с модемом (а точнее - "сервером на той стороне") - набора номера, выдачи AT-команд, отправки и получения файлов, управления локальными файлами ОС и прочее - и все "одной кнопкой". За подробностями читайте файл QTCHAT.DOC в архивах с QTERM.

Во вложении утилита для некоего скриптования и статейка с примером скрипта с комментариями. Те самые AT-команды, которые мы собираемся посылать в ESP12.
Еще нашел чуть более свежие версии QTERM, но пока не патчил. Как пропатчу - размещу здесь же.

И бонус - случайно нашел. Как было написано в комментарии в CPM-хранилище - самая угарная игра. Действительно на это забавно посмотреть. LADDER (он же LodeRunner) в псевдографике для VT-52. Работает что называется искаропки (но можно и настроить под другой терминал - есть setup). В эмуляторе на 5МГц весьма играбелен, даже можно частоту помедленнее наверное.

[Error404]

Во вложении более свежая версия - QTERM v4.3e. Может больше в скриптовом языке (описание в архиве).
На COM-файл применил патч на пересылку по Ymodem/Modem7, тоже найденный в Инете.

[Error404]

Читаю я тут про старинные терминалы, и вижу что все они в 80х в-основном были расчитаны на работу с BBS (bulletin board system), дозванивались до которых через модем подключенный по RS-232. Родилась мысль.
Итак, пару слов о том как можно было бы устроить начальную реализацию взаимодействия Ориона и ESP8266 c "инторнетами".

Лирическое отступление о разработке HackerVBI и Ко для ZXEvo (изучал по диагонали со странички в Бложеках на тутошний конкурс, т.е. давно, и возможно что-то недосмотрел по функционалу).
- ESP8266 и ZXEvo связываются по RS-232, который для приемлимой скорости приходится выкручивать на возможный максимум
- на стороне ZXEvo самописная терминальная программа (только выбор файла и его загрузка либо тут же просмотр/проигрывание), используется графический режим ZXEvo-only
- на стороне ESP8266 серверная часть которая содержит список ZX-ресурсов (файловых хранилищ), каталогизирует их (по этому каталогу и идет выбор на стороне ZXEvo), оттуда скачивает выбранный пользователем файл и передает его на ZXEvo

Что прикольно:
- графическая рамка на стороне ZXEvo
- оно таки уже работает

Что неприкольно:
- ZX-ресурсы (используемые как готовые файловые хранилища) бывают недоступны
- Скачиваемые образы требуют разархивирования, которое происходит на неком внешнем сайте в сети (т.е. не средствами самой ESP8266) - тоже потенциальная точка отказа
- Скачиваемые образы дисков большие и размещаются в оперативке ZX, которой на ZX должно быть в избытке (как это есть на ZXEvo).
- только чтение файлов по списку (нет читалки заранее не заданных отвлеченных страничек, нет поддержки гипертекста, нет обмена между пользователями, нельзя с ZX править содержимое хранилища или хотя бы тупо заливать туда файлы)
- хотя интерфейс и RS-232, но клиент можно использовать только от HackerVBI, штатными ASCII-терминалами низзя.

Итак, мы видим перед собой графически красивый, но сильно урезанный аналог BBS с доступом к внешним хранилищам, расположенными в Интернете и несистематизированными - хранящими ZX-архивы в разных форматах (поэтому на текущем этапе в этой реализации есть сложности с расширением количества этих ресурсов).


Что я предлагаю: в ESP8266 на евойной LUА (язык-интерпретатор в прошивке NodeMCU) запилить полноценный сервер BBS (bulletin board system), который будет отвечать Ориону по RS-232, а по WIFI эта BBS будет иметь доступ к некоему распространенному и общедоступному облачному хранилищу в Инете, где в систематизированной и согласованной между нами форме будут храниться файлы архивов, страничек для чтения (возможно удастся довести их до гипертекстовых) и база данных с перепиской пользователей. Поскольку со стороны Ориона это будет видеться как BBS, то работать с ней можно будет обычными терминалами, качать файлы Орионом можно будет в обе стороны, файлы терминалами штатно льются с/на диск (нет проблемы с требованием кучи ОЗУ), можно будет оставлять сообщения участникам (аналог почты) и можно будет подготавливать и заливать на BBS документы для чтения для групп участников (аналог форума). Продвинутые BBS умеют так называемые DOORs (это типа как CGI: BBS выполняет внешний бинарник, который через ПО BBS общается с клиентом, с использованием этого на BBS были псевдографические игры - квесты, аркады/стрелялки, а можно сделать что угодно что влезает в отображение через ASCII - от интерфейса к стандарным telnet/ftp/elinks/Lynx, до чего у вас фантазии хватит - типа многопользовательских сетевых игр типа Доты )

А вот пример BBS времен CP/M (1980-1982гг). Простая, есть исходники на Bacis и C.
http://www.bbsdocumentary.com/software/AACPM/CPM/RBBS/
http://www.retroarchive.org/cpm/cdrom/CPM/BBSING/RBBS/

А вот как некая BBS выглядит например на слабеньком Commodore-64 (вдруг кто-то не пользовался BBS):
https://www.youtube.com/watch?v=wnzlBWL_c4Q

Благодаря тому что это будет прошивка для ESP8266 для превращения ее в BBS, а клиенты - стандартные терминалы, то решение можно использовать не только с Орионом, но хоть со Специалистом, хоть с RK-86, хоть со Спеком, и под любой ОС куда осилишь портирование терминала (QTERM к примеру - в исходниках), и где есть куда подключить маленький RS-232 брелочек содержащий эту ESP8266: сегодня он у тебя в Орион включен, завтра его же переткнули в RK86, послезавтра - в Специалист или Спек.
Не нужно будет никаких адаптаций к другим платформам, максимум - корень Базы данных BBS менять (где в облаке лежат все ее архивы). А можно и общий архив на несколько платформ забацать. Ну мало ли, например на Орионе под эмулятором ZX кто-то захочет игры от Спека запускать.

А при подключени к ESP8266 microSD-карты (ненуачо, ножки SPI на ESP12 есть же) с локальной копией облачных файлов, оно внезапно превращается в оффлайновое хранилище (а-ля жесткий диск). Типо того что у Vinxru в его реализации SD-контроллера на АтМеге для клонов RK-86 со встроенным файловым коммандером, но куда как универсальнее (если закрыть глаза на необходимость наличия в 8-битке порта RS-232).

А главное - тепло и лампово: BBS же, RS-232 модем, привет из 80х.
И не отменяет работ по написанию программного стека TCP/IP на базе обычных NIC, ибо через ESP8266 сделать нормально его экспорт , уже готового (TCP-функций из ESP8266 в 8-битные клоны по аналогии с Wiznet, например в виде BSD-сокетов), все равно никто не осилит.