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

Каждый выпуск на youtube получается длинный.  И выходят выпуски с большими интервалами.
Всё время хочется сократить и период и размер, но не получается.

Начинаю пилить фичу A. Сейчас закончу, сделаю короткий ролик по ней. Но в процессе выясняется, что для A неплохо было бы доделать фичу B. Но B тянет за собой ещё и C, D и E.

Всё это вырастает параллельно, в итоге ролик оказывается загружен от A до E.
И даже в сюжете их сложно разъединить, чтобы набранный материал оформить как два отдельных ролика.

--

Закончил главную страницу web-сайта, сделал страницу управления временем (часами) платы.

Не стал делать поддержку ntp (синхронизация часов по сервисам Интернет). В ПО платы есть ntp, но ntp получает универсальное скоординированное время (UTC), чтобы из UTC получить локальное время нужны файлы тайм-зон (описатели часовых поясов), нужно управление ими (т.е. селектор на web-интерфейсе) и т.д. Решил пока на это не заморачиваться.

Инсталлятор тоже работает уже. Инсталлятор здесь - это возможность залить на новую плату всё ПО устройства без программаторов и паяльников, за пару минут.

Снятие образа 840К:

Работа программы завершена
Не удалось определить главный формат диска :((

Bridge3: get floppy image
Package version 0.97 (Trollholmsund)
DRIVE CONTROL: 0.008 ms for move the head to the zero track
DRIVE CONTROL: wait for 991556 mks for drive up
Open /dev/spidev1.0 device
SPI mode 0x0, 32 bits per word, 20000000 Hz max
Control keys: 's' - skip track / phase, 'q' - skip phase / quit.
DRIVE CONTROL: 199.46 ms per turn
DRIVE CONTROL: this drive has 87 cylinders
Check '/storages/internal/Bridge3/' access... Success
Config variable only140 not found !
FIN

Печалька :(
Снятие образа 140К ведет себя так же.
Но спектрограммы показываются.

Управление позиционером:

0 трек, 72 оборотов, время мгновенное: 199.55 мс, время среднее: 202.2558 мс

Уровень на линии Density - низкий (пин 2), примерная скорость - 360 об/мин

Кажется, значение "примерная скорость" не зависит от снимаемых показаний. Но если потыкать кнопки, то 360 меняется на 300. Я не понял, как это должно работать :(

Там же:

Кажется, по-прежнему есть пропуски сигнала индекса.

После перезагрузки попытка снять образ показывает вот это.

Ошибка подключения к статусу 840кб

Ошибка подключения к журналу 840кб

Спустя какое-то время работа восстанавливается. Видимо, до этого момента операционка просто не готова, но понять это нельзя (интерфейс-то работает!).

Английский поправлю, спасибо!
Для меня использование for вместо by или to - не редкость. Я не совсем понимаю разницу между for (для ?) и to (у которого куча значений направления, включая и "для")...

It is successfull final.
Я имел ввиду: "Это успешное завершение."

В программе есть ещё два варианта:
It's final. But I couldn't detect a main format :((
It is successfull final. The main format detected and read without errors.
It is good final. The main format detected, but %d error(s) encountered while reading.

--

По прогам:

> Config variable only140 not found !

Это мне пару раз встречалось - ошибка странная, я пока не понял, в каких случаях она возникает.
В файле конфига нет одной переменной (или почему-то её не находит процедура поиска).
Надо чинить.

Workaround: щёлкнуть галочку "Использовать такой же шаблон для образов 840кб дисков:"
Само значение галочки не важно, но при её изменении этот параметр пересоздаётся.

> Снятие образа 140К ведет себя так же.
Прога одна и та же (снятие 840 и 140), переменная тоже одна. Т.е. это та же ошибка.

> "примерная скорость"

Это такая величина, которая измеряется при запуске привода 840 (для 140ки она - константа) и при смене уровня Density. Измеряется по сигналам индекса, но используется не для программы "скорость", а для сохранения в eim3-файл, чтобы потом декодеры могли понимать, какую поправку на скорость чтения делать. Важно, что эта величина может быть только либо 300 либо 360.
Примерно так: if RealSpeed > 330 then speed = 360 else speed = 300.

А дальше уже играет эта проблема:

> The head is on the track   0,   36 turn(s), instant time <b>398.94</b> ms, average time 210.5529 ms

И вот откуда эта штука возникает - я пока не понял. Выглядит так, как будто пропущен один index.
Вроде бы, это бывает не с любыми дисководами. Это надо будет проверять и искать причину.
Сейчас подключен привод 3.25'', но бОльшую часть отладки я вел на разных 5.25''. Вроде бы там не было этой проблемы.

> Ошибка подключения к статусу 840кб

Это не совсем ошибка, тут причина вот в чём:
журналы и статусы - это просто файлы на RAM FS.
Т.е. после перезагрузки ОС они теряются. Пока не запустишь какую нибудь программу, журналов нет.
После запуска любой из прог журнал появляется.
Каждый новый запуск прог журнал переписываются.

{
...можно создавать пустые журналы при запуске ОС...
Или с какой нибудь фразой, вроде "Информации пока нет"....
}

О паре заметок в ToDo:

"? глюки у дисплейчика ?"

Мелкий дисплейчик на плате начал подглючивать: картинка иногда ломалась. Сперва лениво кивал на глюки самого дисплейчика, но сейчас на тестах две платы и когда глюки стали стабильными, причём на обеих платах, пришлось занести это в ToDo.

Сперва поискал вопрос об аппаратном сбросе, нашел его на плате дисплейчика, но он не выведен на гребёнку. Просто на плате есть RC-цепочка сброса и всё. А программного сброса в даташите не нашлось (ssd1306).
Но раньше же глюков не было ?

Поиски начал со здорового электролита, напаянного прямо на ноги дисплейчика. Не помогло.
Потом осцилографом порылся по шине i2c - там вполне прямоугольники, да и частота шины не высокая - 92 КГц примерно.
Потом был логический анализатор шины. Тут бага и нашлась. Но какая!

Контроллер дисплейчика умеет принимать растр либо команды по шине.
Чтобы отличать одно от другого имеется префиксный байт. Четыре варианта: команда в один байт, растр в один байт, команды до условия I2C-STOP, растр до этого же условия.

В драйвере (самописном) есть три процедуры: отправить растр (несколько байт), отправить команду (1 байт), отправить команду (массив). Команды бывают как из одного байта так и из нескольких.

Многие команды имеют размер 1 байт. Я их все отправлял процедурой отправки однобайтной команды.
Но когда был реализован основной функционал, я добавил команду управления яркостью дисплейчика. Она содержит два байта. И по привычке я их отправлял как две однобайтовых команды (copy-paste ж). И - что интересно - контроллер дисплея это вполне переваривал, несмотря на то, что в таком случае два байта (опкод + уровень яркости) приходили в отдельных I2C-транзакциях.

Яркость можно менять резко (просто задать любую нужную) или плавно крутить цикл от минимальной к максимальной или назад. Программно крутить, конечно. Я так и сделал. А поскольку это занимает около секунды, вынес эту операцию в отдельный тред - чтобы не задерживать исполнение других команд.
Пока всё было хорошо.

Но, когда дело шло к завершению разработки, я внёс запуск шелла в автозагрузку. И получилось следующее: рисуется заставка, экранчик плавно зажигается до максимума и затем плавно снижает яркость до минимума (но картинку ещё видно). Ещё до того, как игры с яркостью завершились, уже запускается шелл и начинает рисовать меню.
И вот тут команды управления курсором (от шелла) начинают смешиваться с командами управления яркостью (из скриптов ЛОГО): ЯРКОСТЬ.ОПКОД ... КУРСОР.КООРДИНАТА  ... ЯРКОСТЬ.ЗНАЧЕНИЕ.

Естесно, контроллер дисплея сходил с ума - координата становилась яркостью, яркость - недокументированным опкодом.

Решение же простейшее: отправлять команду яркости как одну двухбайтовую команду. Тогда она не может быть разорвана на шине.

Хм. А код на чистом C написан? Я просто не представляю, как обработку управления ресурсами делать без try finally.
Когда есть блок finally, то он в любом случае выполняется и в нем можно разблокировать все ранее заблокированное.
Но для этого нужен C++.

Вроде есть какие-то костыли для эмуляции try catch https://stackoverflow.com/questions/105 … ments-in-c, но сам я этого не пробовал.

Да, об этом. Тут проблема в том, что сбои в f2 могут быть устранимые, типа деления на ноль, нехватки памяти, отсутствия файла и т.д. А могут быть неустранимые, например, переполнение стека, обращение к недопустимому адресу памяти или получение внешнего сигнала.
И если устранимых сбоев можно избежать, обложив весь код проверками, то со вторыми ничего поделать нельзя. Во всяком случае в C.
Кроме того, еще же есть библиотечные вызовы. Свою функцию можно как-то защитить проверками, а когда код чужой, то не факт, что его разработчик сделал все по фен-шую и вызов не уронит всю программу.

Мне кажется, стоит попробовать sigaction https://stackoverflow.com/questions/338 … gterm-in-c

Кажись, я понял почему программа "Скорость" иногда сообщала о 399 мс на оборот.

Время измеряется подсистемой GPIO, которая в ядре линуха. Она сообщает о времени (некоем внутриядерном) изменения уровня на пине. Т.е. что-то вроде очереди событий, каждое из которых содержит таймштамп и описание события (RISING/FALLING). На первый взгляд было бы логично, если бы эти события выстраивались в какой нибудь FIFO и оттуда выгребались программой.

Но, похоже, авторы этой подсистемы решили, что FIFO - это скучно. И не ясно - какого размера его делать ? Или вообще динамически выделять память (если программа сейчас ничего не читает - на сколько может распухнуть такой стек буквально за секунды, если частота воздействия на лапку будет, например, 100 КГц  ?)
Поэтому они сделали по простому: сообщают только время последнего события каждого типа.
Т.е. не успел выгрести из очереди очередной импульс - получишь тот, который успеешь. Т.е. последний. Сколько пропустил - неизвестно.

Проблема в том, что в зависимости от того, какая страница включена на OLED, отрисовка идёт либо в память ui_server либо отправляется ещё и на физический OLED. Ну и, возможно, какой-то ещё вывод на интерфейсы требует некоторого времени. Плюс опрос клавиатуры на плате (которая не умеет работать по прерываниям). В сумме это занимает где-то те же 200 мс. Т.е. иногда импульсы просто терялись.

Решение: сперва запрашиваем новые события без ожидания. Если ОС сразу вернула что-то, то ставим флаг enable_io = 0 и выполняем всю математику и учёт, но всевозможные printf предваряем конструкцией "if (enable_io)".

Если же ОС ничего не вернула по запросу, тогда уже повторяем запрос, но с разрешенным ожиданием события в 250 мс. И сразу ставим enable_io = 1.

Т.е. любые события учитываются (число оборотов, средняя скорость и т.д.), но если явно не успеваем между !INDEX, то не отображаем очередной шаг пользователю.

И оно заработало нормально :)

Восьмая часть, завершение первого сезона:
https://youtu.be/3E0ZFm4zCFs