Не знаю в тему ли, но.... 1. имеется Аруино + драйвер 4-х моторов + мультисерво (бутерброд) - связь по I2C; 2. малина 3. между малиной и ардуиной предполагается связь по последовательному порту (желательно через блютуз-сериал, но можно и USB-SERIAL). Имею желание организовать протокол связи Modbus RTU между малиной и и ардуиной. Я имею ввиду протокол обмена, а не аппаратную реализацию RS-485. Есть достаточный опыт реализации ведушего устройства Modbus RTU - будет со стороны малины, но нет никакого опыта для реализации ведомого со стороны ардуины. Общая логическая схема обмена предположительно: Raspberry <--modbus-->Arduino<---i2c--->устройства. Со стороны ардуины сейчас реализованно: -управление 4-мя моторами (с реверсом) движения платформы; -угловое позиционирование веб-камеры с помощью сервомашин на платформе. Со стороны малины: -TCP-сервер связи процессов; -TCP-сервер доступа через SERIAL к устройствам по Modbus RTU -OpenCV + Python + C - наработки выделения контуров из изображения (в дальнейшем возможно дополнение ещё одной малиной) Собственно вопрос: Может кто поделится примером для ардуины приёма и передачи массива по сериал. И возможно-ли производить "анализ" некотрых байтов "на лету" в процессе приёма. Также было бы интересно знать какой модулб блютуз для ардуины выбрать для покупки, с целью реализации блютуз-сериал для реализации связи. (возможно модули принимают некоторые байты, после которых они переходят в режим настроек - эти байты надо "экранировать". Такие модули применять для данной цели не допустимо, либо применять протокол отличный от Modbus RTU). С глубоким уважением! Заранее спасибо.
https://github.com/Porokhnya/Greenh...lExecutionModule/UniversalExecutionModule.ino - там есть мал-мала код приёма любого пакета по RS-485, идентификация пакета - по заголовку и окончанию, проверка контрольной суммы, проверка на валидную точку приёма - если модуль включился где-то посередине вещания мастера - он адекватно обработает эту ситуацию. В приведённом скетче гоняется пакет в 30 байт, за глаза на все случаи жизни, фактически.
Спасибо за отзыв! Буду смотреть. Сразу увидел подсчёт CRC - не для Modbus RTU. В принципе 30 байт - ничего, Возможно потребуется несколько обращений - в один пакет не влезет Пока не рассмотрел, но... для команды 3 (чтение регистров) - запрос со стороны мастера: addr 0 - номер устройства на шине (адрес по Modbus RTU) - ведомым обрабатывается "на лету"; addr 1 - номер команды - в нашем случае 3; addr 2,3 - адрес начального читаемого регистра внутри устройства; addr 3,4 - количество регистров для чтения (почему-то в протоколе 2 байта на количество регистров, хотя размер пакета менее 256 байт при размере регистра 2 байта); addr 5,6 - контрольная сумма - считается так: inline U16 MRTU_CRC(BYTE* data, ushort len) { ushort res_CRC = 0xFFFF; ushort count = 0; BYTE count_crc; BYTE dt; while(count < len) { // count_crc = 0; dt = (BYTE)(data[count]); res_CRC ^= (ushort)(dt); // while(count_crc < 8) { if((res_CRC & 0x0001) < 1) { res_CRC = (res_CRC >> 1) & 0x7FFF; } else { res_CRC = (res_CRC >> 1) & 0x7FFF; res_CRC ^= 0xA001; }; count_crc++; }; count++; } return (res_CRC); } На ведущем и ведомом подсчёт одинаковый. На каждый регистр приходится два байта. Можно конечно обращаться и к каждому регистру отдельно или к какому-то их количеству не важно. Но вопрос: При программировании ардуины (USB-SERIAL) и при просмотре сообщений по терминалу по (нему же) - обмен идёт как я понимаю в символьном (строчном режиме). Для Modbus RTU побайтный обмен (0x00-0xFF). Возможна ли такая работа без случайных переходов в режим программирования для ардуины и/или режим настроек для блютуз модуля (из опыта с "осой", где три раза "$" - т.е. "$$$" переводили эту самую "осу" (блютуз) в режим настроек. Тоесть приемлемо ли применять побайтный обмен напрямую. А за пример - Спасибо! Да - уточняю аппаратную реализацию RS485 делать не планирую, но протоколом Modbus RTU пользоваться собираюсь. Вообще-то везде в промышленности он на аппаратной реализации RS-485.
