Я перезалил видео с демонстрацией настройки инструмента «орган Хаммонда».
Изначально видос был залит на «платформу«, но она почила в бозе. В результате я залил на рутуб, и обновил соответствующую запись в блоге.
Блог обо всём.
Я перезалил видео с демонстрацией настройки инструмента «орган Хаммонда».
Изначально видос был залит на «платформу«, но она почила в бозе. В результате я залил на рутуб, и обновил соответствующую запись в блоге.
Подогнал по месту платы правой клавиатуры. Пришлось чуть рассверлить отверстия, в которые продеты шпильки крепления резонаторов. Прилегание плат теперь плотное, расположение магнитов в клапанных окнах — приемлемое.
Следующий шаг — наклейка магнитов в правую и в левую части.
А баян V2, как можете видеть, уже разобран и звучать больше не будет. Следующие звуки будут только из 3-й версии.
Если кому интересно, то вот так платы баяна V3 укладываются на свои штатные места.
Я предварительно распечатывал контуры плат на принтере, вырезал и прикладывал по месту. Но к сожалению, я слишком поздно выяснил, что мой принтер при печати слегка увеличивает. Платы к тому времени уже были заказаны.
Но несмотря на то, что платы оказались примерно на 4 мм короче, чем надо, использовать их вполне можно.
Осталось уточнить размеры «резонатора» для самой левой платы, начертить его, напечатать, и можно будет собирать.
UPD: Вот как-то так (см. рис. 2).
Внутри — широко известный в узких кругах Ketron SD2 + усилитель звука, собранный на TDA8543T. Тот усилитель, который уже имеется на плате Ketron-а, не выдаёт громкость, достаточную для того, чтобы комфортно играть, управляя громкостью с помощью меха. Пришлось прикрутить альтернативный усилитель, который я могу рекомендовать для совместного использования с платой Ketron SD2.
Про сам Ketron SD2 могу сказать, что он хорош. Но недостаточно хорош, для того, чтобы занять место моего основного звукового модуля. Основным модулем у меня пока остаётся ATEMP Pro.DX.
Вот мои наблюдения:
Такие дела.
А вот программные таймеры FreeRTOS-овские меня немножечко разочаровали.
Для реализации таймерных callback-функций есть серьезные ограничения: они должны быть быстрыми и ни в коем случае не должны входить в состояние блокировки (например ожидание мьютекса). То есть там практически такие же ограничения, как и для функций обработчиков прерываний.
С одной стороны, оно понятно, почему так (следствие способа реализации этих самых таймеров). А с другой стороны — доставляет неудобства, т.к. фактически действия «по таймеру» приходится делать не в самой callback-функции таймера, а где-то ещё.
Ну хорошо.
Для моих целей пришлось сделать класс-обертку для реализации моей версии таймеров. У меня единственной задачей таймера является в нужный момент установить нужные флажки в указанной «группе событий» (термин FreeRTOS) — и всё. А уже другая задача будет ждать соответствующего флажка и при его обнаружении делать всё что надо. (На слух всё это звучит «не очень», но реализация получилась довольно удобная и довольно универсальная.)
В результате от «таймеров на millis()» я избавился везде, где это было целесообразно. При этом код, как ни странно, стал более простым и более понятным.

Всего получилось 15 задач.
И все эти задачи раньше приходилось реализовывать вручную, на стандартных костылях Arduino-style (функции tick(), «таймеры на millis()» и всё остальное, в результате чего код становился трудно читаемым).
С переходом на нормальные задачи код стал заметно проще. Всем ардуинщикам очень рекомендую по возможности перебираться на FreeRTOS. Благо, она есть для всего уже.

Стало мне вдруг интересно, раскидывает ли FreeRTOS задачи по разным ядрам контроллера (в RP2040 их два).
Проделал лабораторную работу.
В баяне V3 у меня сейчас используется 11 задач. Я в них добавил кусочек кода, который выставляет флажок в разных местах, в зависимости от того, на каком ядре выполняется задача. Ну и сделал вывод флажков на экранчик.
Оказывается, оно действительно использует оба ядра. Причём не так, что задачи запускаются на конкретном ядре, и потом на нём остаются. Они вполне себе могут перемещаться между ядрами. Видимо, в зависимости от загрузки ядер в каждый конкретный момент.
Очень интересно это всё.

В общем, лекарство от обозначенной в предыдущей заметке болезни выглядит так (см. рис. 1).
В разрыв SPI-цепей CS и MISO впаивается вот такая «пилюля» (асинхронный буфер с 3-мя состояниями выхода). И переводит линию MISO в Z-состояние когда CS = 1.
Надо только в термоусадку эту страсть спрятать.
P.S. Спрятал — см. рис. 2
P.P.S. Вторая пилюля, запаянная на шлейф левой клавиатуры, тоже работает как ожидалось: обе клавиатурные RP2040 не мешают друг другу (до того они не работали вместе на одной шине SPI) и не конфликтуют с SD-картой.