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

[li4]

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

[jorikdima]

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

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

Внешний мультиплексор не особо хочется ставить, надо низкое потребление.
Но, вообще говоря, не будет такой ситуации, когда все эти 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

[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 В) не получится.

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

[SasaVitebsk]

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

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

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

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

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

[Dog Pawlowa]

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

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

[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 драйвера не предлагать

[prottoss]

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

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

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

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

[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]

[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 мс - таймаут в порту отрабатывается аппаратно, а вот уведомлениие об этом событии приложению ОСь выдаст конечно с задержкой, но это уже не столь важно будет - главное таймаут будет зафиксирован

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



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