Твик управления деки VILMA 204-STEREO [2022]

[persey.a]

Сначала хотелось-бы увидеть привод всего этого в "наколенном" исполнении.

Когда-то в самодельном ЛПМ планировал сделать привод азимута. Большая каретка могла тягать подвешенный снизу электропривод. Но проект был похоронен с приходом CD, а теперь остатки пылятся на шкафу.

Здравствуйте, кошмаром для самодельщика считаю начатые и брошенные на разных стадиях проекты. Сколько потрачено материалов сил и самое главное невосполнимого времени жизни, а результат так и не удалось увидеть. С грустью смотрю на фото.В своих самоделках всегда рассчитывал свои силы, чтобы довести до финала, поэтому чего то брошенного практически нет, все в действии. Сейчас с большой осторожностью отношусь к их апгрейду, т.к. можно все работающее развалить, а собрать снова не получится - могут быть всякие непредвиденные жизненные обстоятельства, где будет не до хобби. С Уважением.

[Liv]

кошмаром для самодельщика считаю начатые и брошенные на разных стадиях проекты. Сколько потрачено материалов сил и самое главное невосполнимого времени жизни, а результат так и не удалось увидеть.

Целью радиолюбительства является получение удовольствия от процесса, а не готовое изделие. Если интерес к проекту пропадает, радиолюбитель обязан немедленно такой проект бросить и не мучится с его завершением. Про это я когда-то писал в своем ЖЖ: https://leoniv.livejournal.com/324019.html

[rickw]

кошмаром для самодельщика считаю начатые и брошенные на разных стадиях проекты

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

[Wladimir_TS]

с большой долей вероятности вы подложили ему приличную свинью

А каковы предложения и решения - если деталь нужна ? Учитывая что жилищные и финансовые возможности не позволяют иметь свой станок, а деталь нужна раз в год ?

Или это как-то оформлялось через кассу предприятия?

Во первых с одним человеком никто разговаривать за 1 деталь не будет - той-же бЮстгалтерии на это надо выпустить 100500 бумажек, конструкторам, технологам (технологическая карта, технологический маршрут, заказ материала, карты отклонения для ОТК). Что выливается в 1000-3000% накладных расходов. Я видел, сколько у нас на предприятии стоит выточить 1 винт, размерности М4х30 со ступенчатым участком.... более 1000 рублей за штуку....

Но с другой стороны, на Youtube куча роликов от самодеьлщиков, делают все на свете. Такое впечатление, что самодельщиков стало в разы больше.

Как посмотришь - у этих самодельшиков - чистая мастерская - как будто он там работает первый месяц, новенький инструмент, станков стоит НОВЫХ (хоть и китайских) на неприличную сумму... А делает он какую-нибудь фигню, которая толком не работает, зато качество съемки. Что-то мне кажется это сынки богатых родителей дурью маяться....Ибо - блоггер нынче профессия уважаемая.

А то первый отдел

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

Дальновидные руководители негласно поощряли творчество

Это была редкость, обычно любая инициатива подавлялась и подавляется. Работать надо не что-б сделать быстро-качественно, а строго по инструкции, распорядку и распоряжениям.

[Liv]

А каковы предложения и решения - если деталь нужна ?

Драматизм ситуации заключается в том, что решения нет. Но Вы ту немного лукавите. Что зачит "деталь нужна"? Все, что нужно для жизни, продается в магазинах. А эта деталь - лишь Ваш каприз, без которого можно прекрасно прожить, не доставляя неприятностей другим людям.

А делает он какую-нибудь фигню

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

[persey.a]

Wladimir_TS, Все точно так, кроме того, что первый отдел у нас отвечал за все, не было подразделения, а когда показал между делом начальнику свой собственноручно сделанный генератор НЧ, получил молчаливое согласие пользоваться приборами (осциллограф, В3-38) для настройки своих плат после работы. С Уважением.

[persey.a]

Все, что нужно для жизни, продается в магазинах. А эта деталь - лишь Ваш каприз, без которого можно прекрасно прожить, не доставляя неприятностей другим людям.

Ну да, все самодельщики и есть капризные дети, которым всегда всего не хватает, доставляющие неприятности своим родителям...

Целью радиолюбительства является получение удовольствия от процесса, а не готовое изделие. Если интерес к проекту пропадает, радиолюбитель обязан немедленно такой проект бросить и не мучится с его завершением. Про это я когда-то писал в своем ЖЖ:

Думается в таком виде изначально была не верно поставлена целесообразность проекта как такового...С Уважением.

[Wladimir_TS]

Все, что нужно для жизни, продается в магазинах.

Не все - кое что уже не продается (потому как старое) , что-то еще не продается - слишком новое и з/ч не завезли, что-то продается, но за морем-окиЯном и как его добыть, особенно в эпоху, до широкой интернет торговли, что-то дифицитЪ, а что-то плод инженерного воображения для модернизации вполне бытового, но не вполне прямыми руками разработанного и сделанного.

А эта деталь - лишь Ваш каприз, без которого можно прекрасно прожить, не доставляя неприятностей другим людям.

Здесь вообще возникнет и следующий философский вопрос - а зачем вообще жить и переводить небесконечные ресурсы общества и планеты баз какого-либо смысла ?

для настройки своих плат после работы

На многих предприятиях задержка более 15 минут после окончания рабочего дня приравнивается к опозданию на работу. Так еще и вопросы от 1го отдела будут - а не копировали-ли вы чего секретного, когда коллеги не видят.

[persey.a]

Помню для задержки свыше 1 часа требовалась СЗ. Я имел по крайней мере 55минут. Хватило чтобы предварительно настроить блоки Лексиных не за один присест (а первый блок который там же настраивал был ПК Сухова). Комплексную настройку деки делал дома, к этому времени уже купил в Москве С1-94 в магазине Олимп, а милливольтметр Боровика сделал сам, настроил по В3-38. До сих пор пользуюсь. С Уважением.

[Wladimir_TS]

У нас более 15 минут. А потом лаборатории центрально обесточивались. Оставалось только освещение верхнее а в розетках - ноль.

Я уже не говорю о проходной - причем их 2 - сначала металлодетектор + 2 "архаровца" с ручными, через него в рабочей одежде проходишь в раздевалку, а потом второй пост - уже в своей одежде на улицу ... схемы вноса-вынос были - но сложные.

[Pyku_He_oTTyda]

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

[Wladimir_TS]

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

[Pyku_He_oTTyda]

А две проходных как то способствовали наличию "правильной" кассеты?

[DrLithium]

Заказал несколько дисплеев, пока скидки на али.
Самыми интересным по геометрии попался 1.9" ER-TFTM019-1-SPI 170x320, габариты 62x29 мм, рабочая область 42.72x22.695 мм. Окно в аппарате на просвет - 53x26 мм. С ужасом думаю, что придётся ещё и библиотеки перетаскивать, времени жалко. Но не думаю что возникнут серьёзные вопросы.

По библиотеке БПХ(FTH): перетащить удалось, но пока нормально не работает, данные врут, но меняются. Надо тратить время и сравнивать результаты преобразования данных на каждом шаге и лечить по месту.

По ПпП (поиск по паузам): проще вывести разъём и уже на обратную сторону (от индикатора) добавить очередную "дочку" на которой... помимо усилителя, с выхода УВ добавляется приглушение для 'Cue'. Сигнал 'Mute' формируется в КР(А) согласно состоянию, хотя и сигнал приглушения для 'Cue' по хорошему надо отдавать ему то же. Но тогда бы пришлось тащить управляющий сигнал с КР(А) к выходу УВ, что в итоге не очень удобно. Т.о. прямо с разъёма платы УВ забираем ЛК+ПК и ведём на "дочку". Там реле возвращает обратно на разъём, но в режиме 'Cue' возвращает через делитель. В совсем правильном варианте, если делать аппарат с нуля, то делитель нужно ставить дальше, т.е. непосредственно на выходе разъёма и перед входом усилителя для наушников. Усилитель на ОУ готовит сигнал обоих каналов для АЦП. По ситуации, данные можно брать с одного канала, с обоих каналов или смешивать, тупо забирая то, что больше по амплитуде.

По 74HC165: решил что обязательно надо, т.к. нужна универсальность для сторонних проектов. Определил разъём для дополнительного подключения "расширителей входов", для случая когда в аппарате много кнопок и желательно сохранить функционал.

По 74HC595: так же определил разъём для дополнительного подключения "расширителей вЫходов".

Думаю по пять "вагончиков" в двух составах будет достаточно. Итого, функция за раз будет собирать биты с 40 входов и выплёвывать биты на 40 выходов, да же в отсутствии дополнительных "вагонов". Т.е. для минимально присутствующих "вагонов", актуальные данные движутся без проблем. Для отсутствующих "вагонов": во входных переменных будет "воздух" из отсутствующих 165-х, а "воздух" из выходных переменных будет наполнять отсутствующие 595-е. Если будет нужно больше, то расширить не будет проблемой. Кажись тормозов быть не должно, да и исполнять часто не нужно, для графических дисплеев раз 30 в секунду, ну и + по ситуации.

Т.е. сейчас параллельно идёт: разработка схемы, платы и её геометрия (нужно добиться приемлемой универсальности для разных дисплеев), правка библиотеки БПХ. По приходу дисплеев, тесты работоспособности и перетаскивание библиотек под ассемблер. А пока не пришли, ДИ для восьмёрок + сбор геометрии и определение универсального подключения "дочки" под дисплеи.

По "слоёному пирогу" ПУ(А): база с кнопками, к ней 'Arduino Nano' и две дочки.

[411i6470r]

....не записанные очередным "деятелем рунета" на своем магнитофоне с японской свалки от китайского генератора, а по всем правилам.

это. как я понял, в мой адрес написано ? ну да, я продаю кассеты 3000/3150 записаные с китайского генератора и на японском (заметьте - кварцованном!) магнитофоне. Сразу чтобы не было недосказанностей - я заявляю, что мои кассеты ТОЛЬКО для настройки скорости протяжки лпм, и данные кассеты - не предназначены для контроля и настройки коэффициента детонации, уровня записи, азимутов, и ачх . Но данные кассеты отлично подходят для контроля и настройки скорости лпм - это железно .
а для настройки вышеуказанных параметров - требуются кассеты , записанные в других (лабораторных) условиях, и на совершенно другом оборудовании, и соответственно, имеют другой ценник - примерно десяти-кратный от моего .

С ув.

[rickw]

Пара замечаний из моего опыта.

Заказал несколько дисплеев, пока скидки на али.

Перед тем, как использовать дисплей, особенно цветной, проверьте, насколько он нагружает контроллер. Тормозящий дисплей это плохо, но еще хуже медленная реакция на кнопки или пропуск других важных событий. Обновление дисплея должно крутиться на прерывании (в идеале DMA, если есть, и если есть свободный канал), и у прерывания должен быть низкий приоритет. События должны обрабатываться в первую очередь, а дисплей обновляться в фоновом режиме.

74HC165: решил что обязательно надо

Для входов лучше использовать микросхемы, генерирующие прерывания по изменению уровня на входе. Например, что-то из серии MCP230хх. Иначе придется постоянно опрашивать эти расширители в цикле, что опять же, и контроллер загрузит, и время реакции увеличит.
Для выходов 74HC595 нормально, но я бы тоже предпочел на одну I2C повесить несколько MCP23016/017, позволяющих программно переключить вход на выход при необходимости.

[DrLithium]

Тормозящий дисплей это плохо, но еще хуже медленная реакция на кнопки или пропуск других важных событий. Обновление дисплея должно крутиться на прерывании (в идеале DMA, если есть, и если есть свободный канал), и у прерывания должен быть низкий приоритет.

Спс, я в курсе. DMA в Mega? Не слышал. Вроде в XMega есть, но тут жирно. А надо мной смеялись, что я в 2313 запихнуть всё это не могу. Дисплеи буду сажать на SPI. Кнопки можно опрашивать раз 10 в секунду (хотел на PCINT, на прямых пинов стало жалко), дисплей обновлять раз 30. Пока такие планы, что будет на практике - загадывать не берусь, рано ещё и море других вопросов есть.

Иначе придется постоянно опрашивать эти расширители в цикле, что опять же, и контроллер загрузит, и время реакции увеличит.

Это не сильно грузит, да и ещё можно сделать не каждый раз, т.е. по флагу и многое от одного таймера. У нас вопрос места (по геометрии) и дефицит выводов, что б сделать идеально. Задача стоит сделать так, что бы работало просто хорошо. При этом думаю, что приём и отправку организую параллельно, т.с. за раз.
Время реакции? Самое быстрое у нас - импульсы в перемотках, успеваем - под это дело отданы INT-ы. А другое дело, что есть много чего и это надо организовать между собой. Выбор МС продиктован доступностью, ценой, простотой и надёжностью. Опять же шину TWI постоянно опрашивать не есть хорошо. А будут косяки - будет работа над ошибками.

Да, можно что-то сделать лучше и на другом железе, но тут и сейчас основная идея показать, что можно реализовать и как это заставить работать в сумме. Вопрос отсутствия тормозов в чём-либо - важный, бесспорно. Пока не знаю чего ждать от железа, но OLED по TWI мне точно не понравился. Альтернатива есть хорошо, ни когда не против. Решения можно сюда выкладывать, кому-то будет полезно.

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

[rickw]

Кнопки можно опрашивать раз 10 в секунду (хотел на PCINT, на прямых пинов стало жалко), дисплей обновлять раз 30.

Я изначально кнопки опрашивал в цикле и столкнулся с тем, что на перемотке, когда дисплей активно обновляется, кнопки не всегда срабатывают. Особенно при коротких нажатиях. Раздражает жутко. Пришлось менять Мегу 128 на 1284 и все кнопки переводить на PCINT.

OLED по TWI мне точно не понравился

не понравился чем именно?

шину TWI постоянно опрашивать не есть хорошо.

вот для этого и нужно прерывание по изменению состояния пина, посмотрите серию MCP230xx, если раньше не применяли. Они есть на восемь портов и на шестнадцать. И даже под SPI, хотя я их не пробовал, I2C прекрасно работают. На одну шину можно восемь микросхем подключить.

Выбор МС продиктован доступностью, ценой, простотой и надёжностью.

вот пора уже от этих мег уходить в сторону STM32 в более-менее серьезных применениях, где не просто ногодрыг нужен. Цена младших STM даже меньше старших Мег, а возможностей гораздо больше.
Я сильно не уверен, что цветной дисплей нормально на Меге заработает, но проверьте, может ошибаюсь. Я подключал к STM32 по DMA.

[DrLithium]

...кнопки не всегда срабатывают

Тут надо было идеологию проги менять.

не понравился чем именно?

Частота обновления слишком маленькая.

посмотрите серию MCP230xx

Кжись, Леонид про них говорил чуть выше. Тут мне жутко не нравиться превращение двух проводной шины, в трёх проводную. Как решение оправдано, но мне в данном случае лишний провод жалко тратить, а сдвиговых регистров тут достаточно, при этом есть общие сигналы. По идеи можно определить частоту регенерации экрана для ДИ СДИ или ЖК, и по факту наступления события для обновления, тупо добавить ещё и обслуживание 595-х и 165-х. Т.е. та же регенерация, только чуть дольше и ни каких НЕ срабатываний кнопок, быть не должно.

вот пора уже от этих мег уходить в сторону STM32 в более-менее серьезных применениях, где не просто ногодрыг нужен. Цена младших STM даже меньше старших Мег, а возможностей гораздо больше.

Давно пора, только закостенелость мешает. Трудно от старого и наработанного годами, при этом рабочего и ещё не исчерпавшее свой ресурс, отказаться полностью. И особенно когда нашёл решения (собираемые годами) косяков софта и девайсов, а теперь снова надо хромать на новой платформе, что б достичь того же. А то, что уже дешевле, это все знают, на али пасёмся косяками.

Я сильно не уверен, что цветной дисплей нормально на Меге заработает, но проверьте, может ошибаюсь. Я подключал к STM32 по DMA.

Видосов в сети хватает. И да, проверим что да как...

[rickw]

надо было идеологию проги менять.

проще на прерывания повесить и забыть о проблеме.

Частота обновления слишком маленькая.

Да, было такое на Меге. Пришлось частоту шины до 800кГц увеличить. Проблемы с изображением начинались ближе к 1МГц, остановился на 800. Плюс двойной буфер изображения - пока один отрисовывается, второй выводится на экран.
Кстати, на выходных подключил этот же дисплей на SH1106 к STM32F091(была Nucleo плата с этим контроллером). Особо не заморачивался, запустил на HAL через прерывания, чтобы потом можно было легко на другой контроллер перенести. Простой тест - в основном цикле инкрементируется переменная, обновляется буфер изображения, далее в прерывании он выводится на экран, после завершения обновления экрана снова +1 к переменной и т.д. Итог - около 60 обновлений экрана в секунду.

Трудно от старого и наработанного годами, при этом рабочего и ещё не исчерпавшее свой ресурс, отказаться полностью.

не надо от него отказываться. Для простых применений Меги и Тиньки вполне хорошие контроллеры. На работе, кстати, в последней разработке несложного устройства перебрали кучу восьмибиток от китайских до экзотики, и в итоге остановились на Attiny826

[DrLithium]

проще на прерывания повесить и забыть о проблеме.

Это когда есть такая возможность, то конечно. А в текущем проекте у меня PCINT остался только для энкодера. Отдал бы и его на входы 165-й, но там чисто геометрически не получится, энкодер стоит на "дочке" с индикатором.

Итог - около 60 обновлений экрана в секунду.

Здорово!

[rickw]

Это когда есть такая возможность

а напомните, какой у вас контроллер?

[DrLithium]

AtMega328P

[rickw]

AtMega328P

так у нее же PCINT на каждом порту.
Флеша, кстати, хватит для графики? Шрифты достаточно много места занимают.

[DrLithium]

так у нее же PCINT на каждом порту.

Да. Но всё отдано под периферию и лишнего не то что б нет, а есть дефицит. Т.ч. от прямого использования пинов пришлось отказаться.
USART, TWI, SPI, 595+165, INT0+INT1, Энкодер, ИК ДУ, Поиск по паузам ADC6+ADC7 + 1 пин управление приглушением. И всё, ноги закончились. А все лишние отдал на дисплеи. Т.к. разные типы подключения, где-то за счёт 595-х, где-то SPI. А если что-то будет ещё воткнуть снаружи, то свободные на разъём прямо на "дочке".

Флеша, кстати, хватит для графики? Шрифты достаточно много места занимают.

Чисто программной памяти тут 32К. Знать бы ещё сколько на это уйдёт. Главное запустить, а красоту навести и попозже можно. Ну а если упрёмся, то на другой платформе можно за идеал взяться и лучше вообще с нуля, т.е. с БП и СВП...

[rickw]

Знать бы ещё сколько на это уйдёт.

У меня ушло около 64к, но там несколько шрифтов, и все на С. У вас на асме должно компактнее быть.

[DrLithium]

Пришла часть деталюшек, быстрее чем ожидал. А пока ждал доставки, без дела не сидел.

Вроде бы вышел на +/- универсальный вариант ПУ(А) и то не с первого раза.
Дочерние платки под индикаторы делал и переделывал. Если место остаётся, то думаю отдавать под СДИ (PLAY, FF, REW, REC, PAUSE, REV). Т.к. буду ставить SMD СДИ, то делаю дочернюю платку чисто под СДИ, а то медь платы находится с другой стороны и сверлить лишние отверстия под излучение в нужную сторону как-то нет желания. Уже и так получается, что под CA56-11 предусмотрены сквозные отверстия под индикацию ":". Т.е. СДИ в самом CA56-11 нет, а если подсветить дополнительно, то как бы получить что нужно можно. Это на вырост, или часы или RTC счётчик. В этом дисплее суть такая, нужно что б горели ":", сам поставь пару SMD СДИ под дисплей и зажигай когда нужно.

Времени много уходит на поиск правдивой информации по дисплеям. Есть отличия в реализации, есть/нет толерантности к TTL сигналам, есть подсветка +3.3/5В, ну и есть риск тупо спалить от +5В.

Делаю, управление подсветкой от ШИМ (при наличии оной), расширение 595-х и 165-х разъёмами. Энкодер ставлю на плату дисплея как и ИК датчик.

Отдельно думаю над решением проблемы получения импульсов от подкассетников. Это будет позже, но тестовое железо получено и будут эксперименты. Суть проблемы в том, что бы хватило скорости работы датчиков в перемотках. При этом, на самой плате ПУ(А), разведен вариант на компараторах Леонида, а оптика снаружи. Если новое решение выгорит, то формировать импульсы дополнительно не придётся, хотя и не помешает.

На плате ПУ(А) ставлю джамперы для ОА/ОК и/или +5/+3.3В.

Довольно сложным было вместить дисплей на 36 ног CA56-11 + СДИ режимов + для ДИ, убил 5 дней и тонну перемычек. Тут всё, что бы сделать на ЛУТ. Заказ двухсторонних ПП лучше решит геометрию по разъёмам (надо в две стороны). Желательно обкатать все косяки предварительно, дав при этом возможность остаться на ЛУТ, при отсутствии возможности заказа ПП на стороне.

Далее развёл для 1.77" 160x128 и то не окончательно, т.к. пока без СДИ режимов и думаю это исправить.

В процессе:
SPI 1.77 TFT ST7735S 160x128 + СДИ,
128X64 OLED 1.3 Mono 7Pin SPI SH1106 + СДИ.
На очереди:
LCD 1602 BLUE - не очень лезет по габаритам, но для реализации самый простой,
BQ-N515RD 12-и пиновый, для ДИ + СДИ,
ER-TFTM019-1-SPI - этот по габаритам как родной в окошке, надеюсь с ним всё получится.

Планирую добить геометрию для дисплеев и если косяков не выплывет, то буду потихоньку переходить к железу. Один косяк уже отловил и перекроил базу ПУ. Малая кровь в виртуальном пространстве радует!

[DrLithium]

Пришлось пересмотреть геометрию из-за разной высоты для плат индикаторов, над платой ПУ(А).

Для дисплеев, которые не влезают в окошко:
Энкодер и ИК датчик теперь живут на своей плате, на своей высоте и со своей жёсткостью крепления: разъём 6 пин + два винта через проставки в стойки. Платы индикаторов без разводки энкодера и ИК датчика, теперь сидят чисто на контактах (3+3+6 пин).

Для дисплеев, которые влезают в окошко:
Нет смысла разделять платы индикатора и энкодера + ИК датчика, т.к. они на одной высоте.

Если плата индикатора сидит на разъёмах PLS+PBS стандартной высоты, а сам индикатор помещается в окошке, то плата чуть упирается в рамку окошка индикатора. Подпиливаю высоту разъёмов с 11 до 10 мм.

Проверил размер дисплея на 1.77"... отличается от документа продавца. Перерисовал. Прикинул где и во что он упирается. В окошко естественно не лезет (дисплей 1.3" так же по высоте, 1602 по ширине), а пластик отламывать не хочется. Будет утоплен глубже, из далека это не будет большой проблемой. Конкретно для этого дисплея придётся отказаться от разъёмов и сажать плату чисто на более короткие перемычки, из-за глубины.

Если индикатор не занимает всё видимое поле в окне, то свободное место дополняю индикацией режимов на СДИ. Кусочек ПП д.б. чуть выше дисплея и попадать в рамку окна.

Бутерброд разрастается по этажности, но кажется это не большая проблема, главное что бы геометрически можно было вписать. Снова пришлось перерисовывать плату ПУ(А), позже править платы дисплеев, но теперь тут уже меньше работы, правка схемы + трата времени на поиск инф-ции. Кажется что-то приемлемое стало получаться.

Нужно решить вопрос по регулировке яркости дисплеев, а именно, номиналы деталей фильтра ШИМ для +3.3В. Естественно придётся брать схему Леонида от его счётчика, она чуть отличается от той, что использована в КР(А) для скорости подмотки/перемотки. Помимо ОК/ОА, надо в режиме ОА добавить регулировку для 3.3В вольтовой подсветки. Диапазон свечения начинается где-то от 2.5В и желательно бы растянуть этот коридор на весь диапазон ШИМ-а или тупо пошире. Хотя это не очень важно, просто рабочие значения могут стать менее острыми. Надеюсь кто-то озадачится и набросает. Пока что, для ПП и схемы взял из 'rev9' и добавил выбор +3.3В/5В для ОА, через джампер.

В процессе...

[alias]

Планирую добить геометрию для дисплеев

Может быть вопрос немного не в тему, но если у кого-то есть доступный дисплей OLED 0.69"(ноль шестьдесят девять дюймов) 96х16 I2C, то интересует реальный размер окна/поля(в мм) на котором выводится информация. Есть интерес его применить для индикации счетчика ленты.

А в качестве центрального процессора деки не применить ли Blue Pill?

А о какой из этих "пилюлей" речь идет? STM32F103C6T6 или другой?

[DrLithium]

Вроде получается развести мамку с дочками. Т.с. черновой вариант есть. Сколько впереди пере/доделок загадывать не буду, надеюсь не много. Изменил контакты для дочек и не пожалел. Все варианты развелись и вопрос только в том, что бы влезло (геометрия - ширина, высота, глубина). Не всё будет влезать - это ясно, но работать заставить всё же надо. Нужно тупо запустить все дисплеи кроме 7-сегментных (эти не сложно), но впереди ещё уточнение согласования по логическим уровням. Везде по разному. Все говорят, что обязательно надо ставить 4050, 245, 0108, но как не странно у всех поголовно или на проводках и питание 3.3В, или тупо через резисторы от 220 до 10К. Даже резистивных делителей видно мало. Да и дисплеи (одни и те же) с разными платами, есть толерантные к 5В, есть и только на 3.3В. Пока что, это не особо важно, т.к. дочек позже можно перекроить. А пока займусь мамкой, ПП, ЛУТ, прошивка. Первыми заставлю работать кнопочки и USART.

[rickw]

впереди ещё уточнение согласования по логическим уровням.

Несколько лет назад прикручивал к Веге OLED 128x64 на SH1106. Для теста взял ардуиновскую библиотеку. Да, запустилось на 5В и работало. Но при попытке перевести все на прерывания и получить максимальную скорость - не взлетело. Проверил шину осциллографом, всех деталей уже не помню, но была какая-то проблема с ACK. Посмотрел код в библиотеке - а эти чудики просто передавали данные по I2C, делали приличную задержку после каждого переданного байта, чтобы дисплей его успел переварить, и игнорили ACK как таковой.
Посмотрите даташит на драйвер дисплея. Если там питание 3,3В, то уровень шины должен быть такой же.

[DrLithium]

Посмотрите даташит на драйвер дисплея.

Вся проблема в том, что даташит на дисплей и плата к которой он прилеплен есть два разных девайса. Если плата минимальная, то обычно 3.3 и редко терпимость к есть 5В (обычно для I²C). Если плата жирная, то там и питание и преобразователь логических уровней стоит. Вопрос в том что попадётся и за какую цену. Ну и даташиты... тут такой бардак, что или нужной инф-ции нет или приходится собирать данные по крупинкам. Китайский производитель, в плане документации, почему-то частенько не утруждает себя поступать по канонам. Т.ч. практика в каждом конкретном случае и чужой опыт детекции граблей.

Посмотрел код в библиотеке - а эти чудики просто передавали данные по I2C, делали приличную задержку после каждого переданного байта, чтобы дисплей его успел переварить, и игнорили ACK как таковой.

Во! О чём я и говорил. "Умников" в высокоуровневых языках развелось до жути много и каждый в своей библиотеке норовит задержки вставить. А подумать о том, что с ними будет делать потребитель этого "шедевра", если таких либ несколько, не в состоянии. Хотя... и в низком уровне наверное то же есть такие, но там литературы реально больше, по именно работе протоколов. Уже как-то писал, что в ардуине, в либе по USART, какая-то команда в разных версиях работала-не работала, на силу выкрутился и больше желания туда лезть без причины нет. Адекватную либу найти сложнее, по этому лучше напишу/перепишу на ассемблере/СИ и сам буду рулить сразу всем и вставлять задержки только туда где это можно, нужно и модно!

З.Ы. Брею схему и ПП на предмет подписей и номеров деталей. После перейду к проверке дорожек и как вдарю утюгом по лазерной печати!

[DrLithium]

Что б не скучали:

Тут не запаян один транзистор, позже подвезут. Один разъём стянул, что б можно было проще зацепиться. 23 перемычки, если не обсчитался, это ради одного слоя для ЛУТ. Компаратор для импульсов по Леониду. 165 и 595 на одной шине, да и функция отправки и получения, общая. Дочки будут позже.

А пока набрасываю минимальный код и пытаюсь запуститься...

[DrLithium]

Функции 165-х и 595-х пришлось разводить отдельно. Вся фишка в том, что сигнал защёлки у них работает по разному. Если в 595-х заталкивать данные надо при низком уровне, а разрешать появиться соответственно при высоком, то у 165-х чтение данных происходит при высоком уровне. Прям хоть инвертор ставь. Думаю переделывать ни чего не стоит, а просто вызывать "свою" функцию по надобности. Но было бы красиво за один цикл выдавать и забирать... В любом случае ни на что не влияет, просто код будет чуть иной. Чтение 165-х по флагу взведённому таймером ну очень редко, для антидребезга, раз в 0.1-0.3 секунды. А отправка в 595-е по надобности - регенерация дисплея или того что там дальше подключено.

Для отправки в пять 595-х (40 ножек) нужно 737 тактов, для чтения из 165-х (40 ножек) - 579. Что не дорого и разъёмы расширения стоят - просто подключи своё и добавь свой код.

Чуть поправил код СВП, это что бы в Протеусе не мешал гонять данные по шине. Формирую посылку по шине TWI от ПУ к КР. Вспоминаю, что за чем должно идти в посылке и какой ответ д.б. получен, для реакции на него.

З.Ы. Пришлось текст доставать из дневника и по новой править. Время правки истекло в 6:35 утра и набранное было потеряно... недальновидненько движок форума написан, могли бы дать возможность отката к набранному.

[DrLithium]

Только-только удалось передать по 'TWI' команду 'Play'...

Потратил много лишнего времени на поиск причины "почему не работает". Сначала грешил на свою криворукость, потом на чужую, потом снова на свою... За тем после n-ой проверки по кругу стал грешить на индекс 'PB' (обычно 'P') в названии модели МК. Попробовал из другого проекта вытащить классическую '328P' и проверить так ли это - результат не изменился. Снова начал грешил на свою криворукость притяжение, вероятно усилилось, а я и не заметил.

С горя достал DiSco и запил... ил сканирование шины (это не водка такая, а старинный USB-осциллограф со спектроанализатором, с самописцем и с лог. анализатором). Давно не пользовался с лог-анализом и забыл, что есть удобная функция и как именно ей заставить ловить события по триггеру. Ловил сигнал в ручную, а буфер данных мизерный.

Подумал, что надо проверить чужим софтом. Заливал ардуиновский 'I²C-сканер', тот увидел на шине... ни кого. Подозрения на кривое железо усилились. Хотя м.б. старый пример после обновлений среды не хочет работать нормально или надо было ещё что-то указать дополнительно, но я не понял как и где. Т.ч. крест на железе не ставлю...

Решил добавить вывод кодов по USART-у для большей читабельности событий. Засунул общий вывод кодов, прямо в заголовок прерывания 'TWI', типа один для всех. Поймал в терминале код шины 0x00 - "автобус сломался"...

Менял частоту шины в настройках анализатора и настройках программы. Поймал подтверждение коду шины 0x00 в анализаторе - 'Старт' и тут же 'Стоп'. Снова стал грешить на бракованную партию МК...

Поменял провод на короткий. Не помогло.

Решил добавить вывод кодов по USART-у не в заголовок прерывания TWI, а по местам в 'Case' разбора кодов шины, а в заголовке убрать лишний текст...

И вдруг в терминале код шины стал отличаться от 0x00, появились коды 0x08 0x20 и ещё раз 0x20 (дубль? один из общего, другой по месту? а где дубль для 0x08?). Так, уже что-то... Далее, ещё лучше. Прилетела минимальная ответка от подчинённого мастеру. Тут уже понял, что минимум (1 байт) и равный нулю (массив затирается нулями) это уже условие последнего байта для передачи, т.ч. это жжж не спроста! А это значит что... Не было снова сброшено в ноль смещение по массиву, отправляемых мастеру данных, после их добавления в массив! Нашёл где вставить сброс. Т.ч. теперь надо будет позже перезалить исправленную версию 0.3 КР(А)... Почему в Протеусе это не было проблемой и работало исправно, не ясно, может где-то что-то исправлял и не проверил полностью.

Итого. Как я понял, после условия 'Старт' мешал лишний текст выходящийся в USART. Т.е. после условия 'Старт' надо не мешкая обеспечить выдачу адреса в регистр отправки, что бы автомат начал формировать сигнал на шине. Хоть и было 50кГц, но видимо лишнего для вывода по USART-у, было много и эта задержка мешала. При этом анализатор, из-за короткого буфера (либо долго и на низкой частоте, либо на высокой, но мало по времени), не показывал важную информацию, тупо пропускал её или показывал только не рабочие моменты. Когда поднатыкался в фэйсе оболочки анализатора, то смог таки стабильно ловить по фронту первого импульса пакет данных. Удалось на высокой частоте разглядеть, что адрес уходит и всего лишь нет 'ASK'-а на него. Снова подцепив на коротком проводе подчинённого (отключал/подключал периодически), ответ вдруг был получен, а далее дело техники. Две проблемы наложились одна на другую. Но что-то мешало ещё, не очень понятно, т.к. срабатывать было должно да же с ошибкой в коде на возврат данных. Получается лёгкая криворукость, отсутствие везения, прочие непонятки, а всё работало... Поправил и можно играться.

З.Ы. Попробовал на длинном проводе, аж 288см, частота 50кГц - сработало... Поднял до 100кГц - сработало... Поднял до 400кГц - сработало... Поднял до 800кГц - не сработало... Поменял провод на короткий, 66см - сработало. Длинный это два сваренных вместе мышиных хвоста из старого проекта, со сменёнными колодками с 5 пинов на 4-е!

[DrLithium]

Добавочка.
Пересчитал регистр TWBR и соответственно полученные частоты:

TWBR ________________ F_CPU _________ F_SCL
255 * 2 = 510 + 16 = 526 16000000 / 526 = 30418.25095
152 * 2 = 304 + 16 = 320 16000000 / 320 = 50000
072 * 2 = 144 + 16 = 160 16000000 / 160 = 100000
012 * 2 = 024 + 16 = 040 16000000 / 040 = 400000
011 * 2 = 022 + 16 = 038 16000000 / 038 = 421052.6316
010 * 2 = 020 + 16 = 036 16000000 / 036 = 444444.4444
009 * 2 = 018 + 16 = 034 16000000 / 034 = 470588.2353
008 * 2 = 016 + 16 = 032 16000000 / 032 = 500000
007 * 2 = 014 + 16 = 030 16000000 / 030 = 533333.3333
006 * 2 = 012 + 16 = 028 16000000 / 028 = 571428.5714
005 * 2 = 010 + 16 = 026 16000000 / 026 = 615384.6154
004 * 2 = 008 + 16 = 024 16000000 / 024 = 666666.6667
003 * 2 = 006 + 16 = 022 16000000 / 022 = 727272.7273
002 * 2 = 004 + 16 = 020 16000000 / 020 = 800000
001 * 2 = 002 + 16 = 018 16000000 / 018 = 888888.8889
000 * 2 = 000 + 16 = 016 16000000 / 016 = 1000000

Поскольку дискретность частот определяется одним байтом, то нет смысла указывать в настройках частоты отличные от F_SCL. Так же этот принцип касается и USART-а, 961600 бод или 1000000 бод - по сути одно значение, т.к. будет отброшено дробное при пересчёте и помещении в регистр настроек.

В настроечных регистрах 'TWI' ещё есть делитель на 1,4,16 и 64, но это вряд ли пригодится.

Практика, искал потолок по частоте:
На длинном проводе 288см (подтяжка на двух ВС857С) - работает на 666КГц, на 727КГц не хочет.
На коротком проводе 66см (подтяжка та же) - работает на 727КГц, на 800КГц не хочет.

Т.е. вывод такой, что значение частоты 'SCL' в 100КГц д.б. достаточно по скорости, надёжно для данных и эта частота поддерживается разными устройствами. Ставлю это значение по умолчанию. Но, если на шину будет подключено устройство на 400КГц, то переопределив значение TWBR программно на время сеанса, реально ускорить передачу данных, а после вернуть частоту обратно.

Подтяжка на двух ВС857С+4резистора+диод или на двух резисторах по 4К7, наверное д.б. приблизительно одинакова. Оставил сложную подтяжку. Если её не распаивать на плате ПУ(А), то на плате КР(А) нужно будет джамперами подключить к шине резисторы подтяжки, по 4K7.

Забыл добавить, что проблема удержания 'SCL' отсутствует в железе и дополнительным сигналом держать шину не нужно. Т.е. получается, что просто функцию не реализовали в протоколе в самом Протеусе, что и ожидалось.

[rickw]

стал грешить на индекс 'PB' (обычно 'P') в названии модели МК.

это новые контроллеры от Микрочипа, немножко модифицированные. Добавили пару портов, убрали одну землю и питание. Если новые порты не переключать на выход, то проблем не будет. ID тоже поменялся, если используется avrdude, он его проверяет по умолчанию, нужно либо отключать проверку, либо использовать новую версию, поддерживающую РВ.

после условия 'Старт' надо не мешкая обеспечить выдачу адреса в регистр отправки

эээ, вы как передачу организовали? Я делал так:
подготовили массив того, что нужно передать;
передали старт;
после старта вываливаемся в прерывание twi,
в прерывании через switch в зависимости от статуса шины выгружаем адрес и все байты из массива по очереди;
в конце там же в прерывании передали Стоп.
В зависимости от статуса там же обрабатываем исключения.
Выполняется все очень быстро и автоматически без всякого вмешательства из основного цикла - после передачи байта уходим в прерывание, там же быстро загружаем очередной байт, и идем заниматься своими делами пока он передается.
То же самое и с UART. Как только байт передали, падаем в прерывание USART0_TX и загружаем следующий.

[DrLithium]

ID тоже поменялся,

Спасибо, я давно в курсе нового камня.

эээ, вы как передачу организовали?

Приблизительно так же, то же на прерываниях и без ожидания готовности шины, но у меня ответ данных не готов заранее. По этому приходится придерживать 'SCL' готовить данные, класть в массив, отпускать линию и отдавать по одному после 'Рестарта'.

[rickw]

ответ данных не готов заранее

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

[DrLithium]

в смысле не готовы данные, которые нужно передавать?

Ответ формируется из возможности и исправности. М.б. условие когда ответ будет отрицательным против желаемого. Например, послали 'Play', а мы после отправки данных получили потерю арбитража и в массиве ответа остались нули после затирки. Не ясно случился ли 'Play', но это уже не важно, т.к. перебивка могла быть только в критической ситуации типа "потеря исправного питания". Или ЛПМ по какой либо причине не смог выполнить и остался в 'Stop', возможно кассета не установлена. Или у него тупо нет в карте такого сочетания, например перевести из 'REC' в 'REW'. ЛПМ сформирует состояние, скорость и направление (не помню в каком порядке), прямое или реверсивное. Т.о. ответ зависит от результата исполнения.

Не знаю, насколько это хорошая идея удерживать шину.

Самая, что ни на есть, прекрасная! Это фишка протокола весьма востребована и позволяет за один сеанс закончить двунаправленную транзакцию, при этом не мешая другим. Но это надо учесть, в этом ещё и аппаратная часть помогает. 'Старт' или 'Рестарт' не должен формироваться пока идут данные других девайсов. Но даже, если перебили с ответом (в момент 'Рестарта'), то это можно отыграть и по кодам состояний и принять решение на доп.запрос ответа. Но у меня проще, перебивки не случится, только в свободное окно. Это определено приоритетами адресов.

Тем более, если к ней будет несколько устройств подключено.

Именно по этому. Только мастер на шине начинает сеанс и он решает к кому и когда. Исключение - СуперВизор Питания, но у него свои тараканы и это отдельная история.

Почему нельзя отпустить, подготовить данные, и затем передать старт/адрес?

Не определено время ожидания ответа. Оно м.б. каждый раз разное и подчинённое устройство само решает на сколько надо придержать линию 'SCL' и когда уже начать давать ответные данные. Если начинать отдельный сеанс для ответа, то... а вдруг устройство с ответом ещё не готово ответить, глюкнуло или погорело? Получим ответ поздно или будем молотить повторами или останемся в непонятках... А в текущем случае подождали сколько было надо и не больше, получили точно готовый ответ и свалили освободив шину.

[rickw]

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

Atmega и I2C соединение само по себе не очень устойчивое, а такая комбинация, я думаю, будет очень интересной в отладке. А еще ведь нужно индикатор успевать выгружать, чтобы провалов не было во время перемотки. Есть чем шину записывать, хотя бы десяток байт?

[DrLithium]

Atmega и I2C соединение само по себе не очень устойчивое, а такая комбинация, я думаю, будет очень интересной в отладке.

Я бы так не сказал. Нормальный протокол, а ЭЛТ теликах была такая шина довольно часто и что бы кто-то жаловался на то, что у него звук по вине шины не регулируется, такого вроде не было.

А еще ведь нужно индикатор успевать выгружать, чтобы провалов не было во время перемотки.

Одно другому точно не помешает - в TWI прерывания короткие. Да кода много, но это Switch-Case.

Есть чем шину записывать, хотя бы десяток байт?

Есть старый копеечный "DiSco". И делал ещё сам на базе всё того же Arduino Nano, типа шилд + прошивка. Буфер на 200 смен состояний. Пока хватало. Ну и опять же если что, то Протеус показывает I²C-отладчиком.

[rickw]

Нормальный протокол, а ЭЛТ теликах была такая шина довольно часто и что бы кто-то жаловался на то, что у него звук по вине шины не регулируется, такого вроде не было.

я не о протоколе. Просто при отладке i2c в Атмегах почему-то на порядок больше проблем возникает, чем, например, у STM32. Вплоть до каких-то зависаний шины по абсолютно непонятной причине. Может это только у меня так сложилось.

[DrLithium]

Просто при отладке i2c в Атмегах почему-то на порядок больше проблем возникает, чем, например, у STM32.

Я так понимаю, что ноги растут из средств отладки. В AVR Studio, Atmel Studio и возможно далее, тупо не реализована поддержка. Народу приходится в железе убиваться и в стороннем ПО. Т.е. то, что можно было бы отладить на коленке, приходится искать тяжёлой артиллерией. А что там внутрях творится, остаётся загадкой. Элементарные проблемы обсуждают на форумах годами, а вызвано тупо ленью разрабов.

Как-то давненько пытался в из USI в tiny2313 сделать TWI, дак тупо не было реакции и в чём была проблема так и не понял. Апноты не помогают, софт не делает того, что должно случиться. Искал, что кто-то заставил работать... не нашёл. Вроде на изиэлектрониксе было, но теперь уже нет времени поднимать проект...

Сейчас наступил на грабли, вернулся с Протеуса 8.15 на 8.7 SP3, а до 8.15 был 8.9. Приходится перерисовывать проект. Проблема такая, добавил данные из EEPROM и получаю постоянные не лечибельные вылеты, даже после отката изменений. В 8.7 работает... Мода пошла, не исправлять баги, типа и так схавают... Пичаль. Может надо ехать морды бить? ))

[rickw]

Я так понимаю, что ноги растут из средств отладки. В AVR Studio, Atmel Studio и возможно далее, тупо не реализована поддержка.

есть там отладка, вопрос в том, насколько она удобная. Если совсем уж контроллер мелкий и некуда подключиться, можно и там посмотреть, или в том же протеусе попробовать просимулировать. Мне удобнее UART подключить и выводить интересующие меня данные с живого контроллера.

[DrLithium]

есть там отладка, вопрос в том, насколько она удобная.

Правда? А у меня ни в одной Studio, аппаратный TWI не делал ни чего! Регистры не шевелятся. Работал с TWI в Протеусе, но и в нём SCL не удерживается. Да и ещё в Протеусе для ассемблера переменные не кажет, но это малая проблема.

Мне удобнее UART подключить и выводить интересующие меня данные с живого контроллера.

Это да, СДИ поджечь или сообщение по USART-у - спасает, но менее удобно.

Вот и приходится чуть там, чуть тут и в итоге что-то да получится. Только помнить надо о всех нюансах. Забыл как цеплять EEPROM в Протеусе, нагуглил, а потом увидел что у меня уже есть конвертер *.eep в *.bin'. В Studio то же не просто. То, что должно работать штатно, почему-то из версии в версию перетекает как работа через костыли.

[rickw]

А у меня ни в одной Studio, аппаратный TWI не делал ни чего! Регистры не шевелятся. Работал с TWI в Протеусе, но и в нём SCL не удерживается.

TWI это только осциллограф на реальном железе.
Запустить его не проблема. А вот если оно периодически начинает виснуть или делать не то что нужно, то никакой симулятор тут не поможет.

[DrLithium]

TWI это только осциллограф на реальном железе.
Запустить его не проблема. А вот если оно периодически начинает виснуть или делать не то что нужно, то никакой симулятор тут не поможет.

Как это не странно, но благодаря и анализатору и симулятору, в данном случае Протеусу, понял что происходит в разных проблемах...

Ситуация следующая: в Протеусе работает, в железе слегка, но что-то не так, т.е. есть проблемы.

Сначала оказался флаг 'ASK' перед формированием 'Stop'. Тут смыл не в том, что б не отвечать на пустой байт когда он получен, а подготовится к следующему приёму от мастера (СВП) адреса для нас как для подчинённого. Иначе реакции на вызов не будет и он пройдёт не замеченным, т.к. мы не ответим. Надо будет переопределить этот момент, где и когда снова взводить этот флаг. Оказалось, что этот флаг как раз влияет на завершение сеанса, т.к. 'Stop' тупо не формируется и подчинённый бесконечно гонит "воздух" мастеру. Тут помог анализатор.

Затем благодаря анализатору стало видно, что в ответ на заявленный режим приходит предыдущее состояние ЛПМ, а не текущее свежеизменнённое. Сначала не обратил внимания, но после понял, что удержания шины нет, как планировалось. Чуть ранее писал, что в железе удержание работает, но позже понял, что не так как хотелось бы. Удержание линии 'SCL' дополнительным пином пока не делал, надо всё тщательно проверить в чисто аппаратной реализации. Т.е. реакция на команду есть, а ответ не правильный, т.к. из массива ответа данные отправлялись сразу без обновления, т.е. старые.

Изменил код, не стал сбрасывать флаг 'TWINT' в прерывании и получи задержку в исполнении не прилично большую + глюк самого исполнения команды + неверный код нового режима и проблемы далее...

Вот тут Протеус и показал, что если выйти за пределы кода прерывания не сбросив флаг 'TWINT', а основной код исполнения команды как раз и живёт вне прерывания, т.к. там задержки для тех же электромагнитов, то прерывание 'TWI' происходит снова. Т.е. всё, что нужно сделать, да же при удержании 'SCL' средствами только аппаратной реализации, д.б. засунуто в код прерывания. Думаю так определено разрабами, но почему - не знаю. Возможно, удержание 'SCL' и необходимость сидеть в пределах кода прерывания, это какое-то тяжёлое наследие навязанное рамками ограничений времён разработки.

Тут вижу выход такой же как и планировал, запасной вариант! Придётся, хотя ни как не хотел, использовать дополнительный пин для удержания 'SCL' + сбрасывать флаг 'TWINT' в самом прерывании + запуск в оборот аппарата TWI так же в самом прерывании! А в целом благо, что в КР(А) есть свободная ножка и не далеко, одна перемычка и готово.

З.Ы. Только, что припаял и проверил. Только теперь, после 'Play' начал нормально срабатывать 'Stop' и обратно. Вчера не знал куда надо что б решить, а за сегодня удалось. Осталось решить с 'ASK'-ом, что бы ПУ(А) отзывался как подчинённый и проверить это в Протеусе.

З.З.Ы. Протеус 8.7 SP3 падлюка, валится как не в себя. Позже попробую переставить, но код исполняет хорошо. Пишут, что русские литеры мешают в путях, но у себя не нашёл ни в одном...

Добавлю картинку для интересу:

[DrLithium]

Сижу балуюсь почти трёх метровым проводным пультом, функции плеера+ работают.

Бился с самым сложным - Cueing для 1/3 от скорости перемотки и 1/6. Ошибок было сделано много, т.к. трудно за всем уследить, что именно в разные места прописать. В итоге, больше половины функций сделаны и они работают.

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

А ещё далее, 7-и сегментный дисплей и плата датчиков для счётчика.

[DrLithium]

Добил основной костяк функционала. Естественно пока без доп. кода и дочерних плат не все функции работают полностью, но реагирование заложено и два мозга нормально дружат.

Повторил всю карту ЛПМ.
По Cueing-e: удалось нормально реализовать реакцию на удержание кнопки, при переходе из 1/3 в 1/6 скорости и при отпускании возврат из 1/6 в 1/3.
Добавил в фильтр кнопок реакцию только на нажатие, что бы исключить срабатывание во время отпускания нескольких нажатых кнопок.
Специально с дребезгом не боролся, но проблем в этом плане пока ни каких не замечено.
По скорости: добавил переключение скорости по нажатию трёх кнопок, для разных режимом чуть отличаются. Если добавить ещё 165-ю и подключить кнопки + прописать в фильтре, то скоростью можно будет управлять однократным нажатием персональными кнопками. Скоростей можно (при слегка изменённой ответной реакции) переправить на больше чем две. А тут не портим пластику фейса аппарата.
По реверсу: один оставшийся вывод на 165-й отдал под реверс и прописал реакцию.
По поиску по паузам: в перемотках уже можно увеличивать счётчик повторным нажатием в ту же сторону и уменьшать в противоположную. Остаётся только обеспечить детекцию пауз и изменение значения счётчика. При достижении нуля счётчика, можно будет реагировать, переходить в 'Stop' или 'Play'.
По кнопке на панели: используется как и стоп, но и дополнительно участвует в трёх кнопочных командах (смена скорости в разных режимах).
Индикации пока ни какой, вообще, но место в коде уже определено. По факту успешного исполнения режима будет добавлена реакция индикаторов. По USART-у выводятся сообщения.

В КР(А) пришлось чуть внести изменения в прошивку. Плата чуть изменена, добавлена одна перемычка - удержание 'SCL'. Старая версия 0.3 так же позволяет поставить перемычку, но чуть под углом.

В КР(А) я использовал около 50% программной памяти. Тут в ПУ(А) уже 24%, без ещё кучи запланированного кода. То что задумано, суммарно вряд ли поместится в один камушек. Или другая модель или другая платформа. А пока укладываемся...

Протеус 8.7 SP3 удалось заставить корректно работать без вылетов (за редким исключением). Оказалось, что часть файлов надо было класть по другому пути, в скрытую папку "ProgramData" или при установке менять путь на одинаковый, тогда все файлы в "кучу", в одну папку.

На очереди платы датчиков, дисплей, автостоп, счёт и т.д...