Форум по операционной системе GNU/Linux и свободному программному обеспечению
Текущее время: 20 сен 2019, 08:36

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
Непрочитанное сообщениеДобавлено: 10 сен 2019, 18:55 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Larisa писал(а):
По остальным интерфейсам наше устройство выступает как Master. И там все в порядке. Проверены не все (ПО в процессе разработки), но на одном из этих интерфейсов проходили длительные испытания с весьма интенсивным обменом (один из интерфейсов - обмен 1,5 кБ раз в 150 мс, скорость 230400, используется модификация протокола Modbus), за сутки ни одной ошибки.

Очень интересно...
А почему модификация Modbus? В чём состоит модификация?
Larisa писал(а):
Дополнительно пакеты не ставим, используем библиотеку LibModbus, далее вызовы Posix

Если вы используете стандартную библиотеку LibModbus ... там есть возможность существенно модифицировать Modbus?


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 сен 2019, 18:59 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
По поводу вашей наблюдаемой ошибки:
Larisa писал(а):
Далее два варианта ошибок.
1. Затем посылаем очередной запрос от Master, но ПО с функции select не уходит, то есть прикладная программа данных не видит. Но при этом в канал в ответ уходит 4кБ информации,
частино соответствующей прошлям запросам, это по нашему мнению на сейчас полностью выдается выходной буфер.
Далее обмен восстанавливается. До новых 4кБ. Проявляется при запросах, когда длина ответной посылки более 35 байт.
2. При запросах более коротких ответов нормальный обмен может проходить и более 100 000 раз, но потом порт обрывается наглухо, требуется пререзагрузка Slave устройства.

Т.е., во всех случаях у вас сбой происходит на select()?


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 сен 2019, 19:21 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Хотелось бы некоторые уточнения по ситуации ошибки...
P.S. Я с Modbus, и даже с serial, на C работал последний раз давно, лет 10 назад, поэтому хотелось бы освежить некоторые детали... Если я и возился с Modbus позже, то это было на Python.
Мне нужно адаптироваться и вспомнить что там было ... даже если некоторые вопросы или обсуждения покажутся неуместными... :oops:

Larisa писал(а):
Дополнительно пакеты не ставим, используем библиотеку LibModbus, далее вызовы Posix


Через RS-232 / RS-422 / RS-485 используются 2 варианта Modbus:

1. Modbus ASCII
Цитата:
Данные кодируются символами из таблицы ASCII и передаются в шестнадцатеричном формате. Начало каждого пакета обозначается символом двоеточия, а конец — символами возврата каретки и переноса строки. Это позволяет использовать протокол на линиях с большими задержками и оборудовании с менее точными таймерами.


2. Modbus RTU
Цитата:
В протоколе Modbus RTU данные кодируются в двоичный формат, и разделителем пакетов служит временной интервал. Этот протокол критичен к задержкам и не может работать, например, на модемных линиях. При этом, накладные расходы на передачу данных меньше, чем в Modbus ASCII, так как длина сообщений меньше.


3-й вариант - Modbus TCP - к вашему случаю не имеет отношения...
У вас, как я предполагаю, используется Modbus RTU?

Заголовки (хедер-файлы) LibModbus у вас вот это?:
Код:
olej@ACER:~/2019_WORK/own.WORK/Astra$ aptitude search libmodbus
i   libmodbus-dev                                                               - development files for the Modbus protocol library                                   
i A libmodbus5                                                                  - library for the Modbus protocol                                     

olej@ACER:/usr/include/modbus$ pwd
/usr/include/modbus

olej@ACER:/usr/include/modbus$ ls
modbus.h  modbus-rtu.h  modbus-tcp.h  modbus-version.h

Код:
olej@ACER:/usr/include/modbus$ cat modbus-version.h
...
/* The full version, like 1.2.3 */
#define LIBMODBUS_VERSION        3.1.4
...


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 сен 2019, 19:50 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Larisa писал(а):
Дополнительно пакеты не ставим, используем библиотеку LibModbus, далее вызовы Posix

API LibModbus (#include <modbus.h>) имеют вид modbus_*(), и не требуют дополнительно использовать POSIX API (и настройки порта + и select(), read() и т.д.).
Примеры, что я видел, имели какой-то такой вид:
Код:
 printf( "Waiting for Serial connection\n" );
 ctx = modbus_new_rtu( "/dev/ttymxc0", 115200, 'N', 8, 1 );
 modbus_set_slave( ctx, 0 );
 if( modbus_connect( ctx ) == -1 ) {
   fprintf( stderr, "Serial connection failed: %s\n", modbus_strerror( errno ) );
   modbus_free( ctx );
   return -1;
 }
 printf( "Serial connection started!\n" );
 mb_mapping = modbus_mapping_new( MODBUS_MAX_READ_BITS, 0, MODBUS_MAX_READ_REGISTERS, 0 );
 if( mb_mapping == NULL ) {
   fprintf( stderr, "Failed to allocate the mapping: %s\n", modbus_strerror( errno ) );
   modbus_free( ctx );
   return -1;
 }
 uint16_t tab_reg[ 64 ];
 rc = modbus_read_input_registers( ctx, 1, 0x0A, tab_reg );
 if( rc == -1 ) {
   fprintf( stderr, "%s\n", modbus_strerror( errno ) );
   return -1;
 }
 for( i = 0; i < rc; i++ )
   printf( "reg[%d]=%d (0x%X)\n", i, tab_reg[ i ], tab_reg[ i ] );
 modbus_mapping_free( mb_mapping );
 modbus_free( ctx );
 modbus_close( ctx );

Почему вы пошли по пути использования POSIX API (select(), read(), ...), которые низкоуровневые по отношению к Modbus?

И вам тогда необходимо вручную:
- выдерживать точно тайм-ауты требуемые Modbus RTU (что в Linux не совсем так просто);
- формировать код контрольной суммы CRC ...
- использовать какой-то производящий полином для вычисления CRC (может быть и 0xA001, или 0x8005 - в зависимости от способа которым вычисляете CRC).


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 сен 2019, 20:04 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
- использовать какой-то производящий полином для вычисления CRC (может быть и 0xA001, или 0x8005 - в зависимости от способа которым вычисляете CRC).

- нормальное представление:
Код:
#include <stdint.h>
#include <string.h>
#include <stdio.h>

const unsigned char *string = "123456789";   // Data character string
const uint16_t polynom = 0x8005;
const uint16_t crcinit = 0xFFFF;

unsigned long reflect( unsigned long crc, int bitnum ) { // зеркально отобразить биты
   unsigned long i, j = 1, crcout = 0;
   for ( i = (unsigned long)1 << ( bitnum - 1 ); i; i >>= 1 ) {
      if( crc & i ) crcout |= j;
      j <<= 1;
   }
   return crcout;
}

uint16_t crc_norm( const unsigned char* p, unsigned long lenght ) {
   unsigned long crc = crcinit;
   for( unsigned long i = 0; i < lenght; i++ ) {
      uint16_t c = reflect( (uint16_t)*p++, 8 );
      for( uint16_t j = 0x80; j; j >>= 1 ) {
         uint16_t bit = crc & 0x8000;
         crc <<= 1;
         if( c & j ) bit ^= 0x8000;
         if( bit ) crc^= polynom;
      }
   }   
   crc = reflect( crc, 16 );
   return crc;
}

int main() {
    printf( "%X : %s -> %X\n", polynom, string, crc_norm( string, strlen( string ) ) );
}

Код:
olej@ACER:~/2019_WORK/own.WORK/WaterBiz/Modbus/CRC16.c$ ./crc20
8005 : 123456789 -> 4B37


- реверсивное представление:
Код:
#include <stdint.h>
#include <string.h>
#include <stdio.h>

const unsigned char* string = "123456789";   // Data character string
const uint16_t polynom = 0xA001;
const uint16_t crcinit = 0xFFFF;

uint16_t crc_revr( const unsigned char* p, unsigned long lenght ) {
   uint16_t crc = crcinit, bit;
   for( unsigned long i = 0; i < lenght; i++ ) {
      crc ^= (uint16_t)*p++;
      for( int j = 0; j < 8; j++ ) {
         bit = crc & 0x0001;
         crc >>= 1;
         if( bit ) crc ^= polynom;
      }
   }
   return crc;
}

int main() {
   printf( "%X : %s -> %X\n", polynom, string, crc_revr( string, strlen( string ) ) );
}

Код:
olej@ACER:~/2019_WORK/own.WORK/WaterBiz/Modbus/CRC16.c$ ./crc10
A001 : 123456789 -> 4B37


При вычислениях CRC любой битности (разрядности) тестировать его принято на условной последовательности байт "123456789". И независимо от способа вычисления CRC16 (нормальный или реверсивный) для Modbus RTU результат на тестовой последовательности должен быть один: 4B37.

P.S. Это то, как я помню, и нашёл из своих бывших наработках по Modbus ... может чем-то пригодится.


Вложения:
crc20.c [1019 байт]
Скачиваний: 0
crc10.c [629 байт]
Скачиваний: 0
Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 10 сен 2019, 20:17 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Olej писал(а):
При вычислениях CRC любой битности (разрядности) тестировать его принято на условной последовательности байт "123456789". И независимо от способа вычисления CRC16 (нормальный или реверсивный) для Modbus RTU результат на тестовой последовательности должен быть один: 4B37.

Хотя никто так, через сдвиги, CRC16 не вычисляет, а вычисляют таблично:
Код:
#include <string.h>
#include <stdio.h>

/* Table of CRC values for high–order byte */
static unsigned char auchCRCHi[] = {
   0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
   0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
   0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
   0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,
   0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81,
   0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
   0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
   0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
   0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
   0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
   0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
   0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
   0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
   0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
   0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
   0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
   0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
   0x40
};

/* Table of CRC values for low–order byte */
static char auchCRCLo[] = {
   0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4,
   0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09,
   0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD,
   0x1D, 0x1C, 0xDC, 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3,
   0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7,
   0x37, 0xF5, 0x35, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A,
   0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE,
   0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26,
   0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2,
   0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F,
   0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB,
   0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5,
   0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x50, 0x90, 0x91,
   0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C,
   0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98, 0x88,
   0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
   0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80,
   0x40
};

unsigned short CRC16 ( unsigned char* puchMsg,    /* message to calculate CRC upon */
                       unsigned short usDataLen   /* quantity of bytes in message */
                     ) {                          /* The function returns the CRC as a unsigned short type */
   unsigned char uchCRCHi = 0xFF;                 /* high byte of CRC initialized */
   unsigned char uchCRCLo = 0xFF;                 /* low byte of CRC initialized */
   unsigned uIndex;                               /* will index into CRC lookup table */
   while( usDataLen-- ) {                         /* pass through message buffer */
      uIndex = uchCRCLo ^ *puchMsg++;             /* calculate the CRC */
      uchCRCLo = uchCRCHi ^ auchCRCHi[ uIndex ];
      uchCRCHi = auchCRCLo[ uIndex ];
   }
   return ( uchCRCHi << 8 | uchCRCLo );
}

int main() {
  char* string = "123456789";
  printf( "%s -> %X\n", string, CRC16( string, strlen( string ) ) );
}

Код:
olej@ACER:~/2019_WORK/own.WORK/Vector/modbus$ ./crct
123456789 -> 4B37


Вложения:
crct.c [4.24 КБ]
Скачиваний: 0
Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 11 сен 2019, 10:22 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Larisa писал(а):
На базе одноплатного ПК imx6ul создаем Slave устройство в сети Modbus.

Если вы готовите серийное устройство к производству и распространению + у вас вылазят вот такие плавающие ошибки...
Larisa писал(а):
Далее два варианта ошибок.
1. Затем посылаем очередной запрос от Master, но ПО с функции select не уходит, то есть прикладная программа данных не видит. Но при этом в канал в ответ уходит 4кБ информации,
частино соответствующей прошлям запросам, это по нашему мнению на сейчас полностью выдается выходной буфер.
Далее обмен восстанавливается. До новых 4кБ. Проявляется при запросах, когда длина ответной посылки более 35 байт.
2. При запросах более коротких ответов нормальный обмен может проходить и более 100 000 раз, но потом порт обрывается наглухо, требуется пререзагрузка Slave устройства.

... то я видел бы единственный путь для локализации и диагностики:
- написать простейшего вида 2 Modbus тестирующих приложения: Master + Slave ...
- замкнуть их по 2-м физическим каналам RS-485 (у вас же их 5?)...
- и гонять непрерывно по 1000000 обменов со случайными длинами пакетов данных, от 36 до 252 (это максимум в Modbus RTU?) байт...
- и накапливать статистику

P.S. А в рамках целевой системы, построенной для решения конкретной прикладной задачи, отловить такие "мерцающие" вещи невозможно. Это я предполагаю по опыту многократно наблюдаемых таких ситуаций в ходе реально выполняемых проектов.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 11 сен 2019, 14:31 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Вот краткое описание Modbus, с которым можно сверять обсуждение проблемы (относительно форматов, команд и т.д.) ... как мне кажется, с таким вот по-смешному записанным названием: Сетьевой протокол - Modbus:
Цитата:
Modbus был разработан фирмой Modicon (в настоящее время принадлежит Schneider Electric) для использования в её контроллерах с программируемой логикой. Впервые спецификация протокола была опубликована в 1979 году. Это был открытый стандарт, описывающий формат сообщений и способы их передачи в сети состоящей из различных электронных устройств.

Первоначально контроллеры MODICON использовали последовательный интерфейс RS-232. Позднее стал применяться интерфейс RS-485, так как он обеспечивает более высокую надёжность, позволяет использовать более длинные линии связи и подключать к одной линии несколько устройств.

Многие производители электронного оборудования поддержали стандарт, на рынке появились сотни использующих его изделий. В настоящее время развитием Modbus занимается некоммерческая организация Modbus-IDA, созданная производителями и пользователями электронных приборов.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 11 сен 2019, 17:01 
Не в сети
Интересующийся

Зарегистрирован: 04 сен 2019, 14:14
Сообщения: 6
Олег, у меня вопросы не по ModBus RTU, а по драйверам Ubuntu. У нас тысячи устройств с подержкой протокола работают по всему миру без проблем. По этому углубляться в вычисления CRC не имеет смысла. До Pоsix мы добрались внутри библиотеки LibModbus, там коды открыты. И проблемы лежат в области select(). Сейчас подключиди другую библиотеку SerialPort, отказавшить от LibModbus, проблемы те же. Что-то с драйвером.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 11 сен 2019, 17:34 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 12403
Откуда: Харьков
Larisa писал(а):
У нас тысячи устройств с подержкой протокола работают по всему миру без проблем.

У вас тысячи устройств, но они все работают не под Linux.
Larisa писал(а):
По этому углубляться в вычисления CRC не имеет смысла.

Детали имеют смысл для меня, чтобы понимать что вы там сделали... или чего, может быть, не сделали.
Если ваши устройства работают только с вашими устройствами - то как в деталях там реализовано не имеет значения: обе стороны согласованы друг с другом. Если ваши устройства успешно работают с внешними, рыночными, тиражными устройствами, сторонних производителей - это другое дело. Только 1-2 месяца назад я разгребался ровно с такой проблемой Modbus у других разработчиков.
Larisa писал(а):
у меня вопросы не по ModBus RTU, а по драйверам Ubuntu.

Я предполагаю (только IMHO, догадки), что проблема вылазит не в драйверах Ubuntu, а в ошибках использования API этих устройств в вашем программном коде: режимы инициализации канала, режимы приёма-передачи и др.
И уж точно вопросы не к Ubuntu конкретно, а к инструментам Linux вообще - вы никаким образом не пользуете специфические механизмы дистрибутива. Т.е. нужно смотреть сообщения о подобных проблемах во всех и разных дистрибутивах Linux ... но я такого не встречал.
Larisa писал(а):
До Pоsix мы добрались внутри библиотеки LibModbus, там коды открыты.

Это мне понятно. Мне непонятно - зачем? Зачем имея механизм более высокого уровня, использовать механизм более низкого уровня?
Larisa писал(а):
И проблемы лежат в области select(). Сейчас подключиди другую библиотеку SerialPort, отказавшить от LibModbus, проблемы те же. Что-то с драйвером.

Не убедительно. ;-)
Механизм select() - один из самых старых в UNIX, за 50 лет - вылизанный вдоль и поперёк. И работает успешно в тысячах проектов-приложений. Большинство сетевых приложений, вся IP-телефония - работают на базе select(), и с пакетами за раз (буферами) в разы больше ваших 35 байт или максимальных 252 байт.
Вызывает сомнение select() - используйте poll().
Вообще то, select() сильно перегруженный механизм, путанный - там слишком много деталей, степеней свободы настройки его параметрами. Смотрите, обязательно, вот эту книгу относительно select(), там есть детали, которых нет в других местах (там же и про poll() и его преимуществах перед select()):
Изображение
Скачать книгу можете здесь.

По поводу select() и проблем с ним:
- если у вас единственный канал (дескриптор) для чтения, то select() (с бесконечным тайм-аутом) с последующим за ним неблокирующим read()...
- ничем не отличается от простого блокирующего read()
- но 1-й вариант намного сложнее, а значит более склонный к ошибкам.


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB
[ Time : 0.241s | 19 Queries | GZIP : On ]