[toweroff 0]

Добрый день.

Два устройства общаются между собой по UART.

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

В какую сторону посмотреть?

[Kabdim 0]

TCP over serial?

[Mareng 0]

Если нет мастера, то я бы заменил уарт на CAN. Там уж точно ничего изобретать не надо.

[toweroff 0]

Если нет мастера, то я бы заменил уарт на CAN. Там уж точно ничего изобретать не надо.

Нет CAN у олного из устройств.

[hsoft 0]

Зачем изобретать, получил пакет, подписал и отправил обратно. Вот и подтверждение.

Послали 10 раз, не получили ответа ни разу, ну все, ситуация "клиент не отвечает".

 

[jcxz 184]

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

А зачем вообще Вам этот "механизм гарантированной доставки"? Вы думаете байты искажаться что-ль будут?

Или у Вас всё-таки не канал UART?

[Baser 5]

Мастера нет, каждое устройство может начать передачу

Вы задачу немного неправильно сформулировали.

У вас как раз два мастера. И сетка получается "мультимастер".

Вот на эту тему и ройте. Там главная проблема определение и разруливание коллизий.

[toweroff 0]

А зачем вообще Вам этот "механизм гарантированной доставки"? Вы думаете байты искажаться что-ль будут?

Или у Вас всё-таки не канал UART?

Да в том-то и дело, что именно uart, длина проводников 5см, скорость 115200. Иногда, спорадически, одно из устройств ловит нули или, реже, с вкраплениями 01.

Осциллографом рассмотреть нет возможности из-за отсутствия четкой привязки к чему-либо

И никак не могут понять, кто там кому "гадит", программно или аппаратно

Пока попросили рассмотреть возможность подобного протокола, хотя согласен, это нагромождение сущностей в данном случае

[Mareng 0]

А каким образом на голом уарте сделан мультимастер? через резисторы?)

 

UPD: Все понятно, у вас же только ДВА устройства. Тогда не должно быть проблем совсем. Искать ошибки в ПО, потом в железе.

Изменено 3 мая, 2017 пользователем Mareng

[Nosaer 0]

Да ладно!? 5 см на такой скорости и ошибка?

Может попробовать экранировать провода?

 

Однажды получал 0x00 в конце каждой посылки из-за не большого рассогласования уровней.

[jcxz 184]

Да в том-то и дело, что именно uart, длина проводников 5см, скорость 115200. Иногда, спорадически, одно из устройств ловит нули или, реже, с вкраплениями 01.

5 см при 115200 и при том что это обычный UART???

Ищите баги в ПО. Ну в крайнем случае - в схемотехнике. Никакой "протокол гарантированной доставки" тут не нужен.

[iosifk 3]

Да в том-то и дело, что именно uart, длина проводников 5см, скорость 115200.

Ваши uart могут поддерживать LIN?

И как сделана сеть? Кольцо или звезда? Как определяется начало кадра?

 

[AlexandrY 3]

Два устройства общаются между собой по UART.

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

В какую сторону посмотреть?

 

Если ничего не путаете, то это называется Peer-To-Peer и соответственно протокол называется PPP.

Он штатно входит во все известные RTOS: MQX, uCOS, Keil RTX, mbed OS, FreeRTOS (в составе LWIP)...

Осталось только выбрать RTOS

[Baser 5]

А каким образом на голом уарте сделан мультимастер? через резисторы?)

 

UPD: Все понятно, у вас же только ДВА устройства. Тогда не должно быть проблем совсем. Искать ошибки в ПО, потом в железе.

Угу, точно, если у ТС УАРТы включены кольцом с полным дуплексом, то аппаратных коллизий там вообще быть не может.

Видимо недоработка ПО, необрабатываемые программные коллизии, когда один мастер приняв пакет от другого, хочет ответить на него, а его другой программный поток начинает параллельно мастер-передачу в тоже УАРТ.

Вот каша и получается.

[k155la3 26]

. . . .

И никак не могут понять, кто там кому "гадит", программно или аппаратно

Пока попросили рассмотреть возможность подобного протокола, хотя согласен, это нагромождение сущностей в данном случае

 

Устранять коллизии для такой (небольшой и локальной по размерам) системы с помощью протокола "контрпродуктивно" :)

Проще обеспечить гарантированное их отсутствие - реализовать аппаратную линию "захват канала".

Или нечто подобное TokenRing по алгоритму.

Выловить коллизии можно с помощью лог. элемента "OR" подключенного на RxTx. Выход евойный (Fail)

завести на входы какоголибо отладочного входа прерывания обоих контроллеров или логанализатора или осцилографа.

 

Выходы Tx push-pull или с открытым коллектором ?