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

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

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

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

Прогуливался мимо полок и шкафов на работе, взглядом зацепился за 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-кой :))

--

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

Интересно !

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

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

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

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

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

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

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

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

Спасибо !
Назвал "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

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

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

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

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

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

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