Зажёг панель от магнитолы

[0617]

Решил познакомиться с Arduino, в качестве первого задания выбрал работу с панелькой от магнитолы PANASONIC CQ-DFX683N. Саму магнитолу у меня украли много лет назад, а панелька дождалась своего звёздного часа.
Вложение 44417

Нагуглилась сервисная инструкция на магнитолу, разборка подтвердила, что дисплеем управляет чип 75854. Для связи чипа c процессором головы используется протокол CCB Вложение 44418, формат пакетов описан в документации на 75854 Вложение 44419. На панель подаётся два напряжения питания +5В и +9..10В. По линии +5В измеренное потребление составляет 6мА при передаче данных и 0,2мА при отображении (режимы энергосбережения не изучал); по линии +9В - 60..65мА в зависимости от отображаемой информации

Первым делом подпаялся к контактам разъёма панели - для этого идеально подошёл 14-жильный шлейф с IDC-разъёмом [шлейф с IDC-разъёмом.
Вложение 44421
Собрал в кучу панель, ардуино и два преобразователя напряжения, обмотав всё клубком проводов.

Нашёл проект, из которого взял схему подключения к пинам ардуины и основу программы, хотя в итоге от программы осталось мало чего, ибо формат пакетов совершенно другой.

Микросхема 75854 умеет отображать на дисплее до 164 сегментов и считывать состояние 30 (или около того) кнопок. Некоторые выводы могут быть задействованы как для управления сегментами, так и для кнопок - это выясняется путём анализа схемы из сервисного манула на панель.
Сообщение представляет собой битовую маску длиной 32 байта, логически разделённую на 4 блока. В начале каждого блока передаётся адрес чипа (всегда 0x42 для вывода на дисплей и 0x43 для считывания кнопок), в конце - номер блока (0, 1, 2, 3). В первом блоке передаётся состояние 44 битов управления сегментами и набор управляющих битов, в остальных блоках - по 40 сегментов. Неиспользуемые биты должны быть обнулены. Набор управляющих битов описан в LC75854E.pdf.
В итоге, всё что нужно сделать - дёрнуть парой ног ардуины, отправить первый блок данных, опять дёрнуть ногами, отправить второй блок и т.д.. Отправка данных сопровождается “тактированием” сигналом CL. LC75854E.pdf рекомендует укладываться в 30 мс на отправку всех данных (256 битов), т.е., грубо говоря, период “тактового” импульса должен быть в пределах 100 мкс . На практике я пробовал задавать длину импульса (половина периода) от 1 (минимально возможное значение для delayMicroseconds()) до 500 мкс - всё работает стабильно; при значениях больше 300 становится заметно последовательное прорисовывание сегментов на дисплее.

Сам дисплей состоит из 8 знакомест по 13 сегментов, т.е. на него можно вывести не только цифры, но и страшненькие буквы, и множества служебных знаков. Первый вариант скетча просто зажигал все сегменты, следующий зажигал их последовательно, группами и т.д. В результате через пару часов я получил таблицу в Excel, в которой были прописаны 8*13 сегментов. Никакой системы в нумерации сегментов нет - почти случайный порядок. В дальнейшей по этой таблице составлял маски для отображения символов.
Вложение 44422

Итого, скетч на ардуино считывает из последовательного порта 32 байта и отправляет их в панель. Программ на PC формирует эти самые 32 байта и отправляет в порт. Вся логика реализована на PC (знакогенератор, формирование битовых масок, прокрутка текста и проч).

Следующие задачи:
- попробовать использовать не аналоговые пины ардуины, а цифровые;
- перенести знакогенератор в ардуино и научить её самостоятельно прокручивать текст (нужен простейший управляющий протокол);
- считать состояние кнопок;
- научить ардуину прикидываться HID-клавиатурой;
- …
- купить нормальную магнитолу, научиться не только писать на дисплей, но и считывать с него, написать “всеобъемлющую универсальную программу с неограниченными возможностями” (с) и вывести информацию с дисплея магнитолы на экран андроид-устройства.

Никакой практической пользы от этого не ожидаю, за исключением научиться и разобраться.

В процессе имел тяжёлый опыт с Visual Studio Community: примеры работы с последовательным портом не работали никак от слова вообще. Ни в C++, ни в VB. Потом наткнулся на блог одного инженера, который подтвердил, что MS-реализация работы с COM-портом - одна из худших. При этом processing и putty работали совершенно нормально. В итоге остановился на Lazarus.