А esp8266 сам не умеет как-то обратиться к сетевой шаре (NFS или SMB, пусть даже на роутере, многие роутеры это умеют) с темой 'слыш дай мне список файлов, или 'хочу скачать файл такой-то'? То-есть как бы обязательно иметь самописный сервер?
Вид для печати
А esp8266 сам не умеет как-то обратиться к сетевой шаре (NFS или SMB, пусть даже на роутере, многие роутеры это умеют) с темой 'слыш дай мне список файлов, или 'хочу скачать файл такой-то'? То-есть как бы обязательно иметь самописный сервер?
Так и есть.
Есть даже код для отправки на скорости 115200. Но нет кода для приёма. Была ещё мысль сделать 115200 в режиме турбо, просто подогнав код для скорости 57600. Но это получится под конкретную модель. Потому как ускорение в турбе разное.
Вот этого не знаю. Были наработки в теме про WiFi. Или какой-нибудь BB55. Хотя у AY 8 бит шина IO, должно хватить и на передачу, и на контроль.
- - - Добавлено - - -
На заводской прошивке вряд ли. Но надо почитать интернеты.
Ещё была у меня идея читать через ESP карту SD. Библиотеки для этого есть.
Upd. Забыл сказать главную фишку: тут нет аппаратного контроля передачи. Просто сервер шлёт пакеты всегда определённого размера, а клиент пока не примет нужный объём, не остановится.
А вообще лучше брать нормальный FIFO UART да с контролем потока. А не дергать ноги ай думая о турбо или нет оно.
Потестил скоростя в режиме 3.5 герц:
С карты CF на дискету - 2:10
С сервера на карту CF - 3:30 (без контрольных сумм)
С сервера на дискету - 5:38 (без контрольных сумм)
Наверное, можно чуть ускорить, если писать по дорожкам, а не по 1024 байт. То есть сделать буфер 16*256. И, возможно, отформатировать дискету с другим интервалом.
А с ним не надо держать определённую скорость? Я вот выше писал, что лучше бы достаточное количество сигналов, и такое устройство, чтобы скорость могла быть любой.
Ну сейчас есть прототип, какой есть, автор молодец, что в целом концепцию охватил. Сейчас можно по частям все обдумать и проработать.
А вообще любую передачу, конечно, надо взваливать на контроллер интерфейса, чтоб работа с обменом со стороны cpu выглядела как запись данных в один порт, запись команды в другой порт, а затем циклическое считывание статусного регистра на предмет переваривания/готовности ответных данных от контроллера.
Последовательный интерфейсы - это тепло и лампово, как магнитофон с полосками на бордюре, но мне кажется, что параллельная передача здесь была бы куда более к месту.
И если уж говорить про ESP, то у него должно быть достаточно своих gpio-ног для реализации слейв-устройства с параллельным обменом по 8-разрядной шине данных, адресации регистров импровизированного контроллера и линий управления (rd и wr). То есть аппаратно спековскую часть можно бы сократить до дешифратора адреса(ов) и самого esp, а уж потом он будет цепляться к серверу и по сути реализовывать проксирование, отдавая спеку данные небольшими блоками.
Про то, что хватит быстродействия, я особо не сомневаюсь - хотя бы потому что подобный интерфейс реализовывали неплохо даже на avr-ках (эмулятор вг93+флопа by Helbr тому пример).
У меня есть несколько идей, но пока нет опыта в работе с esp, я пока только чужие проекты собирал и вливал в него. Поизучаю, может чего и придумается.
- - - Добавлено - - -
Там скорость его [FIFO UART] передачи определяется его собственным кварцем и делителем, записанным в один и его специальных регистров. То есть отдал ему данные в буфер - и он их на соответствующей скорости со всеми дополнительными битами (старт/стоп/четность) передал. Если в ответ чего-то ждём, поллим статусный регистр, как в нем увидели готовность принятых данных - забрали их чтением из соотв.регистров. За счёт FIFO можем не очень мгновенно и не очень равномерно принятые данные забирать. Так что это значительно удобнее.
Теперь я понял весь план.
Делаем универсальную платку с портом кондратьева для системного разъёма и ZX BUS.
Подключаем к ней ESP на скорости 921600.
Включаем турбо на ZX, если есть.
Гоняем образы TRD с космической скоростью через мой сервер или бродим по инету через браузер Nihirash.
Возможно, сервер не понадобится, потому что Nihirash что-то говорил про облако (ЕМНИП).
И возможно, ребята такое устройство уже допилили и откроют продажи к рождеству. Говорю наугад, инфы у меня нет.
Только если оставлять UDP сервер и ESP режиме моста, то как её переводить в заводской режим для браузера? Хоть две делай.
- - - Добавлено - - -
Да, только тут наверное придётся программировать ESP.
Вооо, в правильном направлении мысль пошла. Сделать ком порт совместимым с каким-то хоть стандартом , реализованном например в Эво и ZXMCARD. Всю грязную работу свалить на какой-нить 16550. Разве что мегабит это перебор и смысла не имеет. Спектрум и 115200 с трудом вытягивает насколько я вижу. Дело за выбором про окола обмена. И главное в написании софта который будет эту самую сеть реализовывать.
Тут мы опять путаем теплое с мягким. 115200 не удается вытянуть в _программном_ режиме, отдавая весь проц на построение потока данных (и считая такты). А это куча пауз и в общем-то выкинутого впустую времени.
Если обмен сделать на чем-то автономном относительно cpu, то и скорость можно получить иную, а может и вообще иначе реализовать обмен. Никто ж не ругается, что обмен с ВГ93 по 8-битной шине медленный - я вот за такой же вариант обмена, хоть и программного, но весьма продуктивного.
16550 можно пересадить на действующую схему, поиграть с ней в плане "а надо ли вообще", а потом углубляться в реализацию параллельного обмена (на avr я себе это представляю, неужто на esp с этим несправиться?)
Ну не совсем. Я вот прикинул, что мне для потока видео надо 1600 000 бит/с. Смотреть фильмы прямо с сервера ).
Да. Я клиента подправлю для железного порта и готово.
Глянул на ZXMC - что-то мне кажется, что там 115200 максимум. Маловато будет.