2011-12-22 3 views
11

Я пытаюсь прочитать необработанные байты из последовательного порта, отправленного с помощью симулятора протокола Win32 IEC 870-5-101 с программой, написанной на C, запущенной на Linux 32bit.Чтение необработанных байтов из последовательного порта

Он отлично работает для значений байтов, таких как 0x00 - 0x7F. Но для значений, начиная от 0x80 до 0xAF старшего бита является неправильным, например .:

0x7F -> 0x7F //correct 
0x18 -> 0x18 //correct 
0x79 -> 0x79 //correct 
0x80 -> 0x00 //wrong 
0xAF -> 0x2F //wrong 
0xFF -> 0x7F //wrong 

После покопаться в течение двух дней в настоящее время, я понятия не имею, что причина этого.

Это мой конфигурации последовательного порта:

cfsetispeed(&config, B9600); 
    cfsetospeed(&config, B9600); 

    config.c_cflag |= (CLOCAL | CREAD); 

    config.c_cflag &= ~CSIZE;        /* Mask the character size bits */ 
    config.c_cflag |= (PARENB | CS8);      /* Parity bit Select 8 data bits */ 

    config.c_cflag &= ~(PARODD | CSTOPB);     /* even parity, 1 stop bit */ 


    config.c_cflag |= CRTSCTS;        /*enable RTS/CTS flow control - linux only supports rts/cts*/ 


    config.c_iflag &= ~(IXON | IXOFF | IXANY);    /*disable software flow control*/ 

    config.c_oflag &= ~OPOST;        /* enable raw output */ 
    config.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);  /* enable raw input */ 

    config.c_iflag &= ~(INPCK | PARMRK);     /* DANGEROUS no parity check*/ 
    config.c_iflag |= ISTRIP;        /* strip parity bits */ 
    config.c_iflag |= IGNPAR;        /* DANGEROUS ignore parity errors*/ 

    config.c_cc[VTIME] = 1;         /*timeout to read a character in tenth of a second*/ 

Я читаю из последовательного порта с:

*bytesread = read((int) fd, in_buf, BytesToRead); 

Сразу после этой операции «in_buf» содержит неверные байты, так Я думаю, что что-то не так с моей конфигурацией, которая является портом из структуры DCB win32.

Спасибо за любые идеи!

+0

Я отмечаю, что вы сказали: «Второе 4 бита неправильны ...», но ваши данные, по-видимому, показывают только, что высокий бит очищается. (& 0x7f) – BRFennPocock

+0

Я немного запутался в соглашениях об именах. Конечно, высокий бит ошибочен. Thx для уточнения. – punischdude

ответ

14

Основываясь на ваших примерах, только 8-й бит (высокий бит) ошибочен, и это неправильно, поскольку оно всегда 0. Вы устанавливаете ISTRIP в своей линейной дисциплине на стороне Linux, и это может вызвать это. ISTRIP не делает, как утверждает комментарий в коде C, разбивает биты четности. Он разделяет 8-й бит данных.

Если ISTRIP установлен, действительные входные байты сначала должны быть разделены на семь бит; в противном случае все восемь бит должны обрабатываться. IEEE Std 1003.1, 2004 Edition, chapter 11, General Terminal Interface

+0

Спасибо за информацию о 8E1. Никогда не знал этого. –

+0

Спасибо! 'config.c_iflag & = ~ ISTRIP;' сделал трюк. – punischdude

+0

Должен любить эти вводящие в заблуждение комментарии. –

Смежные вопросы