Блог обо всём.
Аккумуляторы, держалка для аккумуляторов, модуль зарядки с защитой от переразряда и два модуля стабилизатора — один будет выдавать 3.3 В, а другой 5 В. (К сожалению, датчики Холла и датчик давления требуют именно 5 В, и питать всю схему от 3.3 В не получится.)
Модули приклею на термоклей к торцам держалки. А весь комплект как-то закреплю уже внутри герметичного объёма. Рядом с платой микроконтроллера.
Сегодня забрал микросхемы согласователей уровней и рассыпуху для новой платы микроконтроллера.
Сама плата заказана (в pcbwave.com — они снова стали принимать платежи с российских карточек). Когда приедет — запаяю.
Обстоятельства заставили меня разориться и купить новые кнопки для баяна (см. рис. 1). Кнопки итальянские, с красивым перламутровым отливом, на 1 мм больше диаметром, чем родные, и гораздо более комфортные для нажатия. Покупал здесь. Кнопки Z-0031 (белые) и Z-0032 (чёрные). Демпферы Z-0051 (чёрные).
Был некий соблазн купить красные демпферы, но всё-таки я решил, что это будет цыганщина, и купил чёрные. Довольно органично смотрится.
А ещё была мысль купить только белые кнопки, чёрно-белые ноты выделять чёрными и белыми демпферами (как иногда делают на концертных баянах). Но я подумал, что это может вызвать лишний напряг при разучивании всякого. А напрягаться, даже немного, мне что-то в последнее время совсем не хочется. Так что остановился на традиционном варианте.
И раз уж я взялся крутить кнопки, я решил, насколько смогу, исправить замеченную мною ранее кривизну второго ряда. Для этого надо было передвинуть крепежные отверстия кнопок второго ряда примерно на 1 мм ближе к первому ряду.
В целом, всё получилось. Получилось не идеально (где-то совсем хорошо, где-то не очень), но, на мой взгляд, заметно лучше, чем было. Но, как обычно, кое-что пошло не по плану.
Читать далее «Заменил кнопки на баяне»Сегодня у меня получилось завести библиотеку MD_MIDIFile на моей RP2040-Zero, на нестандартных выводах SPI.
Устройство инициализируется, файлы читаются. И содержимое файлов выводится в отладочный серийный порт.
Осталась небольшая проблема. Упомянутая библиотека умеет либо, собственно, проигрывать эти файлы, либо выводить их «дамп» в отладочный порт. Причём и то, и другое, она делает «в режиме реального времени» — т.е. с заданной скоростью проигрывания данного файла.
Мне же, для моих «баянных» задач надо будет выбранные файлы сначала сканировать, чтобы убедиться, что содержимое этих самых файлов «правильное», что в них нет ничего лишнего, что могло бы испортить настройки рабочих MIDI-каналов баяна, и что могло бы помешать управлению воспроизведением MIDI автоаккомпанемента (задавать теми, и т.п.). И сканировать надо не со скоростью воспроизведения, а со скоростью чтения файла.
И, судя по всему, придётся эту библиотеку дорабатывать под свои задачи. Хоть я такое и не люблю. Но это будет в любом случае быстрее (и идеологически правильнее), чем разводить ещё одну (свою) библиотеку только для сканирования файлов.
Ранее я писал о том, что научился искать свободный радиоканал. Но делать это надо будет не на стороне приёмника (который будет сделано на Arduino nano), а на стороне передатчика, который будет сделан на RP2040.
Ну и вот сегодня я скачал библиотеку RF24, адаптированную к RP2040, и перенес написанный ранее код на RP2040-Zero.
Работает.
Можно начинать писать классы радиоинтерфейса для обеих сторон.
Я недавно писал, что нашел хороший исходник для работы с EEPROM микросхемами AT24C16.
Оказалось, что он выгодно отличается от «доступных аналогов» тем, что работает очень быстро. Как говорится, «самая быстрая запись в EEPROM на Диком Западе». 🙂
Это потому, что в этом коде есть интересная изюминка. Микросхемы эти обрабатывают запросы на запись/чтение довольно медленно. Микроконтроллер должен ждать окончания предыдущей операции прежде чем отправлять в микруху новый запрос. В 99% примеров кода, доступных в сети, народ тупо лепит задержку на пару миллисекунд. Но в этом коде нет никаких задержек, зато там есть это:
static void at24cxx_wait(int i2c_address)
{
int resault = 0;
do
{
Wire.beginTransmission(i2c_address);
resault = Wire.endTransmission();
} while (resault != 0);
}Это, оказывается, позволяет избежать излишнего ожидания и приступать к следующей операции в ту же самую долю микросекунды, когда микросхема EEPROM готова принять очередной запрос. В результате запись происходит очень быстро. Минимум на порядок быстрее, чем вариант с задержками.
2048 байт (полная емкость) пишутся за 231 мс.
Я тут внезапно осознал, что:
Засунул на макетку микросхему AT24C16 (см. рис. 1).
Она подключается к микроконтроллеру по интерфейсу I2C. Объем памяти — 16 кбит, т.е. 2 килобайта. Это в 2 раза больше, чем встроенный EEPROM на Arduino nano.
Имею сказать, что адресация памяти внутри этой микросхемы нифига не интуитивна. Поскольку там 2048 байт, для их адресации надо 11 бит, т.е. два байта. Я думал, что сначала в эту микруху отправляется 2-байтовый адрес, а она в ответ пришлёт байт, расположенный по этому адресу. А 3 «адресных» ноги на корпусе позволяют задать любой I2C адрес из диапазона 0x50-0x57.
Фигвам. Недостающие старшие 3 бита адреса контрабандой стырены с выводов 1-2-3 микросхемы. То есть эти самые выводы ни к чему не подключены и ни на что не влияют. Вместо этого микросхема отзывается на ВСЕ адреса из диапазона 0x50-0x57. Соответственно, по каждому из этих I2C адресов доступно 256 байт EEPROM памяти. То есть логически эта микросхема выглядит как 8 штук 256-байтных микросхем, сидящих на адресах 0x50-0x57 (с 8-битной внутренней адресацией внутри каждой «микросхемы», естественно). Огонь вообще.
Я очень удивился.
Но в результате разобрался. Сначала «на коленке» написал свою версию кода для чтения-записи, чтобы убедиться, что я логику правильно понял. А потом наткнулся на вполне пристойную реализацию программного интерфейса к этой микросхеме: https://programmersought.com/article/598311367038/
Возьму эту реализацию за основу и сделаю для неё интерфейсный класс-обёртку, который будет скрывать всю эту удивительную логику адресации, а заодно будет оптимизировать запись данных.
Сегодня запаял контактные гребенки в плату и проверил работу OLED дисплея с RP2040. В результате убедился, что:
Wire на Wire1, либо сделать адаптацию библиотеки для RP2040-Zero (не хочу делать ни то, ни другое).В общем, вопрос с подключением дисплея и использованием библиотеки GyverOLED на RP2040-Zero закрыт.
И видос: