Разговоры на тему Коммуникаций и Ориона [Архив] - Speccy

Просмотр полной версии : Разговоры на тему Коммуникаций и Ориона

alx32

02.07.2016, 21:11

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

Error404

02.07.2016, 23:09

Да, я присматриваюсь к разработке от HackerVBI и Ко для EvoTSConf, про нее мы по касательной беседовали на соседнем форуме (http://www.nedopc.org/forum/viewtopic.php?f=35&t=7589&start=75), вкратце - я не в восторге (т.к. работа с контроллером через RS-232 это видится как решение от какой-то безысходности - ввиду того что нет нормального подключения как контроллеру на шине через порт), но решение в принципе на мой взгляд имеет право на жизнь, как имеет право на жизнь и Спектранет на Визнете с его максимум четырьмя сокетами. Это если образно: "стеки не осилили, так хоть как-то так". В-общем, пока нет решения где сделано красиво и системно (как начинал делать я но бросил, т.к. себе все доказал что реализуемо, а больше никому не надо), я бы пользовался и таким.

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

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

alx32

03.07.2016, 08:22

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

Error404

03.07.2016, 10:13

Вообще, был период когда руки на тему 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

03.07.2016, 10:55

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

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

Denn

03.07.2016, 12:39

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

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

82C51 (COM1) - http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=876239&viewfull=1#post876239

16C550 (COM2) - http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=876066&viewfull=1#post876066

Error404

03.07.2016, 20:32

Нужна терминальная программа для связи с 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 я лет пять назад тут постил. В этом образе диска (http://zx-pk.ru/threads/18451-altair-dos-v3-x.html?p=514811&viewfull=1#post514811).
Но Кермит - "вещь в себе", для тупо передачи буковок лучше 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-dlya-prk-quot-orion-128-quot.html?p=876239&viewfull=1#post876239

16C550 (COM2) - http://zx-pk.ru/threads/21984-dsdos-dlya-prk-quot-orion-128-quot.html?p=876066&viewfull=1#post876066

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

Error404

04.07.2016, 19:03

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

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

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

Error404

05.07.2016, 19:02

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

Error404

06.07.2016, 13:58

Читаю я тут про старинные терминалы, и вижу что все они в 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-сокетов), все равно никто не осилит.

aviator

06.07.2016, 14:50

Error404

06.07.2016, 15:51

Эх... BBS, FIDO... Ностальгия...

А может сосредоточиться на стеке TCP/IP? Затем TFTP/BOOTP для загрузки системы, типа бездисковый клиент. А на закуску NFS для доступа к файлам.

Одно другому не мешает. Думаю, это должно быть в двух проектах (в двух прошивках).
Первый на BBS - он будет кроссплатформенным, с работой по RS-232. И его проще реализовать.
Второй - TCP/IP. Будет ли это реализация на ESP (я считаю, это должен быть 8-битный интерфейс к ESP через ножки GPIO), или - как я уже начинал - на более низкоуровневом NIC (типа RTL8019 - сделали же стек на нем для MSX?) - время покажет. Я буду допиливать RTL8019, а кто-то может и на ESP что-то родит.

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

Я основной вопрос задам. Кто запилит BBS в ESP?

alx32

06.07.2016, 18:50

Есть готовый вариант с внешним BBS через telnet на ESP...

alx32

06.07.2016, 18:57

Error404

06.07.2016, 19:37

То есть BBS находится на внешнем сервере, а соединение с ним осуществляется через telnet<>uart переходник на esp.
У меня всё равно кубик без дела валяется, так сервер можно и на нём поднять, статьи на эту тему я уже нашёл. Осталось решить проблему со статическим ip.

Что есть такое "кубик"?
И зачем нам внешний сервер при вполне серьезных ресурсах ESP и общей примитивности логики BBS? Да хоть и не внешний (на хостинге), а в своей же квартире, но он же дополнительный! Опять та история "хочешь работать с Орионом - немедленно включи ПиСюк (Cubieborad/RaspberryPI/не суть)"? А тем более если это сервер в чужой квартире/хостинге когда нет никаких гарантий что оно сегодня работает (как щас помню наши фидошные мытарства когда ноды жили на квартирах, были некруглосуточнымим либо хозяева в отпуске)? Такое решение годится только для отладки.

Правильнее было бы впилить сервер BBS в саму ESP, а на внешнем ресурсе (например гугл драйве, к которому можно и обычными средствами ходить - вон дажен с MSX к нему ходят напрямую через RTL8019) хранить только базы BBS и файлы блокировок (чтобы развести одновременный доступ с нескольких BBS когда у каждого в своей ESP свой отдельный инстанс сервера BBS, стучащегося на ГуглДрайв за данными).

Такое ИМХО у меня. :)

alx32

06.07.2016, 19:56

Тут есть очень непреодолимое препятствие - мало ОЗУ.
Что-то фиксированное можно запилить из-за хорошего объёма флеш (в ESP-12 4Мб), а ОЗУ у чистой запущенной прошивки всего 44Кб (heap). А ещё нужно место под скрипт, переменные, кеши и т.д.

Error404

06.07.2016, 22:00

А у CP/M-ных BBS больше что ли было ОЗУ? Те же 48к TPA. Только в этих 48к были не только переменные, стеки и кеши, а еще и сам код BBS - куда как более рыхлый и не оптимальный за счет примитивной системы команд процессора 8080. Классической BBS (с одним модемом как у нас) много ОЗУ не нужно - она однопользовательская (у любого интернет-сервера главный расход ОЗУ на коннекты и связанные с ними структуры). Вот что кода можно много хранить - это плюс. Конечно, конкретную реализацию придется повыбирать, чтобы не оплачивать лишим ОЗУ программирование "в лоб" и фичи нам не нужные.

alx32

06.07.2016, 22:16

Не кода, а данных...
Пользовательский код хранится ввиде скрипта и не может быть больше объёма ОЗУ, потому как он загружается на выполнение весь...

Error404

06.07.2016, 23:25

Говенная система то на поверку. :) Как я и говорил - для утюгов с WIFI, да светодиодом помигать.

С другой стороны, BBS на ВАСИКЕ, что я давал ссылку в посте выше, имеет исходник в десяток килобайт. Не думаю, что скрипт для Микрософт Васик эффективнее LUA.
А что, вся прошивка которая кроме скриптов - она закрытая, добавлять туда никак?

alx32

06.07.2016, 23:35

Error404

07.07.2016, 12:03

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

Если в флешь добавлять отсебятину нельзя, то где хранятся скрипты на LUA которые кастомизируют устройство? Не в ОЗУ же, это был бы бред - устройство же отключается от питания.
Если есть опция хранить скрипты на SD-карте подключенной по штатному порту SPI и один скрипт может вызывать другие (с SD-карты), то это решало бы проблему.

Также, какие бы ни были замечательные скрипты, некоторые процедуры (типа посылки-приема файлов по *modem где надо файлы на лету обрабатывать - менять битность или считать CRC) полезно было бы скомпилить и иметь в либе бинарными - для скорости (да и громоздко это - делать математику на скриптах некоего интерпретируемого псевдоязыка).

Error404

08.07.2016, 18:00

И тишина........

некоторые процедуры (типа посылки-приема файлов по *modem где надо файлы на лету обрабатывать - менять битность или считать CRC) полезно было бы скомпилить и иметь в либе бинарными - для скорости (да и громоздко это - делать математику на скриптах некоего интерпретируемого псевдоязыка).

А вот и пример: пишем модули на С, добавляем их в прошивку (в либу во флешь) и вызываем из LUA:
https://github.com/nodemcu/nodemcu-firmware/wiki/%5BDRAFT%5D-How-to-write-a-C-module

В примере, кстати, опрос линий GPIO ESP-12 на С, так что и в 8-битном интерфейсе с хостом через GPIO наверное тоже нет ничего нереализуемого.

Итого, в С-модули можно запихать например процедуры приема-отправки из/в Орион файлов по X/Y/7-modem, работу с SD-картой и файловой системой на ней и т.п., какие-то сложные но полезные DOOR-утилиты на которые есть С-исходники (типа Lynx (https://habrahabr.ru/post/78850/)), а на LUА заскриптовать логику самой BBS.

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

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

Таки может LUA из скрипта вызывать другой скрипт - командой "dofile(scriptname)", причем скрипт может быть как текстовым, так и компилированным в некий байт-код (т.е. занимает меньше места и выполняется быстрее). Так что я думаю, в память мы не упремся.
А вот и статья для упирающихся в память (https://nodemcu.readthedocs.io/en/master/en/lua-developer-faq/#techniques-for-reducing-ram-and-spiffs-footprint) :)

Единственно, я пока не понял где оно хранит все эти файлы, с которыми работает из LUA через объект file API и функцией dofile(). Где оно, то самое место, которое они называют "файловой системой без подкаталогов"?

alx32

09.07.2016, 00:00

Прошивка, как и файловая система, находится на внешней флеш-памяти, на интерфейсе spi.

OrionExt

09.07.2016, 00:20

Я бы не дал скучать, Error404, но мои знания в udp, tcp протоколах стремятся чуть выше чем знания винды. Что-бы мастера не вызывать по всякому чиху)
А кто мне в соседней теме поможет)

Error404

09.07.2016, 16:28

Прошивка, как и файловая система, находится на внешней флеш-памяти, на интерфейсе spi.

Внешней относительно чего?
Вот есть некое устройство ESP12 под железной крышечкой - этакая гибридная МСХ (в ранних версиях крышки не было ЕМНИП). Я так понимаю, под этой крышечкой есть микроконтроллер, контроллер WIFI и флешь? Про эту флешь речь? Т.е. файловя система довольно емкая - у ESP12 ЕМНИП флеша 4МБайт. (Ибо есть еще и выводы SPI, выведенные наружу - для подключения всякого разного, к которым и можно было бы еще и подключить uSD-карту). Т.е. получается мы даже без SD-карт ничем особо сильно не ограничены, т.к. BBS не обязательно загружать в ОЗУ всю - пользователь вызывает из корневого меню ее разные функции, и в этот момент их соответствующие скрипты и подгружать по dofile(), а всякое сложнокодируемое - так и вовсе из C-либ (оно будет наиболее оптимальнокомпиленное ибо это прямой бинарный код, а не скрипт).

alx32

09.07.2016, 16:41

Error404

09.07.2016, 22:52

Внешняя - относительно микроконтроллера.

Хорошо, сделали мы BBS, а дальше что? Какой контент она должна выдавать?
Ну пусть будет какая-либо стартовая страничка, и?
Каждый раз перепрошивать флеш при изменении контента?
Если хотим хранить инфу в самой ESP-12?

Я так понимаю, мои потоки сознания народ пролистывает. :)

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

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

А при подключени к ESP8266 microSD-карты (ненуачо, ножки SPI на ESP12 есть же) с локальной копией облачных файлов, оно внезапно превращается в оффлайновое хранилище (а-ля жесткий диск).

Один из вариантов реализации: тем же скриптом что дозваниваемся с клиента будем передавать в BBS адрес корня базы данных BBS - локальный на SD или URL в Инете. Каждый налепит столько скриптов сколько ему надо - по количеству БД в облачных хранилищах + 1 скрипт для SD-карты (или несколько если на карте несколько баз).

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

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

Самое забавное - отлаживать эту "BBS в RS232-брелке" прекрасно можно и на РС. Ибо там есть порт и есть терминал. Делов то - начать да кончить, как говорится. :)

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

Схематику для работы ESP12 от типового порта RS-232 кто-нить набросает?

aviator

09.07.2016, 22:55

Вот смотрите, городим BBS для того, чтобы иметь возможность использовать внешнее хранилище для "Ориона". Это основное назначение. Первая задача, которую надо решить - интерфейс взаимодействия с внешним миром. RS232/485 - медленно, нет сейчас готовой периферии для второго конца. А вот Ethernet в самой раз. То есть, решив задачу по его реализации, мы получаем стандартный канал, много ПО с открытыми исходными текстами, которое можно использовать как основу ПО "Ориона". Естественно, будут ограничения на количество одновременно открытых сокетов, ограничения на скорости приёма/передачи данных, но инструмент получается более мощный, чем BBS.

Error404

09.07.2016, 23:49

Есть стек uIP портированный на Орион. http-сервер, ftp-сервер, telnet-сервер (из примеров uIP). Сокетов в приемлимом для программирования виде там нет, писать под uIP упаришься (поэтому и софта другого нет).

Теоретически можно попробовать сдрать InestorLite c MSX. Тоже гемор еще тот и сокеты там не BSD (т.е. тоже не получится не задумаваясь драть клиентские приложения даже имея это стек и исходники с других платформ - опять кончится тем, что получим только то, что написано автором InestorLite - да, чуть больше uIP, но и только).

Проблема в том, что либ реализующих BSD в виде который помещается в 64к допотопного кода z80 - нет. И писать все это с нуля пороха тоже уже нет.

alx32

09.07.2016, 23:50

http://uploads.tapatalk-cdn.com/20160709/22e1940e962922bc6133159563bc74fe.jpg
Схема esp-12e.[emoji6]

Error404

10.07.2016, 00:01

Но от этого проекта (класического стека TCP/IP под классический NIC) я пока не отказался.
Просто мне уже не 18 лет, когда можно увлечся настолько, чтобы кодить с перерывами на еду, много разбивается об "и на это я потрачу человеко-год? да нунафиг, я подумаю об этом годик спустя" :)

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

Схема esp-12e.[emoji6]

Ну, примерно так я и представлял. Флешь к порту SDIO_DATA подключена так, что кроме ее к нему хрен чего подключишь, типа SD-карты, чтобы работало более чем одно устройство (а можно было бы).
А как это подключать к порту? Через MAX?

aviator

10.07.2016, 09:32

Есть стек uIP портированный на Орион. http-сервер, ftp-сервер, telnet-сервер (из примеров uIP). Сокетов в приемлимом для программирования виде там нет, писать под uIP упаришься (поэтому и софта другого нет). ... Проблема в том, что либ реализующих BSD в виде который помещается в 64к допотопного кода z80 - нет. И писать все это с нуля пороха тоже уже нет.
lwIP может влезть. Тем более, у нас несколько больше 64к. Можно допилить.

Error404

10.07.2016, 11:06

lwIP может влезть. Тем более, у нас несколько больше 64к. Можно допилить.

Смотрел я его. Навскидку, исходников многовато чтобы хотя бы код влез в 64к, плюс нужно порядка 20к-30к ОЗУ под буфера IP (хранить пакеты размера окна акноледжей чего не делает uIP). Конечно, можно попробовать применять ОЗУ из нескольких банок, правда переключения на доступ в ОЗУ прочих страниц съедят процессорное время. Собственно, на форумах lwIP сразу и отвечают - в ваши рамки не влезет.

Попробовать lwIP конечно нужно, только процент успешного завершения при таких вводных маловат. :) Поэтому я подумывал начать с MSX и InestorLite, но пока тоже не знаю с какой стороны начинать с ним - оно тоже заточено под работу с коммутацией MSX-ных страниц под 16к. Вcе было бы проще если бы оно было строго под MSXDOS1 (т.е. работало в 64к), но не тут то было. Описаний к нему много, но все не о том что нужно (для портирования бесполезны). :)

OrionExt

10.07.2016, 18:59

Error404

10.07.2016, 21:01

InterNestor Lite хороший пример профессионального подхода к разработке.
Разработан стандарт UNAPI specification. Я бы на этом поиски прекратил.

Каждый раз удивляюсь, что только не разрабатывают (каждый раз придумывают велосипед),
а на MSX это уже есть.

"Стандарт" этот высосан из пальца. Чтобы чуть-чуть облегчить себе жизнь привязавшись к железке (как следствие - усложнив жизнь таким как я "телепортаторам"). Если они так уж хотели щелкать окнами (чего в-общем то для их ассемблерной реализации и не надо - хватило бы и 64к), то брали бы уж за стандарт банковые ОС типа CPM3 со стандартизированным на десяток лет раньше BIOS. Тогда мне достаточно было бы впилить только поддержку этого BIOS - и полетело бы. Но нет, помешал фатальный недостаток (http://nr2xe23nn5zgkltun4.cmle.ru/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D 0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1 %82%D0%BE%D0%BA).

Аналогичного же мнения я и о системе ихнего позднего связывания модулей (по аналогии с дин. связыванием по именам фукций DLL), что неоправданно меделенно и ресурсоемко для 8-биток, в отличие от обыкновенной для 8-биток "кернали вызовов" с декларированными заранее и описанными переходами и параметрами. Да еще и расположенного под потолком, когда что в CP/M что в MSX-DOS для _удобства_ неглупыми людьми кернали размещались в начале ОЗУ. И они у них уже там есть, но вот нате - еще и под потолок ОЗУ влепили керналь для регистрации модулей.

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

OrionExt

10.07.2016, 22:33

Если так говорить то любой новый стандарт появляется на пустом месте, другое дело как он взаимодействует
с существующим стандартом(-ми) и на сколько новый стандарт продуман на будущее. Главное что он есть.
И новых велосипедов придумывать не надо. И к железке он не привязан, как я понял. Для всего подмножества
железок разрабатывается свой БИОС.

По поводу страниц все немного не так. Товарищ Nestor Soriano изначально как я вижу, планировал использовать
возможности MSX2 и MSX-DOS2. Как, в общем, и его детище Nextor. А ограничиваться MSX-DOS1 это изначально 64КБ и все.
По сути, улучшенная версия СР/M 2.2.

По связыванию модулей, я так глубоко не копал.

Самого постоянно одолевают мысли да что за фигня, когда начинаешь на Орионе щелкать банками.
Но так оно построено. А что Орион-Про не использовать, там с этим полегче.

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

Аналогичного же мнения я и о системе ихнего позднего связывания модулей (по аналогии с дин. связыванием по именам фукций DLL), что неоправданно меделенно и ресурсоемко для 8-биток
Думаю смогу объяснить. Все “супер” юзеры, давно сидят на MSX Turbo R. (из wikipedia - ASCII R800 на частоте 7.14 МГц (быстродействие сравнимо с Z80 на частоте до 29 МГц)).

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

Да еще и расположенного под потолком, когда что в CP/M что в MSX-DOS для _удобства_ неглупыми людьми кернали размещались в начале ОЗУ. И они у них уже там есть, но вот нате - еще и под потолок ОЗУ влепили керналь для регистрации модулей.
Сравнивать кернали СР/М и MSX не корректно. И что плохого БИОС с начала, под потолок системную область. Ну не посередине же (Электроника КР-02 там такое было)).
Под потолком хранится, чего там только не хранится, хуки, системные переменные, барсик переменные, мсх-дос переменные,
даже сетевые переменные для наших КУВТ-ов. Вот прикол все это физически расположено по 0 адресу (0 страница):) А потом это связующее звено для всевозможных переключений между страницами памяти. Все четко и понятно:v2_dizzy_drink:

Error404

10.07.2016, 22:42

Сравнивать кернали СР/М и MSX не корректно. И что плохого БИОС с начала, под потолок системную область. Ну не посередине же).
Под потолком хранится, чего там только не хранится, хуки, системные переменные, барсик переменные, мсх-дос переменные,
даже сетевые переменные для наших КУВТ-ов. Вот прикол все это физически расположено по 0 адресу (0 страница):) А потом это связующее звено для всевозможных переключений между страницами памяти. Все четко и понятно:v2_dizzy_drink:

Еще как посередине! Просто "верх удобства": керналь снизу, керналь сверху, а посередке с 4000H переключаемое окно 16к! Застрелиться и не жить. А у людей то еще и ПЗУ бывает в адресном пространстве (либо сверху либо снизу поэтому и кернали либо там либо там, но чаще, где не экономили 2 лог. элемента, - ОЗУ снизу ПЗУ вверху, и керналь соответственно снизу). И вот как тут писать на, к примеру, С среди таких "прекрасных стандартов где все изобрели"? Четко и понятно, епта.

А что Орион-Про не использовать, там с этим полегче.

ага, выкручиавайтесь теперь, подбирайте комп с окном с 4000, умейте на 4000 оттранслироваться и в эти 16к помещаться.
Единственно нормально сделано на MSX - это Юзикс, да и от того автор умудрился исходники пролюбить (не позаботившись отдать людям, а может пожадничав)

OrionExt

10.07.2016, 23:47

И вот как тут писать на, к примеру, С среди таких "прекрасных стандартов где все изобрели"? Четко и понятно, епта.
:D 64КБ адресуемая область памяти. Хочешь жить умей, вертеться. Так и тут. То туда прыг, то сюда. Придумайте что полутуше и удобней. Я не ведал лучше при всем многообразии оборудования подключаемого к MSX. Четкий маппер ОЗУ по 16КБ, расширение до 4МБ (1985г.). Всего 4 8-бит порта.

выкручиавайтесь теперь, подбирайте комп с окном с 4000, умейте на 4000 оттранслироваться и в эти 16к помещаться.
Ага. Понятно. Блин чего тут скажешь. Хитро. Программисты любят пользоваться всякими фичами. От чего другие программисты страдают (как же это перенести, адаптировать):D Хотя в нашем случаи я думаю смогу объяснить, если глубже вникну в тему.

Еще бы хотел добавить. Тут каждый год по несколько новых ZX, звуковых карт, видео карт появляется т.д. Причем все это зачастую между собой не совместимо. Потраченные человеко-часы в пустую (в большинстве мало кому интересно, кроме узкого круга энтузиастов). В общем разброд и шатание. Чего нельзя сказать о MSX комьюнити.

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

Сори. Тогда давайте от "утюга" вай-фай прикручивать. Проще современного уже ничего не найти.

Error404

11.07.2016, 12:22

:D 64КБ адресуемая область памяти. Хочешь жить умей, вертеться. Так и тут. То туда прыг, то сюда. Придумайте что полутуше и удобней. Я не ведал лучше при всем многообразии оборудования подключаемого к MSX. Четкий маппер ОЗУ по 16КБ, расширение до 4МБ (1985г.). Всего 4 8-бит порта.

горизонтальное растягивание ОЗУ в маленьких окошечках на емкости более пары сотен килобайт (т.е. той емкости которой реально охватить в приложении) имеет мало смысла. Плюс неудобство и снижение производительности при написании большого коммутирующего сам себя кода. Плюс отсутствие реального инструментария кроме как самому на асме ковырять. Соответственно и реально использовать это ОЗУ можно только под электронный диск (который был нужен в 80-х а сейчас при дешевом SD/CF не особенно акутален). Что кстати и показала тема "4Мб ОЗУ для МСХ" где каждый второй отписался что не видит смысла по сравнинию с 1Мб платой Камиля (приложений нет), а каждый первый - что эту избыточную емкость даже и продетектить не может. :)

Еще бы хотел добавить. Тут каждый год по несколько новых ZX, звуковых карт, видео карт появляется т.д. Причем все это зачастую между собой не совместимо. Потраченные человеко-часы в пустую (в большинстве мало кому интересно, кроме узкого круга энтузиастов). В общем разброд и шатание. Чего нельзя сказать о MSX комьюнити.

Потому что сейчас такой тренд, железку оказалось проще выпустить чем насытить решение софтом. Такое не только на Орионе, такая же унылая картина и на многих современных платформах где не сидит команда разработчиков на зарплате, взять те же RaspberryPI/OrangePI. А что такого в MSX комьюнити? Я посматривал туда изредка. Не увидел ничего особо интересного со времен как Юзикс вышел (а это на секундочку, 90-е, почти два десятилетия тому).

Сори. Тогда давайте от "утюга" вай-фай прикручивать. Проще современного уже ничего не найти.

По человекочасам это выйдет проще. Я реально тогда 2-3 месяца убил на uIP, а это еще не самый сложный стек. Главное, что одно не отменяет другого. А появится хоть какое-то решение, которое нам уже сейчас по силам программно (в силу того что программить можно нормально - на РС) - оно подстегнет интерес к TCP/IP, а то уныние кругом царит. :) И стоить будет 1,8$ ESP12F и 0,5$ вся остальная обвязка (разъем, max2?? и стаб на 3,3). А то вон я вчера поискал на продажу V9958 - самое дешевое что есть 11$ (одиннадцать, Карл!). Учитывая что и софта на Орионе под нее неизвестно будет ли, понятное дело - чет приуныл. Вот я стопудово за почти тысячу деревянных никакой контроллер (которых по хорошему под макетирование надо тем более хотя бы пару) покупать не стану.

OrionExt

11.07.2016, 13:45

горизонтальное растягивание ОЗУ в маленьких окошечках на емкости более пары сотен килобайт (т.е. той емкости которой реально охватить в приложении) имеет мало смысла. Плюс неудобство и снижение производительности при написании большого коммутирующего сам себя кода. Плюс отсутствие реального инструментария кроме как самому на асме ковырять.
Ну не было в то время другого способа работать с памятью более 64КБ. На IBM PC – сегменты, те же яйца только в профиль. О 4МБ я написал, как пример дальновидности разработчиков. Была заложена возможность расширения, раз и все оставшееся время.

Потому что сейчас такой тренд, железку оказалось проще выпустить чем насытить решение софтом. Такое не только на Орионе, такая же унылая картина и на многих современных платформах где не сидит команда разработчиков на зарплате, взять те же RaspberryPI/OrangePI.
Тут у меня ключевая фраза была “между собой не совместимо”. Если бы энтузиасты объединились вокруг одной аппаратной платформы, толку от их работы было бы в разы больше. И привел пример MSX комьюнити. А то каждый в своей “деревне” придумывает свой улучшенный клон, получает кучу морального удовольствия и на этом все заканчивается.

OrionExt

12.07.2016, 22:34

Читал. Товарищ Nestor Soriano каким-то образом заимел исходники не вышедшей следующей версии MSX-DOS толи 2 толи 3. Так что, его способности явно преувеличены. Вот и появилась операционная система Nextor. Он там как рыба в воде. Исходники получены не официально, поэтому досей пор не опубликованы, по понятным причинам.

Я к тому, что сдаваться не надо:)

Hacker VBI

13.07.2016, 17:12

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

Главный по этому вопросу у нас TS Labs, email ([email protected])
возможно, чем-то поможем.

Hacker VBI

16.07.2016, 12:13

В общем и целом.
Дорогой Error404.
Писать что-то типа ббс, и уже под саму есп - я не возьмусь никогда) с ббс я не знаком, с внутренностями есп - тоже.

Да и кроме того, я считаю что программа минимум уже мною сделана.
Я продолжаю наблюдать запуски зифы (http://ts.retropc.ru/zifi_ver.php), и вижу что несколько человек в день её используют - это уже хорошо, но недостаточно мне для того что бы продолжать работу по развитию системы.

Т.е.:
- всё базово необходимое в зифе есть, и всё это можно использовать;
- есть открытый код самой зифы, который можно форкнуть и чо-то там дополнять, я подскажу что там и где - надрать процедур можно, заюзать этот стандарт для игр/чего-то-там - вполне не сложно;
- задача выполнена, 4 месяца потрачено не в пустую, народу таки нужно и это всё таки ж используется, пусть и слабо - но постоянно;
- перепиливать для спектрума 128 / другой платформы желания нет, ищется другой маниак :)

Error404

16.07.2016, 12:52

Писать что-то типа ббс, и уже под саму есп - я не возьмусь никогда) с ббс я не знаком, с внутренностями есп - тоже.

Ну, дело хозяйское. :) С маньяками нынче напряжно.

Error404

18.07.2016, 15:12

Поскольку "BBS внутри ESP" неожиданно оказалось для нас слишком сложным делом чтобы быстро быть реализованным, на первое время предлагаю вернуться к варианту

Есть готовый вариант с внешним BBS через telnet на ESP...

Т.е. получится тутошний проект (http://zx-pk.ru/threads/25804-podklyuchenie-zx-spectrum-cherez-internet-k-telnet-bbs.html) (кстати, рекомендую ту ветку к прочтению), но не на этажерке из ардуин и визнетов, а с маленьким и дешевым RS-232 донглом (который в перспективе и еще на что-то заточим). Идеологически этот вариант доступа к BBS и для классического стека TCP/IP на типовом классическом NIC годится - был бы telnet-клиент.

Минус в виде необходимости внешних серверов и перспектив договариваться с их сисопами пока не берем в расчет.