Re[10]: Неправильные данные в серийном порту
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 29.03.16 20:14
Оценка:
Здравствуйте, kov_serg, Вы писали:

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

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

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

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

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

Тогда идеал — последовательность повторов 0x0f.
The God is real, unless declared integer.
Re[11]: Неправильные данные в серийном порту
От: kov_serg Россия  
Дата: 31.03.16 10:50
Оценка:
Здравствуйте, 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
Re[12]: Неправильные данные в серийном порту
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 31.03.16 13:05
Оценка:
Здравствуйте, kov_serg, Вы писали:

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

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

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

break — это длинный ноль. 0x00 — это, грубо говоря, 9 единичных нулей. Пауза — сплошные единицы. Маловато общего.
Я бы понял ещё тестировать плотным потоком 0x00 или 0xff, это было бы проверкой качества передачи единичного бита противоположной полярности...
The God is real, unless declared integer.
Re[13]: Неправильные данные в серийном порту
От: kov_serg Россия  
Дата: 31.03.16 13:28
Оценка:
Здравствуйте, 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, это было бы проверкой качества передачи единичного бита противоположной полярности...
тут дискуссия бесполезна. зависит от того чего вы хотите проверить.
Re[2]: Неправильные данные в серийном порту
От: indee  
Дата: 14.04.16 07:37
Оценка:
Здравствуйте, 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) В идеале посмотреть сигналы на линии логическим анализатором, может там длина битовых интервалов на пределе допустимого.
Это ... как?
Re[4]: Неправильные данные в серийном порту
От: indee  
Дата: 14.04.16 07:38
Оценка:
Здравствуйте, Vain, Вы писали:

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

I>>>>Но иногда вместо ожидаемого набора символов получаю такую последовательность:
V>>>А иногда, это когда? С определённым периодом или случайно?
I>>Случайно, примерно, 1 к 1000.
V>Это относительно того набора, что в примере или, к примеру, здесь 1 это 1МБ данных, ну т.е. каждые 1ГБ?
Относитнльно набора.
Re[3]: Неправильные данные в серийном порту
От: andrey82  
Дата: 14.04.16 08:52
Оценка:
Здравствуйте, indee, Вы писали:

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

Устройство такое.. позволяет получить совмещенные по времени графики логических уровней по нескольким каналам. Например, как здесь Logic. Кстати, китайский клон этого Saleae Logic (на 8 каналов) стоит вообще смешных денег. Только для подключения надо будет преобразовать уровни RS232 в обычный TTL (5В).
Как раз недавно искал причину проблем во взаимодействии RPi с устройством на МК — мне нужно было во время передачи данных в порт выставлять высокий уровень на одной из ножек GPIO, а по окончании передачи массива байт — сразу переключать на низкий (это для стыковки с RS485). С помощью анализатора увидел, что переключение происходило раньше, чем завершение передачи байт — Serial.Write() в Mono работал без ожидания завершения отправки байт в линию.
Re: Неправильные данные в серийном порту
От: indee  
Дата: 14.04.16 09:05
Оценка:
Здравствуйте, 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 посылает и принимает данные правильно.
Re: Проблема в USB to RS-232 FTDI адаптере
От: indee  
Дата: 17.05.16 08:54
Оценка: 1 (1)
Проблема в USB to RS-232 FTDI адаптере.
Заменил FTDI на Prolific PL2303HX — все работает корректно, хотя это FTDI устройство в Windows работает надежно.
Re: Теперь проблемы с Raspberry Pi 3
От: indee  
Дата: 31.08.16 09:27
Оценка:
С 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>Спасибо!
Re: Неправильные данные в серийном порту
От: Mihas  
Дата: 31.08.16 10:00
Оценка:
Здравствуйте, indee, Вы писали:

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

Наблюдал такое же с полусамодельным конвертором USB->UART.
Предположу, что дело может быть где-то в подтяжке с трех-вольтового UART RPi до пяти вольт, которые нужны USB.
А может и дребезг сказывался.
Осцилографом бы посмотреть. Приходилось когда-то видеть "пилообразные битики" в последовательном канале вместо "П-образных".
Отредактировано 31.08.2016 10:03 Mihas . Предыдущая версия .
Re[2]: Неправильные данные в серийном порту
От: indee  
Дата: 02.09.16 06:24
Оценка:
Здравствуйте, Mihas, Вы писали:

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

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

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

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