Коллеги, возник интересный вопрос, может кто пробовал такие извращения. Всего описанного еще не существует, но есть проект. 6 СТМ-к, стоят рядом, каждая имеет свою задачу. Есть ECP, которая по сети получает команды и сливает команды в уарт. Все 6 СТМ включены в этот уарт, все получают эти команды и разбирают свои. Сами в уарт ничего не гонят. С программной точки зрения мне все просто и понятно, но есть сомнения на предмет того, что параллельное подключение по уарт может не работать по какой либо причине с точки зрения железа. Никто не подключал параллельно несколько устройств?

Всё будет работать как есть, нюанс только во входной емкости RX пина и теоретически, при определенном битрейте и кол-ве устройств - будут завалены фронты из-за входной емкости - система работать перестанет.

То есть по факту нужно просто взять и потестировать... В принципе не проблема рядом 6 контроллеров поставить и на дюпонах их зацепить.

Да вообще без разницы, для надежности хоть 1200 можно. Но я думаю 9600

по идее если не делать двунаправленную шину, TX мастера будет работать в режиме push pull и с фронтакми будет проще

может всё же I2C, если такая скорость?

и uart0 остаётся свободным для отладки и прошивки

> I2C гораздо сложнее спорное утверждение, учитывая что есть стандартные библиотеки под все МК, у которых есть TWI/I2C

io0 по идее можно сделать SDA

и I2C изначально под много устройств, а UART чаще под PPP

Еще можно применить модбас, где есть адресация и контрольные суммы

и проще и надёжнее, чем городить самописный протокол

Да, но вот сценарии, при которых I2C зависает - отнюдь не многие рассматривают. Чтобы с этим не возиться - проще взять UART

не знаю про зависания, I2C много лет пихается во всякую бытовую технику и всё ок.

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

"не знаю про зависания I2C" - это типичная ошибка, которая повсюду встречается, люди просто не достаточно проверяют свой код, 2 проекта таких было, где один сбой на I2C вешал всё устройство

modbus работает в промышленной автоматизации таймауты там не просто так, а часть протокола и их обязательно нужно реализовывать или брать не кривую библиотеку

"не знаю про зависания I2C" - это типичная ошибка, которая повсюду встречается, люди просто не достаточно проверяют свой код, 2 проекта таких было, где один сбой на I2C вешал всё устройство

Еще таймауты - ограничивают пропусную способность

Нет, таймауты там именно просто так - нет никаких причин разделять пакеты кодом и не тратить время на возню с таймерами. Когда-то кто-то так решил и теперь все подстраиваются. Даже не все modbus -ethernet gates это соблюдают.

Да как же годами датчики на i2c работают то ?

"не знаю про зависания I2C" - это типичная ошибка, которая повсюду встречается, люди просто не достаточно проверяют свой код, 2 проекта таких было, где один сбой на I2C вешал всё устройство

если RS-485 - да, если UART и в обе стороны - чуть сложнее, если не использовать лог.анализатор)

я пробывал выкидывать таймауты и тестить

modbus работает в промышленной автоматизации таймауты там не просто так, а часть протокола и их обязательно нужно реализовывать или брать не кривую библиотеку

случайно I2C не программный с самописной реализацией?)

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

А когда надо диван купить, вы его размер с микрометром меряете или все таки с рулеткой? На всякое дело нужный инструмент требуется. Нафига мне модбас, когда мне надо 4 байта передать - байт ID, 2 байта команды и байт на контрольную сумму. ID не совпал - игнорируем команду. Контролька не совпала - игнорируем. Дешево и сердито. В модбас я умею, но нафига мне его сюда городить, когда порой и так памяти не хватает?

А когда надо диван купить, вы его размер с микрометром меряете или все таки с рулеткой? На всякое дело нужный инструмент требуется. Нафига мне модбас, когда мне надо 4 байта передать - байт ID, 2 байта команды и байт на контрольную сумму. ID не совпал - игнорируем команду. Контролька не совпала - игнорируем. Дешево и сердито. В модбас я умею, но нафига мне его сюда городить, когда порой и так памяти не хватает?

а если у вас ведомый МК перезагрузиться в момент передачи пакета или один байт помехой потрётся и рассинхронизация выйдет ? вот таймаут в modbus как раз и помогает с рассинхронизацией бороться

да, косяк но modbus позволяет восстановить работу без перезагрузки всей системы

да, косяк но modbus позволяет восстановить работу без перезагрузки всей системы

Эмм.. а зачем перезагружать всю систему в случае ошибки связи?

а они есть

он это пытается анализировать, фигня,

Вы говорите с точки зрения модбаса опять. Либо рукописных протоколов типа модбаса. Повторю - если посылка искажена, то ведомый ее просто игнорирует. И ничего страшного не будет. Ведущий повторит ее через какое то время (скажем через секунду или 10 секунд. У нас тут не ракета, даже и минутная задержка не критична.

ведущий должен как-то понять, что нужно повторить

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

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

свеже подключённое устройство : вот тут беда оно может подключиться в момент, когда передаётся не первый байт посылки