Вид для печати
Я именно про это же. 115200 это всё-таки ощутимо медленно (кто на PC данные по нульмодему гонял, хорошо ощущает), а работа по параллельному интерфейсу (в данном примере работа с ВГ93 и флопом) дискомфорта не вызывает. Короче, надо будет осваивать GPIO на esp и перестраивать все на параллельный интерфейс. Я попробую, правда вряд ли раньше новогодних каникул, за это время что-то вроде тз должно в голове улечься.Цитата:
Сообщение от reddie
по факту без турбо тянет 300, вряд ли сильно больше. (8085 на 4МГц тянет 500, т.е. HD дискеты, но с привлечением аппаратных средств. но это совсем другая история)Цитата:
Сообщение от reddie
У вас 250 кбит между дисководом и ВГ93 или между ВГ93 и Z80? ) Это 2 большие разницы. Ну и давайте посчитаем, 3.5 МГц, я прикинул что если не стараться ну сильно извергаться нужно тактов 40 на байт или бит, смотря чем дрыгаем, это будет в районе 87500 байт или бит. Но это минимальное время идеал но железа без вейтов, занятой шины и не занятых портов.
Это скорость потока данных от ВГ93, под неё уже подстраивается протокол обмена с флопом.Цитата:
Сообщение от Kulich
Приводилось просто как пример для ориентира. Можно вообще к LDIR весь обмен свести, дело лишь в реализации.
Это как? Меняет скорость вращения диска чтоль? ) Как-раз скорость чтение диска константна, и она равна 250,500 и прочие кбит, а вот компьютер может читать данные с ВГ как ему удобнее.Цитата:
Сообщение от reddie
То что 115200 у человека получилось получить только сильно извернувшись и поломав голову и говорит о том что где-то в этих пределах и лежит максимальная скорострельность в операциях, правда организация потока, проверка готовности устройства заметно еще скосят скорость даже при параллельном подключении, еще на таких скоростях у UARTов начинается еррор рейт заметный, значит еще и коррекция ошибок понадобится.
Кстати для того чтобы успешно работать на шине нужен достаточно быстрый контроллер, чтобы он успевал дергаться.
Т.е. там порядка 500-700 нс на то чтоб получить прерывание и выставить ответ или просто отреагировать.
Вот тут интересная статья про эмуляцию дисковода и картриджа на STM32
https://www.kernelcrash.com/blog/emu...sx/2020/06/14/
Подождите. На скорпе копирование с карты на карту через SMUC занимает 5 сек целая дискета. В турбе. А это значит около 1.2 мегабита. И причём это сначала чтение, потом запись. А там шина 8 бит.Цитата:
Сообщение от Kulich
А при обмене на 57600 процессор даже не в турбе довольно много ждёт. И по одному биту всё проталкивает. А на 115200 предел возможностей, похоже, для нетурбы. Но это для UART протокола.
Это уже если лезть в технические дебри контроллера и флопа. На стандартном обмене скорость фиксированная, не просто же так существуют эти обороты диска в 300, 360 и другие. Частота ВГ определяет скорость записи данных. Спектрум обязан принять/отослать данные в порт ВГ по сигналу готовности, иначе вылетит ошибка. Вот эта стандартная скорость и есть 250 Кбит (5 оборотов в секунду, 6 Кб на дорожке, итого 30 Кбайт).Цитата:
Сообщение от Kulich
Выше уже отписали о копировании дискеты за 5 секунд, что довольно неплохо. Да, с карты на карту, но что мешает реализовать эти скорости для других типов хранения (приема) данных?
Ну для 7 мегагерц там уже веселее я за 3.5 приводил расчет. Кажется я знаю как работает это копирование, без участия памяти вообще, так-как это тактов 28 на байт из которых in/out 20 съедают точно.Цитата:
Сообщение от reddie
Но вообще это дело десятое, максимальная скорость. Главное чтоб работало=) Я гофернеты в районе 9600 бороздю и не жалуюсь )
Немного почитал. В общем, с завода умеет работать через TCP, командаЦитата:
Сообщение от polikarpov76
AT+CIPSEND Отправить данные TCP/IP
Как я понимаю, так работает гофер браузер. Посылает текстовые запросы типа GET на HTTP сервер.
Но мне такое не подходит, потому что ответы от сервера могут быть разной длины. Тут нужен контроль передачи, чтобы приостанавливать. А так на 57600 времени на анализ пакета нет. Комп всё время ждёт данные.
А у меня все пакеты от сервера равной длины, поэтому просто.
И размер их около килобайта, потому что у меня не получилось за раз пропихнуть через ESP больше, чем примерно 1200 байт. Если пакет больше, она просто игнорирует его ).
Ещё для ESP бывает FTP клиент, он может тягать файлы с сервера и записывать в свою примитивную файловую систему в память или на SD карту.
Доп.
А когда не знаешь какой длины придёт пакет, вопрос когда остановить приём. Сервер http наверное шлёт в конце пакета символ типа 13 или 0. Значит надо выкроить время анализировать каждый байт на лету. И ещё загвоздка в том, что когда выставляешь бит остановить передачу, она останавливается не сразу. Можно битик и потерять.
Даже если эту перезапись реализовать сдвигами напрямую из одной карты в другую (по SPI или по полному 4-разрядному интерфейсу SD), то все равно надо много доп.информации передавать каждой из карте для адресации единиц размещения (файловую систему-то она сама по себе не детализирует, а как без ее разбора ?). Но в СМУКе ж и этого нет. Как копировать без участия памяти-то ?Цитата:
Сообщение от Kulich
И как за 5 сек вся дискета - разъясните, а то аж уснуть не могу )
Что касается предела скорости обмена, тут Kulich действительно прикинул довольно точно.
Вот такой фрагмент кода читает данные из условного "порта данных" некоей идеализированной железяки, которая в идеальном случае успевает формировать очередной байт данных к каждому новому чтению из порта. После чтения байт сохраняется в буфер в ОЗУ.
На это уходит 43 (то есть даже больше, чем 40) тактов на один цикл (=байт), и это без какой-либо прочей обработки полученных данных и контроля готовности очередных данных перед приемом. 81395 циклов в секунду. Но это "сферический конь в вакууме".Код:ld hl, srcaddr
ld de, length
ld bc, portaddr
loop: in a, (c) 12T
ld (hl), a 7T
inc hl 6T
dec de 6T
jr nz, loop 12T
Если в действительности будет даже вдвое меньше, то ~40Кбайт/с при байтном обмене по 8-разрядной шине уже было бы неплохим результатом (~16 сек суммарное время на получение данных всех фрагментов TRD от сервера + обычное суммарное время записи из памяти на флоп с ожиданием позиционирования).
Если бы такое удалось, уже классно. Все зависит действительно от того, насколько хорошо удастся оптимизировать обработку прерывания при обращении к ESP на чтение. Для нас, начинающих, та еще задачка )