Да как не надо? Надо! Расчётная погрешность выглядит как-то так:
Тут по "Y" отклонение в секундах от времени на момент сбора данных, а собирались в миллисекундах. В начале наибольшее отклонение и это в начале ракорда давало минусовые значения в секундах от начала, которые не отображались верно, т.к. минус в формат расчёта не заложен по определению. Но отобразить само смещение с минусом по ленте для пользователя не проблема, это т.с. выше уровнем абстракции, а тут уровень "железа". Пришлось "зарезать" значения чуть меньше нуля в двух местах, приравнять к нулю "грубой силой" и теперь да же при срабатывании автостопа после перемотки назад, "левые" значения не выскакивают. Часть данных, "головы" и "хвосты" со снятых давнных т.с. "подрезал", что бы влияния ракорда на точность формулы было бы меньше.
Ещё добавил установку нуля счётчику импульсов от начала ленты, при срабатывании автостопа при перемотке назад, т.с. в момент упора. У меня пока СРВ включается по команде по USART. Теперь можно добавить разрешение работы СРВ так же и при срабатывании автостопа после перемотки назад.
Подобных мелочей ещё можно поискать и убирать по мере обнаружения. Но самый главный косяк для точности, это инерция вращения подкассетника. Надо вживлять сигнал направления. С датчика MT6701 брал только сигнал "A", а направление давал сам ЛПМ. Т.е. надо было дожидаться полной остановки ленты. Теперь решил добавить ещё и сигнал "B", т.е. в режиме "ABZ" формируется сигнал подобно тому, что идёт с энкодера. "Z" это импульс начала оборота, тут он не важен. Если использовать оптику, то и тут надо будет ставить два фотоприёмника на один подкассетник. Тогда надо перекраивать платы: материнская ПУ(А) + датчики. Вести придётся не 5, а 7 проводов от датчиков к "маме". С трудом потеснил прежнюю разводку и протянул таки ещё два проводника до платы "Nano", добавилось три перемычки. Но куда их тыкать, если лишних выводов уже нет? Выход такой: отказаться от AtMega328P и перейти на AtMega328PB, но надо чуть править саму "Nano".
Доработка теперь будет следующей:
1. Отпаять резистор у светодиода 'L', что бы не мешал энкодеру
2. Перерезать два проводника между выводами 3 и 28, и ножкой кнопки сброса.
3. Отпаять и приподнять выводы 3 и 6 МК.
4. Добавить перемычку между выводом 3 МК и выводом 3 платы "Nano".
5. Добавить перемычку между выводом 6 МК и выводом 28 платы "Nano".
Т.е. AtMega328PB имеет на месте двух бывших дублей выводов питания 3 и 6, два дополнительных вывода порта 'E', но они не разведены по ножкам платы. На выводах платы две неиспользуемые в проекте ножки, под сигналы 'Reset'.
Кроме того, есть проблема по таймерам. Думал делить таймер 2 между ИК ДУ и замерами лопастей для первой формулы поиска места на ленте, но в AtMega328PB добавили ещё таймеров. Т.е. это вторая причина отказа от AtMega328P.
Т.ч. работы снова навалило, но при этом хочется хоть что-то улучшить в проекте, если это возможно...
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 30 апр 2024, 11:52
DrLithium
По формирователю импульсов сложилось следующее:
Сейчас, в последней версии 0.5 'ПУ(А)', формирователь импульсов на борту. Проверил работу магнитного датчика MT6701 без оного. Счётчик добрался до положенных 35:07 на "студийке" и успешно вернулся в ноль при перемотке назад. На борту датчика присутствует какой-то гистерезис и работает приемлемо. Тогда в версии 0.6, формирователь импульсов выношу за борт и только на плату оптических датчиков. На плату магнитных датчиков не ставлю. Но, если будут выявлены проблемы при отсутствии формирователя импульсов, то можно будет переделать. Схему оптических датчиков рисую, а вот разводку печатной платы не делаю, по двум причинам. Место, на плате датчиков позволяет поставить два двухканальных формирователя, а на борту 'ПУ(А)' 2x2 уже не помещается. Конструкция оптических датчиков м.б. разная и сама геометрия м.б. оформлена по месту, т.е. в зависимости от конструкции ЛПМ и самих датчиков. Будут эти оптопары от мышки или иные, оставляю право выбора за пользователем. Думаю, что моя основная задача не сделать все варианты, а быстрее довести конструкцию и прошивку для удобоваримого состояния.
В версии 0.6 'ПУ(А)' решил отказаться от разъёмов 'PH' для соединения платы датчиков и самой платы 'ПУ(А)'. Надо 6 пинов, но не нашёл у себя, разведу под разъём 'IDC' 10. Нашёл компьютерный готовый 9-и пиновый шлейф с ключом на 10-й ножке. Место на плате появилось, а вот желание каждый раз отковыривать 'PH' пропало. У меня достаточно плохой опрессовщик и постоянно отваливаются провода от пинов "мамы". Покупал давно YAC-12 + YAC-13 и не пользовался и только теперь стало ясно, что это "Гэ на палочке".
Вообще удобно было бы выпаять пару SATA-шных разъёмов с дохлой "мамки", но места может не хватить - ЛПМ узковат, а вот в колёсник самое то. Разъёмы высоковаты и сами кабели жестковаты, а угловой разъём кабеля то же трудно уложить, не гнётся. Т.е. надо хорошо подумать что и куда влезет. М.б. ещё вариант, взять с материнской платы горизонтальный разъём. Т.ч. пока выбрал 'IDC' + 'PLD'.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 05 май 2024, 01:55
SErArt
А плоские шлейфы не пойдут? Их полно в разной аппаратуре и в продаже много, как и разъёмов...
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 05 май 2024, 21:00
DrLithium
Подойдут любые. Вопрос того, что есть под рукой и не жалко. А при разработке ещё важно, что бы сами разъёмы были достаточно надёжными. Иногда приходится десятки раз снимать и ставить обратно.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 09 май 2024, 22:00
DrLithium
Ваял платы ПУ(А) и датчиков. Плата на MT6701 оказалась примитивная. Плата ПУ(А) чуть упростилась, но вот с материалом намучился...
У меня сделан автостоп по двум датчикам сразу и это как оказалось плюс, мог бы не сразу получить информации о том, что не работает прерывание по 'INT1' (подающий). Плату спаял, был протрав в трёх местах, пропаял, поставил перемычки, проверил тестером - всё нормально. Далее перемычки, SMD и прочие детали и разъёмы. Собрал, запустил... срабатывает автостоп. Стал вспоминать что было изменено в последней прошивке. Т.к. перешёл на 328PB, то добавил инициализацию порта 'E', инициализировал таймер 3, прописал обработчик прерывания. По-отключал, но изменений не случилось.
По скольку был уверен в электрической части сразу стал грешить на софт. Подумал, что в 'Atmel Studio 6.2' добавка 'Atmega328PB' всё-таки не совсем корректна реализует новые (в отличии от '328P') функции. Залил последнюю 'Microchip Studio 7.0' создал новый проект, скопипастил из 6.2, скомпилировал и залил. Заработало!
Решил проверить различие 'HEX'-ов нового и старого... Их нет! :0
Залил 'старый ''HEX'... не работает, т.е. срабатывает автостоп.
Проверил пайку перемычек и надёжность разрезов для сигналов 'PE0' и 'PE1' под направление подкассетников - всё в порядке. Сигнал 3 МК (PE0) вывел на вывод 3 платы ардуины, а 6 МК (PE1) на вывод 28 платы ардуины, бывшие ненужные 'Reset'ы. Эту доработку дам в следующей выкладке.
Добавил в прошивку отладочную информацию по 'USART'-у. В итоге понял, что нет реакции от подающего на 'INT1'. Может подпалить успел? Уже думал менять камень...
Подключил осциллограф к разъёму на плате ПУ(А), проверил (что приходит?) сами импульсы - всё идеально!
Проверил на ножке 6 (PD3) платы ардуины - нет сигнала. Т.е. там где проверял и был уверен, что всё норм... оказалась проблема. Потыкал тестером и конечно же это оказалось место пайки рядом с протравом. А вот картинка:
Визуально я так и не понял где именно, не по картинке с зумом и не под сильной линзой. Но, понял что возможно в этом месте мог быть брак и медь слабо держалась. Тестером потыкал и понял, что это средний вариант (на картинке). Т.е. получается как-то чуть задел и случился обрыв. А вот когда залил прошивку из 'Microchip Studio 7.0', то вероятнее всего, контакт восстановился на время.
Переделал проблемное место и то не с первого раза. С первого тут же получил ещё один обрыв и пришлось брать "шире".
Теперь переход на '328PB' получился и могу расписать направление для датчиков подкассетников.
З.Ы. Протестил MT6701 на точность работы со временем, вышел на 35:06 и после перемотки снова в нули. Т.е. формирователь импульсов для магнитного датчика не ставлю, по крайней мере до первых проблем точно.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 10 май 2024, 12:35
SErArt
Для ЛУТа есть ограничения - повторяемость вещей тонких и плотнорасположенных под вопросом.
Для ЛУТа есть ограничения - повторяемость вещей тонких и плотнорасположенных под вопросом
Делал 0.2 мм без проблем. В текущем случае есть локальное пятно, или брак материала или тонер не просыпался плотно и случился протрав. Тут видимо уже из за подсевшего зрения просто не уследил. Вопрос лишь в том, что бы не было подобных косяков. Можно использовать дихлорэтановую/ацетоновую "баню" или спрей для увеличения плотности тонера. Но это не всегда работает правильно. Сейчас у меня приоритет - скорость. Позже можно переделать более качественно.
А по сути дела:
Заменил пару строк в прерывании и датчик чётко распознаёт направление.
Далее планирую дописать то же для датчика подающего подкассетника (параллельный счётчик для реверса) и делать поиск места на ленте/остаток (если указать длину ленты в пакете и вычесть текущее). А пока перемотка назад и срабатывания автостопа дают возможность видеть реальное время. При срабатывании взводится флаг и на дисплей вместо номера импульса (делённого на 4) выводится результат расчёта.
Теперь есть ещё два 16-и битных баймера и один как раз буду использовать для замеров длительности импульсов. После чего можно будет оформить вывод по 'USART' - "отношение" длины импульса приёмного подкассетника к подающему на момент срабатывания приёмного подкассетника. Но делить буду снаружи в Excel-е, т.е. выведу только два замера в нужный момент. Вторая формула будет возвращать приближенное к реальному значение номера импульса приёмного подкассетника. Но при этом нет смысла отключать функцию сброса счётчика номера импульса при срабатывании автостопа после перемотки назад, так будет точнее.
Пока что самый тяжёлый код, это расчёт времени. Для определения положения места в "середине" (не от начала) кассеты, так же нужно применить сложный расчёт, но эти два расчёта не будут работать одновременно. Т.ч. думаю перегрузки не случится и на 16МГц спокойно успеваем посчитать. Следует подумать над определением места в перемотке и проверить точность. Если будет врать, то есть вариант ограничить поиск места только во время рабочего хода. Не хочется делать запуск определения места вручную как отдельный пункт меню, а автоматизировать. В меню можно дать возможность выбирать пройденное/остаток.
А чуть позже буду делать:
вывод данных по команде по 'USART', для построения графика и выведения формулы,
писать ядро расчёта "места" на ленте.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 11 май 2024, 11:48
SErArt
Всё, я сдаюсь) Едва могу уложить в голову общий ход мыслей по теме...
Всё, я сдаюсь) Едва могу уложить в голову общий ход мыслей по теме...
Просто задавай вопросы. Буду вводить в суть.
=========================================
Текущая нить по ПУ(А) такая:
...Меню
функция Goto
скорость
яркость
Добавляю СРВ
сделана функция (по 'USART') вывода данных для построения графика и вывода формулы (в Excel-е) - номер импульса/время в мСек
написано и запущено ядро для отображения времени на дисплее, после пересчёта из номера импульса во время в Сек
добавлена функция сброса счётчика номер импульса при срабатывании автостопа
добавлена функция активации вывода времени после срабатывания автостопа в перемотке назад
добавлена функция сброса значения меньше нуля в значение нуля (проблема проявляла себя в перемотке назад)
переделал платы ПУ(А) и датчиков, добавил два сигнала для определения направления вращения подкассетников
дописываю реальное время для реверса
делаю реверс для платы 'регулятора' на реле, что бы тестировать и исправлять счётчик для реверса
планирую вывод данных (по 'USART') для функции определения места, т.е. для определения номера счёта импульса от начала
далее надо написать ядро для функции определения места
ещё надо будет добавлять функции в меню (надо ещё думать какие и для чего именно)
планирую придумать формат пакетов для данных
для длины ленты конкретного производителя, (т.е. для той же 'C-90' можно сделать несколько вариантов), для больших катков, для малых, для коротких длин, формула уже предварительно придумана - отображает на дисплее в зависимости от номера ID: "С0:15", "L046", "C074", "C180" или как-то так
для конкретной кассеты (ввод ID в меню) привязка к пакету с длиной ленты + время смещения фонограммы от начал + общая рабочая длина + т.п.
придумать где это хранить, вариант подключить по 'TWI' модуль с МК+'SD карта' в 'FAT', только на чтение из файлов с 'ID'=имя файла (это не сложно, просто сделать)
Всё, я сдаюсь) Едва могу уложить в голову общий ход мыслей по теме...
Считал, что у меня хорошо получается делать простые вещи сложно. Но вижу, что мне еще очень далеко до совершенства.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 21 май 2024, 17:41
devel
Идет сборка макета КР(Б) апрельской ревизии =) Правда пока на коленке.
Ход мыслей уловить сложновато, да. Но практика - критерий истины. А пока практических реализаций не было. Но критика уже есть =)
Критика это хорошо. Возвращает с небес на Землю. Я бы хотел собрать оба варианта (Liv и DrLithium), сравнить их. Ну и применение их предполагается разное. КР(Б) - для прямой замены КР в В102/104/204. Есть несколько версий КР, но это уже нюансы.
А вариант Liv - для реверсного ЛПМ, и там где нет необходимости сохранять аутентичность КР+КМ+Р, и все заменить одним модулем.
Жаль, что пока нет последователей, и нет дискуссии. Отладка без экспериментов - дело невозможное. Ну я начал с простого, КР(Б). Дальше будем посмотреть
Почему нет, в теме мелькали фотографии реализации.
Я видел только реализацию pccodecs по мотивам Liv, но для Орбиты МП-121. ЛПМ там такой же, но с мелкими отличиями - там нет датчика блокировки режимов (наличия кассеты), и датчик для счетчика не оптический (Вильма/Санда 207), а герконовый. А повторения проекта DrLithium я пока не видел. Возможно что-то пропустил?
Я видел только реализацию pccodecs по мотивам Liv, но для Орбиты МП-121. ЛПМ там такой же, но с мелкими отличиями - там
нет датчика блокировки режимов (наличия кассеты),
датчик для счетчика не оптический (Вильма/Санда 207), а герконовый.
буквальна сегодня пришли новые плата для оптического датчика, по схеме Liv как на ОЛИМП-005, соберу будет пока для автостопа...в дальнейшем и для счётчика планировал применить... У правление на АРДУИНО уже как пару месяцев работает, автостоп испытать осталось. Спасибо за помощ AlexLV.
Вторая ревизия, в первой перепутал все что мог , и после экспериментов задымиться умудрилась.. Фото публиковал, оптический датчик, на 3D принтере крепления напечатал и штатные отверстия на ЛПМ присутствовали на них и прикрутил.
Я бы хотел собрать оба варианта (Liv и DrLithium), сравнить их. Ну и применение их предполагается разное. КР(Б) - для прямой замены КР в В102/104/204. Есть несколько версий КР, но это уже нюансы.
А вариант Liv - для реверсного ЛПМ, и там где нет необходимости сохранять аутентичность КР+КМ+Р, и все заменить одним модулем.
Жаль, что пока нет последователей, и нет дискуссии.
Чем дальше, тем медленней делаются дела. Чтобы реализовать всё задуманное, и десяти жизней не хватит. Поэтому приходится нещадно рубить проеты, выбирать самое значимое. На данный момент рубанул всю кассетную тематику, занимаюсь только катушечниками. Да и то успехи более чем скромные. Сейчас делаю новый БУ для Олимп-005 на STM32F103, но программирование идёт из рук вон плохо. Сложно это очень.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 26 май 2024, 09:54
DrLithium
По коду:
В очередной раз перелопатил систему прерываний от датчиков, добавил переменных и флагов, для работы со всеми режимами счёта. Счётчиков (наборов переменных) сейчас четыре - обычный счёт для прямого хода и для реверса, для конвертации во время для прямого хода и для реверса.
Сделал команду вывода данных для второй формулы. Ужаснулся - колбасит данные с приёмного датчика, т.е. ровно как и на оптике! И видимо тут ничего не сделать, узел кассеты имеет трение, откуда и происходят рывки. Разобрал плату датчиков и увидел лёгкое подтирание магнитом, но только подающего датчика. При этом есть разница в итоговом кол-ве импульсов на перемотке в прямом ходе и в ревесивном.
По железу:
Брак стеклотекстолита снова себя проявил - не держится, хватает ровно на одну пайку. Надо переделывать плату датчиков с ластами... Надеюсь в итоге с импульсами с датчиков станет чуть получше. Это нужно для фильтрации данных и последующего поиска номера импульса от начала кассеты. Придётся делать вывод реального номера импульса от начала и расчётного по второй формуле. Подбором параметров для фильтра, командами по USART, терминал покажет расчётное попадание прямо во время настройки коэффициентов. Пока планирую поиграться с фильтром Калмана, далее возможно и с другими.
Хочу добавить элемент настройки положения датчика относительно центра вращения магнита и чуть изменить геометрию плат. По даташиту рекомендуется соосностью попасть в 0.3 мм, но у меня было явно больше и вполне работало для первой формулы, использовались импульсы только с приёмного подкассетника.
Для подстройки положения датчика относительно магнита, размеры:
1) высота (зазор, по мануалу 1.0 мм в идеале и 0.5-2.0 мм допустимое) - было впритык, тогда чуть подточить конец оси и/или уменьшить толщину плат "ласт" с 1.6 до 1.0 мм,
2) смещение по горизонтали (соосность по X) - "ласты" с магнитными датчиками оформлю так, что бы их можно было чуть повернуть, отодвинув на нужное расстояние от пластика, добавлю крепёж (винт + гайка + шайба), вместо перемычек гибкие проводки - 4 шт
3) смещение по вертикали (соосность по Y) - в самой плате датчиков сделаю не отверстие, а прорезь для смещения, что бы была свобода выбора: прицелится, после чего зафиксировать.
Тогда важна последовательность сборки:
МС датчиков паяем в последнюю очередь на платы "ласт",
на "ласте" заранее должны пометить перекрестьем центр МС датчика, для прицеливания,
параллельно делаем то же для другого датчика,
собираем "бутерброд" без пайки, просто вставляем винты в отверстия и наживляем в гайки,
ставим "бутерброд" на место и крепим плату датчиков к держателю моторов,
прицеливаемся перекрестиями "ласт" по центру магнитов и закрепляем винтами,
проверяем и поправляем, если нужно,
делаем пометки положения платы датчиков относительно пластика (держателя моторов), т.к. крепёж даёт лишнюю свободу,
снимаем "бутерброд" и паяем МС датчиков и провода от платы датчиков к каждой "ласте",
ставим на место по меткам и крепим окончательно.
При этом находятся крикуны, которые утверждают, что программу для БУ магнитофона можно написать за 3 дня.
Ну если какой-нибудь простенький ногодрыг без цифровых шин, дисплеев и хитрых таймингов, да еще на хорошо известном контроллере, и с имеющимися заготовками, то, наверное, можно. А что-то более серьезное - ну пусть попробуют.
Тут недавно развлекался с тюнером, в котором родной контроллер сдох (цель проекта была не тюнер получить, он просто под руку подвернулся и хорошо в задачу вписался). Использовал малоизвестный мне контроллер, управлять нужно было античными SAA1056/1060, заодно добавил немного функционала в виде прямого ввода частоты, пульта ДУ и разных мелочей. Так это заняло пару месяцев холодных осенне-зимних вечеров с выходными.
Тут недавно развлекался с тюнером, в котором родной контроллер сдох
Что-то подобное делал для управления тюнером и часами магнитолы. Там пришлось 2 процессора менять. Один тоже сделал на платке вместо DIP-40. А второй - управление ЖКИ, на нем еще и часы, при этом потребовалось сражаться за микропотребление. Все это заняло больше месяца довольно активной работы. Так получается, что даже мелкий (на первый взгляд) проект требует уйму времени. Про считанные дни на проект кричат лишь те, кто ничего не делал.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 02 июн 2024, 04:08
DrLithium
Переделывал плату и после 4-х дней проектирования и производства, естественно ни чего не заработало как надо... Не все необходимые ножки МС были подключены, тупо забыл что это надо было сделать. Поправил позже...
Теперь плата датчиков выглядит вот так:
А по-шагово собирал таким образом:
Есть разница в значениях общей длины по времени для разных сторон, в обычном ходе и в реверсивном. Т.е. проверяю перемотку в разные стороны и получаю разницу в секундах, около 4-5. Для одной и той же стороны значение имеет нормальную повторяемость. После воспроизведения времени набегает больше, чем после перемотки. Подумал, что вероятно влияет плотность намотки и/или чуть различаются диаметры катков. Пробовал перевернуть кассету и снова есть та же разница. Вариант, это могут быть датчики или, если исключить их отличие между собой, то дело м.б. в алгоритме обслуживания прерываний. Тогда тут можно будет ещё подумать...
Разница была и будет, и это было понятно с самого начала. Задача сводилась к тому, что бы в одних и тех же условиях выходить на нормальную повторяемость по времени. При этом, желательно обеспечить расчётную точность математики и исключить лишние переменные влияющие на результат:
1) плотность намотки (перемотка-воспроизведение),
2) разные диаметры "катков" в одной и той же кассете,
3) неравномерность полива (тут трудно за этим уследить),
4) дефекты ленты (износ, склейка, грязь, коробление), есть склейка и если она смещена от середины, то м.б. и будет разница, а данные для формулы собирал ещё до склейки,
5) разность датчиков (настройка геометрии магнитных датчиков),
6) подтормаживание рулона внутри самой кассеты (поперечная неравномерность намотки рулона может вызывать разное трение).
С чем-то можно побороться, а об остальном можно и позже подумать. А когда разумные силы приложены к устранению влияющих на результат переменных, можно и продолжить работать с данными.
Далее. Собираю данные для второй формулы - нахождение номера импульса для приёмного подкассетника от начала. Строю формулу и фильтрую. Меняя переменные "на ходу" надеюсь, что смогу за непродолжительное время находить достаточно точное значение. Здесь минимальное время расчёта может пригодиться в будущем, для авто-определения длины ленты. Но это пока планы и как и что будет далее, самому не очень ясно.
Определение места на ленте (это функция второй формулы) будет вызываться при первом запуске рабочего хода (воспроизведение, запись) при условии, что место ещё не определено - кассета только что вставлена или подано питание. Срабатывание автостопа в начале кассеты - лучший метод определения места и это исключает необходимость в использовании второй формулы, т.к. "ноль от начала" будет установлен автоматически для счётчика, по которому и происходит расчёт времени.
Планирую при выборе новой длины ленты в меню, сбрасывать флаг определения места на ленте, но не всегда. Для новых данных, точнее при выборе длины ленты (для точного расчёта времени по формуле) необходим свежий поиск места на ленте, иначе время будет не верное. Но тут есть ещё один момент, если сброс значения счётчика от начал ленты произошёл по автостопу в перемотке назад, то имеем абсолютную (на сколько это возможно) точность места. Но, если имеем только расчётное значение (по второй формуле, точность заданную отношением частот импульсов подкассетников зависимые от выбора данных), то нужно рассчитывать заново. Тогда есть смысл использовать два разных флага и при взведении флага абсолютного места, нужды делать перерасчёт по второй формуле не будет. Ну и выбор длины кассеты в меню не заставит делать перерасчёт заново, просто значения будут течь по другому времени.
Т.о. имеем интересные для реализации задачи:
расчёт времени по счётчику номера импульса приёмного подкассетника от начала (первая формула) - решено,
расчёт номера импульса приёмного подкассетника от начала (вторая формула) - в процессе (при срабатывании автостопа в перемотке назад - работает),
работа с пакетами данных для разных длин кассет (и для больших катков) - запланировано,
реализация выбора длины кассеты в меню - запланировано,
работа с пакетами данных для разных кассет (длина - как один из параметров) - запланировано,
управление моментом подмотки и плавная остановка в перемотке на краях ленты, вполне реально будет сделать, но после реализации пунктов выше.
З.Ы. Уж полночь близится а Германа всё нет... Хочется уже доделать СРВ и далее баловаться с доп. функционалом.
Сколько импульсов придет с датчика за оборот подкассетника?
Зашивал "инструментом" 16 импульсов на оборот. Сильно меньше - будут "скакать" значения секунд в конце кассеты, больше - выше нагрузка на ядро МК. Сделал возможным допустимым пропуск расчёта в перемотке, без ущерба для точности. При необходимости можно задать иное нужное значение имп/об.
В комплекте с МС MT6701 идёт должным образом намагниченный "пятачок" (D = 4 мм, S = 1 мм). Две половинки/боковушки разные: (| - 'N' , |) - 'S'. Другие варианты не подходят. Можно посмотреть даташит на МС MT6701, там этот момент описан. Последняя версия была, кжись, 1.8.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 07 июн 2024, 19:04
DrLithium
Бьюсь над фильтрацией данных, для скармливания в удобоваримой форме второй формуле. Ну и вот что-то такое:
Ну и это всем понятно, да же описывать не буду.
А тут просто "Quasi Una Fantasia"
По сути тут вот что:
нужно убрать "волну", иначе данные колбасит в '+' или в '-',
вопрос как это сделать дешевле, сколько приёмов - какую фильтрацию применить и сколько фильтров использовать для нормальной точности,
после чего значение надо пропустить через вторую формулу для определения места положения, т.е. что бы получить номер импульса от начала кассеты,
это аналог функции "Remain"/"Остаток" и да, эта функция будет требовать какого-то времени для вычисления значения (требуется накопить данные для расчёта).
Операций требуется несколько: усреднение, наложение фильтров, ну и расчёт (по предварительно собранной формуле). Т.е. всё не просто, а по сути - самая сложная часть СРВ. Можно сделать рабочий вариант расчёта, реализовать и да же после всего всё ещё можно будет искать варианты не дорогой фильтрации, для ускорения расчёта места. Ну и надо полагать, то время которое вы видите (в фирменных аппаратах со счётчиками РВ) сразу после вставки кассеты перемотанной на середину, ни что иное как обманка в первое время. У меня иная идея - давать реальное время от начала, сразу как только это будет возможно.
Для нормальной работы конечно это ещё не всё. Получаемое время может быть приближено к реальному, только для формул построенных для текущей длины ленты.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 17 июн 2024, 17:39
DrLithium
Добил код до того, что смог построить графики по данным, снятых уже по второй формуле - поиск номера импульса от начала кассеты, через отношение импульсов (аналог функции 'Remain', ищет не сам остаток, а место, т.е. пройденное). Не сразу заработало, были ошибки, из глобальных - копипаст куска кода при этом забыв поменять имя массива. Как результат - данные портились капитально! Трудновато было подобрать набор фильтров, т.к. исходные данные давали довольно большую пляску. Усреднение за оборот и Калман помогли, но не факт что нет решения лучше. Пока этого решения вполне достаточно для дальнейших работ.
Общий график данных с реального железа.
Увеличенный масштаб, первые 200 импульсов.
А тут подтверждение того, что данные (приблизительно середина кассеты) после фильтрации достаточно стабильные (т.е. не скачут в +/-), что бы можно было точнее получать номер импульса по второй формуле.
С нуля, т.е. после активации функции, происходит накопление данных и последующее выравнивание. Всегда (до последнего времени) казалось, превратить исходные данные в подобный график, не простой задачей. Но теперь уже дорожка натоптана и надеюсь результат даст минимальную погрешность. Думаю, что можно попасть в пределах секунды, иначе +/- 5-8 импульсов (от места), импульсов за 200 (при 16 на оборот). Дальнейшие тесты покажут реальное расхождение и конечно отпишусь...
Далее остаётся, по данным построить формулу, по команде 'Remain' (или как-то иначе 'Elapsed') отсчитать 200 импульсов и пересчитать отношение импульсов в номер импульса от начала. Результат можно сравнить с реальным номером импульса на момент пересчёта, после чего станет понятна погрешность. И если она достаточная, то можно будет уже "железно" прописать присваивание счётчику вычисленного номера импульса от начала. Далее остаётся включить конвертер по первой формуле: номер импульса - время.
Т.е. довольно "толстый кусок пирога" состряпан и что-то выдаёт. Продолжаем продолжать...
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 19 июн 2024, 23:23
DrLithium
Снял данные после фильтрации, получил формулу, получил погрешность определения "места" (номер импульса) от начала. Но первые 210 импульсов подающего подкассетника (210/16=13.125 оборотов) необходимо ждать для попадания в коридор приемлемой точности. Эти значения отрезаны, нет на графике т.к. портят картинку, отклонение доходит до 3000. За то теперь виден коридор погрешности во всей красе, т.е. точность достаточная.
Справа свисает "шнурок" - это ракорд.
По фильтрам.
Что бы имели представление об уровне хаоса, даю с масштабированием...
Имп - это тупо отношение замеров, приёмный/подающий без фильтров
Имп сред. - это отношение замеров, приёмный/подающий, но после усреднения в кольцевом буфере на том же шаге
Калм1 - наложенный фильтр на том же шаге
Калм2 - ещё раз
Калм3 - и ещё раз
Ранее брал тройного Калмана. Сейчас в картинке изменение следующее: добавлен усредняющий кольцевой буфер + заполнение пустот кольцевого буфера первым замером (пустоты в массиве портят сильнее). Тогда и одного Калмана может быть достаточно и это должно дать ускорение поиска места с 208-240, до 90. Иначе это 5.625 оборота и если конец кассеты (рулон заполнен), то ждать расчёта по "Remain" приблизительно секунд 15-20. У "AKAI GX-9" в конце вроде как насчитал секунд 20-25. Поправьте, если есть возможность перепроверить.
Надо заметить, что 16 импульсов на оборот удобно для ускорения усреднения накопленных данных. Можно себе позволить отказаться от функции деления (чего не получится для 3 или 5, а аппаратного деления в 'меге' нету) и получить результат среднего арифметического, просто 4-х кратным сдвигом суммы импульсов кольцевого буфера вправо. Но это ни как не ограничивает в выборе крыльчатки с другим числом лопастей. Просто в одном месте программы надо исправить функцию сдвига на деление. Это чуть дольше по тактам, но совсем несущественно.
Далее.
Проверю расчёт только с одним Калманом и если точность в порядке, то добавляю вторую формулу в алгоритм, делаю вывод реального номера импульса и его вычисленного брата-близнеца и уже после чего, проверяю отклонение в железе.
Надо уточнить работу функции в разных местах ленты и понять сколько импульсов гарантированно нужно ждать, что бы получить достаточное приближение расчёта к абсолютному.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 26 июн 2024, 05:49
DrLithium
Рубился с ядром насмерть...
Начал расписывать последовательность работы с данными. Хотел сделать общую функцию для двух разных формул... Размечтался!
Проблема в том, что приходится приводить данные к целочисленным и по этому нужно схитрить и отбросить запятую умножением на 16 или да же 256^n, а после поделить на 16 или 256^n. Но прядок точности страдает от выбора этой кратности. Для одной формулы хорошо, для второй плохо. Хорошо, согласился на два ядра и первое ядро придётся чуть переписать.
Далее бьюсь в Excel-е над работой внутри ядра для второй формулы. Текущие данные после деления приведены к значениям отношения 0.5-2.0 (можно до 0.25-4). Что избежать проблем в "узких" местах расчёта, пришлось определять потолок отношений диаметров. Вернее, это отношение внешнего 'D' (полного рулона) к внутреннему 'D' (пустому). Пришёл к выводу, что надо ограничить MAX = 4. Катушки катушечников учёл, посмотрел "ГОСТ 13275-87", т.ч. должно хватать. Обычное отношение диаметров меньше 3.0, а у кассет меньше 2.5.
Далее колдовал уже не с байтностью значений, а с битностью. Просто так докатился, т.е. это что бы при минимизировании времени расчёта ядра (выбором нужной библиотеки 24x24, 16x32, 24x16 и т.п.), надо не потерять в точности на отбросах дробной части. Т.е. тут уже не шуточки, т.к. что бы точно попасть в нужное место функцией 'Elspsed'/'Remain', нужно постараться - расчёт такой, попадать в +/- 5 импульсов, т.е. ~1/3 оборота.
Пришёл к выводу, что подходящей реализации целочисленного, беззнакового, аппаратного умножения 32 бита x 32 бита просто нет, т.е. оптимизированной на скорость. Лучшее что нашёл - 105 тактов при заявке "88 cycles + 4 (RET) = 92 Cycles". Пришлось писать самому параллельно изобретая вИлосипед в Excel-е. Довольно быстрой получил "91 Cycles" (с вызовом и возвратом) и чуть позже повторил результат по другому алгоритму. А ещё чуть позже получил "89 Cycles" и вроде как да же "85 Cycles". Думаю больше нет смысла тратить силы на изобретательство, трёх дней достаточно и можно плавно перетекать к написанию остальных вариантов умножений с меньшей битностью. В зависимости от старших значений аргументов, думаю выбирать вариант битности функции. Это должно ускорить суммарное время.
В прошлой версии ядро считало за 1570 циклов, т.е. 10'000 раз в секунду можно было успеть посчитать. Вроде как хватало, но когда увидел крыльчатку в Ревокс на... 30 лопастей, подумал что есть смысл потрудится над скоростью расчётов коих теперь, при новой идеологии и дополнительном функционале, прибавилось. Алгоритм в основном тяжёлый из-за частого умножения (тут оно аппаратное, но всё же) и редко из-за программного деления.
Сложные вопросы решены, осталось что-то дописать и потом связать все куски пазла в единый комок тихого ужаса. Возвращаюсь из ассемблерной преисподней... но это было интересно!
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 04 июл 2024, 10:51
DrLithium
Продолжаю работаю над алгоритмом сборки второй формулы. Вроде всё понятно, но в голове не помещается, стараюсь понятное и осмысленное сразу выкидывать из головы на "бумагу". В очередной раз набрасываю план-шпаргалку. Как думал трудности закончились, не тут-то было. Проблема в том, что есть первая формула и заставить работать систему в сумме со второй не просто. Пришёл к тому, что в какой-то момент времени обе формулы должны работать вместе.
Со стороны пользователя:
Запустил ленту с середины, желаю время - "жму" 'Elapsed' или 'Remain'.
Со стороны системы:
принято - вывешиваю 'CALL',
жду наполнения,
считаю среднее,
фильтрую,
считаю отношение,
фильтрую,
конвертирую по второй формуле (отношение - номер импульса), но... что бы попасть в точные пределы надо ждать нескольких импульсов для сглаживания выбросов,
... тут наверное не хорошо заставлять пользователя долго ждать точного расчёта, по этому...,
конвертирую полученное уже по первой формуле (номер импульса - время),
отключаю вывод "занавески" 'CALL'...,
...и вывожу значение сырого расчёта РВ,
в финале, номер импульса (уже максимально точный для расчёта) гружу в "счётчик импульсов от начала для расчёта РВ",
включаю счётчик в режим вывода РВ соответственно выбору пользователя - пройденное/остаток.
Т.е. пока идёт уточняющий расчёт, наверное лучше это демонстрировать. Демонстрация изменения значений даст представление о том, что функции отрабатывают. А вывод результата раньше по времени (хоть и предварительный) даст пользователю понимание приблизительного остатка времени заблаговременно. Это м.б. важно, если ленты остаётся мало, а расчёт ещё длится. Успеть нажать 'Fader', по предварительному расчёту остатка ленты, лучше чем не успеть узнать результат вовсе и опоздать.
Т.о. получается, что обе формулы иногда должны работать вместе и успевать всё посчитать, при этом не мешая другим функциям делать свою работу. Хорошо бы формулы максимально оптимизировать по времени исполнения и это даст возможность использовать большее кол-во лопастей на оборот в датчиках подкассетников. Повышение кол-ва лопастей на оборот в дальнейшем может обеспечить большую точность времени. Для датчика MT6701 это можно реализовать без особых затрат, просто перепрошивкой на нужное число "лопастей".
Поискал алгоритмы или готовые библиотеки быстрых расчётов. По умножению писал выше что что-то уже сделал сам, а в сети нашлось только в общем виде, т.с. идеи схожие с теми что уже реализовал. По возведению в квадрат вроде ни чего особенного не нашёл. Буду брать своё умножение, если два на два байта, то "25 cycles", если три на три, то уже "50 cycles", по четыре - "85 cycles". Но, для выбора "своей" функции тогда надо предварительно "взвешивать" аргумент. Деление по прежнему самое тяжёлое, т.к. аппаратно не поддерживается в 'Mega'. Поискал деление через умножение, но разумного и внятного особо не нашёл.
До добавления в пункты меню ещё далече, т.е. пока что делаю реакцию на флаги взводимые и сбрасываемые из терминала.
По пакетам следующие мысли...
Для двух формул нужны разные значения коэффициентов, т.е. значений констант для кассеты увеличивается. Тогда есть вариант решить так: основной набор - C-46, C-46L, C-60, C-74, C-90, C-120 и м.б. ещё какие-то зашить в 'EEPROM'. Места мало по этому много вариантов не поместится. Но... есть мысль сделать подключаемый блок внешней памяти по 'TWI' и если этот блок при инициализации будет найден (типа plag&play), то меню будет работать с уже не с пакетами из 'EEPROM', а с пакетами из этого блока.
Ещё пришёл к выводу, что данные для второй формулы лучше готовить... промотав ракорд. Ступенька из-за разницы толщин ракорда и самой ленты даёт о себе знать. Т.е. вторая формула (отношение импульсов - время) "чувствует" этот скачок и прогноз какое-то время идёт с ошибкой. Эта проблема не страшна для первой формулы. Как делать этот пропуск пока ещё думаю. Наверное лучший вариант: дежурить с фонариком у головки и как только пройдёт склейка, выждать чуть времени пока лента дойдёт до бобышки, после чего дать команду на вывод данных, нажав кнопку на терминале. За тем польются данные: номер импульса + длина в тактах приёмного + длина в тактах подающего. Причина по которой это можно себе позволить состоит в том, что в самом начале лучше дать команду перемотки назад до упора (автостопа). В этом случае СРВ будет включён автоматически. Это даст более точный вариант отображения времени, чем после использования функций 'Elapsed' или 'Remain', но это без учёта последующей плотности намотки. Т.ч. выборка петли, после установки кассеты через перемотку назад, в планах, но чуть позже.
Уже кажется что ваяю какой-то бескомпромиссный вариант СРВ, с лучшей точностью чем... не понятно у кого. Отсюда и все сложности, но так себе ставлю задачу. При этом надо себе напоминать, что плотность намотки вносит погрешность. М.б. в будущем подумаю как решить и эту проблему. Что-то типа периодического вызова функции 'Elapsed' в фоне с последующей коррекцией, типа применения масштабирования.
Есть ещё о чём сказать и подумать.
Функция 'Remain' была выведена отдельной от основного времени не спроста. Проблема в том, что пересчёт остатка при записи - наиболее ценная часть СРВ. И даже при погрешности из-за плотности намотки, перерасчёт остатка может дать лучший результат, чем после перемотки кассеты в начало, для сброса счётчика импульсов в начале рулона. Это зависит от того, как была намотана другая сторона, через 'Play'/'Rec' или через перемотку. Разница м.б. несколько секунд! Если более точно, то... только что перемотал - до 14 ! Это для ленты 35 минут на сторону, в перемотке 34:54 vs 35:08 в воспроизведении. Т.е. более рыхлый рулон намотанный под меньшей нагрузкой будет иметь меньше импульсов на всю длину. Из-за разной плотности намотки, в данном случае, набегает ошибка до 0.437%. Наверное по этому кто-то и когда-то рекомендовал хранить ленты именно после перемотки - копир-эффект меньше и лента менее преднатянута. Но, если для остатка по 'Remain' изменить учёт времени с приёмного на подающий подкассетник, то точность именно остатка станет выше.
Отсюда появилась мысль, по результату 'Remain' сохранять дельту остатка относительно счёта пройденного времени. Т.е. вывод остатка показывать после пересчёта как минусовое значение (т.к. остаток) рассчитанное так: общая длина ленты (из пакета), минус текущее пройденное и минус дельта рассчитанная по 'Remain'. Но константа не есть хорошо, тогда...
...Как вариант появилась вторая: вычислять процент погрешности и корректировать счёт времени с поправкой на плотность намотки.
Т.е. работы снова вагон и погода разгрузке этого вагона что-то не помогает...
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 05 июл 2024, 12:34
DrLithium
Добавочка.
Подумал, что не сложно ввести коррекцию в перемотке тупо добавляя 0.53% (в данном случае), т.е. каждые 187 импульсов (настраиваемое) добавлять к "счётчику номера импульса от начала" +1 при перемотке вперёд и -1 на при перемотке назад. После чего сбрасываем счётчик коррекции и считаем снова. Но! Если мотаем назад, а там рулон ни фига не "рыхлый", т.е. после воспроизведения, то будет набегать лишний минус. Тогда есть смысл отталкиваться от того, что все хранят рулоны плотными, т.е. исключительно после воспроизведения. Т.о. перематывая назад считаем, что "кредит" для компенсации равен нулю, т.е. поправку не выдаём - рулон по которому идёт учёт времени... уменьшается и плотность не меняется. При перемотке вперёд разрешаем поправку и при этом считаем выданный "кредит" - рулон рыхлеет (увеличивается быстрее из-за неплотной намотки - импульсов проходит меньше)! При последующей перемотке назад (т.к. "кредит" больше нуля) производим поправку и уменьшаем набежавший "кредит", пока он не истечет до нуля. Т.о. пользователь вставивший "рыхлый" рулон да ещё и с середины должен себе отдавать отчёт в верности РВ, точнее отчёт в невозможности получить высокую точность работы СРВ. Вероятно это поможет частично решить проблему плотности намотки рулона, дав в перемотке точнее попадать в паузы треков. Номер импульса для поправки можно добавить в пакет ленты как байт "после какого значения номера в перемотке, следует произвести коррекцию счёта" и дать значение по умолчанию 190 (~0.52%).
Но. Если намотаем на рулон в перемотке вперёд, а затем добавим "грамм 100" воспроизведения, то "кредит" будет зачислен, а рулон будет иметь попеременную рыхлость. Что делать? Перемотка назад начнёт списывать "кредит" с плотного рулона, а это не правильно. И вот ещё вопрос, в воспроизведении рыхлые слои после перемотки "ниже" этажами спрессует? Если нет, то для остальной проблемы можно найти решение. Прессование можно проверить перемотав рулон с начала и чуть не дойдя конца включить воспроизведение. Судить по отличию от значения в чистой перемотке. Может позже проверю...
Чисто теоретически (практика не исключается) можно выделить массив байт 30-45 (на событие надо байта три, два на номер импульса + один на размер "кредита"), в котором хранить историю перемоток событий на 10-15. Если "кредит" списан, то запись истории стирается. При этом нужно держать последний значимый "кредит" в переменной и мониторить приближение к нему. После "списания" текущего из массива выбирается предыдущая запись о "кредите" и его месту по номеру импульса. Реализовать не сложно и это можно посчитать не дорого.
З.Ы. Это так, очередной набросок на будущее. Исключительно ради того, что бы попадать в межтрековые паузы ... А пока решаю вторую формулу.
Поискал алгоритмы или готовые библиотеки быстрых расчётов. По умножению писал выше что что-то уже сделал сам, а в сети нашлось только в общем виде, т.с. идеи схожие с теми что уже реализовал. По возведению в квадрат вроде ни чего особенного не нашёл. Буду брать своё умножение, если два на два байта, то "25 cycles", если три на три, то уже "50 cycles", по четыре - "85 cycles". Но, для выбора "своей" функции тогда надо предварительно "взвешивать" аргумент. Деление по прежнему самое тяжёлое, т.к. аппаратно не поддерживается в 'Mega'. Поискал деление через умножение, но разумного и внятного особо не нашёл.
Чем такие страдания, может лучше взять более подходящий процессор? Например, тот же STM32F103 стоит на Aliexpress дешевле, чем ATmega88, а имеет тактовую 72 МГц и команды умножения и деления с 32-разрядными аргументами.
Чем такие страдания, может лучше взять более подходящий процессор? Например, тот же STM32F103 стоит на Aliexpress дешевле, чем ATmega88, а имеет тактовую 72 МГц и команды умножения и деления с 32-разрядными аргументами.
Это не страдания, это приятные изыскания. Иногда устаёшь искать решение, иногда от рукоделия, иногда от рутины в кодировании, нужно переключаться. Иногда что-то трудно даётся, но получить адекватный результат - весьма приятно. Да и суть того, что бы остаться на 'Atmega' - это постараться уложить алгоритм в старое ядро и это реально. Диды на более слабых МК делали, а нам слабо? Чуть что не помещается/не получается - брать толще? Да, взять новое проще, но и оно когда-то устареет и кто-то другой скажет что-то типа - 1GHz, 64-разрядными аргументами и зачатками ИИ. Я бы сказал, что сейчас главное не платформа, а алгоритм исполнения и именно с хорошей точностью + быстрая реализация расчётов. Переписать на новое железо не будет проблемой, было бы с чего. Но, если и переходить, то надо ещё потратить времени на этот переход. А пока всё в порядке, процесс идёт...
Сейчас программирование нельзя назвать страданием. Сидят на компиляторах языков высокого уровня (почему высокого, кто так назвал?) типа си. Страдания были (для меня и сейчас) это когда программируешь на ассемблере под конкретный процессор/микроконтроллер. Что сложного использовать готовые библиотеки и даже не создавать макросы?
Сейчас программирование нельзя назвать страданием...
Да, я так же думаю, что под "страданиями" имеется ввиду то, что это что-то типа прохождение самим программером через определённые трудности в решении общих вопросов которые уже давно и благополучно решены.
В данном случае на руках присутствуют все "козыри" (бибилотеки) для решения, т.е. страданий нет. Но когда впадаешь в ступор, типа голова не варит или руки резко изменили радиус от фазы луны, то можно устроить себе подобные страдания-изыскания почитав чужие труды и скажем, проверить альтернативную теорию, в том же Excel-е. И да же, если нет каких-то новых зацепок в сети, то хотя бы удаётся узнать, что... например деление, в случае софтовой библиотеки (от Chan-а), использует самый передовой вариант из доступных. Остальные или страдают по точности, или по скорости. Но вот с умножением нашлось что изменить и получить выигрыш, просто разобравшись в теории. И это не написание с нуля, это тупо правка довольно распространенной реализации.
Скажу, что есть куда большие "страдания" - борьба с самим собой, усталость, настроение, лень, времени нет, здоровье, дёргают в процессе, муза в отпуске, луна не в той фазе, а сосед с перфоратором в той самой и его не отпускает и.т.п.
Сейчас пытаюсь разобраться с флагами для режимов СРВ, задачка простая, но голова подводит. Сижу расписываю "4" по "слагаемым", иначе логически можно накуролесить, а потом тратить время на расхлёбывание. Предпочитаю лучше потупить, получить (вывести) чёткое Т.З. и идти строго по нему.
Надо решить - переключаться флагами между:
обычный счёт,
СРВ, пройдено времени,
СРВ, остаток времени,
для первой формулы - вывод номер импульс/время мСек,
для второй формулы - вывод отношение/номер импульса,
(а после ещё что-то из этого, для реверса продублировать)...
Надо проверить пересечение частей алгоритмов, общие части выделить выше условий, предусмотреть выход из функции по условию, ну по мелочи всё просмотреть. Если что-то вовремя не решить, то позже придётся переписывать ещё раз и ещё...
Например: что бы написать ядро расчёта второй формулы, надо определить формат (номера регистров и разрядность) во время математических операций - это необходимо для скорости. И если идёт разбиение ядра на части, то надо понимать в какой момент что где находится и в какой разрядности. Минимум нужно сделать справку и набросать её в понятном виде. Сделать это легко, но в голове все детали не держатся, приходится мелкими шажками... И вот это можно назвать страданиями, платформонезависимыми и независимыми от языка. Возможно на СИ это можно было бы расписать быстрее, но не думаю что ядро смогло бы считать так же быстро. Есть смысл, при переписывании на СИ, делать ассемблерные вставки ядер.
Про макросы.
Тут то же надо осторожнее, если есть что-то совсем однообразное, то есть смысл. Если это огромные куски (попалась как-то библиотека оформленная... макросом, пришлось переписывать) и часто вставлять, то тут главное не забывать, что это копипаст - код пухнет жутко с новой копией.
например деление, в случае софтовой библиотеки (от Chan-а), использует самый передовой вариант из доступных. Остальные или страдают по точности, или по скорости. Но вот с умножением нашлось что изменить и получить выигрыш, просто разобравшись в теории.
Слишком расточительно тратить собственные силы на борьбу за быстродействие, если это решается просто переходом на другой процессор. Тут даже на решение основной задачи не хватает сил, куда там растрачивать их по пустякам. Когда задача с трудом влезает в процессор по скорости или объему, ее решение многократно усложняется. Зачем быть самому себе злобным буратиной?
Слишком расточительно тратить собственные силы на борьбу за быстродействие, если это решается просто переходом на другой процессор.
Есть один очень сильный (как считаю) контраргумент. Доступность самого камня. С дефицитом каких-то моделей STM уже столкнулись. Гарантии есть? А вот старое и сильно распространённое скорее всего ни куда не денется ближайшие лет 10, минимум.
Тут даже на решение основной задачи не хватает сил, куда там растрачивать их по пустякам.
Хватает и если бы был свежий, то разобрался быстрее. Просто накапливается усталость. Сколько времени проект идёт без перерывов? Планировал отдохнуть, но сорвался и продолжил.
По пустякам? Я так совершенно не считаю. Лёгкая математика конечно хорошо, но я сейчас буксую не на математике вовсе. С этой стороны нет проблем совсем ни каких. Логика сейчас проблема, много условий надо отследить, т.е. платформа тут ни при чём.
Когда задача с трудом влезает в процессор по скорости или объему, ее решение многократно усложняется.
Влезает с запасом и по скорости вероятно, то же без проблем. Но будут ещё задачи, типа "Fast Harltey Transform" и вот только тогда можно будет говорить о нехватке чего-то.
Не понял это откуда и почему? Может со стороны так выглядит? Но мне:
а) не легко, но со знаком +
б) интересно
в) получаю удовольствие от результата и иногда в процессе
г) легко мыслить категориями уровня железа, если это необходимо
д) п. 'г' не мешает оперировать функциями и библиотеками
Нет смысла. Про существование ассемблера лучше вообще забыть.
Когда нибудь так и будет. Но "есть мороженое" пока я "молод" и оно мне ни как "не вредит", буду. А вот выкинуть его действительно глупо - это понимание и азы без знания которых можно "свалять" такого "дурака", что стыдно будет очень долго. Но куда больший печальный опыт был именно от тупого заимствования чужих библиотек на СИ. Ассемблер тем и хорош, что глупости тут в разы меньше. У СИ другое преимущество, скорость написания. Если есть готовое ТЗ и надо только перевести с одного "языка" на другой, то удобнее. Язык не является узким местом, больше проблем в другом. Сейчас я сам себе ставлю ТЗ, занимаюсь архитектурой уровня пользователя и разраба, пишу код, придумываю тесты, ищу логические ошибки... Язык и платформа пока не главное, ни чего не решает и не мешает. Код пишу быстро, когда есть что писать, а основная работа вообще идёт в Excel-е, >95% если речь идёт именно о разработке. Естественно отладка имеет совершенно другой процент.
Позже можно будет заняться переходом на новые рельсы. И это будет вероятно и запланировано, а пока переходить с "узкоколейки" на "полный размер" по среди "Тундры", кажется сомнительной затеей. Или есть какой-то скрытый интерес?
У STM32 есть одно неудобство для отдельных применений, это трехвольтовое питание.
Тот проект с Филипсом на видео выше, собственно, нужен мне был чтобы протестировать замену Мег для тех случаев, где нужны именно 5В, и STM32 уже некоторый overkill. Для этого случая с дальнего угла ящика была вытащена залежавшаяся там коробка с STM8, до которой долго руки не доходили.
Так вот, желания возвращаться на Мегу после этого проекта ну совсем мало осталось. Особенно если нужен не простейший ногодрыг, а предполагается какая-то математика с делением и умножением.
По поводу использования сишных сторонних библиотек, тут смотря откуда библиотека. Например, СТшный SPL прекрасно работает и сильно время экономит. А просто выдернутое с интернета с непонятных источников практически всегда внимательно просматриваю и под себя переписываю. Если оно уже есть и работает, то почему бы не использовать хотя бы алгоритм и/или константы для того же дисплея.
Так вот, желания возвращаться на Мегу после этого проекта ну совсем мало осталось. Особенно если нужен не простейший ногодрыг, а предполагается какая-то математика с делением и умножением.
Легко верю. Прогресс не стоит на месте, ранее были "Хmega" и дороже, теперь есть альтернатива.
С другой стороны есть "умники" которые кричат что "я весь ваш проект шатал в tiny2313 засуну, ещё и место останется". Иногда хочется им дать "по зубам", показав проект который упирается в 32К на меге. Сейчас в текущем проекте >19К, но что-то можно оптимизировать.
А просто выдернутое с интернета с непонятных источников практически всегда внимательно просматриваю и под себя переписываю.
Для ассма собирал по крохам с тем же подходом, правил если было надо. По СИ то же иногда приходилось искать, с разным успехом. И если попадалось "красивое", не проходил мимо.
З.Ы. «Кто ясно мыслит – ясно излагает» (Шопенгауэр) и осталось научится писать такие же комменты к коду.
я весь ваш проект шатал в tiny2313 засуну, ещё и место останется
А смысл? Для устройств в количестве 100к+, где будет каждый цент считаться, там важно найти контроллер подешевле. А для единичных устройств зачем? Думать потом, какой шрифт выкинуть из дисплея или лишнюю букву из UART передачи?
Так вот, желания возвращаться на Мегу после этого проекта ну совсем мало осталось.
Лично для меня главный недостаток STM32 - ужасно сложная периферия. Все возможности нужны крайне редко, но чтобы применить любой периферийный блок даже в простейшем режиме, надо весь мозг сломать. У AVR это выглядит намного более по-человечески. Что касается математики, тут да, без раздумий все переменные беру 32 бита, никаких мучений с выбором диапазонов, да и сам код можно писать намного более небрежно, без напряга, все равно скорости хватит.
EEPROM есть и в STM32L1. Но сейчас такие времена, что страшно применять что-то отличное от массового. Например, при попытке купить STM32F100 (с ЦАП на борту) упорно шлют F103, хоть на корпусе написано F100.
А смысл? Для устройств в количестве 100к+, где будет каждый цент считаться, там важно найти контроллер подешевле. А для единичных устройств зачем?
Тут дело не в стоимости, как я понимаю. Применяется тот контроллер, который комфортней программировать. Про STM32 такого не скажешь, каждый проект на нем - это огромное насилие над собой, хотя потом в процессе и легче.
Далеко не все. Лишняя головная боль - следить за тем, развел сигнал на толерантный порт, или нет. Если ошибся - резать плату. А для выхода, чтобы получить 5 В, надо использовать open drain и подтягивающий резистор, а это для быстрых сигналов не подходит. Вообще, распределение ног на STM32 - это дикая головная боль. Периферия привязана к определенным ногам, некоторые можно переставлять (с помощью remap), после перестановки они могут перекрываться с чем-то другим, всё надо отслеживать. Есть инструменты, автоматизирующие этот процесс, но не хочется обрастать всем этим, как дерево мхом.
В Вашем случае гораздо более полезным будет другой шаг - переход на Си. У меня достаточный опыт ассемблера, больше 10 лет (сначала 8080, потом 8048, 8051, AVR). Переход на Си был крайне болезненным, всюду виделись преимущества asm. Но уже больше 15 лет использую на микроконтроллерах только C/C++ и отвественно могу завить, что был полным идиотом, когда цеплялся за asm.
С другой стороны есть "умники" которые кричат что "я весь ваш проект шатал
Да, таких шатальщиков полно. В соседней ветке мне заявляли, что прошивку для БУ Олимп-005 напишут за 3 дня. Ну и где они? Я уже который месяц бьюсь, но пока даже бета-версии нет. Проблема с самой структурой программы. Хочется сделать красиво, а получается всё переплетенным, где уже на следующий день сам ничего не понимаешь. Крайне некомфортно работать с таким кодом. Код становится более наглядным только ценой значительной потери производительности. Приходится делать многочисленные "обертки" для функций, писать много лишнего ради красоты. Такое тоже коробит. Но, наверное, это правильно. Надо взять процессор помощнее и писать код таким, чтобы он был более понятным человеку, а не максимально производительным.
Ваш проект управления ЛПМ Вильма, за которым я наблюдаю со стороны, выглядит как какой-то сюрреализм. Дело, доведенное до абсолютного абсурда. Требуется создать нечто совсем иное - простую и понятную систему управления. Тогда она будет кому-то полезна. А такой сложный проект - это работа в корзину. Понимаю, что делать простые вещи намного сложнее. На это тут практически никто не способен. Недавно у Макса Крюкова появилась интересная плата управления ЛПМ. Довольна простая, но опять есть какие-то зачатки универсальности, они как плесень поедают хорошие начинания.
Так вот, желания возвращаться на Мегу после этого проекта ну совсем мало осталось.
Лично для меня главный недостаток STM32 - ужасно сложная периферия.
Это я по поводу STM8.
Долго я не решался с ним связываться, отчасти потому что было непонятно, в чем для него код писать. Попробовал ST Visual Develop, вполне нормально. И SPL хорошо работает. Отличный контроллер для тех случаев, когда STM32 избыточен.
DrLithium писал(а): ↑
09 июл 2024, 05:19
А смысл? Для устройств в количестве 100к+, где будет каждый цент считаться, там важно найти контроллер подешевле. А для единичных устройств зачем?
В Вашем случае гораздо более полезным будет другой шаг - переход на Си. ... Переход на Си был крайне болезненным, всюду виделись преимущества asm. Но уже больше 15 лет использую на микроконтроллерах только C/C++ и отвественно могу завить, что был полным идиотом, когда цеплялся за asm.
Не против перехода и да, отдаю себе отчёт, что в СИ есть преимущества. Но "набить руку" надо ещё времени, этим можно заняться позже, после доведения проекта до логической точки. Естественно из-под "пера" будет выходить много быдлокода, и уже представляю кучу "учителей" с "указкой по рукам"...
Ваш проект управления ЛПМ Вильма, за которым я наблюдаю со стороны, выглядит как какой-то сюрреализм. Дело, доведенное до абсолютного абсурда. Требуется создать нечто совсем иное - простую и понятную систему управления. Тогда она будет кому-то полезна. А такой сложный проект - это работа в корзину. Понимаю, что делать простые вещи намного сложнее. На это тут практически никто не способен. Недавно у Макса Крюкова появилась интересная плата управления ЛПМ. Довольна простая, но опять есть какие-то зачатки универсальности, они как плесень поедают хорошие начинания.
Тут основная проблема в том, что ставилась задача не что бы получить сразу готовое+массовое, а вообще рабочее и только. "Выйти на рынок" с готовым к употреблению продуктом, полагаю, это задача номер два, которая м.б. подразумевалась, но не ставилась изначально.
Первоначальный план был просто заставить работать какой-то выбранный набор функций + дать комментарии, что бы было проще разобраться в реализации, т.с. "кирпичная кладка" под разбор. По ходу изваяния намеченного надо было жертвовать остальным, т.е. тем что можно оформить позже. Да и сил у меня на такое сразу точно не хватит, т.е. на то, что бы сразу выдавать совсем готовое. В этом месте на ум приходит "человек-оркестр", супермен и ШХ в одном флаконе, а я вообще просто погулять вышел. Что-то оформлю позже, дам описание, исправлю читабельность и т.п....
Уже по ходу производства логику управления не трудно понять, а вот счётчик не может быть описан подробно по причине того, что он ещё далеко не всё делает что нужно, постоянно приходится вносить изменения. Что бы понять логику того что там происходит, какие ресурсы используются и как этим кодом управлять - нужно давать описание и ёмкое, со схемами перемещения данных, графиками, инструментами и т.п. Я это сейчас не даю, на это совсем нет времени, т.к. постоянно что-то меняется. В проекте делаю ставку на разделение блока управления и исполнения. Точнее, один блок управления (с выбором опций, будет в будущем) -> любой ЛПМ с блоком исполнения.
Видел у Макса его ролики, код не смотрел, может позже пригодится.
Re: Твик управления деки VILMA 204-STEREO [2022]
Добавлено: 10 июл 2024, 08:37
411i6470r
товарыщы , всем привет ! вот не знаю - я по адресу, в этой теме, или нет ? если нет - прошу поправить , но вроде как - кто-то из вас изготавливал платы блоков питания для 104-й , которые под кренки 7812, 7912 . у кого такую платку купить можно ?? без деталей конечно .
Но "набить руку" надо ещё времени, этим можно заняться позже, после доведения проекта до логической точки. Естественно из-под "пера" будет выходить много быдлокода, и уже представляю кучу "учителей" с "указкой по рукам"...
Не могу припомнить особых проблем с написанием программ на Си. После ассемблера всё просто и понятно. У меня основным тормозом было неприятие Си, некоторые проекты в "переходный" период делал и на asm, и на Си. Что было глупосью, конечно, но не мог разорвать с прошлым. По производительности в большинстве случаев проигрыш на Си не чувствуется. За очень редким исключением. Например, прошивку для генератора синуса (типа SG-642 с моего сайта) написать на Си невозможно без фатальной потери производительности (во много раз). Писать всякие менюшки для графического LCD все равно на asm было лень, поэтому поставил 2 процессора - генерация на asm, а управление на Cи. Еще генератор опорной частоты для ведущего двигателя Э-004 тоже на asm, иначе не выжать из программного DDS такой тактовой частоты. Еще на asm есть у меня проект передатчика для ИК-пульта, там модуляция и сама посылка формируется программно. И всё, больше примеров нет.
Что касается "учителей", то с таким на форумах особо не сталкивался. Бывало, перенимал стиль написания каких-то фрагментов из выложенных на форумах примеров, но это единичные случаи. Пример заимствования стиля ниже:
Тут основная проблема в том, что ставилась задача не что бы получить сразу готовое+массовое, а вообще рабочее и только. "Выйти на рынок" с готовым к употреблению продуктом, полагаю, это задача номер два, которая м.б. подразумевалась, но не ставилась изначально.
Мне тоже трудно сформулировать, каким должен быть процессор управления ЛПМ. Хочется видеть что-то красивое, простое и понятное. С таким же простым и понятным, пусть и неточным, счетчиком. Но такой продукт был бы гениальным и создать его крайне сложно. Ваши изыскания, которые можно прочитать на этом форуме, вызывают сильное офигение и слова "ёксель-моксель"...
Ваши изыскания, которые можно прочитать на этом форуме, вызывают сильное офигение и слова "ёксель-моксель"...
А с этого места поподробнее. Что делал не так в изысканиях? Что-то совсем плохое? Что надо исправить? А слова... это у меня наверное просто из-за скуки.
По изысканиям...
Наткнулся на проблему выбора реализации пунктов меню - сколько и чего показывать пользователю. Это определяет кол-во флагов и порядок работы с ними. Если свежевставленная лента на середине, то обязаны иметь функции перехода с обычного счёта к счёту РВ. Т.е. место ищется через функцию пройдено - 'Elapsed' или остаток - 'Remain'. Можно переключиться из 'пройдено' в 'остаток' и обратно. Если значение РВ 'пройдено' было абсолютным (кассета с начала), то можно не пересчитывать (если не было перемоток). А вот остаток всё равно лучше пересчитать, т.к. плотность намотки приёмного подкассетника будет меньше влиять - можно получить большую точность на почти пустом подающем рулоне.
Трудность в том, что надо выбрать, как вести пересчёт между переключениями 'обычный счёт' - 'пройдено' - 'остаток':
пересчитывать только при первом вызове,
пересчитывать всегда при выборе,
дать возможность переключаться между посчитанным и если ещё не считалось, то рассчитать,
дать возможность переключаться между посчитанным и если ещё не считалось, то рассчитать + дать возможность перерассчитать заново.
Думаю что последний вариант.
Вопрос, как дать этот выбор?
Вероятно остановлюсь на выборе из трёх пунктов меню (что бы не плодить лишнего). При этом, перерасчёт можно будет производить только при переходе из обычного счёта - 'regular', в один из вариантов РВ. Т.о. переключение между посчитанным РВ 'пройденого' и посчитанным РВ 'остатка' будет происходить быстро, если оба рассчитаны. При желании обновить расчёт - нужно выбрать в меню пункт 'обычный счёт', а затем снова один из вариантов РВ. Наверно как-то так.
Теперь надо определиться с функцией остатка. Если счёт РВ 'пройденное' опирается на значения обычного счётчика, то на что должен опираться счёт РВ 'остатка'? Или заводить ещё один счётчик, не зависимый от основного или вычислять остаток через смещение от значения обычного счётчика. Во втором случае для вычисления 'остатка' надо помнить смещение, вычисленное как отрицательное время длины ленты за минусом уже набежавшего. Так не очень нравиться, но возможно. А в первом случае, для поиска номера импульса, надо иметь обратную формулу, но проще изменить деление на обратное. Т.е. уже INT1(подающий) / INT0(приёмный), а импульсы для пересчёта 'остатка' РВ брать с подающего подкассетника - что даст более точное значение в конце ленты. Как раз счётчик для реверсивного направления уже имеется на борту. Остаётся добавить знак минуса для значений меньше 1000. Ну и полезно дать смещение по длине ракорда, что бы ноль выходил аккурат на склейку.
З.Ы. Вроде что-то прояснилось. «Теперь этой глупейшей неопределённости будет поменьше!» (Алиса в стране чудес).
От счетчика достаточно показывать реальное время, как в фирменных деках конца 80-х - начала 90-х. Дополнительные функции, типа остатка времени, не обязательны. Они перегружают аппарат и делают его непонятным. А всякий ввод со стороны пользователя, например, типа кассеты, однозначно вреден и его не должно быть.
Вы делаете всё возможное, чтобы люди этим проектом не пользовались.
Может прекратить проект или конкретнее укажете, что именно?
Я иду по плану, разработка далеко ещё не окончена, требуется терпение и время, именно сейчас реализую сложное (как оказалось). Далее ещё наполняю функционалом и как будет достаточно, то возьмусь за универсальность, описание и т.п. Если ещё ни фига должным образом не работает, зачем это описывать и раздавать? Будут правки, переделки и доводки. При этом я задавал вопросы: за что браться в первую очередь и что я услышал? Толком ни "бе", ни "ме". Т.ч., что бы я делал нужное, наверное нужно было бы просто сказать об этом.
Дополнительные функции, типа остатка времени, не обязательны.
Думаю что пусть пользователь сам решает, надо - пользуется, не надо - просто пусть не нажимает. Кто я такой что бы решать за него? Член КПСС? 8)
По СРВ есть принятый/устоявшийся набор функционала. Занимаюсь тем, что разгадал как, хочу обеспечить перекрытие по функционалу и точности, и сделать это лучше чем у лучших мировых аппаратов. Пользователи пост-СССР этого были лишены и дать им это, в полном объёме, моя цель!
'Fader' - полезная штука? Нет же смысла отрицать. Но ещё удобнее ей пользоваться, если известно когда надо активировать.
Смартфоны у всех и так перегружены, и жалоб на это ноль. Есть такое понятие "навароченность" и всегда когда мне кто-то описывал аппарат, то говорил примерно так: там да же такая рюшечка есть! А скромность как украшение - это только когда не смог ни чем украсить готовым или сам не смог сделать украшение. Если что-то не понятно, то можно же спросить и получить ответ. Вот только ни кто ни чего не спрашивает - значит всем всё понятно. Если что-то считаю лишним в аппарате/стиральной машине/самолёт/на эскалаторе, то применяю правило: куда мне не надо - туда я не лезу, а не то посадят в стиральную машину, сбросят с самолёта вниз головой и прямо на эскалатор!
А всякий ввод со стороны пользователя, например, типа кассеты, однозначно вреден и его не должно быть.
Кассета 'FeCr' не имеет уникального 'ID' и при этом на аппаратах бывает кнопка 'FeCr'. Как такой пользоваться, если нечем? Аппарат не Ванга, что-то придётся нажимать. А если придумать как обойтись без нажимания - то я не против. При всём уважении, но часто слышу, что многие любят сами калибровать при наличии автокалибровки. Но, если все нужные данные о кассете собраны в базу, то почему бы это просто не загружать без какого-либо ввода? Это можно будет сделать, но это снова время на разработку. Как я понимаю, пользователю нужно оставить возможность оперировать, т.с. подстраивать. А когда данные готовы/собраны, то пусть работает автомат - читает данные из базы и оперирует ими.
З.Ы. В чём сила брат? В Ньютонах! Наверное закончу когда будет в Паскалях и придавит...
... а если в кассете лента поменяна ? ну вот так произошло. то есть лента не убитая жизнью - вполне пригодна к записи , но вот - в неродном корпусе. так что - в данном случае - шах и мат .
Расчётная погрешность выглядит как-то так:
Да, взять новое проще, но и оно когда-то устареет и кто-то другой скажет что-то типа - 1GHz, 64-разрядными аргументами и зачатками ИИ. Я бы сказал, что сейчас главное не платформа, а алгоритм исполнения и именно с хорошей точностью + быстрая реализация расчётов. Переписать на новое железо не будет проблемой, было бы с чего. Но, если и переходить, то надо ещё потратить времени на этот переход. А пока всё в порядке, процесс идёт...