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

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

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

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

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

ATMega8 к RS485:

Правильно?

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

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

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

Так я Вас не обвиняю. Я просто предложил своё. Пусть сам выбирает.
- Драйвер 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 не использую. Не нравится.