Возникаю проблема при передаче данных между 3мя устройствами почему-то последнее принимает только 90% пакетов а остальные пропадают проект довольно большой и затрагивает 3 вычислительных модуля между которыми предаются данные ПК -> TinkerBoard->DUE.поэтому приводить его и его элементы не удобно. Но хотелось бы получить наводку где стоит искать проблему т.к. моих знаний не хватает. ПК обменивается данными с TinkerBoard по Ethernet ( TCP Socket) по логике TCP гарантирует доставку пакетов и их последовательность однако именно на нём есть большие задержки, это связанно с тем, что передача данных идёт через Wi-Fi где иногда бывают помехи, следующее звено TinkerBoard и DUE обмениваются данными по UART сообщениями типа: <маркер>длина сообщения , сообщение <маркер> тоже довольно надёжный обмен и если передавать данные с задержками ( что-бы отследить работу ) всё работает нормально но при быстром обмене данными возникают потери, пока на ум приходит дублирование передачи данных, точнее возвращения сообщение о том что информация принята но возможно есть другой способ? З.Ы. Сами сообщение очень короткие не больше 10байт ( включая маркеры ) частота обмена при быстром обмене не больше 50Гц что не должно вызвать перегрузку CPU любого из вышеперечисленных ВМ.
Чего источник? Если помех радиоволн это не возможно системе придётся работать в условиях помех. Отсюда вытекает следующий вопрос вы полагаете что потери в TCP хотя протокол гарантирует доставку получается даташит врёт?
Источник проблемы. Я ничего не полагаю: я не видел вашей системы, и я не экстрасенс. И не надо выдумывать даташита на TCP, его не существует.
Если бы я мог изолировать источник проблемы я бы не спрашивал. Вопрос можно было спросить проще по опыту бывают потери пакетов TCP при условии наличия стабильного соединения, и могут ли данные в UART так перемешаться, что сообщения типа: <маркер>длина сообщения , сообщение <маркер> может перепутаться? Согласен это не даташит а документация ( в прочем это формальность ).
Тогда вам следует обратиться к специалистам, которые могут это сделать. Да и вообще всю систему разработать, раз уж вы некомпетентны.
Возможна такая ситуация что проблема в просушке UART, а конкретно ситуация когда порт не готов к чтению ( нет лог 1 пред передачей данных ) он теряет первый бит маркера пакета?
Возможен миллион самых разных ситуаций. Нужно сесть и проверить каждый компонент по очереди, а не заниматься угадайкой.
Если ПК и TinkerBoard общаются по tcp, то может сначала снять трафик на обеих сторонах и сравнить, возможно там потерь и нет вовсе.
Уже проверил по TCP потерь нет, потери возникают на UART и это как правило 1й пакет после задержки остальные приходят правильно. Причём под "1й пакет после задержки" имеется в виду следующая ситуация: При нажатии на кнопку на клавиатуре отправляется сообщение и при отпускании кнопки тоже, если медленно с интервалом 1-2 сек нажимать и отпускать кнопку приходит 100% пакетов. Если быстро нажимать кнопку потом сделать интервал и опять по нажимать в 10% случаев пакет пропадает ( сервомотор не принимает положения отпущенной кнопки ) и по этому отловить баг трудно т.к. по факту всё приходит но какое-то 1но сообщение иногда теряется. Сейчас проверяю вытесняющую многозадачность, ещё возможно дело в GPIO а точнее библиотеке WiringPi но это не точно.
В итоге оказалось что проблема была именно при отправке 1го сообщения, 1 бит данных пропадает вероятно по тому что порт ещё не готов к чтению и повышение напряжения на входе порта принимается как начало передачи, поэтому пред отправкой сообщения необходимо отправить пустой байт write_port(""), после этого сообщения приходят без проблем. Интересно что при отправке с ноутбука такой проблемы нет поэтому вероятно виновата сама библиотека wiringpi вероятно не правильно партированная для TinkerBoard. Это не единственная проблема библиотеки также не работают прерывания для UART хотя флаги работаю.
