А что если Arduino Mega 2560 прикрутить?
Памяти то побольше?
Вид для печати
А что если Arduino Mega 2560 прикрутить?
Памяти то побольше?
8кб, а не 2кб? При том, что цена в 1.5 раз дороже чем на esp32 (с учетом даже конвертеров уровней 3.3-5v). На буфер чтения не хватит в любом случае. И 20кб smt32f103 не хватит. Эти варианты (atmeg’и и stm’ки) - разве что для ограниченного капчуринга. Для большинства случаев, конечно, может и хватить. Но за один проход читать не всегда способны (см выше про плавающую скорость при записи). Дороговата эта мега2560, для своих параметров.
Печально что внешних spi/sram модулей нет. Только недешевые и при этом небольшие 32кб fram, и отдельные чипы sram, которые еще вмонтаживать нетривиально (уж явно сложнее чем на монтажной breadboard с десятком проводков и одним сопротивлением).
Esp32 мне видится более подходящим и недорогим кандидатом для качественной работы с любыми дисками на уровне kryoflux. А для ограниченного double density и ардуины хватит. Даже в принципе плавающие биты можно захватывать. Как раз для UDI. Жаль что flashfloppy его не поддерживает. А hfe(по крайней мере первый) не поддерживает плавающие биты.
В качестве бредовой идеи - STM32 и к нему цветной LCD дисплей по вкусу, с доступным чтением из памяти LCD.
1. объем недостаточен.
2. задержки.
Вообще есть проекты в которых из-за бомжовских объемах ОЗУ использовался бы экран с мусором?
Конечно, на бредовые идеи тратить время никто не запрещает. Вперед.
Объема на одну дорожку должно бы хватить с запасом. Задержки, при использовании быстрого процессора с быстрым SPI, тоже не будут проблемой.
Бредовости же в использовании экранной памяти не больше, чем колхозить FRAM или, прости господи, статику. В свое время я подобный велосипед делал на DRAM.
Бредовость все же в разы больше чем колхозить dram. А spi fram модули для подобного куда более к месту чем _экран_, наглядно заполняемый мусором.
А памяти для свободного размещения дорожки HD диска нужно под 128кб. ED диска - 256кб. 512 кб - чтобы уровня Kryoflux достичь. С ESP32 за 250₽ в принципе все это достижимо без извращений в форме использования экрана как RAM буфера.
Вариант "на каждый расшифрованный MFM байт - один байт ОЗУ" - только для идеального случая. Для такого РобСмиттовский вариант пойдёт. А что-то посерьезнее, с нормализацией плавающей скорости, дампом произвольного flux потока хотя бы с частотой 8МГц, и распознаванием HD дисков (1.44Mb) - необходимо как минимум 128кб. Вообще смешные объемы для 2019г. Но микроконтроллеры с 8кб уже считаются "огого" по сравнению с ардуинским копеечным мусором с 2кб оперативы.. Не смешно?
Я считаю, что имеет смысл два варианта проработать. Самый дешевый, через ардуино, который сам будет готовить mfm поток, после первичного калибровочного чтения (для нормализации скоростных характеристик). И тот, который обеспечит анализ всяких защищенных дисков, то есть точные расстояния между импульсами. Для него нужно капчурить магнитный поток в несколько проходов, усреднять, итд. И тут 520кб памяти esp32 более чем достаточно.
Промежуточные какие-то версии типа бюджетных st32 особого смысла не имеют. Они все равно не дадут нужной детализации для качества, хотя бы близкого к kryoflux, но их возможности будут избыточнее ардуины.