1 OLED дисплей на 2 микроконтроллера

[Valentinos]

Приветствую!
Есть задача на один I2C дисплей выводить попеременно данные с 2-х микроконтроллеров. Теоретически предполагаю, что это достаточно просто сделать на мультиплексоре. Но попытка воткнуть в разрыв SDA и SCL линий CD4053BE (просто потому, что такой мультиплексор у меня есть) дали результат, который меня не устроил. Переключение есть, но есть и шум типа песка - доп. белые точки, через некоторое время дисплей переключается на половинную яркость, а потом вообще вырубается.
В чем может быть причина... и как это можно исправить?
Попробовать купить другой мультиплексор? Увеличить подтяжку линий SDA и SCL к питанию? Или есть другие, не сильно сложные решения, помимо мультиплексора?

[Martian]

третий микроконтроллер, который будет принимать КОРРЕКТНО (потому что никакая фигня не будет мешать) данные от обоих микроконтроллеров, и выводить на дисплей нужные. Либо изменить программу в тех двух, чтобы они понимали, что работают вместе и построили очередь

[u37]

А можно придавливать CLK и работать через аппаратный I2C с нормальной поддержкой задержки обмена.

[MLX90640]

Где-то я уже встречал подобную проблему. Автору - изучить, что такое I2C интерфейс и осознать, что мультиплексоры не нужны, I2C шина может быть общей для многих устройств, и даже в режиме мультимастера может работать. Но чтобы не получалась каша на дисплее, надо договориться микроконтроллерам, что они не будут одновременно отправлять в дисплей данные. Если микроконтроллер не поддерживает режим мультимастер на I2C, то арбитраж доступа к дисплею можно реализовать с помощью отдельной линии между микроконтроллерами, которая будет в режиме pull-up. Микроконтроллер, желающий занять дисплей, должен вначале проверить эту линию, что она находится в высоком состоянии, затем опустить её в низкое состояние и после этого он может начать работать с дисплеем. Второй микроконтроллер, видя низкое состояние этой линии, к дисплею обращаться не будет. И наоборот.

[musor]

MLX90640, идея в принципе годная вот тока на практике малоприменимая
обычно те кто так делаю жаждают засунут 2 готовых ЧУЖИХ СХЕМЫ в 1 корпус и выводить их на дисплей или поперемено или по воле оператора (тумблер/кнопка) при это собиралшик часто не вкурсе не тока исходникоф обох нои даже не знает толком ка раьботает шина даже в режиме точка- точка...про мултимастер ваше молчим я не помню ПОПУЛЯРНЫХ бытовых МК с подержкой сего режима штатно апаратно

[Martian]

поэтому решается третьим микроконтроллером

[alex_]

Я бы установил связь между контроллерами по SPI, контроллер который выводит на дисплей просто бы запрашивал данные у второго и потом всё вместе выводил.
Ещё вопрос: а нафига 2 контроллера, какой смысл?

[MLX90640]

В один контроллер не влезают все хотелки (мало флеша, мало ног), вот на два контроллера и разбросил... А дисплейчик как правило крохотный SSD1306 миллиписической диагональки 0,91".
С мультимастером работают все популярные STM32. Правда, я никогда этим режимом не пользовался, но в описании он есть.
Автор вопроса наверно из тех, кто ищет готовые скетчи и просто соединяет всё вместе скотчем и соплями.

[alex_]

Если нехватает контроллера, то как правило берётся контроллер пожирнее.
Чувствую, пахнет каким то нелепым лисопедом

[Martian]

Нет такого правила. Существование двух контроллеров одновременно не есть лисопед или следствие отсутствия "жирного.

[BOB51]

Достаточно дополнительных линий на каждом МК "запрос доступа к дисплею(ресурсу)" и "доступ к дисплею(ресурсу) разрешен".
Ну и ессно программное обеспечение данных линий.

[alex_]

Martian писал(а):

Нет такого правила.

Может я и не прав, но какой смысл ставить 2 по 0,5 если можно поставить 1 нормальный при этом сэкономить на ресурсах согласования этих контроллеров, если они стоят на одной плате? Или Афтор любитель эротики
Пусть Valentinos сначала объяснит свою мотивацию, чего он хотел этим достичь, может есть более простое и очевидное решение?

[Jack_A]

alex_ писал(а):

Может я и не прав, но какой смысл ставить 2 по 0,5 если можно поставить 1 нормальный при этом сэкономить на ресурсах согласования этих контроллеров

Не всё так однозначно. У меня (в прошлом веке ) в одном приборе трудились 8535 и Мега ( не помню номер ) . Одна в реалтайме оцифровывала сигнал и передавала сигнал другой, которая производила достаточно сложную обработку, с плавучкой и функциями. Предвижу скепсис: взял бы STM32 на 200МГц и не парился... Ребяты, какой STM32 четверть века назад!
Тут скорее всего не тот случай. Но тем не менее...
----------
А 2 по 0.5 на столе смотрятся красивше, чем литра
Про арбитраж доступа согласен, решается супер-просто. Только решает ли он проблему? Один МК выдал строчку, отдал управление, а второй через миллисекунду сказал своё - и где сообщение первого? Всё определяется логикой совместной работы обоих МК, не только в плане OLED.

Последний раз редактировалось Jack_A Пт дек 16, 2022 12:21:17, всего редактировалось 2 раз(а).

[veso74]

Предполагаю с большой долей вероятности: Оба устройства, вероятно, уже готовы. С "чужой" кодом из интернета для две конструкции (только hex). Каждое устройство: как оно работает, что делает каждый контроллер ... может быть неизвестно. Назначение: экономия дисплея, пространства в ящике, объединение конструкций и т.д. .

Чтобы были случайно расположенные точки, в данных есть случайные биты (из переключения?). И будет ли напр. инициализация OLED в обоих МК одинаковые, можем только догадываться ...

[Martian]

В общем, для нормального решения задачи требуется уточнение условий от ТС
Если же предполагать худший случай, как предположил veso74, то решение только в третьем, буферном микроконтроллере.

[Valentinos]

alex_ писал(а):

Если нехватает контроллера, то как правило берётся контроллер пожирнее.
Чувствую, пахнет каким то нелепым лисопедом

Так и есть. Проблема в том, что залезть в 1 из этих контроллеров и переписать программу я не могу. А ставить 2-й дисплей места нет.

[alex_]

Valentinos писал(а):

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

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

[Valentinos]

alex_ писал(а):

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

Первый МК не знает, что есть второй МК и мультиплексор. Со второго МК я переключаю мультиплексор: сначала дергаю ножку INGIBIT, отключая от дисплея обоих, потом, с небольшой задержкой (не знаю, какая нужна, правда) соединяю линии I2C нужного МК и отпускаю INGIBIT.

alex_ писал(а):

логический 0 должен довольно близко находиться к 0В а чуть выше уже будет считать единицей, может мультиплексор не может обеспечить этот стабильный ноль?

Это сколько в вольтах, если VCC 3.3?

[musor]

лог 0 мене 0.4
но это не поможет в таком случае...
кадр должен быть полным в обоих случаях а при таком рещении viewtopic.php?p=4337617#p4337617 это в принципе нереално...

[Valentinos]

musor писал(а):

кадр должен быть полным в обоих случаях а при таком рещении viewtopic.php?p=4337617#p4337617 это в принципе нереално...

Ну, это-то я понимаю. И это как раз не проблема, кадр полный.
На обоих МК дисплей на либе U8g2 в режиме полного буфера (код для первого МК теоретически open source, но разобраться в нем ой как сложно, так что разработчик выкладывает hex).
Подвисание дисплея с частичной отрисовкой кадра на момент переключения большой проблемой не считаю.
Т.е. решение на мультиплексоре в принципе рабочее. Просто есть помехи, иногда сразу, иногда через несколько секунд, иногда через десятки секунд. Иногда с одного МК помехи идут сразу, а с другого через несколько переключений туда-сюда. С помехами и хотелось бы разобраться.