Fido под CP/M

[Error404]

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

Ненуачо, вполне годно.
Только надо добавить 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.

[Advertiser]

[rw6hrm]

Ребят, я не фидошник, но кое-какие фразы из темы мне знакомы. Помещаю ccылку на торрент диска cdrom-1994-11-walnutcreek-cpm , в котором нашел пару BBS и почтовых приблуд. Может быть кому и полезно будет...

https://archive.org/download/cdrom-1...rchive.torrent

[SfS]

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

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

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

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

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

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

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

[SfS]

Главное - протокол сделать. Остальное проще.

[Error404]

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



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

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

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

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

[SfS]

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

Ну коечто уже есть. Типа закрыть-открыть сокет, SLIP. но это мизер

[SfS]

Разобрался с некими глюками UART. сейчас ваяю отладку через SLIP. без неё никуда

[SfS]

Вот такое API получается пока что. zxesp_api.pdf
Интересно, сильно ли будет тормозякать.

[Error404]

А почему должно тормозить? На стороне Z80 всяко не медленнее скорости порта будет работать, 32-битных типов нет (они основной тормоз если использовать С на Z80). А вот на стороне ESP - ХЗ, не имею опыта с ней.

[SfS]

А почему должно тормозить? На стороне Z80 всяко не медленнее скорости порта будет работать, 32-битных типов нет (они основной тормоз если использовать С на Z80). А вот на стороне ESP - ХЗ, не имею опыта с ней.

Там такая неувязка получается.

При скорости 115200, порт выдаёт примерно 10Кбайт в секунду.
То есть за прерывание получается 10000/50 = 200 байт.

Насколько я знаю, буфера у RS232 в спеке - то ли по 16 байт то ли вообще их нет.

То есть не получится прерывание копить буфер, а потом быстро считать. Надо постоянно ждать когда придёт байт.

За время ожидания байта проходит 3500 000 / 10 000 = 350 тактов. Не так уж и много в общем-то. Но всё равно - холостое ожидание.

Если бы буфера были по 256 байт - можно было бы куда эффективнее обмениваться с устройствами.
Просто бы по IM2 повешал опрос буферов - есть данные, считал по быстрому - и дальше что-то делать. Но увы. И прерываний от COM-порта тоже нету вроде.

Но что есть то есть. Пока делаю протокол со стороны ESP8266, как задышит - попробую и на ZX сваять ответную часть.