Неправильные данные в серийном порту - C/C++. Прикладные вопросы

Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
Кабель серийного порта подключен к компьютеру где считываю данные.

В основном посланная строка "0123456789\r" считывается правильно:

number char int
0 0 48
1 1 49
2 2 50
3 3 51
4 4 52
5 5 53
6 6 54
7 7 55
8 8 56
9 9 57
10 13

Но иногда вместо ожидаемого набора символов получаю такую последовательность:

number char int
0 ﾪ 86
1 10
2 ﾢ 94
3 j 106
4 ﾊ 118
5 ﾨ 88
6 8
7 * 42
8 ﾠ 96
9 ( 40
10 8

код:

struct termios PortSettings;


bool OpenPort(){
          
    Port = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY);
    
    if(Port == -1){
        printf("%s", "Error of opening port /dev/ttyUSB0");
        printf("error %d opening %s: %s", errno, "", strerror (errno));
        return false;
    }
    else{
        printf("%s", "\n  ttyUSB0 Opened Successfully\n");        
    }    
    
    
    tcgetattr(Port, &PortSettings);
    
    cfsetispeed(&PortSettings,B9600);
    cfsetospeed(&PortSettings,B9600);
    
    PortSettings.c_cflag |=  PARENB;
    PortSettings.c_cflag &= ~CSTOPB;
    
    PortSettings.c_cflag &= ~CSIZE;
    PortSettings.c_cflag |=  CS8;    
    
    PortSettings.c_cflag |= CREAD | CLOCAL;
    
    PortSettings.c_cc[VMIN]  = 0; 
    PortSettings.c_cc[VTIME] = 20;
    
    PortSettings.c_iflag = 0;
    
    
    PortSettings.c_oflag = 0;
    PortSettings.c_lflag = 0;
    
    tcflush(Port, TCIFLUSH);
    
    tcsetattr(Port,TCSANOW,&PortSettings);    
    
    return true;
}


void WriteToPort(){
            
    tcflush(Port, TCIOFLUSH);
    
    write(Port, "0123456789\r", 11);
        
}

Параметры серийного порта: 9600, 8, evenparity, onestopbit

В чем может быть ошибка?

Спасибо!

Здравствуйте, indee, Вы писали:

I>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>Кабель серийного порта подключен к компьютеру где считываю данные.
...
I>Параметры серийного порта: 9600, 8, evenparity, onestopbit

I>В чем может быть ошибка?

Дребизг (плохой контакт). Или паразитная ёмкость.

10000110011 11000110001 10100110001 11100110011 10010110001 11010110011 10110110011 11110110001 10001110001 11001110011 11011000001
10110101011 10101000011 10111101001 10101011011 10110111001 10001101001 10001000001 10101010001 10000011011 10001010011 10001000001

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, indee, Вы писали:

I>>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>>Кабель серийного порта подключен к компьютеру где считываю данные.
_>...
I>>Параметры серийного порта: 9600, 8, evenparity, onestopbit

I>>В чем может быть ошибка?

_>Дребизг (плохой контакт). Или паразитная ёмкость.
_>

_>10000110011 11000110001 10100110001 11100110011 10010110001 11010110011 10110110011 11110110001 10001110001 11001110011 11011000001
_>10110101011 10101000011 10111101001 10101011011 10110111001 10001101001 10001000001 10101010001 10000011011 10001010011 10001000001
_>

Вряд ли, паразитный набор символов для строки "0123456789\r" всегда постоянен.

Здравствуйте, indee, Вы писали:

I>Здравствуйте, kov_serg, Вы писали:

_>>Здравствуйте, indee, Вы писали:

I>>>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>>>Кабель серийного порта подключен к компьютеру где считываю данные.
_>>...
I>>>Параметры серийного порта: 9600, 8, evenparity, onestopbit

I>>>В чем может быть ошибка?

_>>Дребизг (плохой контакт). Или паразитная ёмкость.
_>>

_>>10000110011 11000110001 10100110001 11100110011 10010110001 11010110011 10110110011 11110110001 10001110001 11001110011 11011000001
_>>10110101011 10101000011 10111101001 10101011011 10110111001 10001101001 10001000001 10101010001 10000011011 10001010011 10001000001
_>>

I>Вряд ли, паразитный набор символов для строки "0123456789\r" всегда постоянен.

Тогда отправляй другой набор данных для опытов

0x00, 0xFF, 0xF0, 0x0F, 0x33, 0xCC, 0x55, 0xAA, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80

Здравствуйте, indee, Вы писали:

I>В чем может быть ошибка?
Похоже на проблему в памятью. Какой-нибудь буфер не разваливается при чтении/записи?

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, indee, Вы писали:

I>>Здравствуйте, kov_serg, Вы писали:

_>>>Здравствуйте, indee, Вы писали:

I>>>>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>>>>Кабель серийного порта подключен к компьютеру где считываю данные.
_>>>...
I>>>>Параметры серийного порта: 9600, 8, evenparity, onestopbit

I>>>>В чем может быть ошибка?

_>>>Дребизг (плохой контакт). Или паразитная ёмкость.
_>>>

_>>>10000110011 11000110001 10100110001 11100110011 10010110001 11010110011 10110110011 11110110001 10001110001 11001110011 11011000001
_>>>10110101011 10101000011 10111101001 10101011011 10110111001 10001101001 10001000001 10101010001 10000011011 10001010011 10001000001
_>>>

I>>Вряд ли, паразитный набор символов для строки "0123456789\r" всегда постоянен.

_>Тогда отправляй другой набор данных для опытов

_>0x00, 0xFF, 0xF0, 0x0F, 0x33, 0xCC, 0x55, 0xAA, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80

При другом наборе данных, другой постоянный и неправильный набор данных.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, indee, Вы писали:

I>>В чем может быть ошибка?
K>Похоже на проблему в памятью. Какой-нибудь буфер не разваливается при чтении/записи?

Как это проверить?
Пробовал Valgrind, все чисто.
Проверял чтение снифером, вроде, кленту данные приходят уже битые, похоже, дисторшен на записи.

Здравствуйте, indee, Вы писали:

I>Как это проверить?
I>Пробовал Valgrind, все чисто.
I>Проверял чтение снифером, вроде, кленту данные приходят уже битые, похоже, дисторшен на записи.
Или уходят битыми, например. Если это таки проблема железа, то советы выше дали, но ИМХО, на железо грешить последнее дело.

Здравствуйте, indee, Вы писали:

_>>Тогда отправляй другой набор данных для опытов

_>>0x00, 0xFF, 0xF0, 0x0F, 0x33, 0xCC, 0x55, 0xAA, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80

I>При другом наборе данных, другой постоянный и неправильный набор данных.

Вы меня не поняли. Я имею ввдиду что на таком наборе данных проще смотреть дребизг.
Данные в ком порте идут последовательно [ 0 (Стратовый бит), Бит0, Бит1, Бит2 ... Бит7, Четность, 1 (стоп бит) ] [...] при этом штатно 0=+12в, 1=-12в
И комбинации 1111 [010101010P1] [010101010P1] [010101010P1] [010101010P1] [010101010P1] 1111 Сответстует строка 0x55,0x55,0x55,0x55,0x55.
Вызывает самую высокую частоту можно даже послушать динамиком.
Далее стартовая последовательнось обычно должна быть максимально энергоёмкой, так что 0x00 0xFF самое оно.

Еще вопрос как часто приходят неправильные данные?

Как вариант
поправь открытие порта

//Port = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY);
Port = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY);

убери flush

   // tcflush(Port, TCIOFLUSH); -- поробуй без этого
   static const char data[]={ 0x00, 0xFF, 0xF0, 0x0F, 0x33, 0xCC, 0x55, 0xAA, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 };
   write(Port, data, sizeof(data) );

Еще можешь сделать 2 стоповых бита вместо одного.
Заведи счетчик отправленых пакетов и передавай его в пакете.

Поменяй кабель на более короткий

Обычная отладка.

Здравствуйте, kov_serg, Вы писали:

_>Дребизг (плохой контакт). Или паразитная ёмкость.
_>10000110011 11000110001 10100110001 11100110011 10010110001 11010110011 10110110011 11110110001 10001110001 11001110011 11011000001
_>10110101011 10101000011 10111101001 10101011011 10110111001 10001101001 10001000001 10101010001 10000011011 10001010011 10001000001

Стартовый бит это логическая 0, соответственно, надо подправить все начала.
(Хотя какой-то чёткой картины от этого всё равно не возникает.)

Здравствуйте, kov_serg, Вы писали:

_>Далее стартовая последовательнось обычно должна быть максимально энергоёмкой, так что 0x00 0xFF самое оно.

Хм, откуда такое правило?

_>Еще вопрос как часто приходят неправильные данные?

_>убери flush
_> // tcflush(Port, TCIOFLUSH); -- поробуй без этого

Это сделает только хуже.

_>Поменяй кабель на более короткий

Ещё можно повысить/понизить скорость и сравнить частоту, если с ростом скорости растёт частота ошибки, то это, скорее всего, ошибка аналогового уровня.

Здравствуйте, Kernan, Вы писали:

K>Или уходят битыми, например. Если это таки проблема железа, то советы выше дали, но ИМХО, на железо грешить последнее дело.

Ну да — с какой там ревизии 16550A сделали действительно безглючный fifo?

Здравствуйте, indee, Вы писали:

I>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
А иногда, это когда? С определённым периодом или случайно?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:

_>>Далее стартовая последовательнось обычно должна быть максимально энергоёмкой, так что 0x00 0xFF самое оно.

N>Хм, откуда такое правило?

_>>Еще вопрос как часто приходят неправильные данные?

_>>убери flush
_>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого

N>Это сделает только хуже.

_>>Поменяй кабель на более короткий

N>Ещё можно повысить/понизить скорость и сравнить частоту, если с ростом скорости растёт частота ошибки, то это, скорее всего, ошибка аналогового уровня.
Кстати, понижение скорости это реальная тема? например до 2400.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, indee, Вы писали:

I>>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
V>А иногда, это когда? С определённым периодом или случайно?

Случайно, примерно, 1 к 1000.

Здравствуйте, indee, Вы писали:

I>>>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
V>>А иногда, это когда? С определённым периодом или случайно?
I>Случайно, примерно, 1 к 1000.
Это относительно того набора, что в примере или, к примеру, здесь 1 это 1МБ данных, ну т.е. каждые 1ГБ?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:

_>>Далее стартовая последовательнось обычно должна быть максимально энергоёмкой, так что 0x00 0xFF самое оно.

N>Хм, откуда такое правило?
Элементарно. Если вы хотите привлечь внимание надо громко рявкнуть потом можно говорить.

_>>Еще вопрос как часто приходят неправильные данные?

_>>убери flush
_>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого

N>Это сделает только хуже.
Не надо предположений. Просто попробуй.

_>>Поменяй кабель на более короткий

N>Ещё можно повысить/понизить скорость и сравнить частоту, если с ростом скорости растёт частота ошибки, то это, скорее всего, ошибка аналогового уровня.
Это правильно. Т.к. если у вас например силовая электроника или авто где рядом система зажигания, то интерфиренция сигналов, помехи
вполне нормальное явление. Поэтому используют контрольные суммы и короткие кадры.

XXX-------------XXX-------------XXX-------------XXX-------------XXX --переодический шум
----DD----DD----DX----DD----DD----XD----DD----DD----DD----DD----DX- --полезный сигнал

Хотя у вас
I>>>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
V>>А иногда, это когда? С определённым периодом или случайно?

I>Случайно, примерно, 1 к 1000.

Очень высокая вероятность. Постоянный неправильный кадр. Скорее всего это прогамный косяк.
Причем очень советую проверить не только передатчик. Но код приёмника.
Т.к. у вас передача с битом четности и не возникает ошибок. То полюбому где-то ляп.

Здравствуйте, kov_serg, Вы писали:

_>Хотя у вас

Это не у меня, я никак не связан с автором темы.

_>>>убери flush
_>>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого
N>>Это сделает только хуже.
_>Не надо предположений. Просто попробуй.

Мне не на чем пробовать, но я таки прошу обоснований к этому пункту.

По остальному — нет возражений (кроме неоднозначной "энергоёмкости" посылок).

Здравствуйте, indee, Вы писали:

I>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>Кабель серийного порта подключен к компьютеру где считываю данные.

I>Параметры серийного порта: 9600, 8, evenparity, onestopbit

Подкину еще версии:
1) Неточно согласованные скорости — частота порта (baudrate) формируется делением исходной частоты на целый коэффициент, что приводит к погрешностям. Актуально для МК со встроенным UART контроллером. К RPi скорее всего неприменимо, и искажения пакетов были бы практически постоянно.
2) В RPi/Raspbian последовательный порт /dev/ttyAMA0 изначально используется системой (консолью), надо отключать использование порта. Возможно, что и в другие порты может какой-то процесс вклиниваться.
3) Копать в сторону железа — как выполнено подключение к компьютеру? Кабель USB-UART на CP1202/FTDI со стороны ПК к UART линиям порта RPi? Или USB-RS232 адаптеры с обеих сторон? (/dev/ttyUSB0 намекает на этот вариант). В идеале посмотреть сигналы на линии логическим анализатором, может там длина битовых интервалов на пределе допустимого.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:

_>>Хотя у вас

N>Это не у меня, я никак не связан с автором темы.

_>>>>убери flush
_>>>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого
N>>>Это сделает только хуже.
_>>Не надо предположений. Просто попробуй.

N>Мне не на чем пробовать, но я таки прошу обоснований к этому пункту.
Некоторрые реализации flush могут не досылать данные, а просто сбрасывать контроллер uart.
соответственно если скорость 9600 то лучше не tcflush, а tcflush, sleep(2ms) т.к. 1байт ~ 1мс
Выдержать паузу очень важно. Т.к. помимо обычных rs232 бывают rs485 с длинной в километры, там еще интереснее глюки бывают.

N>По остальному — нет возражений (кроме неоднозначной "энергоёмкости" посылок).
Не очень понимаю что вызывает возражения. Это больше к физике процесса относится смотри телеграфное уравнение.
Если у тебя на линии есть чему поглащать сигнал, то более энергоёмкий пройдёт дальше и детектировать его проще.

Здравствуйте, kov_serg, Вы писали:

_>>>>>убери flush
_>>>>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого
N>>>>Это сделает только хуже.
_>>>Не надо предположений. Просто попробуй.
N>>Мне не на чем пробовать, но я таки прошу обоснований к этому пункту.
_>Некоторрые реализации flush могут не досылать данные, а просто сбрасывать контроллер uart.

Никакая реализация _flush_ не должна _досылать_ данные. Вы с tcdrain() не попутали?
Или речь про вычистку буферов, а не "досылать"? Тогда, да, некоторые контроллеры требуют хотя бы частичного сброса. Это нормально.

_>соответственно если скорость 9600 то лучше не tcflush, а tcflush, sleep(2ms) т.к. 1байт ~ 1мс
_>Выдержать паузу очень важно. Т.к. помимо обычных rs232 бывают rs485 с длинной в километры, там еще интереснее глюки бывают.

Верю. Но ТС явно сказал, что у него иной случай.

N>>По остальному — нет возражений (кроме неоднозначной "энергоёмкости" посылок).
_>Не очень понимаю что вызывает возражения. Это больше к физике процесса относится смотри телеграфное уравнение.
_>Если у тебя на линии есть чему поглащать сигнал, то более энергоёмкий пройдёт дальше и детектировать его проще.

Тогда идеал — последовательность повторов 0x0f.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:

_>>>>>>убери flush
_>>>>>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого
N>>>>>Это сделает только хуже.
_>>>>Не надо предположений. Просто попробуй.
N>>>Мне не на чем пробовать, но я таки прошу обоснований к этому пункту.
_>>Некоторрые реализации flush могут не досылать данные, а просто сбрасывать контроллер uart.

N>Никакая реализация _flush_ не должна _досылать_ данные. Вы с tcdrain() не попутали?
Имелось ввиду "не досылать" от слова недосылать. Т.е. обрывать передачу на середине передаваемого слова.

N>Или речь про вычистку буферов, а не "досылать"? Тогда, да, некоторые контроллеры требуют хотя бы частичного сброса. Это нормально.

_>>соответственно если скорость 9600 то лучше не tcflush, а tcflush, sleep(2ms) т.к. 1байт ~ 1мс
_>>Выдержать паузу очень важно. Т.к. помимо обычных rs232 бывают rs485 с длинной в километры, там еще интереснее глюки бывают.

N>Верю. Но ТС явно сказал, что у него иной случай.

N>>>По остальному — нет возражений (кроме неоднозначной "энергоёмкости" посылок).
_>>Не очень понимаю что вызывает возражения. Это больше к физике процесса относится смотри телеграфное уравнение.
_>>Если у тебя на линии есть чему поглащать сигнал, то более энергоёмкий пройдёт дальше и детектировать его проще.

N>Тогда идеал — последовательность повторов 0x0f.
Не обязательно: 0x00 пауза 0x00 пауза. Еще есть сигнал break

Здравствуйте, kov_serg, Вы писали:

_>>>>>>>убери flush
_>>>>>>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого
N>>>>>>Это сделает только хуже.
_>>>>>Не надо предположений. Просто попробуй.
N>>>>Мне не на чем пробовать, но я таки прошу обоснований к этому пункту.
_>>>Некоторрые реализации flush могут не досылать данные, а просто сбрасывать контроллер uart.
N>>Никакая реализация _flush_ не должна _досылать_ данные. Вы с tcdrain() не попутали?
_>Имелось ввиду "не досылать" от слова недосылать. Т.е. обрывать передачу на середине передаваемого слова.

Ну, если что-то передавалось раньше, оно побьётся. Когда оно и так не нужно. В чём проблема?
Вы думаете, следующая передача может начаться, когда приёмник ещё ждёт предыдущий байт?

N>>>>По остальному — нет возражений (кроме неоднозначной "энергоёмкости" посылок).
_>>>Не очень понимаю что вызывает возражения. Это больше к физике процесса относится смотри телеграфное уравнение.
_>>>Если у тебя на линии есть чему поглащать сигнал, то более энергоёмкий пройдёт дальше и детектировать его проще.
N>>Тогда идеал — последовательность повторов 0x0f.
_>Не обязательно: 0x00 пауза 0x00 пауза. Еще есть сигнал break

break — это длинный ноль. 0x00 — это, грубо говоря, 9 единичных нулей. Пауза — сплошные единицы. Маловато общего.
Я бы понял ещё тестировать плотным потоком 0x00 или 0xff, это было бы проверкой качества передачи единичного бита противоположной полярности...

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, kov_serg, Вы писали:

_>>>>>>>>убери flush
_>>>>>>>> // tcflush(Port, TCIOFLUSH); -- поробуй без этого
N>>>>>>>Это сделает только хуже.
_>>>>>>Не надо предположений. Просто попробуй.
N>>>>>Мне не на чем пробовать, но я таки прошу обоснований к этому пункту.
_>>>>Некоторрые реализации flush могут не досылать данные, а просто сбрасывать контроллер uart.
N>>>Никакая реализация _flush_ не должна _досылать_ данные. Вы с tcdrain() не попутали?
_>>Имелось ввиду "не досылать" от слова недосылать. Т.е. обрывать передачу на середине передаваемого слова.

N>Ну, если что-то передавалось раньше, оно побьётся. Когда оно и так не нужно. В чём проблема?
N>Вы думаете, следующая передача может начаться, когда приёмник ещё ждёт предыдущий байт?
Многократно такое наблюдал.

N>>>>>По остальному — нет возражений (кроме неоднозначной "энергоёмкости" посылок).
_>>>>Не очень понимаю что вызывает возражения. Это больше к физике процесса относится смотри телеграфное уравнение.
_>>>>Если у тебя на линии есть чему поглащать сигнал, то более энергоёмкий пройдёт дальше и детектировать его проще.
N>>>Тогда идеал — последовательность повторов 0x0f.
_>>Не обязательно: 0x00 пауза 0x00 пауза. Еще есть сигнал break

N>break — это длинный ноль. 0x00 — это, грубо говоря, 9 единичных нулей. Пауза — сплошные единицы. Маловато общего.
N>Я бы понял ещё тестировать плотным потоком 0x00 или 0xff, это было бы проверкой качества передачи единичного бита противоположной полярности...
тут дискуссия бесполезна. зависит от того чего вы хотите проверить.

Здравствуйте, andrey82, Вы писали:

A>Здравствуйте, indee, Вы писали:

I>>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>>Кабель серийного порта подключен к компьютеру где считываю данные.

I>>Параметры серийного порта: 9600, 8, evenparity, onestopbit

A>Подкину еще версии:
A>1) Неточно согласованные скорости — частота порта (baudrate) формируется делением исходной частоты на целый коэффициент, что приводит к погрешностям. Актуально для МК со встроенным UART контроллером. К RPi скорее всего неприменимо, и искажения пакетов были бы практически постоянно.
A>2) В RPi/Raspbian последовательный порт /dev/ttyAMA0 изначально используется системой (консолью), надо отключать использование порта. Возможно, что и в другие порты может какой-то процесс вклиниваться.
A>3) Копать в сторону железа — как выполнено подключение к компьютеру? Кабель USB-UART на CP1202/FTDI со стороны ПК к UART линиям порта RPi? Или USB-RS232 адаптеры с обеих сторон? (/dev/ttyUSB0 намекает на этот вариант). В идеале посмотреть сигналы на линии логическим анализатором, может там длина битовых интервалов на пределе допустимого.
Устройства серийных портов на ПК и RPi реализованы USB FTDI адаптерами. Устройства надежные, использую их годами без проблем.
A>3) В идеале посмотреть сигналы на линии логическим анализатором, может там длина битовых интервалов на пределе допустимого.
Это ... как?

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, indee, Вы писали:

I>>>>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
V>>>А иногда, это когда? С определённым периодом или случайно?
I>>Случайно, примерно, 1 к 1000.
V>Это относительно того набора, что в примере или, к примеру, здесь 1 это 1МБ данных, ну т.е. каждые 1ГБ?
Относитнльно набора.

Здравствуйте, indee, Вы писали:

A>>3) В идеале посмотреть сигналы на линии логическим анализатором, может там длина битовых интервалов на пределе допустимого.
I>Это ... как?

Устройство такое.. позволяет получить совмещенные по времени графики логических уровней по нескольким каналам. Например, как здесь Logic. Кстати, китайский клон этого Saleae Logic (на 8 каналов) стоит вообще смешных денег. Только для подключения надо будет преобразовать уровни RS232 в обычный TTL (5В).
Как раз недавно искал причину проблем во взаимодействии RPi с устройством на МК — мне нужно было во время передачи данных в порт выставлять высокий уровень на одной из ножек GPIO, а по окончании передачи массива байт — сразу переключать на низкий (это для стыковки с RS485). С помощью анализатора увидел, что переключение происходило раньше, чем завершение передачи байт — Serial.Write() в Mono работал без ожидания завершения отправки байт в линию.

Здравствуйте, indee, Вы писали:

I>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>Кабель серийного порта подключен к компьютеру где считываю данные.

I>В основном посланная строка "0123456789\r" считывается правильно:

I>number char int
I>0 0 48
I>1 1 49
I>2 2 50
I>3 3 51
I>4 4 52
I>5 5 53
I>6 6 54
I>7 7 55
I>8 8 56
I>9 9 57
I>10 13

I>Но иногда вместо ожидаемого набора символов получаю такую последовательность:

I>number char int
I>0 ﾪ 86
I>1 10
I>2 ﾢ 94
I>3 j 106
I>4 ﾊ 118
I>5 ﾨ 88
I>6 8
I>7 * 42
I>8 ﾠ 96
I>9 ( 40
I>10 8

I>код:

I>

I>struct termios PortSettings;


I>bool OpenPort(){
          
I>    Port = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY);
    
I>    if(Port == -1){
I>        printf("%s", "Error of opening port /dev/ttyUSB0");
I>        printf("error %d opening %s: %s", errno, "", strerror (errno));
I>        return false;
I>    }
I>    else{
I>        printf("%s", "\n  ttyUSB0 Opened Successfully\n");        
I>    }    
    
    
I>    tcgetattr(Port, &PortSettings);
    
I>    cfsetispeed(&PortSettings,B9600);
I>    cfsetospeed(&PortSettings,B9600);
    
I>    PortSettings.c_cflag |=  PARENB;
I>    PortSettings.c_cflag &= ~CSTOPB;
    
I>    PortSettings.c_cflag &= ~CSIZE;
I>    PortSettings.c_cflag |=  CS8;    
    
I>    PortSettings.c_cflag |= CREAD | CLOCAL;
    
I>    PortSettings.c_cc[VMIN]  = 0; 
I>    PortSettings.c_cc[VTIME] = 20;
    
I>    PortSettings.c_iflag = 0;
    
    
I>    PortSettings.c_oflag = 0;
I>    PortSettings.c_lflag = 0;
    
I>    tcflush(Port, TCIFLUSH);
    
I>    tcsetattr(Port,TCSANOW,&PortSettings);    
    
I>    return true;
I>}


I>void WriteToPort(){
            
I>    tcflush(Port, TCIOFLUSH);
    
I>    write(Port, "0123456789\r", 11);
        
I>}
I>

I>Параметры серийного порта: 9600, 8, evenparity, onestopbit

I>В чем может быть ошибка?

I>Спасибо!

Этот же самый код на ПК с Ubuntu посылает и принимает данные правильно.

С Raspberry Pi 3 все наоборот:

Prolific PL2303HX — почти не работает, а FTDI — более-менее... но всеравно не надежно

Здравствуйте, indee, Вы писали:

I>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>Кабель серийного порта подключен к компьютеру где считываю данные.

I>В основном посланная строка "0123456789\r" считывается правильно:

I>number char int
I>0 0 48
I>1 1 49
I>2 2 50
I>3 3 51
I>4 4 52
I>5 5 53
I>6 6 54
I>7 7 55
I>8 8 56
I>9 9 57
I>10 13

I>Но иногда вместо ожидаемого набора символов получаю такую последовательность:

I>number char int
I>0 ﾪ 86
I>1 10
I>2 ﾢ 94
I>3 j 106
I>4 ﾊ 118
I>5 ﾨ 88
I>6 8
I>7 * 42
I>8 ﾠ 96
I>9 ( 40
I>10 8

I>код:

I>

I>struct termios PortSettings;


I>bool OpenPort(){
          
I>    Port = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY);
    
I>    if(Port == -1){
I>        printf("%s", "Error of opening port /dev/ttyUSB0");
I>        printf("error %d opening %s: %s", errno, "", strerror (errno));
I>        return false;
I>    }
I>    else{
I>        printf("%s", "\n  ttyUSB0 Opened Successfully\n");        
I>    }    
    
    
I>    tcgetattr(Port, &PortSettings);
    
I>    cfsetispeed(&PortSettings,B9600);
I>    cfsetospeed(&PortSettings,B9600);
    
I>    PortSettings.c_cflag |=  PARENB;
I>    PortSettings.c_cflag &= ~CSTOPB;
    
I>    PortSettings.c_cflag &= ~CSIZE;
I>    PortSettings.c_cflag |=  CS8;    
    
I>    PortSettings.c_cflag |= CREAD | CLOCAL;
    
I>    PortSettings.c_cc[VMIN]  = 0; 
I>    PortSettings.c_cc[VTIME] = 20;
    
I>    PortSettings.c_iflag = 0;
    
    
I>    PortSettings.c_oflag = 0;
I>    PortSettings.c_lflag = 0;
    
I>    tcflush(Port, TCIFLUSH);
    
I>    tcsetattr(Port,TCSANOW,&PortSettings);    
    
I>    return true;
I>}


I>void WriteToPort(){
            
I>    tcflush(Port, TCIOFLUSH);
    
I>    write(Port, "0123456789\r", 11);
        
I>}
I>

I>Параметры серийного порта: 9600, 8, evenparity, onestopbit

I>В чем может быть ошибка?

I>Спасибо!

Здравствуйте, indee, Вы писали:

I>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
I>0 ﾪ 86

Наблюдал такое же с полусамодельным конвертором USB->UART.
Предположу, что дело может быть где-то в подтяжке с трех-вольтового UART RPi до пяти вольт, которые нужны USB.
А может и дребезг сказывался.
Осцилографом бы посмотреть. Приходилось когда-то видеть "пилообразные битики" в последовательном канале вместо "П-образных".

Здравствуйте, Mihas, Вы писали:

M>Здравствуйте, indee, Вы писали:

I>>Из Raspberry Pi в серийный порт пишу строку "0123456789\r".
I>>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
I>>0 ﾪ 86

M>Наблюдал такое же с полусамодельным конвертором USB->UART.
M>Предположу, что дело может быть где-то в подтяжке с трех-вольтового UART RPi до пяти вольт, которые нужны USB.
M>А может и дребезг сказывался.
M>Осцилографом бы посмотреть. Приходилось когда-то видеть "пилообразные битики" в последовательном канале вместо "П-образных".

У меня трех-вольтовые UART вообще не работают с RS232/ПК без усилителя.

	От:	indee
	Дата:	17.05.16 08:54
	Оценка:	1 (1)

	От:	indee
	Дата:	17.03.16 09:27
	Оценка:

	От:	kov_serg
	Дата:	17.03.16 15:10
	Оценка:

	От:	indee
	Дата:	17.03.16 15:51
	Оценка:

	От:	kov_serg
	Дата:	17.03.16 18:37
	Оценка:

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	17.03.16 20:19
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	20.03.16 09:33
Оценка:

От:	Vain	google.ru
Дата:	21.03.16 21:33
Оценка:

	От:	andrey82
	Дата:	22.03.16 07:25
	Оценка:

	От:	andrey82
	Дата:	14.04.16 08:52
	Оценка:

	От:	Mihas
	Дата:	31.08.16 10:00
	Оценка: