3 ATMega8 к 1 COM-порту ПК Опции

[li4]

Подскажите пожалуйста как решить такую задачу. Есть 3 ATMega8 каждый из которых используется как 3-х канальный АЦП. Мне нужно их все подключить к одному COM-порту компьютера, причем нужно чтобы передача данных происходила без потерь. Ведь пока 1 контроллер передает данные в ПК, остальные тоже работают, а данные передавать не могут, потому что линия занята.

[Сергей Борщ]

Подскажите пожалуйста как решить такую задачу. Есть 3 ATMega8 каждый из которых используется как 3-х канальный АЦП. Мне нужно их все подключить к одному COM-порту компьютера, причем нужно чтобы передача данных происходила без потерь. Ведь пока 1 контроллер передает данные в ПК, остальные тоже работают, а данные передавать не могут, потому что линия занята.

Поставить четвертый ATMega8, который будет через три софтовых UART общаться с этими, а через аппаратный на вчетверо большей скорости общаться с PC. Ну и естественно в протоколе с РС должна быть реализована поддержка мультиплексирования потока данных.

[Dopler]

Подскажите пожалуйста как решить такую задачу. Есть 3 ATMega8 каждый из которых используется как 3-х канальный АЦП. Мне нужно их все подключить к одному COM-порту компьютера, причем нужно чтобы передача данных происходила без потерь. Ведь пока 1 контроллер передает данные в ПК, остальные тоже работают, а данные передавать не могут, потому что линия занята.

Это реализуется довольно просто, все зависит от объемов данных.
Вот самый примитивный вариант:

1. В каждой меге буффер данных, например, 1024 байт
2. Каждая мега знает свой адрес (номер) на шине, например, 1, 2, 3.
3. Инициатором обмена всегда выступает ПК.
4. ПК шлет адрес меги, а та в свою очередь выдает данные и переводит линии в третье состояние.
5. Так опрашиваются все меги по очереди.

Главное убедится, что время заполнения буффера в три и более раз меньше, чем время передачи данных в ПК. Так же, по адресной посылке меги можно синхронизировать (если это надо).

Можно почитать пункт Multi-processor Communication Mode в разделе описания UART в даташите, там Atmel дает некоторые рекомендации.

[defunct]

...

Идея правильная

Только вот здесь небольшая проблемка:

4. ПК шлет адрес меги, а та в свою очередь выдает данные и переводит линии в третье состояние.

Толку переводить линии в третье состояние? Чтобы больше никогда не словить обращение Хоста?..
Тут нужно добавить внешний мультиплексор, завести на его входы Tx от каждого МК, выход мультиплексора подключить к входу RS232 преобразователя. Rx'ы всех МК соединить параллельно и подключить к выходу RS232 преобразователя.

[vvs157]

Толку переводить линии в третье состояние? Чтобы больше никогда не словить обращение Хоста?..

В 3-е сотояние должны переводиться выходы Мег, а не компьютера

[Dopler]

...

Идея правильная

Только вот здесь небольшая проблемка:

4. ПК шлет адрес меги, а та в свою очередь выдает данные и переводит линии в третье состояние.

Толку переводить линии в третье состояние? Чтобы больше никогда не словить обращение Хоста?..
Тут нужно добавить внешний мультиплексор, завести на его входы Tx от каждого МК, выход мультиплексора подключить к входу RS232 преобразователя. Rx'ы всех МК соединить параллельно и подключить к выходу RS232 преобразователя.

Да ну, зачем такие сложности.

Линии TX от ПК соединяются в одну и подключаются к линиям RX меги (без мультиплексоров), так как линии RX у меги входные. Линии TX от мег соединяются в одну и подключаются к RX ПК. В неактивном состоянии (в режиме, когда ПК выбрал другую мегу) мега переводит свою линию TX в третье состояние (как только заканчивает передачу данных), а когда получает свой адрес по линии RX (которая всегда активна), берет контроль над своей линией TX. Таким образом, в сети будет активна только одна мега, и их можно подключать до бесконечности.
Стоит помнить, что в UART неактивный уровень - лог. единица, поэтому линия TX мег должна быть подтянута к плюсу.

[defunct]

Линии TX от ПК соединяются в одну и подключаются к линиям RX меги (без мультиплексоров), так как линии RX у меги входные.

Tx-линия у ПК одна..
Так что здесь вы повторяете то, что было сказано в моем посте.

Линии TX от мег соединяются в одну и подключаются к RX ПК. В неактивном состоянии (в режиме, когда ПК выбрал другую мегу) мега переводит свою линию TX в третье состояние

Здесь поподробнее.
Как можно перевести Tx линию аппаратного UART'a в Z состояние, не отключив при этом RX?

[Dopler]

Линии TX от мег соединяются в одну и подключаются к RX ПК. В неактивном состоянии (в режиме, когда ПК выбрал другую мегу) мега переводит свою линию TX в третье состояние

Здесь поподробнее.
Как можно перевести Tx линию аппаратного UART'a в Z состояние, не отключив при этом RX?

Да очень просто, в аппаратном UART приемник и передатчик разрешаются отдельно (размыми битами). Уроды в Atmele решили, что копирование из даташитов может повредить, поэтому не могу привести выдержку. Посмотрите описание битов RXEN и TXEN, каждый из них оказывает независимое влияние на соответствующие линии МК.

[defunct]

Посмотрите описание битов RXEN и TXEN, каждый из них оказывает независимое влияние на соответствующие линии МК.

Точно!
Что-то сегодня меня совсем переклинило.

Ну тогда нет проблем

[Dopler]

Посмотрите описание битов RXEN и TXEN, каждый из них оказывает независимое влияние на соответствующие линии МК.

Точно!
Что-то сегодня меня совсем переклинило.

Ну тогда нет проблем

Проблемы возникают, когда необходимо передавать данные через дифференциальные пары (LVDS и тому подобное), вот там приходится городить монтажное или.

[jorikdima]

А можно я тут несколько в сторону отойду. У меня похожий вопрос. Но только мне надоне собирать с нескольких источников, а передавать в несколько приемников. А именно:
Есть MSP430, у него 2 USART (UART или SPI или I2C). И есть 3 или 4 внешних устройства, с которыми контроллер должен общаться - комп по UART, zigbee приемопередатчик по SPI, LCD по I2C, и внешняя флешь по... еще не разбирался, но наверно тоже по SPI. И что делать
Внешний мультиплексор не особо хочется ставить, надо низкое потребление.
Но, вообще говоря, не будет такой ситуации, когда все эти 4 устройства будут работать одновременно, все эти процессы можно разделить по времени. Как в такиз случаях поступают??
Спасибо

[Serj78]

Подтверждаю, можно отдельно включать и приемник и передатчик. У меня через uart объединены 4 контроллера,один из них мастер- обменивается с другими тремя. Все выходы, правда подключены через резисторы 680 ом, но это просто в целях безопасности портов .

2 jorikdima - можно завести на некоторые устройства ножки разрешения работы.у spi оно точно есть, на другие можно попробовать организовать программно. у меня например на одном устройстве из 3-х нет времени ждать пока пройдет адрес- нужен мнгновенный ответ- там соответственно есть ножка отдельная- синхронизация обмена.

[Dog Pawlowa]

Да ну, зачем такие сложности.
Линии TX от мег соединяются в одну и подключаются к RX ПК. В неактивном состоянии (в режиме, когда ПК выбрал другую мегу) мега переводит свою линию TX в третье состояние (как только заканчивает передачу данных), а когда получает свой адрес по линии RX (которая всегда активна), берет контроль над своей линией TX. Таким образом, в сети будет активна только одна мега, и их можно подключать до бесконечности.

Действительно, зачем такие сложности?
Цена вопроса - три диода и резистор без всяких изысков программирования.
Схема называется "монтажное ИЛИ" и приводится в книжках по цифровой электронике уже 40 лет

Но я не понял одного - разве есть компьютеры с TTL выходом последовательного интерфейса. Автор, Вы в курсе про RS232 уровни и TTL уровни?

[li4]

Спасибо всем ответившим.

Линии TX от мег соединяются в одну и подключаются к RX ПК.

Если это допустимо то проще уж наверное ничего не придумать. Значит для счастья нужна лишь программа МК которая будет:
1)TX всех МК перевести в Z состояние
2)Считывать данные из RX порта.
3)Если запрос на считывание не пришел записывать результат оцифорвки в буферную память
4)Если пришел запрос на считывание выдавать в TX все что накопилось в буфере, и текущий результат оцифорвки

Я в программировании для МК не очень силен, поэтому мне бы на AVR C такую программу или хотябы ее часть посмотреть как делается, был бы очень вам признателен.

Сообщение отредактировал li4 - Jan 6 2007, 09:16

[Сергей Борщ]

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

Раз не требуется одновременная работа - то все просто. У MSP430 SPI, UART и I2C(если не изменяет память) выведены на разные ноги, поэтому просто включай нужную периферию через ME1, ME2 и выбирай нужную ногу через PxSEL. Часть интерфейсов можно реализовать программно (например I2C для индикатора).

P.S. продолжать лучше в разделе про MSP

Спасибо всем ответившим.

Линии TX от мег соединяются в одну и подключаются к RX ПК.

Если это допустимо то проще уж наверное ничего не придумать.

Если эти 3 меги находятся на одной плате - тогда действительно это наиболее простое решение. А вот если между ними значительное расстояние, то тянуть TTL уровни уже нельзя а RS232 объединение не позволяет. Я чего-то подумал что есть три законченных устройства, каждое из которых общается с компом, и надо их свести вместе.

[li4]

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

Так и есть. Сейчас это 3 законченных устройства, каждое из которых по отдельности может быть подключено к com-порту компьютера.
А почему нельзя RS232 так объединить?

Сообщение отредактировал li4 - Jan 6 2007, 12:54

[beer_warrior]

А почему нельзя RS232 так объединить?

А потому, что выходы приемопередатчиков не открытый коллектор, а двухтактные. И что будет если на одном выходе 1, а на другом 0 ?
(Входы можно объеденять почти неограничено)

[Dopler]

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

Так и есть. Сейчас это 3 законченных устройства, каждое из которых по отдельности может быть подключено к com-порту компьютера.
А почему нельзя RS232 так объединить?

Действительно, если надо соединить уже три законченных устройства, то просто объединить линии RS232 (те, которые +10, -10 В) не получится. В этом случае проще всего в каждом устройстве сигналы TTL уровня UART перевести в дифференциальный стандарт (RS485 или LVDS), которые позволяют передавать данные на расстояние до 100 метров, а затем на маленькой платке перед ПК перевести эти сигналы обратно в TTL уровни и объединить по монтажному ИЛИ, преобразовать в RS232 и передать в ПК.

Логика работы програм в МК остается той же самой.

[SasaVitebsk]

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

Так и есть. Сейчас это 3 законченных устройства, каждое из которых по отдельности может быть подключено к com-порту компьютера.
А почему нельзя RS232 так объединить?

Честно говоря, не понимаю зачем делать ч/з заднюю дверь.
1) Вам предлагается применить схемотехническое решение на уровне 5V, так как RS232 не предполагает объединений и ADM232(или 207 к примеру) просто вылетит. Но для этого предусмотрен интерфейс RS485 или RS422 со своими драйверами ADM485 (и много других фирм AD,TI,MAX,...) которые предусматривают паралельную работу и стоят СТОЛЬКО ЖЕ!
2) Вам предлагают использовать режим Мастер-Слэйв, так как RS232 предполагает ОДНОВРЕМЕННУЮ передачу в две стороны и аппаратное управление потоком. Именно в RS485 используется режим Мастер-слэйв, а в 422 мультимастер с разрешением коллизий. То есть програмно Вам придётся творить что-то подобное.
3) Результирующий монстр будет непонятного интерфейса, а если Вы будете реализовывать RS485, то Вы можете гордо указать это! И, что ещё важнее, Вы сможете легко добавить пятое, шестое .... и т.д. изделия.

Ну и последнее. Я сейчас практически не применяю COM порт. Проще применить USB. В данном случае переходник USB<->RS232 будет содержать 2 микрухи (FT232RL+ADM207), а USB<->RS485 две(FT232RL+ADM485) или три микрухи (+74HC00) и помещается в спичечный коробок.

[Dog Pawlowa]

.. Именно в RS485 используется режим Мастер-слэйв, а в 422 мультимастер с разрешением коллизий. То есть програмно Вам придётся творить что-то подобное.

Уважаемый, не пугайте народ
Интерфейс RS422 - это всего лишь две дифференциальных пары - Rx и Tx вместо одной в RS485.
Мультимастеринг не оговаривается и в подавляющем большинстве реальных протоколов не используется.

Действительно, если надо соединить уже три законченных устройства, то просто объединить линии RS232 (те, которые +10, -10 В) не получится.

Ну, смотря что называть словом "просто"
Непосредственно - да, не получится. А с помощью тех же волшебных трех диодов и резистора - запросто получится. Это сложно?

[Dopler]

Действительно, если надо соединить уже три законченных устройства, то просто объединить линии RS232 (те, которые +10, -10 В) не получится.

Ну, смотря что называть словом "просто"
Непосредственно - да, не получится. А с помощью тех же волшебных трех диодов и резистора - запросто получится. Это сложно?

Получится и не сложно, судя по всему, автору поста так и надо поступить.

[Сергей Борщ]

Непосредственно - да, не получится. А с помощью тех же волшебных трех диодов и резистора - запросто получится. Это сложно?

Два замечания:
1) Потребуется еще один диод и конденсатор чтобы получать из Tx компьютера уровень -12, к которому будет подтягивать ваш резистор (Можно использовать DTR, RTS но их терминалка любит ставить в +12).
2) Дальность и помехоустойчивость такого решения будет сильно ниже чем у "честного" RS232 (хотя его дальше соседнего стола редко кто таскает).

[SasaVitebsk]

.. Именно в RS485 используется режим Мастер-слэйв, а в 422 мультимастер с разрешением коллизий. То есть програмно Вам придётся творить что-то подобное.

Уважаемый, не пугайте народ
Интерфейс RS422 - это всего лишь две дифференциальных пары - Rx и Tx вместо одной в RS485.
Мультимастеринг не оговаривается и в подавляющем большинстве реальных протоколов не используется.

Вот блин даже попугать не дадут.
На самом деле RS422/485/232 не описывают програмные протоколы а определяют разъёмы и сигналы. Поэтому это я к слову. Но построение определяет. RS422 это даже не две пары, но бог с ними ...

Вы мне объясните, дураку.
1) Почему нельзя применить RS485?
2) Что это за интерфейс у Вас получится?
3) Как это всё механически будет выглядеть? Три законченных устр-ва с преобраз или без них подключаются к коробочке, в которой стоят пребраз. в 5V, потом диоды или микросхема и выходные преобразователи. Плюс внешнее питание! Или если без преобразователей, то 5V короткий кабель (30см) коробочка в ней мелкосхема и выходные преобразователи. Плюс внешнее питание или питание заводится от одного из устр-в. Простите но это же бред!!!
4) Чем хуже мой вариант? Законченное устр-во с двумя разъёмами. Допускает подключение до 32 устр-в. По цене - то же решение. По надёжности и помехозащищённости лучше. По дальности лучше. Конструктивно законченое. Програмно - абсолютно одинаково придётся решать.

Так в чём дело? Кто-нибудь мне пояснит?

[li4]

Почему нельзя применить RS485?

Я спросил потому что не знаю как реализовать, а разнообразие ответов меня немного сбивает с толку. Что лучше использовать? Если RS485 подходит, то буду искать примеры на эту тему. Спасибо.

Сообщение отредактировал li4 - Jan 6 2007, 23:23

[Сергей Борщ]

Вы мне объясните, дураку.
1) Почему нельзя применить RS485?

4) Чем хуже мой вариант? Законченное устр-во с двумя разъёмами. Допускает подключение до 32 устр-в. По цене - то же решение. По надёжности и помехозащищённости лучше. По дальности лучше. Конструктивно законченое. Програмно - абсолютно одинаково придётся решать.

Так в чём дело? Кто-нибудь мне пояснит?

Ну первое что приходит в голову:
а) придется переделывать не только софт существующих устройств но и их железо.
б) Устройство в количестве 1 шт. само по себе работать не сможет - все равно нужен будет переходник в 485(422).

В остальном - конечно, в случае нескольких устройств применение 485 оправдано и грамотно. Обсуждаемый вариант соединения RS232 по И элементом диодно-резисторной логики на рассыпухе - это скорее наиболее простое, быстрое, настольное, одноразовое решение для себя. Т.е. себе я бы так сделал, кому-то - или 485 или мультиплексор на проце однозначно.

[defunct]

Почему нельзя применить RS485?

Я спросил потому что не знаю как реализовать, а разнообразие ответов меня немного сбивает с толку. Что лучше использовать? Если RS485 подходит, то буду искать примеры на эту тему. Спасибо.

Подходит более чем, это будет стандартное решение задачи.

Просто уже редко встречаются темы где стандартные решения уместны. ;>
Вот вам и насоветовали экзотики.

[li4]

Значит выбираю RS485 .
Достаточно каждый контроллер (выводыTX и RX) подключить к DS485 и тогда их можно будет объединить в одну линию? А чтобы эту линию подключить к компу использовать один преобразователь ST232?

Сообщение отредактировал li4 - Jan 7 2007, 01:18

[SasaVitebsk]

Значит выбираю RS485 .
Достаточно каждый контроллер (выводыTX и RX) подключить к DS485 и тогда их можно будет объединить в одну линию? А чтобы эту линию подключить к компу использовать один преобразователь ST232?

преобразователь типа такого

Прикрепленные файлы

 USB_485.zip ( 18.3 килобайт ) Кол-во скачиваний: 101

 

[li4]

С USB это интересно и перспективно, но сначала хочу подключить к COM-порту, потому что уже есть готовая программа для считывания из него, а с USB у меня вообще опыта работы нет.
Выводы TX и RX ADM485 можно подключать напрямую к соответствующим выводам ATMega8 или нужно сначала преобразовать уровни с помощью ADM232?

Сообщение отредактировал li4 - Jan 7 2007, 12:31

[defunct]

С USB это интересно и перспективно, но сначала хочу подключить к COM-порту, потому что уже есть готовая программа для считывания из него, а с USB у меня вообще опыта работы нет.
Выводы TX и RX ADM485 можно подключать напрямую к соответствующим выводам ATMega8 или нужно сначала преобразовать уровни с помощью ADM232?

Дык Вам не придется менять программу, подключив устройство на FT232 к USB у вас появится просто еще один ком-порт..

[Сергей Борщ]

Выводы TX и RX ADM485 можно подключать напрямую к соответствующим выводам ATMega8 или нужно сначала преобразовать уровни с помощью ADM232?

Почитайте даташит, сравните уровни напряжения, подумайте.

[prottoss]

Подскажите пожалуйста как решить такую задачу. Есть 3 ATMega8 каждый из которых используется как 3-х канальный АЦП. Мне нужно их все подключить к одному COM-порту компьютера, причем нужно чтобы передача данных происходила без потерь. Ведь пока 1 контроллер передает данные в ПК, остальные тоже работают, а данные передавать не могут, потому что линия занята.

Очень много насоветованно и я тоже хочу посоветовать))) Зайдите на http://modbus.org там много чего полезного подчерпнете я думаю, если, конечно, английским владеете

[Dog Pawlowa]

Вы мне объясните, дураку.
1) Почему нельзя применить RS485?
2) Что это за интерфейс у Вас получится?
3) Как это всё механически будет выглядеть?
4) Чем хуже мой вариант?
Так в чём дело? Кто-нибудь мне пояснит?

Да Вы правы во всем! Конечно, RS485 лучше. Но...
Я лично не стал советовать RS485 исходя из уровня знаний автора топика. Он программист на PC. Чтобы использовать RS485, ему нужно сделать следующие вещи в области, которой он не занимался:
- подключить драйвер RS485 к микроконтроллеру
- дописать управление направлением в программу микроконтроллера
- изготовить переходник RS232-RS485 (взяв откуда-то 5В питания)
- дописать управление направлением в программу микроконтроллера
- столкнуться с неприятностями, которые создает Windows
- смириться с этими неприятностями :-)
Убедиться, что все равно получается левое решение (интрефейсы гальванически не развязаны со всеми вытекающими последствиями), в один момент сжечь порты компьютера или пару микроконтроллеров, не говоря уже о постоянных сбоях...
Нет уж, пусть он попытается обойтись заранее простым решением.

[li4]

Почитайте даташит, сравните уровни напряжения, подумайте.

Действительно, что-то я совсем обнаглел, вместо того чтобы описание почитать сразу готовый ответ захотел, извиняюсь .
Из описания ST485:

Код

Absolutle maximum ratings:
Vcc: 12V
RE, DE: 05V..Vcc+0.5V
Vdi(DI):-0.5..Vcc+0.5V
Vdo(A,B): +-14V
Vri(A,B): +-14V
Vro(RO): -0.5..Vcc+0.5V

Значит наверное надо подключать так:
COM-порт ПК к RS485:

ATMega8 к RS485:

Правильно?

Нет уж, пусть он попытается обойтись заранее простым решением.

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

Сообщение отредактировал li4 - Jan 7 2007, 17:15

[prottoss]

Значит наверное надо подключать так:

Посмотрите вот этого зверя, может понравится

Прикрепленные файлы

 SP331.pdf ( 169.88 килобайт ) Кол-во скачиваний: 227

 

[SasaVitebsk]

Да Вы правы во всем! Конечно, RS485 лучше. Но...
Я лично не стал советовать RS485 исходя из уровня знаний автора топика. Он программист на PC. Чтобы использовать RS485, ему нужно сделать следующие вещи в области, которой он не занимался:
- подключить драйвер RS485 к микроконтроллеру
- дописать управление направлением в программу микроконтроллера
- изготовить переходник RS232-RS485 (взяв откуда-то 5В питания)
- дописать управление направлением в программу микроконтроллера
- столкнуться с неприятностями, которые создает Windows
- смириться с этими неприятностями :-)
Убедиться, что все равно получается левое решение (интрефейсы гальванически не развязаны со всеми вытекающими последствиями), в один момент сжечь порты компьютера или пару микроконтроллеров, не говоря уже о постоянных сбоях...
Нет уж, пусть он попытается обойтись заранее простым решением.

Так я Вас не обвиняю. Я просто предложил своё. Пусть сам выбирает.
- Драйвер RS485 подключается практически так же.
- Программу (причём обе) скорее всего ему ломать всё равно придётся. Ваше будет аппаратное решение или моё - неважно. Вы то понимаете что три независимых устр-ва подключаются к одному порту! Тут как не крути придётся делать арбитраж или устранение коллизий. И то и другое - это изменение программы.
- Я предложил на USB, но можно и на RS232. Питание в этом случае берётся так. Ч/з диоды с неиспользуемых выходов (DTR,RTS) снимается 12V и с него формируется 5V. Остальное также как и в моей схеме.
- можно и автоматическое переключение, но я делаю програмное. На самом деле - три корооотеньких прерывания.
- Да Винда, особенно если ч/з USB и VirtualComPort создали (для меня) неразрешимые проблемы, поэтому....
- я предложил действительно смирится и использовать аппаратное переключение направления от компа

А вот здесь я с Вами не соглашусь. Получается стандартное для такого случая решение. Драйвера поддерживают все мыслимые стандарты и я ни разу не видел "вышебленных" портов таким образом! Ну и я не знаю о каких сбоях Вы говорите. В моём последнем изделии я применил RS485 (надо была дальность большая) Правда мне хватает скорости 1200, но я предусмотрел 115200. Так я пробовал передавать на 305 метров (бухта сетевого кабеля) файлы 64Кб со скоростью 4800. Сбоев не было. Но люди в этом форуме пишут что работают на скорости 2Мбита по этому интерфейсу.

[Dog Pawlowa]

...Питание в этом случае берётся так. Ч/з диоды с неиспользуемых выходов (DTR,RTS) снимается 12V и с него формируется 5V...
... Ну и я не знаю о каких сбоях Вы говорите...

Несколько уточнений...
Если питание взять, как Вы предлагаете, это не будет настоящий RS485, потому что в этом случае не будет обеспечена нагрузочная способность драйвера. Это значит, что работать в принципе будет, но с оговорками по скорости и расстоянию. Ссылки на то, что у Вас все работало хорошо, не принимаются

А про сбои... А фиг знает, как программист разведет питание Заведет питание микроконтроллера на длинные провода наружу, потом будет жаловаться, что AVR непомехоустойчивый.

А по доработке программы мой совет - не преодоление коллизий, а из исключение коллизий путем адресации контроллеров. Кроме того, по программированию RS485 есть масса тонкостей, касающихся работы в условиях помех. Например, програмисту нельзя рассчитывать на растяжку сигналов резисторами.
Но не будем усложнять жизнь? Успехов всем

[prottoss]

...

Я конечно извиняюсь, что влезаю в такую умную беседу, но зачем говорить о велосипеде и пытаться его изобретать? Или интерес ради "просто вумно поболтать" ?. Опять же о том же MODBUS. Это конечно не панацея от всех бед, но все же дефакто промышленный протокол, использующийся в разных формах практически повсюду... Вот Вам его кратенькое описание, еслиф кто не ф курсе))). Там и физический интерфейс и программный. Enjoy!!!

Прикрепленные файлы

 Modbus_over_serial_line_V1.pdf ( 267.8 килобайт ) Кол-во скачиваний: 234

 

[singlskv]

Я конечно извиняюсь, что влезаю в такую умную беседу, но зачем говорить о велосипеде и пытаться его изобретать? Или интерес ради "просто вумно поболтать" ?. Опять же о том же MODBUS. Это конечно не панацея от всех бед, но все же дефакто промышленный протокол, использующийся в разных формах практически повсюду... Вот Вам его кратенькое описание, еслиф кто не ф курсе))). Там и физический интерфейс и программный. Enjoy!!!

Прошу прощения у автора топика что влезаю со своим вопросом,
но надеюсь что он меня простит (ему это тоже очень понадобится, наверное...)

Не встречал ли кто-нибудь библиотечки под PC (Win) на С++ которая реализует
протокол MODBUS (PC, конечно клиент)?

Минимальные/максимальные требования к библиотечке:

1. Работа на скоростях 9600/19200/115200
2. Управление направлением пердачи(не обязательно, есть модем с автоопределением)
3. CRC само собой (но это не вопрос)
4. Желательно минимальное количество классов (типа CSerial,CModbus и все)
5. Поддержка минимального набора функций (по сути интересен только запрос/ответ,
остальное сам допишу)
и вот теперь самое главное:
6. Контроль межбайтовых и межпакетных промежутков в пакетах Modbus (ну конечно
на столько, на сколько это вообще возможно под Win)

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

P.S Да, все это должно работать со стандартным драйвером COM порта под Win
Специальные serial modbus драйвера не предлагать

[Сергей Борщ]

Из описания ST485:

Код

Absolutle maximum ratings:
Vcc: 12V

Это несколько не то. Это максимально возможные значения параметров при которых эта микросхема еще не сгорит (соседние уже могут ). Ориентироваться надо на раздел Specifications, или его еще называют DC characteristics. Там указываются номинальные (типичные, рабочие) значения параметров.

Значит наверное надо подключать так:
COM-порт ПК к RS485:

да, почти все правильно, только ноги земли и V- у ST232 попутаны и для переключения направления используется не CTS (это вход у компьютера) а DTR(или RTS, не помню точно а подсмотреть сейчас негде). Есть еще упоминавшийся вариант без специального сигнала для переключения направления. Посмотреть идею можно здесь: http://www.bb-elec.com/bb-elec/literature/485sd9r-3803ds.pdf. Активная передача только одного уровня (второй формируется резисторами подтяжки) снижает максимальную скорость и дальность, но в большинстве применений такое решение вполне работоспособно. Здесь http://electronix.ru/forum/index.php?s=&am...st&p=138444 я выкладывал схему с несколько лучшими парамтрами (там же объяснение за счет чего).

ATMega8 к RS485:

TxD на DI, на DE можно и ICP1, а можно и OCRх (тогда таймер сможет аппаратно выключать передачу). Или опять же взять идею автоматического переключения из схем по ссылкам. Резистор ставится не в каждом устройстве а только на концах линии (в документе который выложил prottoss про него расписано в разделе 3.4.5).

Нет уж, пусть он попытается обойтись заранее простым решением.

Мы не ищем простых путей . Хочу научиться делать как надо, а не лишь бы как.

Серьезная заявка на успех. Так держать!

Я конечно извиняюсь, что влезаю в такую умную беседу, но зачем говорить о велосипеде и пытаться его изобретать? Или интерес ради "просто вумно поболтать" .

Любое изобретательство есть движение вперед. В сторону опыта (который сын ошибок трудных), например. За документ спасибо, очень познавательно.

[Stanislav]

Граждане, а можно и мне свой пятачок вставить?
Что если сделать так: TX условно первой меги подключаем к RX условно второй, TX второй - к RX третьей, TX третьей - ко входу микросхемы драйвера RS-232. Далее, RX первой меги подключаем ко выходу драйвера RS. Имеем "колбасу", по которой данные будут передаваться из одного МК в другой, для этого нужно только организовать простую очередь программными средствами, причём информация будет доходить до/из каждого из контроллеров совершенно естественным путём.
Преимущества - нужен только один драйвер без всякого дополнительного "железа". Недостатки - МК должны быть расположены на одной плате, или, по крайней мере, близко друг к другу, чтобы обойтись без дополнительных драйверов.
Будет работать?

[Сергей Борщ]

Имеем "колбасу", по которой данные будут передаваться из одного МК в другой
Будет работать?

Будет. Только нужно чтобы все устройства были включены. Отказ любого приводит к "падению" всей системы. Близко располагать не обязательно.

[SasaVitebsk]

...Питание в этом случае берётся так. Ч/з диоды с неиспользуемых выходов (DTR,RTS) снимается 12V и с него формируется 5V...
... Ну и я не знаю о каких сбоях Вы говорите...

Несколько уточнений...
Если питание взять, как Вы предлагаете, это не будет настоящий RS485, потому что в этом случае не будет обеспечена нагрузочная способность драйвера. Это значит, что работать в принципе будет, но с оговорками по скорости и расстоянию. Ссылки на то, что у Вас все работало хорошо, не принимаются

А про сбои... А фиг знает, как программист разведет питание Заведет питание микроконтроллера на длинные провода наружу, потом будет жаловаться, что AVR непомехоустойчивый.

А по доработке программы мой совет - не преодоление коллизий, а из исключение коллизий путем адресации контроллеров. Кроме того, по программированию RS485 есть масса тонкостей, касающихся работы в условиях помех. Например, програмисту нельзя рассчитывать на растяжку сигналов резисторами.
Но не будем усложнять жизнь? Успехов всем

Давайте не путать моё устр-во и его. В моём переходник USB<->RS485, так что с током у меня всё в поряде. Ну и с прогой тоже, хотя я и не совсем доволен. Но у меня пакеты с предопределённой длиной, запросы, ответы, таймауты, автоопределение и т.п. То есть не весь MODBUS, но принципиальные вопросы я решил.

А по его устройству я исходил из того, что он планировал на RS232 работать, - а это 15 метров. Так что переходник RS232<->RS485 будет устойчиво работать от питания RS232. К тому же у него небольшие массивы передаваемых данных (как я понял). То есть можно выбрать скорость небольшую.

Ну а насчёт коллизий, так я это просто к слову. Конечно предпочтительней адресовать запрос и получать ответ. Но просто с коллизиями возможно попробовать не переделывать прогу на PC. Или почти не переделывать.

да, почти все правильно, только ноги земли и V- у ST232 попутаны и для переключения направления используется не CTS (это вход у компьютера) а DTR(или RTS, не помню точно а подсмотреть сейчас негде). Есть еще упоминавшийся вариант без специального сигнала для переключения направления.

Обычно применяется RTS (что-то типа request to send), но я видел переключение и DTR. Но всё таки я очень рекомендую в PC применить "автомат". По типу приведённого Вами или мной. А то я провёл исследования и был крайне огорчён. Бывают случаи, когда комп банально дробит пакеты. Рвёт даже посередине. (На хорошей скорости и при применении VirtualComPort). При таком раскладе (причём я не уверен что начало передачи начинается сразу) трудно определить завершение пакета с подходящей точностью. Требуется вводить задержку.

[prottoss]

Прошу прощения у автора топика что влезаю со своим вопросом,
но надеюсь что он меня простит (ему это тоже очень понадобится, наверное...)

Не встречал ли кто-нибудь библиотечки под PC (Win) на С++ которая реализует
протокол MODBUS (PC, конечно клиент)?

А что, сложно накропать самому? Вы вроде грамотный и вполне подкованный чел Документик, который я выложил почитайте, там и для слэйва и для мастера алгоритмы расписаны, (или, если Вам угодно и для сервера и для клиента). На том же http://modbus.org есть бесплатные исходники (на Си естественно) ... под PIC правда, но HAL подменить, для Вас, я думаю не проблема....

Или проблемы с программированием под Win32???

[Dog Pawlowa]

...

Я конечно извиняюсь, что влезаю в такую умную беседу, но зачем говорить о велосипеде и пытаться его изобретать? Или интерес ради "просто вумно поболтать" ?. Опять же о том же MODBUS. Это конечно не панацея от всех бед, но все же дефакто промышленный протокол, использующийся в разных формах практически повсюду... Вот Вам его кратенькое описание, еслиф кто не ф курсе))). Там и физический интерфейс и программный. Enjoy!!!

За документ спасибо.
Что касается велосипеда... Мне дело представляется по другому. Вы дали клиенту рыбу, а я пытался объяснить, как устроена удочка.
Мой следующий шаг - напомнить, что, кроме Modbus, существует огромное количество протоколов (у меня на полочке стоят три папки с описанием более 40 протоколов заправочных систем), а Ваш следующий шаг ? Дать исходники проекта?
Кстати, Modbus не использую. Не нравится.

[prottoss]

За документ спасибо.

Спасибо не мне, а ребятам которые придумали хороший протокол. Просто на компьютере можно не только по форумам вопросы печатать (это не Вам лично), а еще много интересных мест посетить

Что касается велосипеда... Мне дело представляется по другому. Вы дали клиенту рыбу, а я пытался объяснить, как устроена удочкаМой следующий шаг - напомнить, что, кроме Modbus, существует огромное количество протоколов (у меня на полочке стоят три папки с описанием более 40 протоколов заправочных систем), а Ваш следующий шаг ? Дать исходники проекта? .

Я не дал ему рыбу - Вы говорите так, как будто я ему подорил 4-е платы - одна для РС, а на остальных гордо восседают мега8))). Я просто, чем бестолково объяснять, дал челу готовый документ, в котором довольно разжеванно говорится про все, что ему нужно, чтобы организовать относительно простой многопроцессорный обмен.

Кстати, Modbus не использую. Не нравится.

Ну и пускакй не нравится, ребятам из Ford, BMW, Toyota, Nissan, Daewoo... продолжать? очччень нравится. И не только им, шахтерам, металлургам, нефтянникам ETC

[Dog Pawlowa]

ребятам из Ford, BMW, Toyota, Nissan, Daewoo... продолжать? очччень нравится. И не только им, шахтерам, металлургам, нефтянникам ETC

Я уже писал - аргументы "у меня все работает" и "все используют" я не принимаю Эти аргументы не технические, а скорее демагогические (без обид )
Например, будь все шоколадно, перечисенные фирмы не занимались бы протоколом LIN.

[prottoss]

ребятам из Ford, BMW, Toyota, Nissan, Daewoo... продолжать? очччень нравится. И не только им, шахтерам, металлургам, нефтянникам ETC

Я уже писал - аргументы "у меня все работает" и "все используют" я не принимаю

Дадада - "А Баба Яга против", знаю

[singlskv]

Прошу прощения у автора топика что влезаю со своим вопросом,
но надеюсь что он меня простит (ему это тоже очень понадобится, наверное...)

Не встречал ли кто-нибудь библиотечки под PC (Win) на С++ которая реализует
протокол MODBUS (PC, конечно клиент)?

А что, сложно накропать самому? Вы вроде грамотный и вполне подкованный чел Документик, который я выложил почитайте, там и для слэйва и для мастера алгоритмы расписаны, (или, если Вам угодно и для сервера и для клиента). На том же http://modbus.org есть бесплатные исходники (на Си естественно) ... под PIC правда, но HAL подменить, для Вас, я думаю не проблема....

Или проблемы с программированием под Win32???

Проблем с программированием под Win32 нет.
Есть проблеммы у Windows

1. Работа на скоростях до 115200
6. Контроль межбайтовых и межпакетных промежутков в пакетах Modbus (ну конечно
на столько, на сколько это вообще возможно под Win)

на скорости 115200 один байтик передается 87мкс
межбайтовый промежуток 4 байта = 347 мкс

а стандартные таймуты COM порта начинаются от 1мс
и Sleep тоже от 1 мс , и при этом еще и не отрабатывается
а такт операционки 10-20мс

а если вводить везьде большие задержки, то 115200 может чудесным образом
превратиться в 19200
да и контроль остается только по длинне пакета и по CRC

Вот собственно по этому и хочется найти исходники где реализован
хоть какой-то контроль.

Например можно для контроля промежутков использовать Performance Counters.
Просто очень не хочется наступать на все грабли на этом пути,
особенно если на них уже кто-нибудь наступил

[prottoss]

Есть проблеммы у Windows

Использовать выносного клиента, с достаточным объемом памяти, и скоростной шиной с РС - USB например))) Пример - pdiusbd12 + atmega8515 + 64k SRAM

[singlskv]

Есть проблеммы у Windows

Использовать выносного клиента, с достаточным объемом памяти, и скоростной шиной с РС - USB например))) Пример - pdiusbd12 + atmega8515 + 64k SRAM

К сожалению, по условию задачи, этот вариант не подходит

[prottoss]

[quote name='singlskv' date='Jan 8 2007, 17:35' post='194214']

1. Работа на скоростях до 115200
6. Контроль межбайтовых и межпакетных промежутков в пакетах Modbus (ну конечно
на столько, на сколько это вообще возможно под Win)
[/quote]
на скорости 115200 один байтик передается 87мкс
межбайтовый промежуток 4 байта = 347 мкс

а стандартные таймуты COM порта начинаются от 1мс
и Sleep тоже от 1 мс , и при этом еще и не отрабатывается
а такт операционки 10-20мс

а если вводить везьде большие задержки, то 115200 может чудесным образом
превратиться в 19200
да и контроль остается только по длинне пакета и по CRC

Вот собственно по этому и хочется найти исходники где реализован
хоть какой-то контроль.

Например можно для контроля промежутков использовать Performance Counters.
Просто очень не хочется наступать на все грабли на этом пути,
особенно если на них уже кто-нибудь наступил
[/quote]Для начала: межбайтовый промежуток можно сделать и 1 мс - таймаут в порту отрабатывается аппаратно, а вот уведомлениие об этом событии приложению ОСь выдаст конечно с задержкой, но это уже не столь важно будет - главное таймаут будет зафиксирован

Ну а межкадровые таймауты поймать не так уж и сложно и обычными средсвами, хотя можно и аппаратный таймер задействовать



А какие у Вас требуемые межкадровые интерывалы? И что за контроллеры?

[li4]

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

Если все верно, то прошу объяснить какие номиналы должны быть у R1, R2, R3, R4, R5 и C1. И будет-ли данная схема работать на скорости 115200 бит/c?

[Сергей Борщ]

прошу посмотреть правильно-ли я все соединил:

Вы опять попутали выводы V- и GND у ST232. На GND подается земля, на V- минус С4, плюс С4 на землю. На выводе V- получается напряжение около -10в. Если есть возможность - используйте ST202 - ей достаточно керамических конденсаторов на 0.1 мкФ. R1 не нужен - ST232 не умеет переводить выход в третье состояние.

Если все верно, то прошу объяснить какие номиналы должны быть у R1, R2, R3, R4, R5 и C1. И будет-ли данная схема работать на скорости 115200 бит/c?

У меня работает на 115200. R2 - подтяжка, 1К...4К7 для 115200, при меньших скоростях сопротивление можно увеличивать, при этом снижается потребеление. R3 10К, C1 1нФ, R4 и R5 согласно документу, который привел ув. prottoss должны быть 450...650 ом.

[li4]

Все исправил, схемы приняли вид:
RS232 to RS485:


AVR to RS485:


Если все верно, то 1/3 дела сделано, теперь бы еще программу для МК под эту схему придумать.

Сообщение отредактировал li4 - Jan 8 2007, 18:57

[SasaVitebsk]

ребятам из Ford, BMW, Toyota, Nissan, Daewoo... продолжать? очччень нравится. И не только им, шахтерам, металлургам, нефтянникам ETC

Я уже писал - аргументы "у меня все работает" и "все используют" я не принимаю Эти аргументы не технические, а скорее демагогические (без обид )
Например, будь все шоколадно, перечисенные фирмы не занимались бы протоколом LIN.

Мне тоже не нравится. Кажется устаревшим, излишне перегруженным и в то же самое время не полным. То есть объявление - "у меня тоже MODBUS" - абсолютно ничего не даёт. На сто процентов модбас нефтяников не будет работать с модбасом форд. Да я и не уверен что форд-тайота услышат друг-друга. Если, да то это только в случае, что они договорились м/у собой "кроме протокола". Хотя надо признать, что сама структура первого уровня - пакеты - формат пакетов - таймауты - CRC - придраться особо не к чему. К сожелению с LIN не разбирался и до CAN тоже руки не дошли. Хотелось бы конечно. Но пока не было такой задачи.

Компонента MODBUS у меня нет, но есть компонент COM порт и RS485. Я его использовал, но немного корректировал. У меня есть сомнения что под виртуалом вообще полностью можно создать MODBUS. singlskv совершенно точно перечислил причины. Только что с этим боролся.
Пробовал вот такой вот вызов таймера
TimerID:=timeSetEvent(ASpeed[Speed],0,@TimeProc,0,TIME_PERIODIC);
10мс отрабатывает нормально, но можно и меньше. Но тоже есть проблемы. Мне обещали подогнать правильную работу ч/з OPENGL. Буду пробовать.

[prottoss]

Мне тоже не нравится. Кажется устаревшим, излишне перегруженным и в то же самое время не полным. То есть объявление - "у меня тоже MODBUS" - абсолютно ничего не даёт. На сто процентов модбас нефтяников не будет работать с модбасом форд. Да я и не уверен что форд-тайота услышат друг-друга. Если, да то это только в случае, что они договорились м/у собой "кроме протокола". Хотя надо признать, что сама структура первого уровня - пакеты - формат пакетов - таймауты - CRC - придраться особо не к чему. К сожелению с LIN не разбирался и до CAN тоже руки не дошли. Хотелось бы конечно. Но пока не было такой задачи.

Компонента MODBUS у меня нет, но есть компонент COM порт и RS485. Я его использовал, но немного корректировал. У меня есть сомнения что под виртуалом вообще полностью можно создать MODBUS. singlskv совершенно точно перечислил причины. Только что с этим боролся.
Пробовал вот такой вот вызов таймера
TimerID:=timeSetEvent(ASpeed[Speed],0,@TimeProc,0,TIME_PERIODIC);
10мс отрабатывает нормально, но можно и меньше. Но тоже есть проблемы. Мне обещали подогнать правильную работу ч/з OPENGL. Буду пробовать.

Когда я говорил про Фордов, нефтянников и иже сними, я как раз и имел ввиду программный протокол, а физическая часть на вкус и цвет - Форд и Ко использует K-Line , нефтянники используют диф. пары, кто-то предпочитает радио потому как расстояния разные (одна из главных причин) и стимулы.



ЗЫ: Как OpenGL может помочь, что то я не догоняю??? Это которая с Direct3D дружит?

[Сергей Борщ]

Все исправил, схемы приняли вид:
AVR to RS485:

Опять почти. В документе "имени prottossa" в разделе 3.4.6 сказано (даже выделено), что резисторы растяжки должны быть только в одном месте на всю шину. В вашем случае без переходника 232-485 система не работает, поэтому их имеет смысл оставить именно в этом переходнике, а в "AVR то 485" R1 и R2 исключить.

Если все верно, то 1/3 дела сделано, теперь бы еще программу для МК под эту схему придумать.

Повод прочитать раздел 2.4 Master / Slaves State Diagrams упомянутого документа

[prottoss]

В документе "имени prottossa" ...

Щаз лопну от гордости

[WHALE]

В документе "имени prottossa" ...

Щаз лопну от гордости

prottoss Не надо,нам вас будет недоставать.

[SasaVitebsk]

В документе "имени prottossa" ...

Щаз лопну от гордости

prottoss Не надо,нам вас будет недоставать.

И кто тогда будет поддерживать программатор Вашего имени, который я всем рекламирую.

[singlskv]

ЗЫ: Как OpenGL может помочь, что то я не догоняю??? Это которая с Direct3D дружит?

Возможно и может, надо глянуть в эту сторону (мысля очень интересная)
дело в том что у OpenGL должны быть очень шустрые таймеры(не помню уже, давно это было, да и не на PC), ему ведь 3D графику в реалтайме выводить надо.
А стандартные виндусовые таймеры нормально начинают работать от 10мс.

Некоторые пытаются использовать MMTIME, там вроде такт получается 1-3мс

[prottoss]

ЗЫ: Как OpenGL может помочь, что то я не догоняю??? Это которая с Direct3D дружит?

Возможно и может, надо глянуть в эту сторону (мысля очень интересная)
дело в том что у OpenGL должны быть очень шустрые таймеры(не помню уже, давно это было, да и не на PC), ему ведь 3D графику в реалтайме выводить надо.
А стандартные виндусовые таймеры нормально начинают работать от 10мс.

Некоторые пытаются использовать MMTIME, там вроде такт получается 1-3мс

Я некоторое время занимался программированием 3D графики, и, как человек икушенный в этом не легком деле, скажу Вам что OpenGL базируется на DirectX, DirecX создан для Windows и он не использует точных таймеров. Для сдерживания, допустим FPS, используется обычный софтверный тамер системы Реалтайм для игрухи это 25 -50 ФПС.



ЗЫ: Представляю картину. Огромный зал с компьютерами, супер АСУ так сказать. Дядьки с умными лицами ставят Ваше ПО на систему удаленного управления объектами, бубны, торжественная музыка... Хлоп ... Аншлаг... Версия DirectX на Вашей системе устарела, требуется обновление ПО... ... Ну а че, прально, и оператору хорошо, вечером мона Кваку новую погонять, хехе

[otrog]

Дабы не заморачиваться с микросекундными задержками в windows я использую протокол WAKE. В нем определение границ пакетов происходит по служебным байтам. Есть исходники и на мк и на компьютер, за что огромное спасибо Леониду Ивановичу.
К сожалению ссылка на протокол не работает. Если интересно могу выложить исходники здесь.

ПС WAKE открытый и бесплатный протокол, в отличие от MODBUS.

[prottoss]

Дабы не заморачиваться с микросекундными задержками в windows я использую протокол WAKE. В нем определение границ пакетов происходит по служебным байтам. Есть исходники и на мк и на компьютер, за что огромное спасибо Леониду Ивановичу.
К сожалению ссылка на протокол не работает. Если интересно могу выложить исходники здесь.
ПС WAKE открытый и бесплатный протокол, в отличие от MODBUS.

Я не знаком с этим протоколом, но чувствую, что если есть служебные байты, значит данные скорее всего символами передаются (???), а это пахнет удвоением пакетов данных...



А в каком месте MODBUS закрытый протокол?????????????

[GDI]

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

[prottoss]

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

Это минус... Всю посылку придется сравнивать со служебными символами, а это опять потеря времени, за которое мы боремя

[GDI]

не все так плохо.. признаком стаффинга является один из 4х служебных символов, с ним и сравнивается каждый байт..

Прикрепленные файлы

 wake.pdf ( 219.95 килобайт ) Кол-во скачиваний: 192

 

[otrog]

Ссылка на WAKE
http://www.spetspribor.com/support/software/wake/wake.html
к сожалению не работает , поэтому выложил сохраненную страницу со всеми файлами на ФТП
/upload/DOCs/WAKE.rar

байт-стаффинг конечно не очень хорошо, но жесткая времянка еще хуже(ИМХО).
А то что MODBUS закрытый может я и ошибся, но всякие там оговорки типа:

After 30 days, the ActiveX Controls stop communicating and return a result indicating that trial has expired

мне не нравятся.

ПС
2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

[li4]

otrog: Выложил сохраненную страницу со всеми файлами на ФТП
/upload/DOCs/WAKE.rar

У меня к сожалению нет доступа к этому ФТП, может закинеш эти файлы мне на e-mail: labor@online.ua?

[prottoss]

2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Зато на моем сайте есть достаточное количество информации, что бы разобраться в протоколе и начать продуктивно работать в этом направлении. Что касается исходников - я уже говорил выше - есть на http://modbus.org совершенно БЕЗВОЗМЕЗДНЫЕ готовые исходники (под PIC, но переделывается влет за неделю) и для клиента и для сервера. Все на Сях. Может быть выложу и свои - надо их причесать немного...

[otrog]

otrog: Выложил сохраненную страницу со всеми файлами на ФТП
/upload/DOCs/WAKE.rar

У меня к сожалению нет доступа к этому ФТП, может закинеш эти файлы мне на e-mail: labor@online.ua?

Положил сюда:
http://rapidshare.com/files/11035544/WAKE.rar.html (1.8 Мб)

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Отличная идея

[SasaVitebsk]

2 prottoss На Вашем сайте исходников MODBUS нет, значит это закрытый протокол .

Мдя, после того, что я тут выложил, и Ваших слов некоторые точно подумают, что MODBUS придумал я , хм....я уже подумываю о новой версии - PROTTOSSBUS, а че? звучит ...

Зато на моем сайте есть достаточное количество информации, что бы разобраться в протоколе и начать продуктивно работать в этом направлении. Что касается исходников - я уже говорил выше - есть на http://modbus.org совершенно БЕЗВОЗМЕЗДНЫЕ готовые исходники (под PIC, но переделывается влет за неделю) и для клиента и для сервера. Все на Сях. Может быть выложу и свои - надо их причесать немного...

Это замечательно, может кому то понадобитсся именно полный MODBUS. Я, правда достаточно давно, реализовывал его на ASM51. В принципе с точки зрения микроконтроллера ничего сложного нет. Но для меня немного нафталином попахивает.

А вот с точки зрения PC, всё не так просто. Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Всё идейно важное, - на мой взгляд из первого уровня (как я бы сказал) из MODBUS взял тот же WAKE. А для меня красивым протоколом на втором уровне является X-modem. Я исследовал для себя. Он даёт самую высокую скорость при ошибках в линии. Очень идея красивая. Правда я делал адаптивные размеры пакетов и анализировал статистику.

Интересно было бы повозится с LIN и с CAN. Чтобы самому составить своё собственное мнение.

А вообще интересно наблюдать, что все более-менее современные протоколы в конечном итоге приближаются к сетевым.

[defunct]

Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Разве идея MODBUS это не master-slave (запрос-ответ)?
Насколько помню там тупо до ужаса.
Посылаешь пакет, ставишь тайм-аут (отфонарный) ~100ms, если в ответ что-то пришло - хорошо, считаешь CRC, 0 - отлично, проверяешь код функции, совпал - значит ответ на наш запрос, ну а дальше парсишь сообщение.
Слейву еще проще. Получил команду - отправил незамедлительно ответ.

Где там задержки в 1.5 символа-то?

фунции modbus драйвера:

Код

void mb_SendPacket(U8 *pData, U8 size)
{
  while (size--)
    uq_PutChar( *pData++ );
}


void mb_PutMessage(PModbusDesc pDesc)
{
    pDesc->CRC = mb_crc16( (U8 *)pDesc, sizeof(*pDesc) - 2 );
    mb_SendPacket( (U8 *)pDesc, sizeof(*pDesc));
}

U8 mb_GetMessage(U8 *pStorage, U8 *retsize, U8 maxsize)
{
  U32  tempclock = Kernel_GetClock() + 100; // 100 ms timeout
  U8   temp;
  *retsize = 0;
  do
  {
     if ( (uq_GetChar(&temp)) && (*retsize < maxsize))
     {
        pStorage[(*retsize)++] = temp;
     }
     Kernel_idle();
   } while (Kernel_GetClock() < tempclock);
  
   return ((*retsize) == 0) ?  FAILED : SUCCESS;
}

[singlskv]

Слейву еще проще. Получил команду - отправил незамедлительно ответ.

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

Посылаешь пакет, ставишь тайм-аут (отфонарный) ~100ms, если в ответ что-то пришло - хорошо

если ставить слишком большие таймауты, то это очень плохим образом может сказаться
на производительности линии, если она слегка шумит

Где там задержки в 1.5 символа-то?

По стандарту нужно чтобы каждый принимаемый байт попадал в фрейм
длительностью 1,5 байта на данной скорости.
Правда эту часть стандарта обычно никто не контролирует строго.
Главное это чтобы межбайтовые промежутки не превышали межпакетные.
Ну и контролировать можно только со стороны слейва.
Если слейв микроконтроллер то это сделать легко, а вот если PC под Win да и еще скорость
приличная, то тогда легче сразу повеситься

Когда мастер PC под Win то существует проблема обрезания длинных пакетов:

Например задача - контроллировать задержку в 1.5 символа (пишу по памяти) на высоких скоростях (а RS485 поддерживает до 2Мбит) представляется сомнительной. Я столкнулся с тем что у меня PC самопроизвольно рвала пакеты. Иногда вставляя незначительные промежутки, но и скорость у меня не рекордная! А что будет на большой? Кроме того незнание момента окончания передачи для PC, а расчёт его, - тоже вызывает ощущение - не очень.

Кстати SasaVitebsk какая у Вас скорость ?
Удалось ли победить обрезание пакетов ?

[SasaVitebsk]

Кстати SasaVitebsk какая у Вас скорость ?
Удалось ли победить обрезание пакетов ?

Я сделал и програмно тоже, но получалась такая шляпа. Обрезание пакета не происходило, я расчитывал задержку.
Но возникала проблема со слэйвом. А именно: надо было послать ответ тогда, когда мастер гарантировано переключал направление с передачи на приём. Поэтому картина вырисовывалась следующая. Мастер вставляет задержку чтобы не было "обрезания", а слэйв вставляет задержку относительно задержки чтобы гарантировано попасть на приём. Но если мастеру - всё по барабану, то слэйв, чтобы подтвердить приём - фактически простаивает. Но это только пол беды. У меня была задумка - автоматически подстраивать скорости. Когда-то я реализовывал полный автобод, но тут у меня у слэйва не было ресурсов. Слэйв работает всё время и отвлекается только по поступлению пакетов. Поэтому я решил упростить задачу (что оправдано в данном интерфейсе). Принцип такой. Мастер посылает пакет (каждый пакет - какая-то команда). Слэйв поступает таким образом: Отвечает Ok, Error или не отвечает. Ok - CRC Ok. Error - запрос на повтор. (то есть команда понята, но CRC - Error) А нет ответа если не понят пакет (Метка - команда). Это даёт возможность "сканировать" мастером с определением скорости захвата. Но тут и незадача. Работа осущ. на скоростях 1200-115200. Таким образом размер паузы увеличивается на размер 1.5 байта на младшей скорости (~12ms). Что приводит к доп. увеличению задержки на ответ.

Короче я по концовке поставил со стороны PC аппаратный одновибратор по обычной схеме (на 7400).

Задержки таковы: 5мс - слэйв. Мастер выжидает таймаут 50мс.

Но в принципе по мне это не бьёт, так как максимально эффективная скорость передачи (на больших данных) у меня 4800. Это значит, что при дальнейшем увеличении скорости коннекта, - скорость передачи не растёт. Включаются механизмы управления потоком.


Кстати у меня есть програмка тестирования MODBUS протокола из под PC. Когда реализовывал его - пользовался. Всё работало. (Правда давно было) Могу выложить если интересует.

[prottoss]

2 singlskv

Зачем так щипетильно относится к стандарту MODBUS? Я принимаю, что серверу (то бишь периферийному контроллеру), естественно, надо отслеживать и межсимвольные и, обязательно, межкадровые, интервалы. Но клиенту (то бишь РС), межсимвольные интервалы ИМХО не нужны, и большинтсво ПО, по крайней мере с которым я более менее знаком, не проверяет их. Достаточно контрольной суммы в пакете, поля длины пакета и таймаута кадра (опять же ИМХО). Я достаточно плотно занимаюсь с горношахтным оборудованием. Линии связи - более 15 километров!!! Под землей и на поверхности, при этом кругом 6 киловольт и 660 вольт, потребители по 400 кВт!!! Вся электроника прекрасно дышит в ритм и у диспетчеров и под землей. И ни каких специальных кабелей - обычные телефонные 20-и парники...

[Leonty]

1. В асинхронном режиме можно ввести метрику процессора (UART).
2. В синхронном - реализовать мультипроцессорный режим MPCM.
И все.

[defunct]

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

Я не согласен c этой частью стандарта, потому что такая задержка ничем не обоснована, кроме кривизны мастера. Нормальный драйвер переключается на прием сразу после отправки последнего бита.

если ставить слишком большие таймауты, то это очень плохим образом может сказаться
на производительности линии, если она слегка шумит

Однако это позволит запросто избавиться вот от этого:

Когда мастер PC под Win то существует проблема обрезания длинных пакетов

По стандарту нужно чтобы каждый принимаемый байт попадал в фрейм
длительностью 1,5 байта на данной скорости.

опять-таки, эта часть стандарта объясняется только кривизной мастера, и надумана только для ASCII режима. В RTU посылки-то с нормальным кодом защиты, т.о. нам не страшны любые искажения и смещения потока.

[SasaVitebsk]

Я думаю всё это обосновано следующим. Должно быть описано КАЖДОЕ состояние. И это, в принципе, правильно. Я начал передавать фрейм. Передал - заголовок. Слэйв принял. Но ждать он может ограниченное время - иначе клинч.

Давайте посчитаем какой должен быть разрыв м/у байтами. Фактически разрыв м/у байтами должен быть меньше, чем для слэйва принятие решения о завершении пакета. Так какой он должен быть? Ну возьмём фиксированный - к примеру 5мс. Нельзя. Для скорости 1200 бод (а нижняя по стандарту думаю вообще 300) байт - 8.3мс. Таким образом для данной скорости 5мс - мало. Поэтому таймаут привязан к скорости. Возьмём 10 байт. Учтём, что после завершения пакета (для слэйва) слэйв должен обработать команду и подтвердить её приём или ответить на команду. Таким образом к задержке для мастера надо прибавить ещё задержку на ответ. Таким образом чем больше задержка - тем ниже пропускная способность шины. Это понятно. Таким образом желательно ввести МИНИМАЛЬНУЮ задержку. Но она не может быть меньше одного символа. В этом случае мы просто не будем знать закончилась ли передача. Ну вот Вам и формула должна быть минимальная задержка более одного символа. Выбрано 1.5.


Как раз здесь у меня претензий нет. Претензии по самим командам. С некоторыми я ни соглашусь ни в жизнь.

Должен быть интерфейс. Слейв должен по запросу выдавать свою програмную модель что-ли. А мастер не вправе читать/писать всё подряд. Мастер и слэйв должны быть защищены друг от друга. А здесь протоколы этого не предусматривают.

[singlskv]

Не, незамедлительно нельзя!
по стандарту нужно выдержать интервал не менее 4 длительностей байта

Я не согласен c этой частью стандарта, потому что такая задержка ничем не обоснована, кроме кривизны мастера. Нормальный драйвер переключается на прием сразу после отправки последнего бита.

Ну во первых назвать Windows нормальным мастером рука не поднимется
Во вторых, выдерживать эти межпакетные интервалы Вам все равно придется, иначе
другие устройства, которые придерживаются стандарта могут Вас не понять
А для Win это проблема, если Вы попытаетесь воспользоваться просто задержкой
Sleep(xx) для интервала xx менее такта операционной системмы (10-20 мс) то, можете
с удивлением обнаружить, что Sleep(10) например, чудесным образом превращается
в задержку 15мс, а иногда в задержку 300 МИКРОСЕКУНД
А нужно гарантированно выдерживать не менее 4 байтов

На самом деле конечно не все так печально.
В стандарте оговаривается рекомендация, выдерживать 3,5(4) байта промежутки
только для скоростей до 19200. При более высоких скоростях, рекомендуется выдерживать
межпакетный промежуток не менее 1750мкс.
Хотя это все равно не вписывается в возможности Win.
А если при каждой пересылке мы будем ждать 20мс, т.е. гарантированно больше такта
операционки, то максимальная производительность интерфейса будет 50 пакетов в
секунду (примерно).
При пакетах запрос/ответ например по 8 байт и скорости 115200 мы будем иметь
производительность канала: (8+4+8)*50=600 байт в секунду вместо 11520.

Еще пару слов в поддержку 4(3,5) межбайтового интервала.
Пусть у нас есть один мастер и 2 слейва.
Мастер шлет запрос первому слейву и ждет от него ответ.
В какой момент второй слейв должен решить что могла начаться передача ему ?
Вот сидит он и слушает общую линию, и как он может определить что начался новый пакет
который нужно попытаться разобрать ?
Есть еще парочка пременений этому межпакетному промежутку, но чего-то и так слишком много
буковок получилось ...

если ставить слишком большие таймауты, то это очень плохим образом может сказаться
на производительности линии, если она слегка шумит

Однако это позволит запросто избавиться вот от этого:

Когда мастер PC под Win то существует проблема обрезания длинных пакетов

К сожалению, не всегда.
Здесь ИМХО, есть несколько моментов.
1.Кривизна serial драйверов Win.
2.Кривизна чипсетов на мамках.
3.Ну и опять же длина таймаутов
по пунктам 1. и 2. от нас конечно мало что зависит, ну можно конечно немного
погуглить и найти более коректный драйвер
по пункту 3. могу ответственно заявить что COMMTIMEOUTS для высоких скоростей
вещь довольно кривая, да и при скорости 115200 время одного байта 87мкс, а минимальный
таймаут 1мс

ЗЫ. У меня на нотебуке при пересылке длинных пакетов иногда пропадают байтики
внутри пакета

Слейв должен по запросу выдавать свою програмную модель что-ли.

Ну вроде никто не мешает реализовать это в рамках стандарта

А мастер не вправе читать/писать всё подряд. Мастер и слэйв должны быть защищены друг от друга. А здесь протоколы этого не предусматривают.

Ну дык слейв и не обязан отдавать все что у него попросили и записывать все что ему сказали.
Может и отказаться и ответить что "нету у меня такого адресу, отвали"

[SasaVitebsk]

....
К сожалению, не всегда.
Здесь ИМХО, есть несколько моментов.
1.Кривизна serial драйверов Win.
2.Кривизна чипсетов на мамках.
3.Ну и опять же длина таймаутов
по пунктам 1. и 2. от нас конечно мало что зависит, ну можно конечно немного
погуглить и найти более коректный драйвер
по пункту 3. могу ответственно заявить что COMMTIMEOUTS для высоких скоростей
вещь довольно кривая, да и при скорости 115200 время одного байта 87мкс, а минимальный
таймаут 1мс

ЗЫ. У меня на нотебуке при пересылке длинных пакетов иногда пропадают байтики
внутри пакета

Слейв должен по запросу выдавать свою програмную модель что-ли.

Ну вроде никто не мешает реализовать это в рамках стандарта

А мастер не вправе читать/писать всё подряд. Мастер и слэйв должны быть защищены друг от друга. А здесь протоколы этого не предусматривают.

Ну дык слейв и не обязан отдавать все что у него попросили и записывать все что ему сказали.
Может и отказаться и ответить что "нету у меня такого адресу, отвали"

По поводу первой части.
По моему все мы, включая defunct говорим об одном и том же, но просто разными словами.
В обобщённом виде выглядит так: В принципе к стандарту претензий нет, но есть претензии к PC+Windows, которые не позволяют реализацию данного стандарта в полном соответствии. При этом приходится чем-то жертвовать слегка "подправляя" стандарт под себя. Жертвуем мы чем-то "несущественным". Правда неесущественным для себя. Иными словами мои жертвы, ваши и defunct могут отличаться. Хотя скорее всего будут работать м/у собой.

По поводу второй части. Всё правильно "никто не мешает реализовать это в рамках стандарта" и т.д. Я не спорю. Я просто говорю что он не полный в моём понимании. Так как то что я реализую в рамках стандарта и то что Вы реализуете в этих же рамках и в полном соответствии - не будет совместимо. Причём без всяких там "скорее всего". Даже если мы с вами будем делать одну и ту же вещь! Эти вещи должны быть прописаны самим стандартом. А этого нет!

[otrog]

Слейв должен по запросу выдавать свою програмную модель что-ли.

Давно присматриваюсь к "Пирамиде".
http://upload.caxapa.ru/pyramid/

Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. Единственное требование к терминалу –
реализация стандартов доступа, относящихся к системе Пирамида. Вся информация о
параметрах, методах работы с ними, элементах навигации по параметрам должна храниться
исключительно в приборе.

Изумительно выглядела бы связка WAKE(транспортный уровень) + Пирамида(логический уровень).

[SasaVitebsk]

Слейв должен по запросу выдавать свою програмную модель что-ли.

Давно присматриваюсь к "Пирамиде".
http://upload.caxapa.ru/pyramid/

Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. Единственное требование к терминалу –
реализация стандартов доступа, относящихся к системе Пирамида. Вся информация о
параметрах, методах работы с ними, элементах навигации по параметрам должна храниться
исключительно в приборе.

Изумительно выглядела бы связка WAKE(транспортный уровень) + Пирамида(логический уровень).

Подписываюсь под этим. Я это выстрадал.

При последней реализации меня пытались заставить разрешить прямой доступ к памяти! Причём основания такие - программа на PC тоже будет отлаживаться и ошибка невозможна. С другой стороны изменение логической модели МК приведёт лишь к изменению обслуживающей проги.

Ну я упёрся как бык. Говорю - это без меня. Я не могу отвечать за прогу, с которой удалённо (за моей спиной) работает другой программист. Ну в конце концов пришли к компромису, но я очень не доволен результатами. У меня даже в мозгу не было, что мне придётся кому-то объяснять такие вещи. Я просто был к этому не готов.

[Dog Pawlowa]

Я потерял исходное сообщение, кто это высказал:
"Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. "

Абсолютно с этим согласен. Ровно год назад перед разработкой нового прибора я решил, что должно быть именно так. И заложил в прибор новый протокол, эдакий очень упрощенный SNMP. Как и браузерe SNMP, браузеру этого протокола абсолютно все равно, какое устройство подключено - он автоматически сосчитает имена всех доступных объектов, создаст закладки в окне, прочитает текущие значения. Есть программа осуществляющая более сложный доступ (чтение и запись переменных, вывод на экран) по простому неветвящемуся скрипт-файлу. Логика работы прибора может быть легко проверена браузером протокола вручную. Если более сложная программа для PC нужна, она не будет единственным средством работы с прибором, можно не зависеть от другого программиста.
Пока доволен результатом, планирую выложить все на сайте фирмы, включая порты слэйва под AVR и MSP. Более того, есть порты мастера и для микроконтроллера, что обеспечивает "прозрачность" контроллера, который служит шлюзом.

К чему это я? Да просто читаю, как сложно реализовать стандартный низкоуровневый протокол под Windows, и предложения убрать часть спецификации. И в чем смысл частичного соблюдения каких-то спецификаций? Зачем нести полуразрушенный самими же прах старых протоколов? Совместимость все равно не гарантируется! Если хотя бы один обязательный пункт спецификации MODBUS не выполнен, это уже не MODBUS!

[SasaVitebsk]

Я потерял исходное сообщение, кто это высказал:
"Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. "

Абсолютно с этим согласен. Ровно год назад перед разработкой нового прибора я решил, что должно быть именно так. И заложил в прибор новый протокол, эдакий очень упрощенный SNMP. Как и браузерe SNMP, браузеру этого протокола абсолютно все равно, какое устройство подключено - он автоматически сосчитает имена всех доступных объектов, создаст закладки в окне, прочитает текущие значения. Есть программа осуществляющая более сложный доступ (чтение и запись переменных, вывод на экран) по простому неветвящемуся скрипт-файлу. Логика работы прибора может быть легко проверена браузером протокола вручную. Если более сложная программа для PC нужна, она не будет единственным средством работы с прибором, можно не зависеть от другого программиста.
Пока доволен результатом, планирую выложить все на сайте фирмы, включая порты слэйва под AVR и MSP. Более того, есть порты мастера и для микроконтроллера, что обеспечивает "прозрачность" контроллера, который служит шлюзом.

К чему это я? Да просто читаю, как сложно реализовать стандартный низкоуровневый протокол под Windows, и предложения убрать часть спецификации. И в чем смысл частичного соблюдения каких-то спецификаций? Зачем нести полуразрушенный самими же прах старых протоколов? Совместимость все равно не гарантируется! Если хотя бы один обязательный пункт спецификации MODBUS не выполнен, это уже не MODBUS!

Я именно о том же.
В настоящий момент меня не очень интересует данная тема, но когда припрёт, то боюсь опять начнётся ваяние велосипеда. Если будет возможность с интересом прочту Вашу статью. Понятно, что конкретная реализация не обязательна, а вот идея порой стоит многого. Очень не хочется наступать на те же грабли на которые уже кто-то наступал.

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

[otrog]

Я потерял исходное сообщение, кто это высказал:
"Целью проектирования является разработка простого метода доступа к внутренним
параметрам приборов. Базовое условие - терминал не обязан знать или предполагать что-
либо о приборе для решения этой задачи. "

Моя вина . Это цитата из описания системы "Пирамида", ссылка на которую содержится в моем предыдущем сообщении.

[Svin62]

Скажите пожалуйста, вот если соединять слейвы с мастером выполненные на микроконтроллерах в мультипроцессорном режиме, то мастер указывает в 9-ом бите, что это: адрес или данные. А вот СОМ-порт компа может слать этот девятый бит?
В программе "терминал" установить режим с 9-м битом невозможно, нет там такого флажка.

Так же читал о возможности передавать идентификатор (адрес/данные) в стоп-бите.
Может быть его можно устанавливать/сбрасывать в компе?

Если комп не поддерживает на ур-не железа такую возможность, то как программно эмулировать на компе мультипроцессорный режим?

Короче, как мне добраться из компьютерной программы к этим битам.

Спасибо.

[demiurg_spb]

ИМХО никак.
Но может быть есть драйверы RS-232 которые имеют режим 9-ти бит данных типа FTDI, но я что-то не помню.
Или можно забацать как Real сделал на FT2232 ногодёргательным методом....

[zltigo]

Короче, как мне добраться из компьютерной программы к этим битам.

Управляя битом четности, ибо он и есть тот самый девятый бит . Есть возможность в 8250 устанавливать его в конкретное состояние (смотрите mark/space). 

[Svin62]

Управляя битом четности, ибо он и есть тот самый девятый бит . Есть возможность в 8250 устанавливать его в конкретное состояние (смотрите mark/space). 

Это в структуре DCB нужно установить поле Parity:
Parity - Определяет выбор схемы контроля четности. Данное поле должно содержать одно из следующих значений:

EVENPARITY-- Дополнение до четности
MARKPARITY-- Бит четности всегда 1
NOPARITY-- Бит четности отсутствует
ODDPARITY-- Дополнение до нечетности
SPACEPARITY-- Бит четности всегда 0??????????

Значит мне надо работать со значениями MARKPARITY/SPACEPARITY ?

Большое спасибо!

[zltigo]

Значит мне надо работать со значениями MARKPARITY/SPACEPARITY ?

Да.