Fido под CP/M [Архив] - Speccy

Просмотр полной версии : Fido под CP/M

spleen

27.03.2007, 13:34

Народ, а подскажите, существовал ли софт для работы с фидо (мэйлер/тоссер/трекер/ридер) под CP/M?

Максагор

27.03.2007, 13:56

Народ, а подскажите, существовал ли софт для работы с фидо (мэйлер/тоссер/трекер/ридер) под CP/M?

Вроде терминалки существовали. Насчет остального не знаю. Что жеткасается терминалок, то, к примеру, под ATM была одна: http://atmturbo.nedopc.com/download/cpm/system/lnmaster/lnmaster.zip
Правда, сделана она была под специально подключаемый к сабжу HAYES-совместимый момед Z-Contact 1200 (специально разработанный для АТМ), следы которого затерялись в пучинах истории. Но при желании можно покопаться в проге и переписать ее под более другие модемы...

falanger

29.04.2007, 18:12

Максагор

08.05.2007, 17:43

А переработать её под работу через СОМ-порт Камилевской карты ZX-MC с любыми внешними модемами? Не привязыватся к какому-то конкретному млмеду?
Камилевсткая карточка постепенно становится де-факто стандартом как я вижу...

Думаю, что можно. Вот только кто делать-то будет? Спасение утопающих - дело рук самих утопающих. :)

Sonic

10.05.2007, 16:17

Вообще по идее ведь работа с последовательным портом в CP/M идет через драйвер...

Максагор

29.10.2017, 21:45

UP-ну ка я древнющщщую тему. Давайте все же разберемся подробно - имеется ли FIDO-шное ПО под CP/M 80 (v2.2)? Пока серфинг в сети дал только утилиты UUENCODE/UUDECODE. Однако, почему-то не верится, что под столь популярную в 80-х гг. ОСь никто не пытался создать пакет софта под сетку, пик популярности которой также приходится на это десятилетие.

creator

29.10.2017, 21:53

Максагор, ZED на сях писан, сырки доступны. ;)

Максагор

29.10.2017, 22:00

ZED на сях писан, сырки доступны.

Я не о возможности его создать сейчас. А по наличию по сути.

Например, CP/M-совместимая ОС использовалась в Роботроне-1715, а эта машина имел более чем серьезное примерение с соответствующим распространением. Я еще в начале "нулевых" "роботроны" на кассах московских вокзалов. и никто с роботронов в FidoNET не выходил?

jerri

29.10.2017, 22:02

creator, zed это не для слабонервных
я помню его дефолтный тоссер
пока номан его не переписал.

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

Максагор, видимо не нужно было

solegstar

30.10.2017, 18:51

Максагор, на Профи вроде был Terminal.

alvis

31.10.2017, 12:04

На Профи была фидошная терминалка, в двух вариантах - ч/б и цветная, разумеется работали в расширенном экране
. Причем умеющие полноценно работать с почтой, в т.ч. упаковывать пакеты. Работали со стандартным модемом подключаемым через COM-порт.

Максагор

31.10.2017, 13:55

На Профи была фидошная терминалка, в двух вариантах - ч/б и цветная, разумеется работали в расширенном экране

Ну, если вывод текста осуществлялся через системные вызовы CP/M, то режим графики маловажен. Интересно только на сколько символов в строке - 64 или 80 она рассчитана.

Причем умеющие полноценно работать с почтой, в т.ч. упаковывать пакеты. Работали со стандартным модемом подключаемым через COM-порт.

Это здорово. Особенно если работа непосредственно с "железом" модема выделена в отдельный драйвер, который можно сменить.
В общем, если у кого есть - то объявляется поиск хотелось бы "пощупать" самолично на предмет переделки и использования на АТМ.

Error404

31.10.2017, 18:31

А почему FIDO? Весьма усложненная система (сети нод у нас нет, как и нет задачи ходить через одну свою ноду и чтобы ноды обменивались базами). Почему не BBS например, большинство из которых имеют не только файловое хранилище, но и личную почту и групповые рассылки/подписки (и работают по telnet)? Вместо модема, та же ESP8266 одной AT-командой подключается на любой IP, любой порт (одна TCPIP-сессия), этого вполне достаточно чтобы зателнетиться к BBS и сидеть там как мы сейчас на форуме тут сидим.

Максагор

31.10.2017, 20:39

Этот вариант тоже годится.

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

Почему не BBS например, большинство из которых имеют не только файловое хранилище, но и личную почту и групповые рассылки/подписки (и работают по telnet)? Вместо модема, та же ESP8266 одной AT-командой подключается на любой IP, любой порт (одна TCPIP-сессия), этого вполне достаточно чтобы зателнетиться к BBS и сидеть там как мы сейчас на форуме тут сидим.

Хотелось бы поиграться с имеющимся на АТМке COM-портом. Он как-то с ESP8266 может сопрягаться?

SfS

01.11.2017, 07:15

Хотелось бы поиграться с имеющимся на АТМке COM-портом. Он как-то с ESP8266 может сопрягаться?

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

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

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

Shiny

01.11.2017, 09:05

creator, zed это не для слабонервных
Это текстовый редактор?

jerri

01.11.2017, 09:59

Шынни, да написан на С тормозной как паровой каток

http://triumph.hop.ru/Rick_Murray.html

Shiny

01.11.2017, 09:59

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

Error404

01.11.2017, 10:01

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

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

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

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

alvis

01.11.2017, 13:14

Ну, если вывод текста осуществлялся через системные вызовы CP/M, то режим графики маловажен. Интересно только на сколько символов в строке - 64 или 80 она рассчитана.
Важно тем, что в расширенном экране удобнее работать. 64/80 в СР/М на Профи можно переключать "на лету". Весь софт это понимает. Все делается через видеодрайвер.

Это здорово. Особенно если работа непосредственно с "железом" модема выделена в отдельный драйвер, который можно сменить.
В общем, если у кого есть - то объявляется поиск хотелось бы "пощупать" самолично на предмет переделки и использования на АТМ.
Именно через драйвер, т.к. на Профи существует два варианта СОМ-порта, встроенный на платах версий 4 и 5 и в виде внешней платы подключаемой через системный разъем. Эти варианты несовместимы по портам.
Где-то у меня есть все это на дискетах. Постараюсь найти, если нужно.

caro

01.11.2017, 15:38

Максагор

01.11.2017, 20:03

Нашел у себя в базе два архива с программами для Profi в среде CP/M-80 для работы с модемом.
http://caro.su/files/terminal.zip и http://caro.su/files/terminal.rar
В первом архиве образ диска, в другом куча файлов.
И еще один архив с Версией терминала для Profi с цветным экраном:
http://caro.su/files/tmcolor.zip

Спасибо!

Кстати, там в дете про сборку АТМ3 идет обсуждение твоих прошивок клавиатуры:
http://zx-pk.ru/threads/27525-novaya-plata-atm-turbo-8-0-rev-2017.html

Если будет какая-то информация, подключайтесь.

SfS

06.11.2017, 10:41

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

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

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

Error404

06.11.2017, 11:21

Собственно, на 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

06.11.2017, 13:59

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

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

SfS

06.11.2017, 15:24

Насколько я немного пару лет назад почитал про ESP, там стек весьма специфически сделан: сокеты там работают в сторону WIFI-подключений, и уже эти подключения могут опционально помигать светодиодом или что-то выплюнуть в RS-232.

Сокет не может быть "в одну сторону". Сокет - это двунаправленный обмен данными.
Пример, я на ESP8266 делал WEB-сайт. Постоянный обмен данными - от ПК или смартфона запросы, а ESP8266 формирует ответы для рисования веб-странички.

Да о чем я? Для PENTEVO уже создан и прекрасно работает ZiFi http://ts.retropc.ru/ . Это программка, которая через esp лезет в инет и качает музон или игры и пишет их на диск. Ну ещё плеер и вьюер там есть.
Но это чисто для Pentevo.

Что такое ESP8266? Это микроконтроллер с вай-фай транспортом. На нем может крутиться RTOS. Производитель поставляет стандартные прошивки, которые управляются с помощью AT-команд. Недостаток AT-команд в том, что ими сложно рулить. Но в Pentevo сделано.

И ещё есть SDK, в исходниках. Там на C/С++ - можно как угодно делать. Хочешь точка доступа, хочешь станция. Хочешь к тебе коннектятся, хочешь ты. Там и роутер сваять можно и веб-сайт и управление реле если надо.

Я так понимаю, что в принципе, даже стандартная прошивка ESP может обинтернетить любой спек с RS232. Только софт где брать?

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

Вот моя поделка для ESP в исходниках: https://github.com/salextpuru/esp_slip_control
Спеку она не поможет, но зато видно, что ограничений для ESP нету.

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

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

Ограничения, которые я вижу:
1. ESP - только в режиме STATION (точка доступа не нужна).
2. Одновременная поддержка не более 4х соединений.

API- по согласованию с соавтором.
Пока я вижу функции соединиться, разъединиться, отправить данные, принять данные. Ну там видно будет.

Если кому интересно - пишите.

jerri

06.11.2017, 16:03

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

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

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

Error404

06.11.2017, 21:41

Сокет не может быть "в одну сторону". Сокет - это двунаправленный обмен данными.

Давай вот без этих таких вот фраз через губу? Мы с тобой не первый раз говорим за TCP, и ты прекрасно знаешь, что я в теме куда там направлен обмен. :)

Да о чем я? Для PENTEVO уже создан и прекрасно работает ZiFi http://ts.retropc.ru/ . Это программка, которая через esp лезет в инет и качает музон или игры и пишет их на диск. Ну ещё плеер и вьюер там есть.
Но это чисто для Pentevo.
Что такое ESP8266? Это микроконтроллер с вай-фай транспортом. На нем может крутиться RTOS. Производитель поставляет стандартные прошивки, которые управляются с помощью AT-команд. Недостаток AT-команд в том, что ими сложно рулить. Но в Pentevo сделано.

Не канает, по крайней мере в известной мне реализации. Zifi не дает доступа к самому транспорту или сокетам, оно использует доступ у некому API в ЕСП-шке, прослойке, которая сама по себе и не дает произвольного доступа к любому ресурсу, а по некоему списку. Клиентское же ПО не оперирует сетевыми категориями, а скорее работает как BBS-клиент (но при этом ZIFI нельзя использовать для доступа к многочисленным BBS в Инете, о чем я авторов просил - но увы)

Я так понимаю, что в принципе, даже стандартная прошивка ESP может обинтернетить любой спек с RS232. Только софт где брать?

Да, в ESP уже есть AT-команда для соедининия с любым портом любого сервера (задается IP). Вопрос в том что за сервис на на том сервере/порту. Если это например BBS по телнет, то не надо вообще ничего - на Спеке достаточно обычного терминала, умеющего в RS-232. По крайней мере на CP/M это вообще не проблема, есть хорошие вещи типа QTERM. Но это не совсем то что нужно, т.к. только один "сокет", чтобы подключить второй сервер, надо закрыть предыдущее соединение.

Вот моя поделка для ESP в исходниках: https://github.com/salextpuru/esp_slip_control
Спеку она не поможет, но зато видно, что ограничений для ESP нету.

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

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

Ограничения, которые я вижу:
1. ESP - только в режиме STATION (точка доступа не нужна).
2. Одновременная поддержка не более 4х соединений.

API- по согласованию с соавтором.
Пока я вижу функции соединиться, разъединиться, отправить данные, принять данные. Ну там видно будет.

Если кому интересно - пишите.

КМК, c точки зрения интегрирования с уже имеющимися вариантами стека на Z80, могут быть два варианта API (ориентируясь на более-менее уже готовые решения на стороне Z80):
1. API уровня L2 (MAC/PHY) - ESP реализует только функции инициализации и приема-передачи пакетов, весь стек на стороне Z80 - это легко интегрируется в клиентское ПО типа uIP или Inestor (но придется попахать: что та что другая далеко не сахар для портирующего).
2. API уровня L4 (ESP реализует весь TCP/IP, API - BSD-сокеты или подобное) - такое используется на системах с WizNet, готовая реализация - Спектранет с W5100(для ESP потребуется некоторая адаптация).

С первым вариантом я наелся и никому не советую (хотя работающий uIP вроде и получился - на базе NIC RTL8019), второй не изучал вообще. Но может еще кто-то подключится?

SfS

07.11.2017, 10:47

Давай вот без этих таких вот фраз через губу? Мы с тобой не первый раз говорим за TCP, и ты прекрасно знаешь, что я в теме куда там направлен обмен. :)

Извини, вовсе не через губу:) Не помню хоть убей с кем именно и о чём я говорил и тем более не помню кто что знает, а что нет. Тем более если разговор был относительно давно. Не хотел обидеть.

Да, в ESP уже есть AT-команда для соедининия с любым портом любого сервера (задается IP). Вопрос в том что за сервис на на том сервере/порту. Если это например BBS по телнет, то не надо вообще ничего - на Спеке достаточно обычного терминала, умеющего в RS-232. По крайней мере на CP/M это вообще не проблема, есть хорошие вещи типа QTERM. Но это не совсем то что нужно, т.к. только один "сокет", чтобы подключить второй сервер, надо закрыть предыдущее соединение.

ESP на уровне AT команд держит до 4х соединений. Так что уже можно "мультисети" строить:) Там проблема больше в том, что ИЗ ESPв спек данные могут прилететь в любой момент. И часть теряется.

КМК, c точки зрения интегрирования с уже имеющимися вариантами стека на Z80, могут быть два варианта API (ориентируясь на более-менее уже готовые решения на стороне Z80):
1. API уровня L2 (MAC/PHY) - ESP реализует только функции инициализации и приема-передачи пакетов, весь стек на стороне Z80 - это легко интегрируется в клиентское ПО типа uIP или Inestor (но придется попахать: что та что другая далеко не сахар для портирующего).
2. API уровня L4 (ESP реализует весь TCP/IP, API - BSD-сокеты или подобное) - такое используется на системах с WizNet, готовая реализация - Спектранет с W5100(для ESP потребуется некоторая адаптация).

С первым вариантом я наелся и никому не советую (хотя работающий uIP вроде и получился - на базе NIC RTL8019), второй не изучал вообще. Но может еще кто-то подключится?

Я за второй вариант.

Грубо говоря, пишутся функции-обёртки для Z80. Эти функции-обёртки с помощью протокола (надо его подумать) отправляют запрос на ESP, которая их обрабатывает и высылает ответ.

То есть примерно так:
1. Пользователь вызывает функцию
connect( "192.168.2.200:2100", "TCP")
2. Функция обёртывает это в протокол обмена и шлёт по КОМ-порту запрос к ESP.
3. ESP подтверждает, что запрос принят или возвращает ошибку (например, не хватает сокетов или нет связи с точкой доступа)
4. Если запрос принят, то функция ждёт от ESP результата соединения и возвращает его пользователю. Например - номер сокета или -1 если ошибка.

Точно так же дисконнект.

точно так же - запись данных.

А вот с чтением получается хуже. Там надо на прерывания вешать чтение и буфера делать в ESP и тогда можно вычитывать в фоне.

SfS

08.11.2017, 10:00

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

Error404

08.11.2017, 22:42

Вот пока такие сумбурные мысли в голове моей. 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.

rw6hrm

08.11.2017, 22:52

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

https://archive.org/download/cdrom-1994-11-walnutcreek-cpm/cdrom-1994-11-walnutcreek-cpm_archive.torrent

SfS

09.11.2017, 07:01

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

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

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

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

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

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

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

SfS

09.11.2017, 10:33

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

Error404

09.11.2017, 12:09

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

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

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

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

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

SfS

09.11.2017, 15:25

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

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

SfS

11.11.2017, 10:11

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

SfS

13.11.2017, 08:47

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

Error404

13.11.2017, 11:36

SfS

13.11.2017, 12:04

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

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

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

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

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

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

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

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

Error404

13.11.2017, 14:59

У ESP есть еще регистр SPI, и я где-то видел как к нему подключали SD-карту. А можно ли использовать его для обмена с хостом чтобы считать уже пришедший и хранящийся в буфере ESP пакет? Тогда пакет можно будет прочитать быстрее, в рамках одного прерывания, и не надо будет сооружать RS-232 (он есть не у всех, например у меня пока под рукой нет ни одного компа на Z80 с RS-232). Но надо будет соорудить контроллер SPI для Z80. И Мастером должен быть хост а не ESP (возможно ли такое?)

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

А как ты такую же задачу с RS-232 решаешь в реализации на PC?

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

С другой стороны, пускай обработчик работает по прерыванию, пока пакета нет, он отдает время шедулеру (выходит из своей процедуры), а как пакет пришел - делает DI и начинает вычитывать пакет пока не считает его весь, затем EI и далее по цепочке. Да, часть прерываний, пришедших за время вычитки пакета, будет "проглатываться" - ну и что? И опять же, не все пакеты максимальной длины, значительная часть короче: проглотится не так много прерываний, а при массовом обмене большими данными ну пускай система будет притормаживать остальные задачи (всегда чем то приходится платить).

SfS

13.11.2017, 16:54

RS232 есть на мультикартах всех. У меня на пентеве и на фениксе оно тоже есть.
Я про spi тоже думал. Но первый вариант если оно вообще взлетит будет на rs232.
Spi в esp еще не пробовал.
Мастером в любом случае zx будет.

На пц все проще. Там на уровне ос и вызова select все разруливается. Скорости хватает. Прерывания естл от rs232.

Да я пока вообще не морочусь. Просто отметил, что будет проблемка простоя в будущем. В принципе если будет все работать под rs232 то и под spi можно переделать.

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

RS232 есть на мультикартах всех. У меня на пентеве и на фениксе оно тоже есть.
Я про spi тоже думал. Но первый вариант если оно вообще взлетит будет на rs232.
Spi в esp еще не пробовал.
Мастером в любом случае zx будет.

На пц все проще. Там на уровне ос и вызова select все разруливается. Скорости хватает. Прерывания естл от rs232.

Да я пока вообще не морочусь. Просто отметил, что будет проблемка простоя в будущем. В принципе если будет все работать под rs232 то и под spi можно переделать.

skyther

13.11.2017, 22:03

SfS

14.11.2017, 05:49

esp умеет в spi slave. тут примеры: https://github.com/esp8266/Arduino. можно например вот этот https://github.com/jsalin/esp8266_modem проект переделать под spi. единственное нужна не простейшая плата esp-01, что-то со всеми выводами.

Да я в курсе, что умеет. Просто RS232 мне больше нравится. Разница в цене у есп01 и болеt продвинутых несущественная в общемто, так что ориентироваться можно и на ESP 07 например.
Кстати, я пишу в SDK NONOS, то есть без операционки и не в ардуино.
Там вроде 3 задачи максимум и по событиям разруливается всё. Очень удобно, что всё коллбэками сделано. Красиво можно разрулить всё.

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

В идеале, если оно вообще заработает и я не забью на это, то хотелось бы сделать так:

На ESP имеется перемычка, которая позволяет выбрать интерфейс (RS232 или UART-RS232).
Со стороны спека имеются драйвера для всех реализаций с единым внешним пользовательским интерфейсом.

Естественно, если я буду делать это на спеке, то вставлю драйвера в этот сборник: https://github.com/salextpuru/sdcc-noinit

Как-то так.

SfS

15.11.2017, 08:51

Если кому надо, я причесал SLIP https://github.com/salextpuru/libslip

SfS

15.11.2017, 18:16

По-маленьку что-то вроде интерфейса вырисовывается. Есть ещё сомнения по поводу куда CRC воткнуть. https://github.com/salextpuru/libslip

SfS

24.11.2017, 10:50

В час по капле, но работу с пакетами через SLIP допиливаю. Скоро начну эксперименты с реальным ESP8266 и реальным спеком.

SfS

17.12.2017, 18:09

Ура. Пакеты бегают по слипу! не виснет!

http://my-files.ru/Get/9dg8yy/20171217_210935.jpg

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

В общем, скелет есть. Драйвер компорта как отдельная сущность. Протокол SLIP как отдельная сущность. И надстройка для упаковки-распаковки команд ещё не отлаженная.
Сейчас написал маленькую программку, которая эмулирует на ПК то, что в ESP8266 будет и частично есть. На ПК отладка проще.
На фото справа - это монитор спека. Спек шлет poll()-запросы о состоянии сокетов и вайфай, а ПК ему отвечает. Это пока всё, но запрос-ответную часть уже проверить можно.

Теперь буду наращивать мясо - открыть-закрыть сокет, прочитать-записать в сокет.

Все весьма шустренько) Было бы куда шустрее, если бы не отрладочный вывод на спеке.

Error404

16.01.2018, 17:27

Ежемесячный пинг. Как дела в проекте? :rolleyes:

SfS

17.01.2018, 05:52

Новогодний аврал и выходные выкинули месяц) Ещё и ремонт дома приключился.
На выходных закончу ремонт комнаты, разгребу завал и продолжу.

SfS

24.01.2018, 18:02

Протокол вроде заработал. Но реализацию API ещё писать и писать. То, что есть глючит страшно.

В воскресенье еду в командировку на неделю. Так что пока опять всё на 10 дней тормознулось как минимум.

SfS

06.02.2018, 12:33

Вернулся из командировки. Солнечный Узбекистан) Клёво)

Error404

20.02.2018, 12:38

А между тем, публика ждет (http://zx-pk.ru/threads/28862-specialist-ipx-tcp-ip.html), интерес подогреваем посильно. :)

SfS

13.03.2018, 07:47

Публика ждёт, а я гад такой уже месяц за работу не садился. Каюсь.

Максагор

25.11.2022, 17:38

Апну старую тему... Как там разработка?