Olej писал(а):И давайте переформулирую я, а вы только подтвердите ("да" - "нет") и поправите...
Итак (как я могу судить)...
1. У вас есть ARM одноплатник (SBC)
собственной разработки и сборки, сильно похожий на iMX6UL, но
не от производителя, не фирменный...
2. На нём стоит Linux
вашей собственной сборки, с помощью BuildRoot собранный...
3. У SBC 5 (или больше?) аппаратных сериальных портов, которые можно аппаратно переключать между режимами RS-232 / RS-485;
Покажите (чтоб дальше к этому не возвращаться):
4. Из имеющихся портов 4 RS-485 предназначены для управления "вниз" разной периферией - в режимах Master Modbus...
Для поддержки Modbus на этих 4-х портах используется API пакета LibModbus в составе Linux.
На уровне API: modbus_new_rtu(), modbus_connect(), modbus_mapping_new(), modbus_read_input_registers() и т.д. (/usr/include/modbus/modbus.h).
Правильно?
5. Оставшийся 5-й порт RS-485 преназначен для связи "вверх" по управлению, в режиме Slave Modbus...
Поскольку API библиотеки LibModbus предназначена
только для написания ПО Master, вы пишете ПО этого канала используя низкоуровневый API терминальных линий POSIX.
На уровне UNIX/POSIX/Linux API: struct termios, open(), read(), write() ... и т.д.
Правильно?
6. При обмене этого Slave с Master возникают
плавающие ошибки (1:6000, 1:100000) ... некоторые из них приводят к тому, что канал Slave после них полностью "умирает".
Вы обмен-тестирование проводили с Master из
этой же своей реализации? Или с какими то
сторонними Master, из другой реализации: автономными, какими-то эмуляторами из Windows и т.п.?
Вы можете организовать "петлю" обмена, внутри одного и того же SBC, между этим Slave и любым из 4-х каналов Master?
7. Поскольку это готовится реализация для серийных, тиражных поставок, то допустить эти, хоть и редкие, сбои нельзя - это в будущем рекламации от заказчиков и попадание на хорошие деньги...
Нужно
локализовать место (уровень) возникновения сбоев, выяснить причину и устранить.
Теперь я правильно излагаю?