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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ATMega8 к RS485:

Правильно?

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

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

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

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

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

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

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

Я конечно извиняюсь, что влезаю в такую умную беседу, но зачем говорить о велосипеде и пытаться его изобретать? Или интерес ради "просто вумно поболтать" ?. Опять же о том же 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 драйвера не предлагать

Это несколько не то. Это максимально возможные значения параметров при которых эта микросхема еще не сгорит (соседние уже могут ). Ориентироваться надо на раздел Specifications, или его еще называют DC characteristics. Там указываются номинальные (типичные, рабочие) значения параметров.
да, почти все правильно, только ноги земли и 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 я выкладывал схему с несколько лучшими парамтрами (там же объяснение за счет чего).
TxD на DI, на DE можно и ICP1, а можно и OCRх (тогда таймер сможет аппаратно выключать передачу). Или опять же взять идею автоматического переключения из схем по ссылкам. Резистор ставится не в каждом устройстве а только на концах линии (в документе который выложил prottoss про него расписано в разделе 3.4.5).
Серьезная заявка на успех. Так держать!

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

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

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

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

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

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



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

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

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

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

Спасибо не мне, а ребятам которые придумали хороший протокол. Просто на компьютере можно не только по форумам вопросы печатать (это не Вам лично), а еще много интересных мест посетить
Я не дал ему рыбу - Вы говорите так, как будто я ему подорил 4-е платы - одна для РС, а на остальных гордо восседают мега8))). Я просто, чем бестолково объяснять, дал челу готовый документ, в котором довольно разжеванно говорится про все, что ему нужно, чтобы организовать относительно простой многопроцессорный обмен. Ну и пускакй не нравится, ребятам из Ford, BMW, Toyota, Nissan, Daewoo... продолжать? очччень нравится. И не только им, шахтерам, металлургам, нефтянникам ETC

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

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

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

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

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

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

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

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

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