Fido под CP/M

[Error404]

ESP8266 по умолчанию управляется AT-командами. Но если надо, я могу написать свою прошивку, опыт есть.

Есть даже моя готовая прошивка, позволяющая весь TCP стек держать на спеке, а ESP будет просто как сетевуха.

Правда, есть ли TCP на спеке - не знаю. Но на ПК тестил - работает на ура. КОМ-портовая сетевуха рулит

C TCP/IP на Z80 вообще проблема. Более-менее серьезная реализация с открытым кодом мне известна одна - Inestor на MSX (сложноватая: написана на АСМ, имеет привязки к мапперам МСХ), все остальное либо частичное, либо без исходником и для давно канувших платформ. На Спеке пошли по пути прикручивания Wiznet-подобных штук (когда TCPIP обслуживает контроллер/"модем") - такое можно реализовать в ESP? Типа Wiznet-а подключенного по ком-порту с неким API по работе с готовыми сокетами?

[Advertiser]

[SfS]

C TCP/IP на Z80 вообще проблема. Более-менее серьезная реализация с открытым кодом мне известна одна - Inestor на MSX (сложноватая: написана на АСМ, имеет привязки к мапперам МСХ), все остальное либо частичное, либо без исходником и для давно канувших платформ. На Спеке пошли по пути прикручивания Wiznet-подобных штук (когда TCPIP обслуживает контроллер/"модем") - такое можно реализовать в ESP? Типа Wiznet-а подключенного по ком-порту с неким API по работе с готовыми сокетами?

Собственно, на ESP8266 уже есть весь стек TCP. Поддерживает до 4х соединений одновременно. (Может и больше можно - но я не пробовал и не разбирался).
Про TCP/IP на спеке я написал, что это возможно как вариант. Собственно, реализаций TCP именно на z80 я много видел в инете, но насколько они работают - ХБЗ.

Что касается ESP, то я использую SDK и там творить на C/C++ можно что хошь. Можно и API какое-нибудь.

[Error404]

Собственно, на ESP8266 уже есть весь стек TCP. Поддерживает до 4х соединений одновременно. (Может и больше можно - но я не пробовал и не разбирался).
Про TCP/IP на спеке я написал, что это возможно как вариант. Собственно, реализаций TCP именно на z80 я много видел в инете, но насколько они работают - ХБЗ.

Что касается ESP, то я использую SDK и там творить на C/C++ можно что хошь. Можно и API какое-нибудь.

Насколько я немного пару лет назад почитал про ESP, там стек весьма специфически сделан: сокеты там работают в сторону WIFI-подключений, и уже эти подключения могут опционально помигать светодиодом или что-то выплюнуть в RS-232. Нам же надо развернуть это API наоборот: чтобы движок TCPIP слушал RS-232, а по WIFI общался с внешним миром в зависимости от того что ему хост дует в RS-232. Т.е. в оригинале WIFI-подключения это initiatior, а RS-232/GPIO - target (для управления утюгом по WIFI: его включения, выключения и проигрывания на утюге мелодий). Под это было заточено всё: от LUA до оригинальных прошивок, такое ощущение что на разработчиках одинаковые шоры.
А мы же - наоборот, хотим дать свободу утюгу, чтобы он сам был initiator и по своей инициативе через RS-232 решал к чему он желает подключиться.

Возможно что-то изменилось за прошедшие пару лет?
Про Zifi знаю, но там не то что хотелось бы, а нечто промежуточное между описанными выше вариантами.

[Error404]

Собственно, реализаций TCP именно на z80 я много видел в инете, но насколько они работают - ХБЗ.

Реально работающих - две: от UZIX и от Inestor (т.е. оба раза на MSX). Все остальное - из z88sdk, старые оригинальные CP/M и C64 останки на ассемблере, клоны uIP (моя реализация и варианты с Contiki) - это все профанация ибо не несут по человечески сделанного, т.е. хоть с чем-то совместимого, API (всякие "протосокеты" на макросах - это ананизм а не API ), т.е. реально ничего на них не развернешь кроме примитива типа телнета и веб-сервера, для которых строго говоря и TCPIP не то нужен, люди прекрасно делают на голом L2 и процедуре в сотню строк.

[Shiny]

мне показался zed удобным. на реале не гонял.

[jerri]

мне показался zed удобным. на реале не гонял.

ну там с тоссером от SoK он более менее
а вот оригинальный никакой вообще

а после появления Lara Croft Zed не более чем курьез для оригинала

[SfS]

Вот пока такие сумбурные мысли в голове моей. zxesp_api.pdf

[Error404]

Вот пока такие сумбурные мысли в голове моей. zxesp_api.pdf

Ненуачо, вполне годно.
Только надо добавить ioctl c переключателем блокирующий/неблокирующий режим (собственно, и все настроечные функции wifi_* туда же в некий case{IOCTL_FUNC}).

Тогда станет так:
int16_t recv(int8_t sockfd, void *buf, int16_t len, int8_t flags); /*Читает данные из сокета.*/

Возвращает: количество считанных байт (>0) или код ошибки (<0, в т.ч. код для "соединение закрыто")
либо возвращает 0, если данных нет (неблокирующий режим) либо управление не возвращается пока не появятся данные (блокирующий режим)

Слушающие сокеты тоже хотелось бы, нам же серверные вещи тоже понадобятся, тот же telnet к консоли z80.

И не вижу ничего плохого в поллинге. На единичном опросе статуса устройства из регистра он даже быстрее работает, чем обработка единичного прерывания от устройства по смене того же статуса (меньше команд на прочитать флаг наличия данных). Один хрен например в Юзиксе по таймеру уже много чего опрашивается, добавим туда еще и вызов esp_poll(). Я вот думаю в своем клоне CP/M отказаться от RS-232 по INT, оставить только по poll (сейчас там оба, для INT нужен кольцевой буфер, обработку переполнения и т.п. при этом скорость получается меньше при прочих равных).

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

А ограничение в 4 сокета оно реально hardcoded или когда-нить в будущем можно будет его преодолеть?

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

Кстати, в исходном UZIX для TCPIP применялся RS-232-модем по SLIP или PPP. Просто вспомнилось. Жаль, что потеряны все исходники, относившиеся к TCPIP UZIX.

[SfS]

Только надо добавить ioctl c переключателем блокирующий/неблокирующий режим (собственно, и все настроечные функции wifi_* туда же в некий case{IOCTL_FUNC}).

Ну это можно. Но я сначала хочу на ESP сделать прогу. А потом уж за спековскую часть можно приняться.

Возвращает: количество считанных байт (>0) или код ошибки (<0, в т.ч. код для "соединение закрыто")
либо возвращает 0, если данных нет (неблокирующий режим) либо управление не возвращается пока не появятся данные (блокирующий режим)

Я придерживаюсь идеологии линуха-униха.
А там в случае неблокируемого сокета, если данных нет возвращается ошибка EAGAIN.

Да и разночтений нет. 0 вернулся - сокет закрыт. Хоть блокируемый хоть нет.
Код ошибки же в любом случае надо анализировать.

слушающие сокеты тоже хотелось бы, нам же серверные вещи тоже понадобятся, тот же telnet к консоли z80.

Я там про них написал. Но это вторая часть. Там хоть с виду всё и несложно, но потрахаться придётся здорово.
Да и слона надо по кусочкам есть)

[Error404]

Ну это можно. Но я сначала хочу на ESP сделать прогу. А потом уж за спековскую часть можно приняться.



Я придерживаюсь идеологии линуха-униха.
А там в случае неблокируемого сокета, если данных нет возвращается ошибка EAGAIN.

Да и разночтений нет. 0 вернулся - сокет закрыт. Хоть блокируемый хоть нет.
Код ошибки же в любом случае надо анализировать.

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

А код молотить - да, это придется немало.