В зависимости от ваших настроек связи каждый передаваемый символ / байт должен быть:
1 start bit
8 data bit
0 parity bits
2 stop bits (this should be 2 -> spec says 11 bits/char, but I have seen implementations that use 8N1)
-------------------------------
total: 11 bits/byte
1) Запрос
address: 1 byte
function code: 1 byte
starting address: 2 bytes
quantity of registers: 2 bytes
crc: 2 bytes
-------------------------------
total: 8 bytes
Min time: 1s/9600bits * (8 bytes) * (11 bits/byte) = 9.2 ms
2) Интервал молчания между кадрами
Min time: 1s/9600bits * (3.5 bytes) * (11 bits/byte) = 4.0 ms
3) Ответ
address: 1 byte
function code: 1 byte
byte count: 2 bytes
register values: 24 bytes (2*12)
crc: 2 bytes
-------------------------------
total: 30 bytes
Min Time = 1s/9600bits * (30 bytes) * (11 bits/byte) = 34.3 ms
Таким образом, теоретическое минимальное время прохождения сигнала туда и обратно составляет: 9,2 + 4,0 + 34,3 = 47,5 мс
Таким образом, похоже, что есть потенциал для улучшения,но трудно точно знать, где ваши задержки.
В дополнение к тому, что предлагали другие, я обычно ставлю область видимости на линии связи, чтобы посмотреть, близки ли кадры tx и rx к теоретическим временам.Вы также должны быть в состоянии сказать, сколько времени занимает ответ сервера, посмотрев на время между концом tx и началом кадров rx.Если вы можете каким-то образом инициировать область действия перед тем, как начать отправку запроса, вы также можете измерить время, необходимое клиенту для генерации и начала передачи кадра запроса.