Вариант Б КР - полное совпадение.
Вариант А КР - не полное, нужны будут доработки. Что именно и зачем уже становиться ясно.
Сигнал импульсов автостопа и сброса автоотключения с регулятора становятся больше не нужны. Становиться нужен электронный счётчик, а его надо кормить "отборными" импульсами, ни каких левых и не во время, да ещё и нужного направления! Контроль автостопа теперь в МК, как и автоматического отключения. В итоге провод освобождается - "АО" 5 пин регулятора. Меняем направление провода и можно управлять скоростью 4,76/9,53, естественно после доработки самого регулятора (заняться этим раньше не успел). В КМ теперь укорачивается цепочка: пин 4 - пин 8. От коллектора V11(T9) до нижнего R40 перемычка, с выбрасывание лишних деталей.
Чуть выше описал несколько моментов. Рекомендую придерживаться варианта именно с двумя МК в разных местах. Один тупо/интеллектуально обслуживает ЛПМ, второй панель... третий ЖК-панель, четвёртый тест ленты, пятый раздаёт коррекцию, шестой следит за питанием и т.д. Далее, расширение функционала наращиваем частично добавлением в существующие МК или если это сложная задача, то отдельным модулем. Удобство в приоритете!devel писал(а): ↑14 дек 2022, 23:43Мое предложение было выделить этот МК из ПУ, сохранив штатный ПУ, а МК разместить рядом с МК на КР. Т.е. на КР - два МК: один собственно КР, другой "кнопки-лампочки". И тут здравая мысль - заменить два МК одним ибо зачем тогда два МК на одной плате, общающиеся между собой по TWI =) Но тогда больше лапши тащить к новому КР от доработок ЛПМ, и в целом, получается хуже в плане дальнейшего развития. Зато одной мегой можно обойтись, и сохранить всё кроме КР в девственном виде.
Сделав на одном МК получим клубок из паутины в котором сами же и запутаемся, не один день взвешивал что и как лучше. Придётся вешать расширители портов и гонять их по всему аппарату а-ля TWI. Не ставить же 2560 и получить в итоге TEAC Z7000? Я же наоборот придерживаюсь концепции: меньше проводов между блоками при дешёвых МК, способных покрыть все хотелки. Кроме того, если затолкать огромную кучу хотелок в один МК, можно просто попасть на: 1 - нехватку ресурсов по прерываниям, 2 - конфликты которые тяжело будет отыскать (искать можно месяцами), 3 - сложный для понимания и для отладки код.
А сейчас стоимость МК позволяет облегчить себе жизнь + делать блоки по своему законченному функционалу куда проще и надёжнее. Иначе расширение функционала для одного МК станет проклятьем, а не удовольствием. Тот же тест ленты добавить в этот же один флакон, станет неподъёмным делом, а вот отдельно - будет не сложно. Дать возможность выбора пользователю из энного кол-ва дисплеев и то задача не из простых: дать поддержку регенерации, электрическую совместимость, ОА/ОК, инициализацию + контроль выведенных данных и т.п. для каждого типа дисплея м.б. своё. Идея с центральным управляющим и даже не одним подчинённым, а несколькими мне нравиться больше, т.к. смотрю на это со стороны разработчика, а не потребителя.
Сохранить всё в девственном виде идя на огромную переделку функционала, трудно, иногда не возможно - придётся от чего-то нового отказываться. Да и за чем её сохранять когда сама просится? Вряд ли кто-то скажет: "- Да ты что? Как же так было можно? Вандал!"
З.Ы. Да и от варианта Б я не отказывался. Посмотрим во что его можно будет превратить и где во что-то упрёмся.
Намного проще и удобнее охватить взглядом все вместе и увидеть противоречия или нестыковки, чем прочитать и представить в уме.
Вопрос в том как будет удобнее. Можно на дом вызвать "мастера на все руки" или отдельно "сантехника", отдельно "электрика". Зачем себя ограничивать? Время потраченное на перетыкивание разъёма из одной дырки в другую не очень велико. Думаю вопрос в том как разделена программа. Если в одном флаконе, то один порт USART на всё. Если как я предлагаю делить на два, то будет проще разделить соответственно.
