LINUX.ORG.RU

[C++] /dev/ttyS0 9-bit protocol

 


0

1

Приветствую всех.

Я реализую 9-битный протокол пердачи данных по последовательному интерфейсу в формате: START DATA7...DATA0 MODE STOP (Parity-bit определяет признак адреса устройств и конца сообщения). Я нашёл как устанавливать этот бит в 1 или 0 с помощью техники описанной здесь http://www.lothosoft.ch/thomas/libmip/markspaceparity.php :

"Setting 8S1 or 8M1 with the undocumented CMSPAR flag

Although undocumented, many systems support the CMSPAR flag (control mode flag for MARK/SPACE parity) defined as:

#define CMSPAR 010000000000

If this flag is set together with the PARENB (parity enable), SPACE/MARK parity is used instead of EVEN/ODD parity. To select SPACE parity, use

tio.c_cflag |= PARENB | CMSPAR;

tio.c_cflag &= ~PARODD;

in the termios struct of the serial device (see the termios manpage). MARK parity is selected by

tio.c_cflag |= PARENB | CMSPAR | PARODD;

The disadvantage of this method is that it might not work on all systems."

Вопрос в том как получить значение этого бита на принимающей стороне?

Принимающая сторона, в соответствии с протоколом, должна сделать аналогичные действия по переводу с 8битного режима на 9битный. Мудаки, которые писали протокол очевидно для микроконтроллеров наверно знают, когда, т.е. по какому правилу надо менять параметры СОМ порта.

Обычно 9бит вкулючают в начале, т.е. сначала нюхаут адрес устройства, и если он совпадает, то переводят СОМ порт в 8битный режим до получения CRC.

Удачи...

anonymous
()

Собственно значение бира приложению не надо получать! Принимающая сторона перенастраивает СОМ порт в 9битный режим в нужный момент времени. Но даже в 9юитном режиме отправитель и приёмник обмениваются 8битными данными, 9-й бит проверяют драйвера СОМ порта отправителя и приёмника.

anonymous
()
Ответ на: комментарий от anonymous

>Мудаки, которые писали протокол очевидно для микроконтроллеров наверно знают,

Очевидно что люди которые писали протокол напротив с головой - то что 8250 на PC не умеет работать в 9 битном режиме - это проблемы пользователей этого старого говна мамонта. Зато при таком раскладе не нужно реагировать на каждый прилетевший в порт байт - все лишнее сбрасывается аппаратно.

koTuk
()

Я не уверен что это сработает но основная идея уже прозвучала - тебе этот 9 бит не нужен, устанавливаешь псевдо 9 бит режим с mark на принимающей стороне и ожидаешь прихода байта (вот тут я не уверен что так будет работать - будет он сбрасывть байты приходящие со space или нет) в этом случае первый полученный байт и будет либо адресом целевого устройства либо завершением посылки. Если адрес твой переводишь на 9 бит со space без игнора ошибки четности с маркировкой "плохих" байт (байт с установленным mark придет в виде 0xff,0x00,mark_byte настоящий 0xff из потока будет заэкранирован 0xff,0xff)

koTuk
()
Ответ на: комментарий от koTuk

>Если адрес твой переводишь на 9 бит со space без игнора ошибки четности с маркировкой "плохих" байт (байт с установленным mark придет в виде 0xff,0x00,mark_byte настоящий 0xff из потока будет заэкранирован 0xff,0xff)

Я тут нагоордил - можно еще проще, переводишь в 8 битный режим 8n1, space бит будет восприниматься как стоповый а на байт c mark будет вызывать ошибку протокола передачи.

koTuk
()
Ответ на: комментарий от koTuk

>Очевидно что люди которые писали протокол напротив с головой - то что 8250 на PC не умеет работать в 9 битном режиме - это проблемы пользователей этого старого говна мамонта. Зато при таком раскладе не нужно реагировать на каждый прилетевший в порт байт - все лишнее сбрасывается аппаратно. koTuk * (*) (13.11.2008 22:28:12)

да умеет он работать и работает. Делают люди протоколы с поддержкой 9бит и оно работает на uart16550. Другое дело, зачем во время обмен данными менять параметры СОМ порта? Надо нормально писать протокол, чтобы не было такой необходимости. Да, конечно могли бы сделать uart16550 ,jлее интеллектуальным, ну уж что имеем, то и имеем. Конечно, устарел уже надо на ethernet переходить, а не париться с rs-485.

anonymous
()

Спасибо большое за советы. Идея хорошая попробую обязательно. Только беспокоет всё таки наличие этих 0хFF маркировок: у меня 0xFF в протоколе имеет значение negative-acknowledge character (NAK) :(

в целом протокол передачи имеет вид:

команды - ADDRESS* DATA[0..N] CHK

ответы - DATA[0..N] CHK* или однобайтовые - ACK, RET, NACK

* - означает установку бита mode(parity) в единицу.

Боюсь, что проверяться и маркироваться будет только чётность/нечетность, а не конкретно установка бита в 1 или 0 ...

necromant ★★
() автор топика
Ответ на: комментарий от necromant

>Боюсь, что проверяться и маркироваться будет только чётность/нечетность, а не конкретно установка бита в 1 или 0 ...

У меня тоже на счет этого сомнения есть. Еще вариант - вычислять этот 9 бит исходя из условий приема - но слишком через задницу получится... Идея такая - режим четности на принимающей стороне чет или нечет без разницы - как тебе удобней, не игноришь данные с ошибкой четности с отметкой как было написано выше (0xff,0x00,byte) в случае ошибки четности, прием побайтно - после приема каждого байта подсчитываешь количество ненулевых битов и исходя из установленной тобой четности и того что байт пришел с ошибкой или без ошибки вычисляешь какое значение имел 9 бит.

koTuk
()

есть вариант - ставиш внешний уарт который без проблем понимает 9 бит и пользуеш его по аналогии с микроконтроллерами.

Есть стандартные специально для этой цели но навскидку ниодного не помню

cvv ★★★★★
()
Ответ на: комментарий от necromant

>Только беспокоет всё таки наличие этих 0хFF маркировок

прочти еще раз документацию. кажется это настраивается

cvv ★★★★★
()
Ответ на: комментарий от cvv

спасибо за совет, но к сожалению железная часть проекта вне моего ведения - за аппаратную часть отвечают другие люди в другой части света, мне лишь нужно программно реализовать протокол и API-интерфейс к нему.

necromant ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.