Комментарии 82
Люди в мире общаются на разных языках - это позволяет людям «понимать» друг друга и работать вместе, создавая общую систему. Например, в Европе диалоги между людьми происходят преимущественно на немецком, французском, английском, или итальянском языках. Ниже рассмотрим их все по очереди, приведя по 5 слов из каждого, и заодно оценим их достоинства и недостатки..
"Протокол SPI — это синхронный серийный интерфейс"
Так протокол или интерфейс? ))
IDC - прямо подумал, что пропустил что-то, а речь про I²C.
За год у автора 180 статей и 30 комментариев))
I Dva C.
не верно - и в квадрате с.
ИИС=И2С, ниже цитата:
I2C (Inter-Integrated Circuit; pronounced as “eye-squared-see” or “eye-two-see”)
Автор и жрец, и жнец, и на дуде игрец. Сегодня у него аппаратная часть, вчера - JS, позавчера - Dart...
I²C вообще-то должно произноситься как "ай скуэрд си". Извините за столь ужасную транскрипцию.
Основные отличия не в этом.
SPI требует отдельные линии для CS (ChipSelect) что не удобно если чипов много. Для сокращения количества линий используют I2C, по двум проводам можно подключить 127 устройств. Используется обычно для настройки. А SPI особенно в многобитных режимах для скоростной передачи большого количества данных. Контроль ошибок организуется вручную.
UART очень простой и поддерживается почти всем. Контроль ошибок примитивный бит четности, так что обычно тоже делают ручной контроль целостности. Имеет разные реализации RS232 и режимы передачи с контролем передачи и без, полудуплексный и двухсторонний, диф пара RS485 (half duplex; диф пара может передавать данные на несколько километров) или токовая петля, IRDA, KLine и т.п. И тоже есть сигнал положить линию break, что бы если мультимастер можно было всех призаткнуть. Не говоря уже о тьме протоколов, помимо текстовых, modbus rtu, profibus, obd2, mdb, ccnet, ...
CAN изначально задумывался как шина для подключения сенсоров. Вы просто вешаете на линию еще один датчик и он периодически вещает свои показания. В зависимости от его адреса у него разный приоритет и тип кадров. И кадр данных до 8байт и сразу с контролем целостности. И бортовой компьютер сразу может использовать его показания. Как правило организуется аппаратно. Но на практике люди почему-то упорно пытаются его использовать как транспортную шину для передачи потока данных, изобретая велосипеды.
Кстати есть еще замечательный длинный "сдвиговый регистр" JTAG с уймой возможностей.
ps: I2C = IIC читается и-два-цэ. IDC
Чем дешево и просто соединить микроконтроллеры звездой с длиной проводов до 20 метров? Хочу сделать в квартире проводные выключатели-кнопки для света. В кнопке помимо сухого контакта, еще нужна лгбт подсветка, поэтому без микроконтроллера в каждой кнопке никак.
Modbus и i2c работает с задержками, CAN кажется слишком сложным.
По витой паре все кнопки будут соединяться с центральным WT32-eth01.
Дешево и просто использовать зигби и не делать себе мозг. Если уж прям кабель хочется и скорости, то Ethernet, а, теперь скорости не очень хочется? Тогда банального modbus rtu хватит за глаза (в обычной жизни никому 60 событий в секунду выжимать из выключателя не надо, хочется плавной анимации света? Задавай скорость и цвет к которому стремимся например раз в 1/4 секунды. И этого будет достаточно что бы обмануть глаза). Хотя не совсем ясно зачем лгбт подсветка, но хозяин барин. Я сейчас лично смотрю на выключатели с экраном, да, это еще более упорото, но зато как эффектно…
Про модбас вот что пишут. Задержки на реакцию до половины секунды. Или это обычный, не rtu?
"Решили наступить на те же грабли? Ну не подходит Modbus под управление светом по своим характеристикам. При этом многие все равно пробуют — на столе же все прекрасно работает, а потом плачут. Причина проста — поллинг.
Вам нужно опрашивать каждый выключатель с периодичностью хотя бы в 100мс или быстрее, чтобы обеспечить приемлемое время реакции на нажатия. Больше устройств на шине — больше данных, которые нужно передать и обработать в каждом цикле опроса. И уже начиная с десятка устройств на шине надежной работы контроллера Modbus при таком периоде опроса вы не добьетесь и придется это время увеличивать, что выльется в тормознутость.
Modbus годится только для медленной инженерки с периодом опроса не менее 0,5с — датчиков температуры, управление отоплением, поливами, насосами и т.д. И то нужно быть осторожным с временем реакции, например при защите насосов."
ZigBee - это же ретрофитная технология, когда не было возможности или денег тянуть провода? Она у меня будет там где не важно, что отвалится. В текущей архитектуре у меня она зависит от HA и zigbee2mqtt. Любой из этих сервисов падает - и свет не включается. А хочется, чтобы такая базовая функция зависела максимум от одного надежного микроконтроллера. Можно помудохаться и спарить ZigBee устройства напрямую, но нужен тогда ZigBee модуль реле на 60 штук, не знаю как такой сделать.
Задержки на реакцию до половины секунды
Это искусственное ограничение с учетом характера протокола: для датчика температуры полсекунды вполне норм. Но не фактическое быстродействие: если даже написать весь код на python на контролере и то не такая жуткая задержка должна получиться, нужно же передать десяток байт всего, а modbus это обычный UART на физике RS485. Точно так же работает протокол DMX-512 который управляет как раз светильниками: так там их несколько десятков и обновление данных происходит на частотах в десятки пакетов в секунду. Т.е. вопрос архитектуры.
Не обязательно использовать форматы modbus, можно можно гонять байты в своем формате поверх RS-485, но придется решать вопрос кто ведомый, а кто ведущий, или применять т.н. мультимастеринг - и получиться нечто напоминающее CAN.
CAN по сути борется с периодическими запросами на уровне своей архитектуры, там не обязательно запрашивать состояние, выключатель сам рапортует об изменениях и "добивается" чтоб его "хоть кто-то" услышал. При этом это тот же последовательный интерфейс, по структуре пакетов не так уж отличающийся от modbus, только физика адаптирована для многостороннего обмена и разрешения коллизий. Ну и аппаратура CAN по сути делает все сама, по стандарту.
С беспроводкой - история та же. Либо вопрос-ответ, либо - кто во что горазд. Существуют десятки, если не сотни беспроводных интерфейсов , в которых помимо физики отличаются формат передаваемых пакетов. Но история такая же - есть общая среда передачи данных (канала как бы один), одновременно все передавать не могут (точнее -могут, но будет коллизия). В случае zigbee мы по сути имеем черный ящик и там все сделано "само", остается надеяться что по уму.
Вот вечно путают интерфейс с протоколом. Отсюда и проблемы. Какие "полсекунды" у модбаса? Это еще смотря в что завернуть. В промышленности вполне используется модбас на разных типах интерфейсов и задержки не превышают сотых долей секунды. Не, если руки настолько из одного места растут, то можно завернуть модбас через LoRa и иметь "пинги" длительностью в минуты и часы, не спорю. Но это все полная чушь, на самом деле. Для начала стоит ознакомиться хотя бы с парочкой уровней OSI.
вот подробнее:
https://home-matic.ru/2019/11/rs-485-modbus-v-umnom-dome/
Я не эксперт, полагаю вся проблема модбаса в том, что сенсор не может сам послать сообщение центральному контроллеру, ему надо ждать, когда его опросят.
Пойду скажу нашим контроллерам что они слишком медленно обрабатывают ввод/вывод на модбас.. (нет)
rs-485
и rs-422, если нужен full-duplex
RS-485, like RS-422, can be made full-duplex by using four wires. Since RS-485 is a multi-point specification, however, this is not necessary or desirable in many cases. RS-485 and RS-422 can interoperate with certain restrictions.
Это удобно для соединения точка-точка, с инфраструктурой же это скорее усложение
Идеально как раз CAN 1мбит можно 40м, там диф пара. В применении он не сложный, т.к. реализован аппаратно. По прерыванию просто забираете телеграмму с данными (до 8 байт) в которой информация о событии. Более приоритетным устройства просто с ставите меньший адрес. Остальные повторяют если их прервали. При этом можно насильно попинать каждого отдельно или всех вместе пнуть. Более того можно обнаруживать кз и обрыв линии. Берёте какой-нибудь esp32-с3 и алга. Как бонус можно беспроводное соединение прикрутить.
ps: всё работает с задержками, для этого при проектировании надо это учесть заранее, что бы уложиться в имеющиеся ограничения.
CAN звездой не делают, там нужна незамкнутая петля и обязательны терминаторы. Плюс, свои грабли имеются, которых нет в более простых протоколах.
Те же самые проблемы и с RS485 будут. Но если очень хочется, то ни кто не помешает и звездой сделать. Терминаторы ставят что бы на больших скоростях передачи данных отраженные и стоячие волны не мешали. Но если снизить скорость передачи то вполне работает.
если снизить скорость передачи то вполне работает.
и
Идеально как раз CAN 1мбит можно 40м, там диф пара.
взаимоисключающие параграфы.
Вполне реально 1мбит на 40м. Но если у вас более длинная линия то и скорость придётся снижать. Я же говорил что обычно перед тем как делать записывают хотелки и делают расчеты того что можно получить и от этого пляшут.
ps: Минимальную скорость реакции тоже можно оценить по размеру кадра и частоте шины:
Вполне реально 1мбит на 40м. Но если у вас более длинная линия то и скорость придётся снижать. Я же говорил что обычно перед тем как делать записывают хотелки и делают расчеты того что можно получить и от этого пляшут.
Да знаю я все эти таблички наизусть. Вы просто сами то одно пишете, то другое, и что можно без терминаторов на концах линии со звездой, и что 1 Мбит на 40 метров запускать. Тут либо одно, либо другое. Вместе - не будет. Хотя CAN в лабораторных условиях заводили и вовсе без терминаторов, и даже по такой километровой линии что-то удавалось передавать, но это вариант не для продакшена, любой чих (наводки, неидеальность проводимости линии, трансиверы разных моделей итп) и всё, bus-off.
трансиверы разных моделей
Это да некоторые железяки для контрольной суммы не делали nrz, а другие делали в результате для "везучих" пакетов ack распологался в разном месте и такой пакет никогда не доходил. По поводу помех, у нас вообще оптика использовалась, что бы помех было поменьше.
Это да некоторые железяки для контрольной суммы не делали nrz, а другие делали в результате для "везучих" пакетов ack распологался в разном месте и такой пакет никогда не доходил.
Ок, просто отмечу, что это функция контроллера, трансивер ничего про контрольные суммы не знает, его задача - напряжения и крутизна фронта.
По поводу помех, у нас вообще оптика использовалась, что бы помех было поменьше.
Конвертеры среды волокно-CAN видел, но CAN по оптике - это как?
Rs485
Можете ещё на DALI посмотреть.
Заводские устройства выходят в копеечку, но там очень простая аппаратная реализация и уже всё "из коробки" заточено на управление светом.
Спасибо, что мне не пришлось писать об этом.
Сделав акцент на том, что в SPI мастер генерирует клок и поэтому задает темп обмена, как можно было следом рассказывая о I²C/TWI умолчать, что тут слейвы могут навязывать шине свою, более низкую скорость обмена, удерживая SCL?
CAN — это многоузловой, серийный коммуникационный протокол, который позволяет множеству устройств (нод) на автобусе общаться друг с другом без необходимости главного управляющего устройства.
Это фиаско. Никогда еще Штирлиц не был так близок к провалу. Спасибо за статью о серийных автобусах. Впрочем, как это вы забыли упомянуть об Универсальном Серийном Автобусе?
Все хорошо (проилистал по диагонали), но последняя таблица поставила под ворос "валидность" всей остальной статьи.
Особенно "хорошо" получился uart (потому как написание в таблице идет в разрез даже с тем что написано в статье)
Хотя и остальное тоже. Есть подозрения что вся статья сгенерирована нейросетью, а потом вычитана. Уж больно это сильно похоже на классические "галюцинации"
Открываю даташит на рядовой STM32 и вижу великолепие разных "протоколов": SMBus ,PMBus , USART , OSPI, LIN , ISO7816 , IrDA , SAI, SPDIFRX, MDIO, USB , TT-CAN, CANFD ...
Редкий специалист знает их все. Идет бесконтрольный рост "протоколов" .
Так что автора понять можно. Легче забыть об этом.
По статье ощущение, что автор не работал ни с одним из них.
Это в каком "рядовом" STM32 есть CANFD?
А зачем специалисту знать их все? Есть задача, посмотрели как её лучше решать на том железе, которое доступно, выбрали интерфейсы, и погнали делать. А будет это UART, I2C, SPI, CAN или ещё что-то - специалисту пофиг, если он специалист.
занятное суждение, но чую я некий изъян. если выбирать не зная, то можно и не учесть какие то моменты, которые потом больно всплывут.
Так нужно же почитать, посмотреть что пишут на форумах, попробовать на макетке, если есть возможность. На то и специалист, чтоб принимать решения, последствия которых скажутся через несколько месяцев.
Я уж не говорю о том, что сейчас решения иногда принимаются не исходя из лучшего, а потому что "у нас вот это уже есть, а вот то ждать 25 недель" и "это не разрешено для применения, а вот то разрешено".
UART
Десятки метров (зависит от скорости)
Не нужно путать UART и RS-232, это два разных физических интерфейса.
Ну и могли бы дополнить, что UART/RS-232 используется только между двумя устройствами. Конечно, из него можно сделать кольцевую сеть, но у нее есть свои недостатки.
И странный выбор интерфейсов, SPI I2C UART которые используются для близкой передачи и довольно специфичный CAN который используется для дальней передачи данных и требует дополнительную микросхему интерфейса.
485/422 вполне нормально поддержывают множэственность устройств, на томжэ самом уарте
Но тут речь про UART, а не про RS-232/422/485.
да неужэли?
уарту микроконтроллера без разницы на какую физическую линию работать
Разница огромная, это разные физические интерфейсы. UART не потянет линию которая рассчитана на RS-232, и тем более RS-422/485 которая к тому же симметричная. Мало того, они по электрическим уровням отличаются, и подключив RS-232 напрямую в UART порт контроллера просто выйдет из строя.
Смешались в кучу кони, люди...
UART не потянет линию которая рассчитана на RS-232, и тем более RS-422/485 которая к тому же симметричная.
здрасте. приехали.
Контроллеров с физическим интерфейсом RS-232/422/485 на сколько помнится не существует. Чтобы подключить контроллер на RS-*** интерфейс по сути вы подключаете преобразователь уровней с логических уровней UART контроллера в логические уровни RS-***.
Еще раз перечитайте на какое сообщение я отвечал:
уарту микроконтроллера без разницы на какую физическую линию работать
Не нужно путать UART и RS-232, это два разных физических интерфейса.
UART не является ни физическим ни интерфейсом.
Строго говоря, не суще... Нет, не так.
Стандарт TIA/EIA-232 описывает физические параметры интерфейса RS-232. Но правил передачи - протокола - в нём нет. В TIA/EIA-232 не описывается сколько бит должно быть в символе, какими могут быть битрейты, сколько должно быть стоп-битов и как воспринимать ситуацию, когда они отсутствуют.
С другой стороны, никакого единого стандарта UART не существует. Есть, скажем так, традиция, поддерживаемая отдельными производителями чипов и разработчиками ПО.
Традиционно, в символе UART от 5 до 8 бит и 1/1,5/2 стоп-бита. Но, например, мост MCP2221 поддерживает только 8-битные символы и 1 стоп-бит. А мост XR21V1410 поддерживает 7-, 8- и... 9-битные символы! Потому, что они исполтзуются в UART-подобном протоколе MDB.
Ну а что. Автору что интерфейс что протокол - все едино.
Да уж. Обделался конкретно. Вместо гпт чата сделал перевод в Гугле с английского. И поехали ноды на автобусе.
Да уж. Обделался конкретно. Вместо гпт чата сделал перевод в Гугле с английского. И поехали ноды на автобусе. Плюс тому кто первый заметил.
одно только "взаимодействия в микроконтроллерах" чего стоит. как минимум "взаимодействия применяемых в микроконтроллерах"
Вы хоть читайте, что постите, а то в CANе устройства висят на автобусе. Bus в английском - это не только автобус, но и шина...
Пользуясь случаем, спрошу: делаю блинкерное табло на шести матрицах, каждая 28x24 точки. Позади каждой матрицы управляющая ей Arduino Nano, плюс ещё одна ESP32 где крутится веб-сервер, принимающий команды и отсылающий списки изменённых пикселей на шесть Nano. Табло в длину почти два метра. Какой интерфейс лучше использовать для передачи данных ESP32->Arduino? На первый взгляд пиксели обновляются небыстро, электромагниту нужен миллисекундный импульс чтоб перебросить диск пикселя на другую сторону, так что каждой матрице нужно примерно 0.7 секунды чтоб обновить все точки. Реально же, даже при быстрой рассылке пакетов на все матрицы и обновлении точек "в фоновом режиме" шесть матриц в ряд обновляются не одновременно и это заметно на глаз, так что хотелось бы скорость передачи повыше, чтоб можно было показывать анимацию.
Пока делаю соединение на I2C и на каждой Nano дипами задаю свой адрес, но не уверен что это правильный выбор для быстрой надёжной коммуникации на два метра.
Прототип
Прототип их 2x2 матриц по I2C вроде работает, но в конечном варианте матрицы будут расположены в ряд 6x1 или 8x1 и расстояние от ESP32 до Arduino Nano может достигать 2 метров.
Не одновременно это одно, не успевает — это другое. Если проблема в первом, нужно просто ввести latch-сигнал. Сначала центральный контроллер отправляет подряд обновленные субквадраты, и контроллеры квадратов их принимают, запоминают, но ничего внешне не делают. Затем центральный контроллер отправляет этот сигнал (или отдельным проводом, или широковещательным пакетом на шине) и все квадраты разом обновляют свои пиксели.
Здесь может возникнуть другая проблема: одновременное, идеально синхронизированное срабатывание тысяч механических пикселей приведет к значительному броску тока и значительной же просадке питающего напряжения. Так что нужно подумать о питании и конденсаторах в каждом квадрате.
Если же проблема именно в неуспевании (а оно должно успевать даже если поменялся абсолютно любой и каждый пиксель), нужно увеличивать частоту и пересматривать протокол.
Я бы не использовал I2C. Я бы использовал кастом-шину в виде линий:
PIX
CLK
HSYNC
VSYNC
Каждый квадрат знает свое место в дисплее (благодаря тем же дип-переключателям), слушает шину и считает синхронимпульсы. Досчитавшись до нужных чисел, начинает «мотать на ус». Latch-командой может быть не отдельная линия, а необычное сочетание переходов (как старт/стоп в I²C).
Сигналы можно передавать по дифпарам, чтобы одним выстрелом убить несколько зайцев: уйти и от помех и проблем с несимметричными линиями, и от проблем с перекосом потенциала земли из-за больших «рывков» тока в момент переключения. 4 предложенных сигнала тогда отлично укладываются в стандартную витую пару.
Но вообще, анимация на механическом дисплее не звучит, как хорошая идея.
Стоп, какая latch-команда, в предложенной схеме она не нужна, её роль выполняет VSYNC.
CLK инкрементирует счётчик текущего столбца. HSYNC сбрасывает счётчик столбца и инкрементирует счётчик текущей строки. VSYNC сбрасывает все счётчики и диктует всем субмодулям показать «накопленное» содержимое.
Я бы использовал кастом-шину в виде линий
А вот это хорошая идея, спасибо! Исторически я начинал с одного квадрата управляемого с Arduino, для простых вещей вроде часов этого достаточно. Потом захотелось объединить несколько квадратов в большое табло. Диски блинкерного табло остаются в последнем состоянии даже при отсутствии питания, поэтому я нацелился на умный протокол ESP32->Arduino позволяющий, например, передавать только пиксели изменившие состояние. Добавил команд с примитивами вроде отрисовки линий, и пошло-поехало...
Сейчас, оглядываясь назад, вижу, что отрисовку лучше делать на ESP32, а квадратам нужны только две команды:
1. Показать битмап на весь квадрат
2. Расшевелить пиксели. Дело в том, что если диск не менял своё положение несколько часов, то он может залипнуть. Вероятность небольшая, около 1%, но пикселей три тысячи и пара десятков мёртвых точек бросается в глаза. Подозреваю, что дело в остаточной намагниченности сердечников. Чтоб расшевелить точку, нужно быстро переключить её туда-обратно несколько раз, c разной длительностью импулься. Операция низкоуровневая, особенно из-за варьирующихся таймингов, поэтому хотелось бы оставить её на Arduino, а ESP32 будет раз в несколько часов посылать команду на очистку матриц, а потом восстанавливать последнюю картинку.
Сигналы можно передавать по дифпарам
Я правильно понимаю, что средствами лишь Arduino это не реализовать, и нужны дополнительные микросхемы типа применявшихся в автобусе (с которого и были сняты табло) для обмена между водительским компьютером и контроллером табло чипов SN75176? Тогда уж наверное проще использовать CAN - стандартный интерфейс, дифпары, меньше сигналов.
Но вообще, анимация на механическом дисплее не звучит, как хорошая идея.
Постоянно показывать видео, пожалуй, не стоит - быстро сотрутся пластиковые усики дисков, но анимация в разумных пределах может быть полезной.
Мой случай - когда началась корона и всех отправили на удалёнку, резко возросло количество митингов с веб-камерой. А тут как-раз раздобыл табло от старого автобуса. Разобрался как работает родной интерфейс (он медленный, потому как автобусу часто обновлять маршрут не надо), повесил табло позади себя на стену чтоб было видно во время созвонов, сделал простой http-интерфейс на ESP32. Теперь можно с серьёзным видом слушать собеседника, а на табло, вдруг, появляется комментарий типа "ну и что-бы могло пойти не так". Митинги стали веселее, коллегам по работе нравится, теперь каждое утро их ждёт цитата дня. Потом добавил простых анимаций - в декабре по табло падали снежинки, или можно показать что-то предельно пафосное, а потом запустить Пакмана, съедающего текст.
Как-то так
В целом работает неплохо, но мои новые идеи уже упираются в быстродействие. Для последовательного обновления нескольких тысяч точек нужно до 4 секунд, так и пришёл к цели повесить Arduino на каждый квадрат и обновлять их параллельно.
PS: Я программист, а не электронщик, прошу прощения за дилетантские вопросы.
Тогда уж наверное проще использовать CAN - стандартный интерфейс, дифпары, меньше сигналов.
Для такого проще modbus rtu поверх какого-нибудь rs485: протокол прост как три рубля, железяки стоят три копейки (и не нужен контроллер), скорости те же, ну и за раз 256 байт можно передать.
Проблема выходит не в скорости обмена выходит, а в медленных пикселях и в последовательности обмена. Ну и может в arduino что то мешает, особенно если какая нибуть софтовая реализация протоколов, да неспешные битовые операции.
В принципе можно реализовать прямо таки одновременный вывод данных до 8 шт. UART, или SPI на минималках (до 8 линий данных, по одной на каждый сегмент, а клоки общие). Сегменты пусть даже и arduino обслуживает, хотя она будет реализовывать обыкновенные счетчики и регистры сдвига. Но тут скорости должно хватить даже на единственную кольцевую шину SPI в штаном режиме (сегменты просто выбирают нужный байт данных по порядковому номеру, и ретранслируют далее)
Дифпары на подобном протоколе тоже как бы не вопрос, но тут не такие расстояния, не такие условиях помех и не такие скорости чтобы так замарачиваться. На светодиодных матрицах вроде обычные низковольтные сигнала на самых простых проводах и все работает очень быстро.
кстати для описываемой задачи, для всяких стримеров на фон, предлагаются светодиодные экраны, но они не дешевые. Да и вообще чисто в видео поток можно всякое накладывать - чисто софтовая задача будет :) :) :)
Но судя по фоткам прототипа там явно ен програмист печатные платы делал.
Судя по фоткам, вообще не совсем понятно зачем там ардуины. Блок с дешифраторами в DIP-корпусах там уже присутствует, можно попробовать работать напрямую с ними.
Ну не совсем напрямую, это скорее мультиплексор причем на 5В, а не 3.3В. на esp32 для этого выводов маловато, особенно если не 4 сегмента, а больше. но там достаточно каких нибудь защелок с SPI/i2c чтобы 10 линий не параллелить. Вполне нормально для этого ардуину использовать, точнее - какой-нить мелкий контроллер на 5В, но зачем то там еще и дополнительные мелкие буфера на платах, наверное ардуины на 3,3В - это уже слишком наворочено выходит.
Тянуть шесть 34-жильных шлефов от матриц к центральному микроконтроллеру и на стороне ESP32 расширять шину до сотни сигналов кучей 74595 или каких-нибудь MCP23S17? А потом программировать одновременное формирование шести диаграмм, выдерживая интервалы меньше миллисекунды, при том что на ESP32 ещё крутится веб-сервер и рендерятся кадры анимации? А потом захочется вместо панелей Lawo c пикселями 10 мм взять матрицу от Brose с писелями 15 мм, а на той отсутвуют драйверы оси Y и нужны уже шлейфы на 60 контактов и драйверы на стороне контроллера и всё придётся переделывать заново.
Можно наверное и так, но мне проще было разделить ответсвенность: ESP32 решает задачи высокого уровня и формирует битмапы, не заботясь об электромеханической реализации, а Ардуины уж вовремя включают/выключают электромагниты.
Интерфейсы матриц
Lawo, драйверы X и Y, 34 пина с питанием и управляющими сигналами. Моя Arduino с I2C (пока) интерфейсом.
Brose, 60 пинов, драйвер только по оси X, линии Y выведены прямо на разъём и должны устанавливаться извне (24V). Arduino с I2C (пока) интерфейсом и самодельным драйвером оси Y на ULN2803 и TD62783.
типа применявшихся в автобусе (с которого и были сняты табло) для обмена между водительским компьютером и контроллером табло чипов SN75176
SN75176 двунаправленная, в данном случае это оверкилл. Субквадрат ничего не должен передавать центральному блоку.
Ресивер на 4 дифпары можно сделать из одной микросхемы счетверённого компаратора (или ОУ), обвязав каждую единицу так, чтобы получился триггер Шмитта. Со специализированной микросхемой, конечно, легче.
CAN не лучше, потому что больше оверхед на передачу служебной информации, которая в предложенном мной варианте не передаётся, а вычленяется из подсчёта импульсов. То есть при тех же физических параметрах линии (включая частотно-зависимые), через 4 дифары PIX/CLK/HSYNC/VSYNC можно передать больше, чем через CAN. И при этом никакие CAN-овские фишки типа мультимастерности и разрешения коллизий не нужны. Так зачем же тащить сюда CAN?
"двунаправленная " тут звучит путающее, хотя "полудуплексная" тоже не отобразит мысль. Подобных микросхем (RS485) навалом и ничего страшного если они будут работать "наполовину". Это всяко проще чем сочинять свое, да и искать "половинку" 485 имеет ли смысл. Ну а в случае CAN вообще вопрос так не стоит.
Явно пора жениться пора.
это не баг это фича, на демосцене - только так и делают (за хорошое видео с анимацией типа badapple на таком табло вполне реально приз словить даже при нынешнем прогрессе)
Что то вообще жирновато получается с ардуинами, в табло этом и так уж регистров видимо навалом, ну и регистры с управлением по i2c, по spi бывают
высшим пилотажем было бы использование возможностей подключения rgb экранов в esp32-s3 но это точно придется углубиться в его программирование
видео с анимацией типа badapple
Как же без него
в табло этом и так уж регистров видимо навалом
Увы, нет. Табло, наверное, бывают разные, но в попадавшихся мне от автобусов 90-х гг. выпуска электроника предельно простая. На матрицах производителя Lavo установлены три драйвера электромагнитов на микросхеме FP2800A - один по оси X и два по оси Y (один для установки пикселя, другой для сброса). Драйвер имеет 5 линий адреса, выбор состояния пикселя DATA и вход ENABLE. Всё это выведено на 34-пиновый разъём, к нему, кстати, подходит IDC кабель от старых дисководов. Матрицы производителя BROSE ещё проще, на них установлен только драйвер оси X, а все линии Y выведены на разъём и нужно уже 60 контактов. Никакой памяти или последовательных интерфейсов нет, поэтому и использую Arduino:
1. Получить от центрального микроконтроллера очередной битмап желаемого состояния и сохранить в framebufer
2. В цикле по всем пикселям где новое состояние отличается от последнего показанного:
2.1 Установить адреса по X и Y и состояние DATA (перебросить диск на чёрная или желтую сторону)
2.2 Установить ENABLE по X и Y
2.3 Подождать 750 микросекунд
2.4. Cбросить ENABLE
2.5 Подождать 250 микросекунд
2.6 Перейти к следующему пикселю
В каждый момент времени драйвер может подавать ток лишь на один электромагнит. Матрицы можно объединять в цепочки до 8 штук, так оно у меня сейчас и работает, но для последоватьельного обновления всех 6 нужно около 4 секунд. Для автобуса сойдёт, ему маршрут менять раз в день, а вот для моих целей хотелось бы обновлять матрицы паралельно, поэтому и хочется посадить отдельный Arduino на каждый квадрат, и отдавать им команды с центрального ESP32 который обеспечивает веб/REST интерфейсы для управления табло из браузера или приложения.
как тебе такое, @nikhotmsk :)
Самое крутое flip-dot табло - это здесь: https://hackaday.com/2015/01/14/the-giant-flip-dot-display-at-ces
Я так понял, там стоят промышленные ethernet to serial конверторы
По одной точке медленно будет. Нужно этот старый контроллер заменить на hc595 или что-то такое, только с большим током на выходе, и ими уже командовать с ардуино.
При стандартном способе сборки блинкерных табло с горизонтальными и вертикальными линиями и парой диодов на каждый электромагнит пиксели, можно адресовать только по одному. Точнее можно одновременно переключать все пиксели одинакого состояния в строке или столбце, но тогда возрастут токи (300 mА на пиксель) и понадобится экзотический драйвер. Табло по ссылке собрано из польских модулей XY5 28x14. На каждой матрице свой контроллер, команды получает по RS485. При напряжении 24V и новой матрице реально перебрасывать диск импульсом в 500 мкс. Так-как обрабатывать нужно лишь изменившие состояния точки, то быстродействия хватает для простых анимаций.
Что-то такое я и хочу повторить. Всё хорошо, но поляки за своё творение просят 500€ за 28x14, это 1,27 евро за одну точку. Матрицы с разборки автобусов выходят 0.05-0.08 евро за точку, в эту цену входит металлический корпус с подсветкой и пусть медленный, но работающий контроллер с I2C поверх RS-422. При такой разнице в цене имеет смысл разобраться и сделать самому.
Там у них тоже че то наворочено, микросхем хватит чтобы каждым пикселом управлять отдельно, плюс контроллер уровня atmega2560, а уж всякие rs485 и ethernet - для дистанционного управления, отдельная тема
Тут же ведь можно избавиться от этих неудобных драйверов, так их даже выпаять хлопотно будет, а свои ключи силовые ваять - тоже удовольствие на любителя.
А вот на уровне софта и межмодульного взаимодействия вероятно есть чего поулучьшать.
Так это же текст AI-шкой сгенерирован, поэтому и столько ошибок, неточностей вплоть до откровенного бреда... Я считаю что за такой контент нужно банить!
а слово СЕРИЙНЫЙ никому глаза не колит? явно перевод делало существо, не знакомое с темой.
Кратко про протоколы взаимодействия в микроконтроллерах: SPI, IDC, UART, CAN