|
|
И снова MODBUS |
|
Привет всем. Что-то я совсем запутался с MODBUS RTU. В документации звучит примерно так - если при передаче фрейма между байтами возник интервал тишины 1.5 сек, то SLAVE закончит прием текущего сообщения и следующий байт будет воспринят как байт следующего сообщения. Но ведь у нас разделяющий интервал между фреймами 3.5 сек!!! ??? Вообщем либо я торможу, либо одно из двух... И что значит - если между фреймами меньше 3.5, то подчиненный - воспримет байт следующего фрейма как байт текущего (долепит) фрейма, а ошибка!!! ??? или об этом сообщать мастеру не надо????? |
|
 |
|
Небольшое уточнение. Речь идет не о секундах, а о СИМВОЛАХ. Если прошло время, равное периоду следования 3.5 символов, а кадр не был завершен или не поступило нового символа, устройство очищает кадр и предполагает, что следующий принимаемый байт - это адрес устройства в новом сообщении. |
|
|
|
|
Но тогда не понятно как микроконтроллер должен реагировать при задержке между кадрами менее 3.5 символов? Ведь конец кадра мы однозначно при приеме можем определить, а тут еще прилетает байт, напр. через 2.0 символа, ну какой-нить мусор... Как быть? Просто промолчать? Я так и хочу сделать, но соответствует ли это самому протоколу? |
|
|
|
|
Да, забыл, еще непонятна последовательность CRC в кадре, что сначала идет - старший или младший байт? |
|
|
|
The CRC field is appended to the message as the last field in the message. When this is done, the low–order byte of the field is appended first, followed by the high–order byte. The CRC high–order byte is the last byte to be sent in the message. |
|
|
|
|
Спецификацию протокола Modbus на русском языке, а также имитаторы master- и slave-устройств можно взять на http://sysavt.h11.ru/docs/inter.html
|
|
|
|
Все байты пришедшие с здержкой менее 3.5 символов относятся к текущему кадру |
|
|
|
Если в фоновом цикле особой вычислительной мощи не требуется, то можно и предопределять конец кадра; или, скажем, реализована только одна функция (например 0х03), то длина кадра по умолчанию предопределена. Иначе все-таки прийдется строить ПО микроконтроллера так, что конец кадра определяется строго по появлению паузы в передаче. |
|
|
|
Чего-то меня настораживает этот вариант - попахивает переполнением приемного буфера... Тем более что функции MODBUS-а как правило сильно упрощаются разработчиками с помощью ограничений, а значит не требуют больших временных затрат на анализ конца кадра. Кроме того, если запрос превышает грубо говоря 8 байт, то обязательно используется счетчик байт, а значит мы однозначно можем определить длину кадра. |
|
|
|
|
Длину кадра безусловно можно определить. Но в конктретных реализациях на микроконтроллерах возникала такая ситуация (особенно на скорости 115200 б/с), что в обработчике прерываний можно только проверить четность байта и записать принятый байт в ОЗУ - времени проверять длину кадра просто нет.
|
|
|
|
Ответить 
|
Страница 12> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
