51

Re: Мост # 3 - специализированный компьютер для чтения дискет

Понятно, чтобы процесс был максимально наглядным.
Я просто как-то отвык от интерфейсов на отдельных светодиодах ;), когда можно взять недорогой экран 3” 256х64 и на нем нарисовать все эти точки и стрелки.

52

Re: Мост # 3 - специализированный компьютер для чтения дискет

2 sintech : спасибо за ссылочку на инструкцию, почти то же самое на sjways: отправляем герберы на адрес, указанный в описании лота, потом приходит ссылка на али, счёт и сколько надо там заказать.
Счёт выставили на $25 за 5 плат + $10 за доставку, на али заказываем 15 штук по $1 + доставка ещё $20 - те же $35 в сумме выходит.

Я маленько протупил тут: в письме было написано: "Write 15 in quantity and pay the order."
Я и подумал, что это будет полная сумма заказа ("норм, jlcpcb столько же просят, на онлайн калькуляторе сильно больше было"), не обратил внимание на стоимость доставки.

Но, в общем, в любом случае уже пришло подтверждение что всё ок, платы в производстве, ждите номер трека.

53 Отредактировано Voldemar0 (10-07-2022 04:38)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Посылка в пути 4 дня

Последняя информация о местоположении получена 6 июля.

Примерный срок доставки службой «China EMS ePacket» от 24 до 26 дней. Примерный срок доставки службой «Почта России» от 23 до 28 дней.

54 Отредактировано Voldemar0 (22-07-2022 11:30)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Прогуливался мимо полок и шкафов на работе, взглядом зацепился за USB-шный флопик.
Старожилы говорят, что лет 10 назад, а может даже и чуть позже некто брал этот флопик в командировку.
Какой-то объект, вроде АТСки, который надо было немного подконфигурировать, а всё ПО как раз было на дискетах.

И че-то меня вдруг вопрос заинтересовал: а как оно работает?
Вопрос не простой: когда мы используем через USB какой нибудь НЖМД или DVD - то они уже имеют унифицированный шинный интерфейс и вопросы формата записи и прочие интимные подробности прячут внутри. А снаружи только конвертор ATA/ATAPI - USB.

С другой стороны: где-то бродила байка, что когда к каноничной PC (врёмен до UEFI) подключался USB-накопитель, то BIOS отличала флопик от харда, в основном, только по объёму. Если только пользователь не подкрутил в BIOS SETUP соответствующую настройку. Получается, что USB-флопик, вероятно, имел интерфейс всё тот же - UMASS STORAGE - который поддерживают и всякие флешки и прочая USB-базирующаяся накопительная техника. Т.е. для линуха и для винды никаких особых драйверов не надо, всё по стандарту.

Но тогда возникал другой вопрос: а как флопики форматировать в таком дисководе ? Вроде как команд форматирования для флешек, хардов и прочего как бы отсутствует?

Сегодня я поизучал этот интересный вопрос: кто-то может быть удивится, но: всё в порядке, USB-флопики работают, даже на вполне современных системах. Проверил на Win10 - ок, с комстроки даже можно форматировать. Разве что с кешированием непорядок: ничего не меняю на диске, не вынимаю его, но любые действия в "Проводнике" сопровождаются перечтением едва ли не половины дискеты. Проверил в linux: всё хорошо, правда вылез интересный нюанс: каноничная утилита fdformat с USB-флопиками работать не хочет. Для такого случая используется новая утилитка: ufiformat. Ну и ладно, главное - работает. Интересно, что fdformat входит где-то по умолчанию в debian (через пакет util-linux), а ufiformat пришлось ставить отдельно, через apt. Доступ к флопику через устройства группы /dev/sd* - т.е. это слой SCSI-devices - как и все флешки, (S)ATA, ATAPI...

Из этого всего напрашивается вывод, что USB-флопик - это уже не просто флопик + конвертор протоколов, а устройство с полноценным флоп-контроллером, имеющим USB интерфейс. И также это означает, что где-то в стандартах UMASS STORAGE сидит команда форматирования дорожки накопителя, возможно, как -то объединённая с командами включения/выключения привода и движения головок. И, скорее всего, всё это как-то перекликается с древней темой SCSI-интерфейсов.

Я к чему это всё: аппаратная архитектура Моста 3 не исключает такого странного режима, как контроллер usb-флопа  ;)

Дискета, которую я пробовал форматировать, использовалась с Агатом и имеет заклеенное отверстие плотности записи.
И виндовый format таки это понял и отформатировал её на 720к. При том, что в его встроенной справке этот формат не указан (ключик "/F:" - единственный вариант значения - "1.44").

Вот и посмотрим, что скажет виндовый формат на предложение поработать с дисководом 140-кой :))

--

Печатки пока где-то совершают вояж по Китаю. Даже до границ не добрались.

55 Отредактировано sintech (22-07-2022 12:27)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Недавно тоже купил себе USB-флоп для облегчения работы с дискетами на современном PC и задался примерно такими-же вопросами.
Оказалось, что для дисководов в USB Mass Storage Class отведен отдельный subclass 0x4 - UFI (Specifies how to interface Floppy Disk Drives to USB). Расшифровки UFI в самих документах нет, но я бы предположил что это USB Floppy Interface ;)

В документе "UFI Command Specification" как раз описаны все команды по работе с дисководом и они похожи на обычные 12 байтные ATAPI команды, через которые работают CD-ROM, Iomega ZIP и LS120.
В число команд входит READ CAPACITY 25h, в которой устройство отвечает хосту номер последнего доступного сектора, для дисковода 1.44 это 0xb3f. Еще есть команда READ FORMAT CAPACITIES 23h, в которой устройство явно передает объемы в которые можно форматировать носитель, для UFI похоже доступны только три варианта 720к, 1.2м, 1.44м.

P.S. На али продаются адаптеры USB - 34pin к которым можно подключить обычный дисковод https://aliexpress.ru/item/1005001812138589.html

P.P.S. Две недели назад заказал несколько маленьких печаток в PCBWay с оплатой прям на сайте и доставкой CDEK. После производства они на две недели провались в черную дыру, а потом вынырнули в Москве и на следующий день курьер принес домой.

Post's attachments

Attachment icon ufi_format.png 24.38 kb, 50 downloads since 2022-07-22 

56 Отредактировано Voldemar0 (25-07-2022 07:29)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Интересно !

Порылся по ali: платка с доставкой 500-600 р, полный usb-флопик: 900 р. Т.е. где-то есть флопики без USB по 300-400р ? :)
Интересно, у них встроенный контроллер - это сразу однокристальный дисковод или всё таки микрух две: аналоговый канал отдельно и usb- контроллер отдельно?

57

Re: Мост # 3 - специализированный компьютер для чтения дискет

Вот потроха моего usb-fdd:

Spoiler

https://i.ibb.co/dMDm0kj/1.jpg

Spoiler

https://i.ibb.co/5R9zLsN/2.jpg

58

Re: Мост # 3 - специализированный компьютер для чтения дискет

А маркировку крупных микрух можешь написать?

59

Re: Мост # 3 - специализированный компьютер для чтения дискет

Маркировка той, что хорошо видна: FDN305 - это стандартный контроллер флопа.
К сожалению, рассмотреть скрытую под механикой не получается, разобрать - не вариант, там упоротая конструкция, боюсь не соберу обратно.

60

Re: Мост # 3 - специализированный компьютер для чтения дискет

Платы пришли, снял маленький тизер по монтажу:
https://youtu.be/A4wfbLg44yU
Где-то на неделе будет первая серия: монтаж цепей питания, SoM и проверка запуска SoM.

61

Re: Мост # 3 - специализированный компьютер для чтения дискет

Первая часть.
https://youtu.be/_7bCbuQS3lQ
Довольно длиная, следующие будут короче.

Сколько будет частей - пока не знаю.
Буду снимать постепенно.

Надо ещё над дизайном внутреннего сайта подумать.
Чтобы как-то не сложно, но всё таки удобно.

62

Re: Мост # 3 - специализированный компьютер для чтения дискет

Вторая часть.
https://youtu.be/oZwRrj_YNbs

63

Re: Мост # 3 - специализированный компьютер для чтения дискет

Я фигею  с тебя, зеленый.  Это что-то потрясающее. Последний раз я такие чувства испытывал, когда в 5 лет увидел чайку (Газ-13).

64

Re: Мост # 3 - специализированный компьютер для чтения дискет

Приезжай в Томск. У нас тут в соседнем дворе Чайка стояла чья-то, с полгода.
А недавно видел в потоке машин что-то вроде Руссобалта проехало (карета с двигателем и чемодан сзади). И даже не дымило на всю улицу. Не успел сфотать.
С месяц назад, около Телецкого Озера проезжал ГАЗ М-1, в идеале, на номерах.
Где-то ещё американцы годов 70-80 катаются.
А в моём дворе 968 запор зависал долгое время, на ходу, в весьма приличном виде.

65 Отредактировано Voldemar0 (10-09-2022 11:32)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Мысль пришла интересная.

Когда я думал о семплере, я его представлял как упрощенный контроллер : т.е. это устройство, которое через равные промежутки времени анализирует текущее значение входного уровня сигнала. Однако поскольку контроллер упрощенный, он не анализирует, а только запоминает значение.

Когда я понял, что SPI-контроллер не вывозит эту задачу, то пытался придумать некое расширение, которое бы включало внешнее ОЗУ и матрицу, которая выдаёт адреса и запоминает значения входного сигнала.
Вопрос в размере ОЗУ: большое для всей дорожки или небольшое, но которое процессор будет читать одновременно с работой дисковода (т.е. хранящее не всю дорожку, а только выравнивающее скорости чтения с дискеты и захвата процессором).
Семплер в текущем виде - это и есть большое ОЗУ и тактовый генератор.

Но, в конце концов, для дальнейшего анализа важны только интервалы между фронтами.
Значит, вообще-то, простой семплер может быть устроен совсем не так: он может состоять из счётчика и логики, которая, при поступлении очередного импульса сохраняет значение счётчика в ОЗУ и затем сбрасывает счётчик.

В чём тут преимущество: поскольку у нас нет задачи анализировать интервалы, превышающие примерно 15 мкс, то  это потребует заметно меньшего объёма ОЗУ.
Сейчас семплер работает с 8 МГц, т.е. для интервала в 4 мкс это составляет 32 интервала или бита.
Для интервала 8 мкс - это уже 64 бита.
Если же ввести счётчик тактов и хранить его, то 64 интервала - всего 6 бит счёта.
Даже максимальный интервал укладывается в 1 байт: 15*8 = 120.
Минимальных же интервалов - 1 мкс и меньше (т.е. которые бы занимали меньше байта при сохранении как выборки, а не счётчик) у нас не ожидается. Даже если читать HD - всё равно там минимум - около 2 мкс.

При этом точность оценки расстояния между фронтами нисколько не страдает.

Такая схема бы снизила требования к объёму внешнего ОЗУ, к тому же ускорила бы его перенос в основное ОЗУ системы. Во первых, за счёт меньшего объёма переносимых данных, а - во вторых - за счёт того, что преобразование отсчётов в интервалы времени происходило бы снаружи проца.
Сейчас оно делается программой, исполняющейся на ЦП.

Надо покрутить эту идею, возможно, после какой-то опыта с Мостом 3 станут понятны и другие возможности его улучшения и можно будет использовать их в Мосту 3.1.

66

Re: Мост # 3 - специализированный компьютер для чтения дискет

Так вроде все это уже реализовано в аппаратных блоках существующих микроконтроллеров:
* Timer Input capture в STM32 и их китайских аналогах
* RMT в ESP32

67 Отредактировано Voldemar0 (11-09-2022 09:32)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Да, теперь припоминаю, что и у AVR где-то мелькал такой режим таймеров.

У imx я не помню такой фичи, но там 3000 страниц документации и можно не расчитывать, что я их все внимательно читал. Может там и есть что-то. А если нет - то воткнуть мегу мелкую рядом, её даже прошивать можно с imx'а...

Допустим, один период кодируем в один байт, средняя длительность периодов ~6 мкс, 200000/6 = 33 тысячи байт в 0.2 секунды. 166 кб/секунду надо будет протащить из меги в imx - это битрейт около 1.5 мбит/секунду, если передавать последовательно. Либо тащить параллельно, благо там gpio пока ещё много свободных (вчера как раз сидел и разбирался с тем, как у imx ногами одновременно махать - похоже, есть минимум два способа).

Но отложим это пока.

Текущая реализация семплера предельно простая и вполне работает, в т.ч. на имеющейся плате - проверил уже. Пока медленно, но идеи есть, где копать.
Также вчера удалось измерить скорость вращения 840ки по сигналу Index, точность - знака 3 легко, 5-6 знаков, если собирать статистику по нескольким оборотам. И голова уже хорошо бегает.

Post's attachments

DSC_3913s.jpg, 380.7 kb, 750 x 514
DSC_3913s.jpg 380.7 kb, 100 downloads since 2022-09-11 

68

Re: Мост # 3 - специализированный компьютер для чтения дискет

Третья часть:
https://youtu.be/7V4imsdkGTQ

69 Отредактировано Voldemar0 (25-10-2022 11:50)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Начал писать чистовик ПО управления пользовательским интерфейсом, возникла странная трабла:
микруха tm1637 упорно не хочет реагировать на нажатия некоторых кнопок. Уже до осцилографа дошло и он не показал ничего интересного.

tm1637 - широко распространнённый в инетах и магазинах драйвер светодиодного дисплея и как драйвер он работает вполне хорошо и в соответствии с мануалом. Но если верить даташиту, у него есть возможность зацепить клавиатуру с матрицей 8x2, при этом 8 - это число сегментных линий управления дисплеем (т.е. клавиатура и дисплей используют совмещённые выводы), а 2 - это два отдельных входа для сканирования клавиатуры. И вот, почему-то, кнопки, подключенные на нечётные сегментные линии вообще никак себя не проявляют. Хотя на дисплее все сегменты работают.. Процедура чтения всех клавиш общая: запрос байта и в нём сидит номер сегментной линии и бит входа - т.е. 3+2 бита. На неработающие кнопки микра не реагирует никак : возвращает байт 0xFF, что соответствует отсутствию нажатия чего либо.

Не то, чтобы это фатальная проблема сейчас, но очень уж странная. Т.е. отказ микры вроде как невероятен - сегменты дисплея нормально работают. Отказ линий входа клавиатуры тоже невероятен - половина кнопок по ним работает. Порылся в инете на предмет всяких ардуинских драйверов, но в них либо нет поддержки клавиатуры либо она крайне похожа на мою.
--
Когда закончу с клавиатурой, смогу закончить практически написанную прогу "скорость" (которая по индексу работает на 840ке) - она работает, но пока только "внутри себя".

70

Re: Мост # 3 - специализированный компьютер для чтения дискет

Кто знает, как по английский называется позиционер головок ? Или лучше как назвать диагностическую прогу, которая измеряет скорость дисковода и двигает головки ?
Speed meter and head positioner ? head seeker ?
Нужно внутреннее имя, там только латиница.

71

Re: Мост # 3 - специализированный компьютер для чтения дискет

Позиционер официально "head actuator". Хотя некоторые его называют просто "stepper" (типа "шаговик").
Измеритель скорости вращения будет что-то вроде "spindle RPM meter".
Все вместе... ну пусть будет "spindle and actuator tester".

72 Отредактировано Voldemar0 (04-11-2022 20:16)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Спасибо !
Назвал "Spindle RPM and actuator tester". Как яхту назовёте так и поплывёт :)
На экранчике платы называется просто ">> Скорость <<", в web-интерфейсе будет какое-то развёрнутое название.
--
По софту есть три больших вершины, которые нужно достичь:

1) Переходим от моделек к чистовым прогам. Нужна система сборки (Makefile) и хорошие архитектурные решения по части раскидывания общих функций по библиотекам.

В основном ПО Моста3 повторяет ПО Моста2, но творчески.

clock - прога, проверяющая часы теперь будет называться sram-check, она проверяет ОЗУ семплера, ну и тут же можно сделать проверку кварца семплера. Её пока нет в чистовом виде, но есть в виде черновика, пока без проверки кварца.

Тут некоторая заморока в том, что я стал докапываться насчёт низкой скорости обмена с семплером и выкопал следующее:
Всё таки сам SPI-контроллер работает на 30 МГц и всё норм. Не норм в том, что само обращение к стеку драйверов весит прилично по времени. Кроме того, судя по исходнику верхнего же драйвера в стеке, там есть некоторые лишние действия: ядро сперва получает данные в память контроллера SPI, потом тащит их в основное ОЗУ ядра, потом перекладывает оттуда в ОЗУ программы. Получается не быстро. Даже оптимизация обращения к драйверу (больше данных за обращение - примерно 60 слов вместо 15) уже позволила приподнять скорость раза в 1.5. Но этого мало. Есть мысль, что ещё можно улучшить пару мест: в драйвере верхнего уровня сразу предусмотреть первый слой раскодирования - чтобы в мою прогу шли уже интервалы, а не голые выборки; и кроме того попытаться распараллелить получение данных из памяти контроллера в память ядра и первый слой раскодирования. Сейчас на время получения данных из контроллера поток исполнения просто стопится.

И всё же прога "скорость" у меня уже почти в чистовом варианте. Она работает, выводит на консоль и на индикаторы платы результаты.
Причем я объединил в одну две программы моста2: pos и speed. Т.е. она одновременно измеряет скорость и позволяет двигать головку. Пока измерение только для 840-ки, по сигналу индекса. В дальнейшем её нужно будет расширить на случай 140ки и измерений по интервалам между адресными полями - в 140ке сигнала индекс нет.

По итогу работы над ней кристализовались несколько библиотек:
- GPIO - управление дискретными линиями проца через новый интерфейс ядра gpio-chip. Это управление не через /sys/class/gpio, как было до 5-го поколения ядер, а через /dev/gpiochipX. В общем-то, немного ровнее код тут получается, и - что для меня важно: для входящих линий ядро делает пометку о точном времени события (т.е. когда линию дёргают снаружи). Для проги Скорость это даёт хорошую точность измерений по индексу. Замер по адресным полям в этом уже не особо нуждается - там вся точность определяются точностью генератора семплера.

- drive_control - всё управление флопиком: включить/выключить, подвинуть голову (вправо, влево, на нужную дорожку, на ноль) и всё такое прочее. Насколько возможно, эта библиотека нивелирует разницу между управлением 140кой и 840кой.

- err_proc - всякие мелочи по самоконтролю программ, отладке, assert() и всё такое.

- term - управление прогой во время её работы из консоли: т.е. например: Скорость считает периоды, но я хочу сдвинуть головку: я нажимаю стрелку и прога, не прерываясь, что-то двигает головой. В реалиях юниха на это нужно немного дополнительных действий, так как терминал, обычно, настроен на то, чтобы работать со строками, а не отдельными кнопками. А мне нужны не только кнопки с консоли, но и клавиатуры, размещённой на самом устройство. Плюс к тому, для работы с web-интерфейсом прога тоже должна иметь какой-то простой механизм взаимодействия с браузером.

Да, есть библиотека ncurses, которая решает всё по консольной клавиатуре и экрану, но я опасаюсь, что её применение усложнит режим работы прог в качестве бекэнда для web-режима.

- UI-server и UI-client. Это механизм для удобного управления пользовательским интерфейсом платы. Т.е. сюда включаются как драйвера контроллеров LED, OLED, клавиатуры так и механника удобного использования всего этого добра из конечных программ. Примерно так:
ui_printf("LED8:%4d", track) - и переменная track сразу улетает на крупый дисплей.
или так:
ui_printf("OLED:\\6l\\0pПериод: \\i%6.2f мс\\i ", (double) delta / 1000000);
Выводит в строку 6 позицию 0 OLED-дисплея строку "Период: 199.56 мс", причём цифра выводится в инверсии.
Шрифт, само собой, агатовский.

Эта механника может использоваться как из C-шных прог так и из sh-скриптов, которые будут работать с пользовательским интерфейсом при запуске устройства, настройке в полях и, собственно, запускать пользовательские проги.

Можно сказать, что эта первая вершина достигнута.

2) Вторая вершина - это также начать чистовик web-интерфейса. Пока у меня был готов только примерный дизайн, сейчас уже надо переходить к его движку. Именно сейчас, потому что если для его работы потребуются какие-то доработки прог, то проще дорабатывать одну Скорость, чем потом всё остальное.

Поскольку web-интерфейс должен быть активным, то есть в реальном времени отрисовывать результаты работы прог и позволять немного управлять ими (остановить, пропустить данный трек, ....) то нужно два канала связи: от web к плате и от платы к web.
Протокол HTTP пилился не для интерактива и всё, что было доделано потом для интерактива рядом с HTML - в том или ином ракурсе очень напоминает костыли. Пока их три: AJAX - который умеет оба направления, но только по запросу браузера, Server Side Event - который умеет только от сервера к браузеру, зато по запросу сервера и Websocket, который умеет в обе стороны, по запросу любой стороны, но использует уже не чистый HTTP, а его расширение, которое должен поддерживать сервер.
Сервер я расширять/писать свой или вкручивать готовый на node.js не хочу ибо лень копаться. Поскольку нагрузка на web-сайт у нас хорошо предсказуема, обойдусь, для начала AJAX'ом: опрос сервера раза 4 в секунду должен дать хорошую возможность как отправить нажатия кнопок от браузера на плату, так и забрать новые результаты. НО ! Если результатами будет полотно из информации о каждом прочитанном треке, то к конца съёма диска оно будет достигать уже нескольких килобайт и гонять их 4 раза в секунду будет, возможно, не очень хорошо. Тогда будет логичнее AJAX оставить только для управления web-> плата, а плата-> web всё таки отправлять через SSE - там хорошо ложится логика "отправлять только дополнения, а не всё каждый раз".
Но для SSE нужна несколько более сложная обёртка, которая отправляет сперва всё, что есть, а потом следит за появлением новой информации и отправляет только её.

В общем: это примерно те вопросы, которые предстоит решить, чтобы считать вершину 2 достигнутой.
Когда она будет достигнута, можно будет снимать следующее видео.

3) Вершина три: это архитектура единой проги, которая будет читать и декодировать трек.

Сейчас у меня, фактически, три программы: одна формально читает RAW, преобразует его в массив интервалов между импульсами, вторая делает умный вид и синтезирует пять/десять/пятнадцать файлов байтового потока, различающихся настройками алгоритмов декодирования, затем стоит EimEditor, который из байтового потока собирает сектора и - наконец-то - может проверить их контрольные суммы. Это всё нужно согнать в один код, который будет прогонять данные по какой-то одной ясной цепочке и, только если не получит правильные CRC, будет пытаться изменить свои настройки и пробовать ещё раз.

Самое сложное всегда: продумать архитектуру. Её приходится, буквально, нащупывать. Сперва придумать хоть что-то, реализовать это, убедится, что тут чего-то ещё не хватает, опять переделать всё и так раза два-три, пока не всё не начнёт становится красивым. Если всё выглядит красивым, скорее всего, оно правильно. Пока что.

--

Итог на сегодня:

1) От моделек перешёл к чистовикам. Прога Скорость, работает и выглядит как настоящяя. Плюс несколько полезных библиотек.
2) Перепробовал несколько микрух контроллеров LED- у всех баг с кнопками, о котором я ранее писал. Поскольку эту уже вторая существенная ошибка в плате (первая была в питании Ethernet), то дело явно идёт к тому, что по завершению разработки ПО второй экземпляр устройства будет уже на новой плате.
3) Запаял несколько регуляторов 12->5v, всё ок, работают (нужны на случай питания платы только от +12в). И к ним ещё пару разъёмов питания.
4) Запаял UART-USB конвертор, работает хорошо, но нужен только для удобной отладки ПО (до этого пользовался внешним).
5) Запаял USB-разъём для флешек. Потом пару дней искал, почему он не работает. Оказалось: одну настройку в ядре пропустил. USB поддерживается стеком, включающем два драйвера физических компонент: MXS_PHY (от FreeScale уровень физического интерфейса) + CHIPIDEA (похоже, FreeScale лицензировал готовый IP-блок - это уровень какой-то внутренней USB-логики). Вот MXS_PHY у меня был, а CHIPIDEA - нет. Вроде как USB cтартует, загружается обобщённый драйвер USB, но лапы снаружи проца висят в Z-state и ничего не хотят.

<6>[    0.133709] usbcore: registered new interface driver usbfs
<6>[    0.133828] usbcore: registered new interface driver hub
<6>[    0.134012] usbcore: registered new device driver usb
<6>[    1.127870] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<6>[    1.140567] usbcore: registered new interface driver usb-storage
--- до сюда доходил и всё ---
<4>[    1.150150] imx_usb 2184000.usb: No over current polarity defined
<4>[    1.156422] imx_usb 2184000.usb: 2184000.usb supply vbus not found, using dummy regulator
<3>[    1.776949] mxs_phy 20c9000.usbphy: Data pin can't make good contact.
<4>[    1.785970] imx_usb 2184200.usb: 2184200.usb supply vbus not found, using dummy regulator
<6>[    1.803654] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
<6>[    1.839165] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
<6>[    1.844950] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
<6>[    1.853310] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
<6>[    1.860597] usb usb1: Product: EHCI Host Controller
<6>[    1.865501] usb usb1: Manufacturer: Linux 5.4.3-g9c2490ac8-dirty ehci_hcd
<6>[    1.872345] usb usb1: SerialNumber: ci_hdrc.1
<6>[    1.878016] hub 1-0:1.0: USB hub found

На картинке: прога выводит два интервала: мгновенный (последнего оборота) и усреднённый по всем оборотам.
По усреднённому видна интересная тенденция: по мере прогрева флопика скорость немного растёт (где-то в сотых мс).

Post's attachments

DSC_5034s.jpg, 128.41 kb, 750 x 651
DSC_5034s.jpg 128.41 kb, 95 downloads since 2022-11-04 

73

Re: Мост # 3 - специализированный компьютер для чтения дискет

Voldemar0 пишет:

НО ! Если результатами будет полотно из информации о каждом прочитанном треке, то к конца съёма диска оно будет достигать уже нескольких килобайт и гонять их 4 раза в секунду будет, возможно, не очень хорошо.

Можно же два AJAX запроса сделать: первый просто спрашивает, есть ли какие-то новые данные для отображения и получает true/false, а второй запрос выполняется только если изменения есть и получает сами данные.

74 Отредактировано Voldemar0 (05-11-2022 10:07)

Re: Мост # 3 - специализированный компьютер для чтения дискет

Данные-то будут новые: максмалочка - 5 строк в секунду, если не 10. Тут вопрос больше о том, что их не хочется все целиком каждый раз вытаскивать. Но тогда надо как-то фиксировать границы - до сюда уже отдали, а дальше - нет. А это уже пахнет буфером, в который будет всё складываться на сервере, и два указателя: получено в буфер, отдано из буфера. Вот как раз SSE в такой логике удобнее. Но нужна прослойка управления буфером.

В AJAX всё просто: прога на сервере всё скидывает в файл, файл отдаётся по какому нибудь пути вроде /cgi-bin/get-log.cgi. Файл постепенно растёт, каждый раз забирается полностью и полность же отображается.
Но объёмы большие.

В SSE запускается прога, которая, например, через innotify (интерфейс ядра ОС, которые сообщает об изменениях в файлах и каталогах) ловит события изменения файла. Прилетело событие, она отправляет браузеру новый заголовок (в существующем соединении) и ту часть данных, на который файл увеличился.

И тут только одно мне не ясно: если страница будет закрыта в браузере, как эта прога-бекэнд поймет, что можно завершать работу ? По какому сигналу или событию? Вероятно, сервер должен закрыть канал связи с ней.. Но не уверен, что  lighttpd это делает... Надо проверять. С другой стороны: если идёт съём диска, то он как раз не должен прерываться при обрыве связи с компом управления. Т.е. при повторном запросе надо вновь отдать всю инфу по текущему процессу. Так что, в любом случае, буфер отчёта по текущей задаче должен быть на сервере.

И второй вопрос: под каждую прогу свой механизм делать или попытаться обобщить и найти какие-то совпадающие части.... Прог несколько и они разные:
- тест сэмплера (всего несколько строк: процент прохождения теста или bar)
- скорость/позиционер (всего несколько цифр, меняющихся или выводящихся в виде списка), возможно, в этом же коде будет и спектроанализатор (графика!). Эти данные как раз не обязательно хранить, можно просто скидывать новые в браузер, после чего забывать о них.
- чтение каталога диска (можно за один запрос получить - самый простой случай).
- быстрое чтение в dsk (с минимальными перечтениями сбойных блоков).
- чтение eim/raw  (много строк, по паре на трек + ретрейсы по одному треку + несколько проходов по диску).

75

Re: Мост # 3 - специализированный компьютер для чтения дискет

Всё, понял. Хорошо, что обсудили.

Буфер должен быть на длительных операциях по любому: потому что съём нельзя прерывать при отпаде клиента.
А значит статус может быть получен только из буфера (при обрыве связи, падении браузера и прочем).
ОЗУ полно, так что не проблема. Это развяжет прогу съёма от бека-фронта-webа.
Обратный поток (с клавишами) - там уже не так критично. Отпадёт и ладно.

Буфер можно вытаскивать по SSI - наработки есть уже кой какие, надо будет только их немного подпилить под задачу.

А для остальных операций (скорость, каталог...) - либо только ajax, либо тот же SSI, только интерпретатор результатов свой (т.е. бекэнд общий, а фронт под каждую прогу свой).

Наверное так.