galjoen 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Сравните с: А в 485-м интерфейсе багов нет и логов никаких не надо! И ловить нечего... По заказу одной из известных фирм сделал прибор, подключающийся на их 485 шину (с протоколом типа модбаса), слушающий и пишуший весь трафик вместе с паузами на встроенную флеш. Вообще, это что-то типа чёрного ящика, но ради интереса посмотрел лог с весьма ответственного объекта при нормальной работе. Так багов там немеряно. Вообще удивительно - как всё работает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 2 июля, 2010 Опубликовано 2 июля, 2010 · Жалоба Не скажите. Знаете, почему уважающие себя люди никогда не будут использовать нашу электронику в ответственных местах? Потому, что в нашем воплощении RS485 логи, таки, нужны и ловить есть чего. Даже простейший Modbus сообразно со стандартом сделать не можем... Ключевое слово было выделено. 485-й интерфейс "простой как ээээ Мир" © :) т.е. если и нужны логи, то это будут логи протокола, а не интерфейса. А там ведь товарищ логирует и ловит причуды интерфейса, затем и уже отдельно - наверняка приколы протокола уровнем повыше, и думает что это хорошо и так и надо... Так багов там немеряно. Вообще удивительно - как всё работает. Потому что есть КЗ (код защиты). А сколько там пакетов теряется - то уже совсем не важно. Уважающий себя мастер в случае ответственного объекта всегда спросит дважды, и при несовпадении двух ответов спросит еще разок и так до тех пор пока не будет полного консенсуса между мастером и слейвом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба А чего ж нет, выводы у t13 сильные - DC Current per I/O Pin - 40.0 mA.Не знал, т.к. моя рабочая лошадка mega8(88,48). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба Лучше потратить пару часов на изобретение своего, с учетом своих потребностей, а не брать Modbus и "расширять" его потом. Ну а зачем расширять? Стандартных команд более чем достаточно. Мало того, половина обычно даже не используется. В новых редакциях даже файлы уже кидать можно. Единственное, что бы добавить - автоматическую раздачу адресов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба 485-й интерфейс "простой как ээээ Мир" © :) т.е. если и нужны логи, то это будут логи протокола, а не интерфейса. А там ведь товарищ логирует и ловит причуды интерфейса, Не совсем понял, что тут называется интерфейсом, а что протоколом. Похоже под интерфейсом понимается физический уровень, т.е. драйверы. Если так, то у CAN (стандартного, 2-х проводного) драйвер проще и лучше, чем у 485. По крайней мере, там не может возникнуть случая, когда один драйвер тянет шину в 1, а другой в 0, и те девайсы, что ближе к первому, воспримут состояние на шине как 1, а ко второму - 0. Да и послушать шину чтобы сравнить, что там реально происходит с тем, что он отправил, девайс не может. Т.е. может, конечно, но толку нет - всё равно совпадёт. Да и проводов к драйверу меньше - при гальваноразвязке актуально. А сколько там пакетов теряется - то уже совсем не важно. Даже если теряется 100% пакетов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба Не совсем понял, что тут называется интерфейсом, а что протоколом. Похоже под интерфейсом понимается физический уровень, т.е. драйверы. Интерфейс включает также и формирование/декодирование фреймов которые по нему гуляют, определение ошибочных фреймов. CAN'овкие фреймы (те что Вы программно формируете) сложнее тех что ходят по 485-му. Фрейм в 485-м - включает Start ... данные ... Parity.. Stop, формируется/и декодируется железом UART'а. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба Интерфейс включает также и формирование/декодирование фреймов которые по нему гуляют, определение ошибочных фреймов.Не совсем так. Имеет смысл говорить не про интерфейсы и протоколы, а про уровни согласно сетевой модели OSI. Тогда RS485 это физический уровень, а CAN это уже канальный уровень. Бо RS485 на аппаратном уровне не поддерживает детектирование коллизий и контроль целостности данных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба Имеет смысл говорить не про интерфейсы и протоколы, а про уровни согласно сетевой модели OSI. Тогда RS485 это физический уровень, а CAN это уже канальный уровень. Бо RS485 на аппаратном уровне не поддерживает детектирование коллизий и контроль целостности данных. Не премешивайте теплое с мокрым. На аппаратном уровне 485й интерфейс способен формировать, детектировать и декодировать фреймы, их начало/конец и их целостность (четность/наличие правильного стоп бита) средствами UART'а МК. Разница между 485-м/CAN'ом/Ethernet'ом и т.п. только в размере фрейма и способе обнаружения ошибок. Канальный уровень заканчивается на фреймах. Следовательно 485-й интерфейс, как и CAN, включает и физику сигналов и канальный уровень. Чтобы пресеч возможные дебаты по этому поводу, вот для Вас цитата взятая по Вашей же ссылке: Канальный уровень (англ. Data Link layer) Основная статья: Канальный уровень Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает во фреймы, проверяет на целостность, если нужно, исправляет ошибки (посылает повторный запрос поврежденного кадра) и отправляет на сетевой уровень. Для 485-го исправлять ошибки просто не нужно, т.к. нет смысла усложнять простые вещи - протоколы верхних уровней сами все исправят, повторят и т.п. при необходимости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 3 июля, 2010 Опубликовано 3 июля, 2010 · Жалоба Не премешивайте теплое с мокрым. На аппаратном уровне 485й интерфейс способен формировать, детектировать и декодировать фреймы, их начало/конец и их целостность (четность/наличие правильного стоп бита) средствами UART'а МК.Ну раз у вас такая аргументация, то давайте уж тогда основы рассматривать. Если вас это не очень затруднит, то найдите, пожалуйста, в стандарте TIA/EIA-485-A, который специфицирует интерфейс RS485, упоминание об UART, микроконтроллерах и фреймах или вообще что-либо отличное от электрических и частотных характеристик этого интерфейса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 4 июля, 2010 Опубликовано 4 июля, 2010 · Жалоба Ну раз у вас такая аргументация, то давайте уж тогда основы рассматривать. Если вас это не очень затруднит, то найдите, пожалуйста, в стандарте TIA/EIA-485-A, который специфицирует интерфейс RS485, упоминание об UART, микроконтроллерах и фреймах или вообще что-либо отличное от электрических и частотных характеристик этого интерфейса. Приведу полное название документа на который вы ссылаетесь - "Electrical Characteristics of Generators and Receivers for Use in Balanced Multipoint Systems", чтобы было видно, что он описывает ну.. явно НЕ интерфейс. Иначе слово interface фигурировало бы в названии документа. Заодно можно на дату выхода стандарта посмотреть, - тогда и МК с UART'ом еще не существовали в природе, а если и был то один. :) Спаведливости ради соглашусь, что по физике 485-го можно гнать что угодно, например HDLC фреймы. Но реалии таковы, что дефакто RS-232/485 в отрыве от UART'а сейчас НИКТО мало кто рассматривает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 4 июля, 2010 Опубликовано 4 июля, 2010 · Жалоба Приведу полное название документа на который вы ссылаетесь - "Electrical Characteristics of Generators and Receivers for Use in Balanced Multipoint Systems", чтобы было видно, что он описывает ну.. явно НЕ интерфейс. Понятие "интерфейс" является довольно раплывчатым, это "совокупность средств и методов взаимодействия между элементами системы". Не имея ни малейших на то оснований, вы пытаетесь навязать какое-то свое, частное понимание этого термина. Бесспорным фактом остается то, что RS485 специфицирован стандартом TIA/EIA-485-A (а до этого - стандартом RS-485), и что в этой спецификации нет и намека на свойства и характеристики, которые вы приписываете какому-то мифическому "интерфейсу RS485". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 4 июля, 2010 Опубликовано 4 июля, 2010 · Жалоба Бесспорным фактом остается то, что RS485 специфицирован стандартом TIA/EIA-485-A (а до этого - стандартом RS-485), и что в этой спецификации нет и намека на свойства и характеристики, которые вы приписываете какому-то мифическому "интерфейсу RS485". Имею на то все основания - все кому не лень без задней мысли подключают драйвер RS485 к UART'овому RXD/TXD, RE/DE цепляют на UART'овый RTS. Производители МК для UART'а даже режим специальный придумали и так и назвали (UART MODE RS485). Ковертеры RS232<>RS485 впринципе не могут работать с данными отличными от UART фреймов, а здесь почему-то мы отвлеченно рассуждаем о том, что RS485 это строго физика. Нет не строго физика. И в контексте конкретно этой темы все кто предлагал пользовать RS485 - подразумевали эту связку UART<>RS485, как само собой разумеющееся явление. Связка UART<>RS485 PHY образует 485-й интерфейс, без этой связки RS485 - это непригодная к использованию фантазия расстояний, частот, напряжений, терминаторов и прочего хлама, такая же как Ethernet PHY в чистом виде. Понятие "интерфейс" является довольно раплывчатым, это "совокупность средств и методов взаимодействия между элементами системы". Не имея ни малейших на то оснований, вы пытаетесь навязать какое-то свое, частное понимание этого термина. Именно совокупность, т.е. не только как связать снаружи много 485-х драйверов (что и описывается в документе), но и как связать внутри, вчастности как МК подключить к RS485-й сети. Если вернуться к вышеупомянутой модели ОЗИ - интерфейс - это связь между уровнями (например интерфейс связи сетевого уровня с канальным), т.е. подразумевает стыковку с двух сторон, а протокол - связь множества элементов на одном уровне (например протокол сетевого уровня). Поэтому см. выше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 4 июля, 2010 Опубликовано 4 июля, 2010 · Жалоба Ковертеры RS232<>RS485 впринципе не могут работать с данными отличными от UART фреймов, а здесь почему-то мы отвлеченно рассуждаем о том, что RS485 это строго физика. В принципе, это, как раз, не так. Конвертор RS232-RS485 в строгом смысле - это только преобразователь уровней сигналов, т.е. физических интерфейсов в чистом виде, и не более того. Никакого UART-та внутри там, как правило, нет. А снаружи - он только подразумевается. Другое дело, что подразумевается - практически всегда. Однако, ни что не мешает, вместо UART, прицепить к драйверу RS485 (или к RS422, или к RS232) модуль который будет использовать, например, манчестерскую кодировку. Если такое решение будет использоваться согласованно, для всех устройств на линии - все будет работать, никуда не денется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 4 июля, 2010 Опубликовано 4 июля, 2010 · Жалоба Что то мы залезли в теорию, причём выясняется как теоретически правильно называется связка UART+драйвер RS485 (UART+485). Думаю, для практиков, а начинающие здесь это практики, это не представляет интереса. Поэтому предлагаю обсудить связку UART+драйвер CAN как базу для создания маленькой сети. Это будет гораздо интереснее. А уж как это будет называться - не так важно. Пусть будет UART+11898, если ни у кого нет возражений. На мой взгляд, именно такая связка наиболее оптимальна для создания маленькой сети т.к.её стоимость незначительно выше (драйвера одинаковой "брендовости" дороже на $0.3) чем UART+485, а по свойствам (мультимастерность, приоритеты, эхо-контроль и т.д.) она приближается к CAN. Я так вообще не могу найти ни одного недостатка у UART+11898 по сравнению с UART+485. Если в том же модбасе заменить все драйвера RS485 на CAN-овские всё продолжит работать как ни в чём не бывало... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 4 июля, 2010 Опубликовано 4 июля, 2010 · Жалоба Если в том же модбасе заменить все драйвера RS485 на CAN-овские всё продолжит работать как ни в чём не бывало... А как насчёт длины линии в 1..2 км? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
