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

[Error404]

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

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

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

[Error404]

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

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

А вот и пример: пишем модули на С, добавляем их в прошивку (в либу во флешь) и вызываем из LUA:
https://github.com/nodemcu/nodemcu-f...ite-a-C-module

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

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

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

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

Таки может LUA из скрипта вызывать другой скрипт - командой "dofile(scriptname)", причем скрипт может быть как текстовым, так и компилированным в некий байт-код (т.е. занимает меньше места и выполняется быстрее). Так что я думаю, в память мы не упремся.
А вот и статья для упирающихся в память

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

[alx32]

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

[OrionExt]

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

[Error404]

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

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

[alx32]

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

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

[Error404]

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

Хорошо, сделали мы 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]

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

[Error404]

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

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

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

[alx32]

Схема esp-12e.