Ethernet+TCP/IP, Самое дешевое решение Опции

[Rst7]

Решил поделиться с народом своим проектом. Положу в отдельную тему, а не в "Исходники...", потому как скорее всего надо будет обсудить

Предыстория такова - давно хотел сделать дешевое и простое подключение своего устройства к Ethernet, естественно с поддержкой TCP/IP. Сначала рассматривались общеизвестные варианты типа RTL8019, Wiznet и т.д. - первый отпал по причине слишком уж камня большого, второй - дорого. Была попытка реализовать PHY-уровень при помощи USART в режиме SPI на Mega88/168, однако оказалось, что если с передачей нет проблем, с приемом все хуже - слишком уж сложной получается схема синхронизации тактовой частоты проца с синхросигналом, выделенном из манчестера, в единичном экземпляре оно конечно поднимается, но о серийном повторении - ну никак.
Потом взгляд переместился на микросхемы PHY, и, при внимательном изучении, оказалось, что довольно просто обеспечить работу с PHY при тактовой проца 20МГц. Да и со стоимостью нет вопросов - Realtek'овский RTL8201BL стоит всего около 1$ (как заметил zltigo, Realtek вообще славится экстремально дешевыми решениями в области Ethernet). Была сделана тестовая платка (схему и pcb прилагаю) и на ней все запущено. Не обошлось без подводных камней, но они были успешно обойдены

.SCH и .PCB файлы в архиве - это схема и разводка тестовой платы. Проц используется ATMega168-20AI, PHY - уже упомянутый RTL8201BL, 74HCT547 - буферный регистр, заодно и преобразование уровней 3.3-5В (только не всех линий, по науке надо было еще кое-что преобразовать, но было лень. Вдруг будете использовать в более-менее серийном устройстве - не забудьте все выполнить как положено)

Сами исходники - под EWAVR5.10.

Код

          1 960 arp.h - заголовочник для ARP-пакетов
          6 404 eeprom_3.s90 - работа с троированным eeprom
          1 668 ethernet.h - заголовочник для Ethernet-пакетов
<DIR>          HTMLsource - каталог с исходными HTML-файлами и компрессором, который генерирует файл pages.c, запустите generate.cmd и посмотрите
            831 icmp.h - заголовочник для ICMP-пакетов
          2 400 ip.h - заголовочник для IP-пакетов
          3 487 mac.c - передатчик Ethernet-пакетов
          3 365 macros.m90 - вот не помню, файл из стандартного иаровского комплекта, зачем перенес в проект - хоть убейте не помню
          6 240 mac_rx.asm - прием Ethernet-пакетов
         21 591 main.c - HTTP-сервер
          4 188 md5cheat.c - MD5 для Digest-авторизации
         16 690 network.c - собственно TCP/IP-стек
            102 network_addr.h - адреса по умолчанию
          5 728 network_routines_avr.c - оптимизированные под AVR всякие процедурки, используемые стеком
         52 023 NikeE.ewp - проект
            159 NikeE.eww - воркспейс
          2 890 nike_e.h - заголовочник всего проекта
          4 993 pages.c - запакованные HTML-странички
          1 159 pages.h - заголовочник от страничек
<DIR>          PCAD - схема/плата
            204 prog.bat - прошиватель
          1 733 stdafx.h - типы данных
          2 731 stuff.asm - тут быстрый i2a (для AVR) и таблица CRC32
          6 256 tcp.h - заголовочник для TCP-пакетов

Заголовочники написаны на основе заголовочников из стека Prottoss'а, за что ему и спасибо.

Есть пара маленьких тонкостей - прием пакета написан на ассемблере, а вот передача - на Си, но я посматривал в листинг, посему исправления нужно вносить очень аккуратно, а вообще-то желательно переписать на ассемблере и посылку пакета. По простому можно заставить IAR сгенерить не листинг, а исходный текст (есть там галочка) и подключить его к проекту вместо mac.c.

На MAC-уровне реализовано управление входящим потоком при помощи метода, среднего между Back-pressure и Collision-Based. При переполненом внутреннем буфере на первый входящий пакет генерируется встречный пакет (как в Collision-Based) из 0x55, который оканчивается, когда буфер освобождается (Back-pressure).

Внутренние буфера 2*256 байт, поэтому, например, ICMP-пакет пинга с -l 209 дропается, а с -l 208 - нормально обрабатывается. Для TCP это не мешает (хотя, конечно, и падает скорость передачи), т.к. максимальный размер пакета регулируется окном.

Интерфейс стека с пользовательским софтом выполнен как вызов CallBack-функции, которая должна обрабатывать события TCP_EVENT_CONREQ (запрос соединения), TCP_EVENT_CONNECTED (соеденино), TCP_EVENT_CLOSE (закрыто), TCP_EVENT_ABORT (прервано), TCP_EVENT_ACK (подтверждение ранее переданных данных), TCP_EVENT_DATA (принята новая порция данных), TCP_EVENT_REGENERATE (повтор посылки с начала), TCP_EVENT_SEND (посылка следующей порции). Непосредственно разбор этих сообщений выполняется в HTTP_hook, который вызывает HTTP_hook_DATA_RX для обработки новых данных (например, собственно запроса GET/POST) и HTTP_hook_DATA_TX (генерация данных для передачи).

На данный момент реализованы только слушающие (серверные) сокеты, но нетрудно сделать и клиентские.

В HTTP-сервере реализована digest-авторизация. Соответственно пришлось пободаться с MD5 в плане уменьшения занимаемого места, удалось поместить его в 1100 байт, больше его под AVR не ужмешь видимо (хотя, конечно, пару байт всегда можно сэкономить, я имею в виду глобальное ужимание).

Само наполнение HTTP-сервера сейчас банальное - управление портом С, вывод значений АЦП и отдельная страничка настроек IP/MAC-адресов и задания новых login/pass.


Ну а вот так выглядит спаяное устройство


Ну и о скорости. wget в зависимости от погоды показывает 130-160 КБайт/с (порядка 1 Мбита/с). Теоретический предел приема - гдето под 4Мбита/с. Т.е. дропать пакеты он сможет именно с такой скоростью (и даже быстрее, потому что сначала я проверяю, мой ли пакет, а только потом считаю CRC32, этот расчет выполняется медленнее приема пакета, тут ничего не попишешь)

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

 NikeE.zip ( 106.73 килобайт ) Кол-во скачиваний: 11119

 

[A.l.e.x.]

А не проще ли на ENC28J60, как реализовано здесь http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex ?

[Rst7]

А не проще ли на ENC28J60

Дороже и жрет больше (причем намного, моя плата жрет ~50ма).

[zltigo]

А не проще ли на ENC28J60...

Дык, если говорить о цене решения, то PIC фитюлька стоит немало, да и греется, как печка. Хотя, конечно, MAC уровень сама собой обеспечивет и память на борту имеет...
P.S.
Опаздал с ответом но 1:1 с Автором

[Rst7]

на борту имеет...

На борту еще имеет 6 страниц ераты. Причем, в самых неожиданных местах.

но 1:1 с Автором

В смысле?

[A.l.e.x.]

Дороже и жрет больше (причем намного, моя плата жрет ~50ма).

Со стоимостью понятно, согласен. А можно ли на этой плате сделать переходник TCP/IP - COM со скоростью 115200, и с максимальной длиной пакета 255 байт со стороны COM? Т.е. подобие Modbus Ethernet Gateway.

[zltigo]

На борту еще имеет 6 страниц ераты.

И массу неописанных моментов в поведении и обработке ошибок.....
Хотя в общем-то работает без явных проблем в моих условиях

В смысле?

В смысле "один к одному" - полное совпадение взгляда .

[alexander55]

Со стоимостью понятно, согласен. А можно ли на этой плате сделать переходник TCP/IP - COM со скоростью 115200, и с максимальной длиной пакета 255 байт со стороны COM? Т.е. подобие Modbus Ethernet Gateway.

Очень хорошая идея, но еще лучше под 2 сети Моdbus.

[A.l.e.x.]

Я слышал, что у каждого ethernet-устройства должен быть уникальный MAC адрес. Можно ли задавать произвольные или одинаковые адреса?

__eeprom char MAC_EEPROM[ETH_HWA_LEN]={0x00,0x04,0x25,0x00,0x00,0x02};

[Rst7]

А можно ли на этой плате сделать переходник TCP/IP - COM со скоростью 115200, и с максимальной длиной пакета 255 байт со стороны COM? Т.е. подобие Modbus Ethernet Gateway.

Можно. Но надо подумать. Потому как ОЗУ мало, надо где-то буфер для приема хранить.

Можно ли задавать произвольные или одинаковые адреса?

Одинаковые - не стоит. Произвольные, с некоторой степенью риска - можно. Этот ID (первые три байта) - это Atmel'овский ID, последние три байта - собственно серийный номер устройства.

[defunct]

Rst7
ЗачОт!

[Dog Pawlowa]

Rst7
ЗачОт!

Ага, особенно за то, что выложил.

[bzx]

Если вести разговор о самом дешёвом решении, то PIC18F66J60 будет самым оптимальным вариантом, если мало ресурсов, то можно выбрать и помощнее PIC18F97J60. Цена вопроса ~4-5€

[defunct]

Если вести разговор о самом дешёвом решении, то PIC18F66J60 будет самым оптимальным вариантом, если мало ресурсов, то можно выбрать и помощнее PIC18F97J60. Цена вопроса ~4-5?

Это сам чип или чип с обвязкой?
т.к. ничто не мешает в решении Rst7 поставить m48 вместо m168. и цена вопроса mk - emac - phy превратится в ~1.5?

[Rst7]

Цена вопроса ~4-5?

Незащитано. Тут цена вопроса $2.5(а то и 2)+$1+сколько-то копеек буфер. Да и предубеждение у меня супротив пичков )

Тут другое на самом деле. Главное - идею в массы толкнуть. Кроме того, на LPC c FastGPIO портируется аж бегом. На SAM - надо посмотреть, но можно влезть вроде. Да и на 16-тимегагерцовый AVR тоже вроде получается всунуть.

[aaarrr]

На LPC и SAM портировать можно, но смысла большого нет - младшие кристаллы с MAC стоят достаточно дешево.

А идея и реализация красивые

[Mc_off]

RESPECT !!!

Спасибо огромное !

[Rst7]

младшие кристаллы с MAC стоят достаточно дешево

Да не скажите, вполне ничего так бесплатное приложение получается к LPC2103 например, или LPC213x-01. Тут нас zltigo все время пугает приходом супер-камней LPC1000 (если не ошибаюсь), тоже может круто получиться (хотя качество кодегенерации у IAR под Cortex оставляет желать лучшего)...

[singlskv]

Немного не по теме основного топика, но начал смотреть Ваш код с main и увидел:

Код

    while(ADCSRA_ADSC);
    __disable_interrupt();
    *p=ADC;
    __enable_interrupt();

и не понял смысл запрещения прерывания на время считывания ADC.
Зачем это сделано ?

Ааа, понял, просто для того чтобы 16бит значение считывалось за раз,
просто я такое чтение ADC в основном цикле никогда не использую и подумал что это нужно(зачем то, иногда) для правильного
считывания ADC.

[zltigo]

zltigo все время пугает приходом супер-камней LPC1000...

Да не пугаю совершенно и не думаю, что они супер по возможностям будут, но цены в нижней ценовой категории скорее всего подвинут. А то Luminary с Ethernet на борту совершенно дикие цены имеют для мелких потребителей. А так скорее всего достаточно обычные Cortex-M3 - софтовую эмуляцию можно пробовать уже сейчас на STR32. Только не могу придумать для чего можно применить подобные решения - для большого количества мелких девайсов уж слишком Ethernet структура громоздкой (не сколько дорогой, сколько именно громоздкой и ненадежной из-за обилия кабелей и свичей) получается. А если девайсы штучные, то и ультраэкономия как-то менее привлекательна. Что остаетя? Что-то офигенно массовое для бытового потребления? Что?

Ааа, понял, просто для того чтобы 16бит значение считывалось за раз,
просто я такое чтение ADC в основном цикле никогда не использую...

А просто, какие-нибудь больше, чем 8bit переменные модифицируемые в прерываниях или других процессах используете? Так вот та-же проблема....

[singlskv]

А просто, какие-нибудь больше, чем 8bit переменные модифицируемые в прерываниях или других процессах используете? Так вот та-же проблема....

Да использую, использую....,
просто при беглом просмотре мне показалось что это защита на время считывания 10бит регистра
ADC, и кстати к аккурантности в этом вопросе есть некоторые предпосылки...,
ну а потом просто понял что здесь 16бит защищенный доступ в чистом виде...

[Rst7]

ну а потом просто понял что здесь 16бит защищенный доступ в чистом виде...

Причем, именно для записи значения, для считывания из ADC он нафиг не нужен.

[GDI]

Идея очень хорошая и ее по праву можно поставить в один ряд с софтовой реализацией USB на AVR. Сам когда то думал о таком, но дальше идеи дело не зашло.

Теперь это надо как то красиво назвать, например EtherAVR или AVR-MAC и разместить где нибудь в интернете, например на embedders.org, могу дать контакты, если что.

[alexander55]

Что-то офигенно массовое для бытового потребления? Что?

Дешевая замена Xport - первое, что приходит в голову.
PS. Если удастся подключать через OPC-драйверы, то тогда открывается широкая дорога в АСУТП.
Представьте только, WinCC, InTouch совместимость.

[Rst7]

PS. Если удастся подключать через OPC-драйверы,

Я так понимаю, имеется в виду уже поступившее предложение о конверторе Modbus<->Modbus over TCP?

Ну давайте попробуем реализовать. Можете кратенько написать, чего надо? Только не надо отсылать читать мануал по Modbus over TCP

[alexander55]

Я так понимаю, имеется в виду уже поступившее предложение о конверторе Modbus<->Modbus over TCP?

Да.

Ну давайте попробуем реализовать. Можете кратенько написать, чего надо? Только не надо отсылать читать мануал по Modbus over TCP

Вобщем-то уже реализовано.
По-простому.
Используется протокол TCP/IP, соответствующего WinSock 1.1.
Сервис использует TCP/IP порты, незадействованный в системе.
Обычно контроллеры общаются с другими через сервер данных (база данных) по изеру и выступают в качестве клиентов.
Протокол OPC является посредником, он интерпретирует данные TCP/IP портов в пакетах и разносит их по полям ее. Этот протокол предназначен для стыковки с любым типом оборудования. Он весь гибко программируется (порты, поля пакетов).
Каждый производитель систем автоматизации считает своим долгом разработать свой набор :
- сервер данных (по их мнению наиболее быстрый)
- драйвер OPC
- систему визуализации.
Надо не релизовывать, а проверять на предмет конфигурируемости и совместимости с тем или иным продуктом.
PS. Надеюсь, что не запутал Вас.

[A.l.e.x.]

Я так понимаю, имеется в виду уже поступившее предложение о конверторе Modbus<->Modbus over TCP?

Ну давайте попробуем реализовать. Можете кратенько написать, чего надо? Только не надо отсылать читать мануал по Modbus over TCP

В MODBUS может использоваться 2 режима передачи данных: ASCII или RTU. RTU более интересен, т.к. применяется CRC16, а скорость передачи вдвое выше. Также его реализация получается проще(или компактнее).
В RTU-режиме сообщение начинается с интервала тишины равного времени передачи 3,5 символов. Максимальная длина фрейма - 255 байт. Для Modbus over TCP разбирать содержимое фрейма необязательно, достачно знать начало и его длину. Алгоритм работы приблизительно такой:
Со стороны USARTа: ожидание начала пакета, приём пакета до интервала между ними в 3,5 символа или до длины 255, пересылка полученного пакета в ethernet. Аналогично со стороны ethernet.

Возможно, лучше было бы пересылку пакетов осуществлять после проверки CRC.
Вот так выглядит фрейм:
---------------T----------T-----------T-----------T----------T---------------¬
¦ старт_____¦ адрес_¦функция_¦ данные_¦ CRC__¦ конец ¦
+-------------+---------+-----------+-----------+----------+---------------+
¦T1-T2-T3-T4¦ 8 бит ¦ 8 бит ¦n x бит ¦ 16 бит ¦T1-T2-T3-T4 ¦
L--------------+---------+-----------+-----------+----------+---------------

[alexander55]

Этот вариант самый удобный для реализации контроллера, т.к. ПО не изменяется.
Некоторая засада заключается в том, что запросы должен делать сервер (выполнять функцию мастера), что не очень вписывается в идеологию, которую я рассказал выше (вот здесь и могут быть вопросы). Вероятно, возможен какой-то программный мост между OPC и мастером.

[Erv&Sed]

RST7 я вас правильно понял, у вас реализован в том числе и HTTP протокол???

[Rst7]

у вас реализован в том числе и HTTP протокол???

Весьма неполный, как Вы понимаете.

[cornflyer]

msp430 + ENC28J60

[_Pasha]

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

Пакеты с BAD CRC.
Их надо как-то регистрировать. Как?

[Rst7]

msp430 + ENC28J60

Ну это ничем не отличается от любой_камень+ENC28J60. Это мы уже обсудили на первой странице

Их надо как-то регистрировать. Как?

Регистрировать? Отбрасывать да и все.

[_Pasha]

Регистрировать? Отбрасывать да и все.

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

[Rst7]

Сторона, отправившая плохой пакет, должна знать о том, что пакет не прошел.

Чето я там такого не припомню. Можно дословную цитату, что делать с пакетом, у которого плохо с CRC?

[_Pasha]

Чето я там такого не припомню. Можно дословную цитату, что делать с пакетом, у которого плохо с CRC?

Да это понятно - через таймауты все откинется.

If the server receives the request, but detects a communication error (parity, LRC,
CRC, ...), no response is returned. The client program will eventually process a
timeout condition for the request.

Получается, нужна обязательная поддержка диагностических команд и счетчиков. А это - разбор пакетов и, в общем, никакой прозрачной реализации репитера не будет.
Т.е. application layer нужен?

[Rst7]

Т.е. application layer нужен?

Ну не целиком же. По-быстреньком посмотреть, нет ли ахинеи в принятом пакете и дропнуть его, если что не так.
А можно конечно и совсем тупо транслировать его в 485, пусть там разбираются. Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

Я бы сделал все-таки эти проверки.

[_Pasha]

Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

Я бы сделал все-таки эти проверки.

Поговорили. Я этот случай и имел ввиду.

Резюме: будет две ипостаси: тупой репитер и как полноценная аппликуха для диагностики и поддержки конфигурируемого адресного пространства в ведомом сегменте RS-485. Дабы трафик был гуманный.

[Rst7]

Поговорили. Я этот случай и имел ввиду.

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

[defunct]

Максимальная длина фрейма - 255 байт.

Откуда взято ограничение длины?

Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

В обе стороны сделать CRC. В модбасовую сторону по modbus полиному "0xA001",
в Eth сторону - по любому оговоренному способу.

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

IMHO совсем не обязательно делать over TCP.
На мой взгляд, over UDP будет ничуть не хуже и даже быстрее, при этом значительно проще, плюс можно броадкастом общаться сразу с несколькими конвертерами. Гарантировать доставку - фиксированным числом ретрансмитов.

[_Pasha]

Откуда взято ограничение длины?

В обе стороны сделать CRC.

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

1. Modbus_over_serial_line_V1_02.pdf

The maximum size of a MODBUS RTU frame is 256 bytes.

С учетом адреса.

2. Хочется простого репитера, не вникающего даже в CRC. Хотя, с другой стороны, если прикрутить именно UDP, то и аппликуха влезет достаточно умная

3. +1

[Rst7]

Падаждытэ

Насколько я понимаю, есть спецификация Modbus over TCP, а вот over UDP как-то не встречал.

[sensor_ua]

есть спецификация Modbus over TCP

это не повод. Речь же вроде шла о туннелировании пакетов Modbus over serial line через сие устройство. А Modbus over TCP говорит, что CRC относится у него не к просто к инкапсулированному пакету Modbus over serial line, а к пакету в рамках TCP, где мухи отдельно и котлеты отдельно, потому это не есть туннелирование в чистом виде. ИМХО, туннелировать через UDP будет всё же попроще

[Rst7]

Речь же вроде шла о туннелировании пакетов Modbus over serial line через сие устройство.

Может я чего-то не вкурил? Я понял так, что хочется преобразователь Modbus over TCP <-> Modbus over serial line, чтобы и то и то согласно спецификации работало.

[sensor_ua]

Хм... думаю, что речь всё же шла об туннелировании Modbus over serial line <->TCP/UDP <->Modbus over serial line. При этом преобразование Modbus over serial line <->TCP/UDP может делаться как в устройстве, подключенном по RS к PC (чтобы не писать нового софта - вариации на тему Modbus over serial line гораздо более распространены), так и в самом PC.

[_Pasha]

Хм... думаю, что речь всё же шла об туннелировании Modbus

А вот и нет! Изначально,

Протокол OPC является посредником, он интерпретирует данные TCP/IP портов в пакетах и разносит их по полям ее.
********************************
PS. Надеюсь, что не запутал Вас.

Запутал-таки

Очевидно, обе реализации, как тоннель, так и виртуальный RTU, имеют востребованность.

По поводу TCP есть одна засада:
Modbus_Messaging_Implementation_Guide_V1_0b.pdf

Normally, on MODBUS serial line a client must send one request at a time. This means that the client must wait for the answer to the first request before sending a second request.
On TCP/MODBUS, several requests can be sent without waiting for a confirmation to the same server. The MODBUS/TCP to MODBUS serial line gateway is in charge of ensuring compatibility between these two behaviors.

Хочется услышать мнение RST7, как бороться с накоплением пакетов.

[galjoen]

А что вы всё в Модбас упёрлись? На мой взгляд это совершенно убогий протокол. Существует только из-за тяжёлого наследия. И тут ещё проблемка: пока мы весь пакет от ведомого не получим - работать с изернет не сможем. А 256 байт на скорости 115200 это более 20 милисекунд. Можно конечно извратится и чтение с USART в том-же цикле, что и чтение из изернет сделать, но это уж совсем большой изврат. Так и придётся для модбас 2й процессор ставить.
На мой взгляд переходник в CAN более перспективен. У CAN-то всё буферизировано. Да и у АВР с CAN - ОЗУ и FLASH поболее, хотя и дороже конечно.

приема - гдето под 4Мбита/с. Т.е. дропать пакеты он сможет именно с такой скоростью (и даже быстрее, потому что сначала я проверяю, мой ли пакет, а только потом считаю CRC32, этот расчет выполняется медленнее приема пакета, тут ничего не попишешь)

Могу написать, как CRC32 за 14 тактов на байт считать (за счёт увеличения размера потребной FLASH конечно). А вообще-то с какой скоростью из изернета к нам байты валятся? Может удастся CRC32 на лету считать? Если глупость написал - не пинайте. В изернете я полный ноль. Кстати может подскажете, что про изернет почитать. Это я насчёт переходника изернет2CAN.

А ещё я у вас Rst7 заметил странный код на асме:
dec R16
tst R16
Это зачем так сделано? Если задержка нужна - нагляднее nop поставить. Хотя я может там чего не понимаю конечно.
Rst7 - если не трудно изложите идею чтения данных из изернета пожалуйста, так чтобы чайники вроде меня поняли.

[defunct]

Хочется услышать мнение RST7, как бороться с накоплением пакетов.

Очевидно, в пределах линейки m48-168 - никак.
Надо больше памяти. M162 и внешнюю память или ARM.
Но тогда вся прелесть устройства (дешевизна) отпадает.

Думаю более логичным будет организация тунеля UDP<->modbus serial, а TCP GW реализовать на PC (если вопрос с поддержкой спецификации over TCP действительно актуален) и буфферизацию соответcтвенно делать там же.
e.g.


1. PC Modbus over TCP
|
2. <intermediate format over UDP >
|
3. Modbus over UDP
|
4. modbus serial

Первые два пункта реализовать на PC.
3-й и 4-й - возложить на девайс.

Сервер преобразовывающий Modbus over TCP в некий промежуточный формат over UDP с которым и будет работать девайс будет достаточно простой аппликушкой, с автопоиском UDP клиентов, опять же через broadcast.

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

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

[_Pasha]

А что вы всё в Модбас упёрлись?

Слухи о кончине модбаса сильно преувеличены.
Насчет TCP
Microchip TCP/IP stack

P.S. Кто-нить знает, как с доставабельностью Atmega164/324 ?

[Rst7]

Хочется услышать мнение RST7, как бороться с накоплением пакетов.

Тут я думаю играми с размером приемного окна мы вопрос решим. Принимается один пакет, размер окна выставляется 0, пакет отправляется в усарт, принимается ответ, отправляется в сокет и размер окна устанавливается опять в исходный. Вся буферизация будет в стеке большого брата.

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

[A.l.e.x.]

Откуда взято ограничение длины?

согласен, ошибка . На самом деле ограничения немного другие:

RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.

http://www.modbus.org/docs/Modbus_Applicat...tocol_V1_1b.pdf на странице 5

[Rst7]

И тут ещё проблемка: пока мы весь пакет от ведомого не получим - работать с изернет не сможем. А 256 байт на скорости 115200 это более 20 милисекунд. Можно конечно извратится и чтение с USART в том-же цикле, что и чтение из изернет сделать, но это уж совсем большой изврат.

По сравнению с самой идеей - это так, пыль для моряка. Вообщем, это не вопрос.

Так и придётся для модбас 2й процессор ставить.

Я надеюсь, обойдемся одним. В крайнем случае перейдем на лпц2103, не много проиграем

На мой взгляд переходник в CAN более перспективен. У CAN-то всё буферизировано. Да и у АВР с CAN - ОЗУ и FLASH поболее, хотя и дороже конечно.

И изобретать свой протокол для передачи пакетов кэн через эзернет? Нет чтото у меня желания.

Могу написать, как CRC32 за 14 тактов на байт считать (за счёт увеличения размера потребной FLASH конечно).

Напишите, посмотрим.

А вообще-то с какой скоростью из изернета к нам байты валятся?

Один полубайт за 8 тактов

Может удастся CRC32 на лету считать?

На XMega, разве что.

А ещё я у вас Rst7 заметил странный код на асме:
dec R16
tst R16
Это зачем так сделано? Если задержка нужна - нагляднее nop поставить. Хотя я может там чего не понимаю конечно.

Это не я. Это IAR психанул. Делался этот код из листинга сишного варианта процедуры, вот и осталось.

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

В понедельник. Сейчас ниасилю с мобильника.

[galjoen]

Могу написать, как CRC32 за 14 тактов на байт считать (за счёт увеличения размера потребной FLASH конечно).

Напишите, посмотрим.

В ZH всегда старший байт адреса таблицы переходов. Эта таблица состоит из 256 rjmp и начинается с адреса кратного 256. ZL, R19, R18, R17 - CRC аккумулятор. R16 - принятый байт CRC которого надо подсчитать.

Код

eor ZL,R16; получили в ZL объединяющую величину [1 такт]
ijmp; переход на таблицу переходов, а оттуда rjmp на наш случай [2+2 такта]

mAF:; сюда попадаем из таблицы переходов по rjmp. Объединяющая величина =AF. Таких кусков кода 256 штук.
ldi ZL,XX1; 1е число табличного вычисления CRC [1такт]
eor ZL,R19; получили новый старший байт обновлённого CRC аккумулятора [1 такт]
ldi R19,XX2; 2е число [1 такт]
eor R19,R18; следующий байт CRC ак-ра [1 такт]
ldi R18,XX3; 3е число [1 такт]
eor R18,R17; следующий байт CRC ак-ра [1 такт]
ldi R17,XX4; это младший байт - его ни с чем ксорить не надо [1 такт]
; итого получили обновлённый CRC32 ак-р, потратив на это 12 тактов. Ещё 2 такта понадобятся чтоб rjmp вернутся назад.

Объём всего этого 9*256 слов = 2304 слова. Так что таблицу из 256 rjmp придётся посредине размещать. Чтоб rjmp доставал.
А текст всего этого я ессно не вручную писал, а програмку составил. Она .asm и формировала.
У меня там даже 12 тактов на байт получалось. Т.к. я следующий байт сразу-же после вычисления CRC читал. Без rjmp назад. 256 копий кода получилось. Зато 1мегабайт в секунду успевал принять и CRC32 на лету посчитать при 20 мГц тактовой!
К сожалению у АВР команды eori с непосредственными данными нет. Если бы была - на 3 такта быстрее и на 3*256 слова короче получилось бы. Хотя м.б. можно eor на subi/sbci заменить. Но для этого теорию CRC посмотреть нужно.

А насчёт CAN - я имел в виду, что через эзернет только данные передаваться будут. А CAN протоколом пусть АВР занимается. Хотя тут вот какой вопрос - можно-ли сделать так, чтобы иногда передача через эзернет по инициативе нашего устройства начиналась? Или обязательно его опрашивать всё время надо?

[AlexG_changed]

Слухи о кончине модбаса сильно преувеличены.

Это точно.

P.S. Кто-нить знает, как с доставабельностью Atmega164/324 ?

По efind'у - не очень хорошо. Но, учитывая, что я сейчас работаю с ATmega324 - при желании можно.

[SasaVitebsk]

А для меня, было бы интересно COM порт виртуальный реализовать. Тогда, в одну сторону MODBUS не проблема. Нельзя же всё на Rst7 валить. Ну а туннель, не всем нужен.

[_Pasha]

В ZH всегда старший байт адреса таблицы переходов. Эта таблица состоит из 256 rjmp и начинается с адреса кратного 256.

Пока не вникал, работает ли Ваше ЦРЦ в целом, но
сразу встречное предложение:

Код

; пусть CRC32_stuff - адрес начала табличного вычислителя, сразу за таблицей прерываний

; ЦРЦ аккумулятор младший байт в регистре CRC_Lo

.def  Reg_m8 = r20; ввели регистр, в котором постоянно болтается 0x08

    ldi Reg_m8,0x08

; как добраться до вычислителя
   eor      CRC_Lo, r16       ; 1
   mul      CRC_Lo, Reg_m8; 2
   movw   zL, r0                 ; 1
   adiw     zL, CRC32_stuff  ; 2
   ijmp                              ; 2

Бухгалтерия: продули 5 тактов и два регистра, выиграли 256 байт.
Ессно, без претензий на абсолютную правоту.

[galjoen]

Пока не вникал, работает ли Ваше ЦРЦ в целом, но
сразу встречное предложение:

Можно и так конечно, но 5 тактов это 35% снижения скорости. А 256-3=253 слова (а не байт) экономии это только 12.5%. И ещё при таком способе экстремально быстро CRC посчитать не получится (это я не про 5 тактов). Я после каждого расчёта CRC rjmp не делал, а с приёмом синхронизировался, следующий байт данных читал, в буфер сохранял, ксорил и ijmp там-же делал (на это от 7 тактов уходило - если данные ждать не приходилось). И на расчёт CRC32 12 тактов уходило. Итого 19 тактов, что меньше 20. Т.е. как я уже писал - удавалось в поток данных 1 мБайт в секунду вклиниваться и в реальном режиме его контролировать.

А я CRC32 в том примере считал вводя данные в старший байт CRC аккумулятора. Мне это как-то ближе. Хотя исторически все почему то в младший байт вводят. Ну и производящие многочлены в этих случаях побитно переставлены - EDB88320 и 04C11DB7.

[galjoen]

Бухгалтерия: продули 5 тактов и два регистра, выиграли 256 байт.
Ессно, без претензий на абсолютную правоту.

У меня тоже предложение, как FLASH сэкономить. В табличном вычислителе ничего не вычислять. А только регистры загружать. Тогда мы в 3 такта проиграем, а в коде 3*256=768 слов выиграем. А в регистрах проиграем т.к. ещё 3 регистра по сравнению с первоначальным вариантом задействовать придётся. Но итог всё равно лучше чем у вас получится - т.к. в тактах проигрыш 3 такта а регистрах всё как и вас (у вас тоже 3 регистра добавилось R0, R1 и регистр =08).

Код

; пишу со вводом в младший байт CRC акк-ра
; R4, R3, R2, ZL - CRC акк-р. R17, R18, R19 - вспомогательные регистры. R16 - принятый байт CRC которого надо подсчитать.
; тут инициализируемся
rjmp Begin; идём в начало цикла

backCRC:
eor ZL,R2; получили новый младший байт обновлённого CRC аккумулятора [1 такт]
mov R2,R17; необходимая пересылка на кот-й теряется 1 такт [1 такт]
eor R2,R3; следующий байт CRC ак-ра [1 такт]
mov R3,R18; необходимая пересылка на кот-й теряется 1 такт [1 такт]
eor R3,R4; следующий байт CRC ак-ра [1 такт]
mov R4,R19; необходимая пересылка на кот-й теряется 1 такт [1 такт]
; итого получили обновлённый CRC32 ак-р, потратив на это 17 тактов.
Begin:; Здесь точка первоначального входа в цикл чтения данных и расчёта их CRC

; Тут получаем данные, для которых собственно и считается CRC32

eor ZL,R16; получили в ZL объединяющую величину [1 такт]
ijmp; переход на таблицу переходов, а оттуда rjmp на наш случай [2+2 такта]

mAF:; сюда попадаем из таблицы переходов по rjmp. Объединяющая величина =AF. Таких кусков кода 256 штук.
ldi ZL,XX1; 1е число табличного вычисления CRC  - младший байт[1такт]
ldi R17,XX2; 2е число [1 такт]
ldi R18,XX3; 3е число [1 такт]
ldi R19,XX4; 4е число [1 такт]
rjmp backCRC; регистры загружены - возвращаемся собственно на вычисление [2 такта]

Итог:
1. По сравнению с моим первоначальным вариантом - проигрыш 3 такта =21% быстродействия, 3 регистра, выигрыш на 33% FLASH меньше -1536 вместо 2304 слов в таблицах (+ то, что rjmp везде доставать будет).
2. По сравнению с вашим вариантом - проигрыша ни в чем нет, выигрыш по быстродействию 2 такта =12%, выигрыш по FLASH 20% 1536 вместо 2048 слов в таблицах (+ то, что размещать можно не в начале/конце FLASH).
Если кому интересно - могу и с "классическим" вариантом сравнить (где команды lpm используются).

А у меня - такие чайниковские вопросы по теме:
1. Какое преимущество даст подсчет CRC32 на лету.
2. Какое преимущество увеличение ОЗУ (что такое "дропает").
3. Не будет ли проблем с мак-адресом. В смысле не придётся ли за него кому-нибудь платить.

[Rst7]

1. Какое преимущество даст подсчет CRC32 на лету.

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

2. Какое преимущество увеличение ОЗУ (что такое "дропает").

to drop - бросить. Среди людей, работающих с ЛВС означает отбрасывание пакета по какой либо причине - не наш, не содержит ожидаемых данных, не смогли обработать из-за отсутствия ресурсов и т.д.

3. Не будет ли проблем с мак-адресом. В смысле не придётся ли за него кому-нибудь платить.

По науке - надо заплатить. Но, я думаю, что если пользоваться Atmel'овским ID - конфликтов Вы не встретите

[_Pasha]

... только регистры загружать.

Логично.

Если кому интересно - могу и с "классическим" вариантом сравнить (где команды lpm используются).

А чего там сравнивать - классика медленнее.

Что-то было про "заменить eor на subi" - не получится.

А если нибблами считать? Там извратиться никак нельзя?

ИМХО, если на лету не считать, то проц будет колом вставать часто. А у нас же еще RS-485 есть. Ему тоже жить хочется.

Уровень УАРТ - через прерывания и буфер приема/передачи. Это понятно.
Забирает памяти 256 байт, выровненных + 1 регистр-указатель навсегда отобрали.

[galjoen]

А если нибблами считать? Там извратиться никак нельзя?

Когда мне FLASH для таблицы из 256*32х битных слов не хватало я CRC нибблами считал т.к. всего 16*32х битных слов надо. Быстрее чем побитно получалось, но и только.

ИМХО, если на лету не считать, то проц будет колом вставать часто. А у нас же еще RS-485 есть. Ему тоже жить хочется.

Ну рассчёт CRC работе RS485 мешать не будет. Прерывания-то во время рассчёта ничо не мешает разрешить. А вот наоборот, во время работы с RS485 (и передача и приём) с эзернетом работать не получится (ни принимать ни передавать). Т.к. прерывания от USART это минимум 12..13 тактов если в нём даже никакие ошибки не проверять. Хотя конечно можно извратится до невозможности и во время приёма/передачи по эзернет с USART по готовностям работать. Придётся приём/передачу 1 байта по USART по нескольким приёмам/передачам по эзернет раскидать. Даже и с двумя USART одновременно таким образом работать получится. Занимался я такими извращениями, но размер потребной FLASH при этом увеличивается многократно. И время кодирования/отладки соответственно т.к. кол-во вариантов приёма/передачи и переходов между ними большое получается + переходы от передачи по USART к ожиданию ответа и приёму самого ответа. Это примерно как для ПЛИС вручную программу писать.

Уровень УАРТ - через прерывания и буфер приема/передачи. Это понятно.
Забирает памяти 256 байт, выровненных + 1 регистр-указатель навсегда отобрали.

Чтобы и во время работы с эзернет USART работать продолжал - ему 256 байт ОЗУ на передачу и 256 байт на приём надо. И это на каждый USART. Так что без внешнего ОЗУ видимо не обойдёшся. А ещё видимо придётся 16ти разрядные таймеры считающие с частотой процессора под это дело задействовать.

[_Pasha]

Быстрее чем побитно получалось, но и только.

Я имею ввиду, что у нас обмен с RTL8201 идет нибблами.

Чтобы и во время работы с эзернет USART работать продолжал - ему 256 байт ОЗУ на передачу и 256 байт на приём надо.

Дык это в общем случае. А здесь RS485, т.е. полудуплекс.
Поэтому именно 256 байт.

По поводу прерывания приема символа из RS485 берем шаблон из ГЦЦ ISR(xxx,ISR_NOBLOCK){} и все.

[galjoen]

Дык это в общем случае. А здесь RS485, т.е. полудуплекс.
Поэтому именно 256 байт.

Т.е. вы предлагаете принимать в тотже буфер из которого только что передали запрос? Но в этом случае если в ответе например CRC не совпадёт, мы повторить запрос не сможем т.к. этим неверным ответом буфер затрём.

По поводу прерывания приема символа из RS485 берем шаблон из ГЦЦ ISR(xxx,ISR_NOBLOCK){} и все.

А тут я не понял. Как на асме-то приём выглядеть будет. И передача тоже. Её ведь тоже по прерыванию придётся делать. Или вы предполагаете так поступить: пока с RS485 работать не закончили - с эзернетом не работаем. Ну и наоборот. Но что-то мне такой способ не нравится. И так-уж RS485/модбас сильно тормозной. Ну и то, что в этом случае мы токо мастером сможем быть. А слейвом никак.

[_Pasha]

мы повторить запрос не сможем т.к. этим неверным ответом буфер затрём.

Дык там не надо повторять. Просто молчание ягнят. Ошибка обнаруживается по таймауту.
С другой стороны, их надо регистрировать в диагностических целях, чтобы наш конвертор не превращал систему в общество слепо-глухонемых. Это возможно только в случае реализации набора счетчиков и некоторого сервиса уровня аппликухи. Подробно на modbus.org. Курим мануалы

А тут я не понял. Как на асме-то приём выглядеть будет.

Экий Вы непонятливый...

Код

rxc_isr:
             sei
             push  r0
             in      r0,Sreg
             push  r0
             push  xL
             push  xH
             push  zL
             ldi     xH,high(Modbus_Buffer)
             lds    xL, ModBus_BufPos; не надо нам регистр портить для хранения указателя. Это от лукавого
             lds    zL,UDR0
             st      X+,zL
             sts    ModBus_BufPos,xL
             pop   zL
             pop   xH
             pop   xL
             pop   r0
             out    Sreg,r0
             pop   r0
             reti

Передача аналогично.
В первом приближении обработку ошибок не включаем. Пока не прижмет
Обработка пакета и его формирование в самом низком приоритете.
Паузы в 3.5 символов, таймауты и т.д. по единому системному таймеру на базе Т1.
В такой постановке вопроса чем более тормозной модбас, тем спокойнее душа программера

[Rst7]

rxc_isr:              sei

Вот так делать нельзя, флаг UDRE снимается после чтения UDR, поэтому, разрешение прерывания в самом начале приведет к попе.

Но это не вопрос, там все в принципе решается. Щас занялся этим, как раз несколько огрехов поймал (неправильно стрипается VLAN-тег, перенес его отбрасывание прямо в прием пакета; где-то между ревизиями случайно грохнул отбрасывание пакета длинной меньше 64 байт и т.д.)

Вы мне вот что скажите, сколько времени ожидать пакет от slave'а после передачи ему запроса?

[_Pasha]

MODBUS over serial line specification and implementation guide V1.02 p.19

The master is configured by the user to wait for a predetermined timeout interval ( Response time-out) before aborting the transaction.
This interval is set to be long enough for any slave to respond normally ( unicast request). If the slave detects a transmission error, the
message will not be acted upon. The slave will not construct a response to the master. Thus the timeout will expire and allow the
master’s program to handle the error. Note that a message addressed to a nonexistent slave device will also cause a timeout.

Практически >= 1 секунды.
Если посмотреть на те же преобразователи частоты - от 100мс до 10 секунд.

Вот так делать нельзя, флаг UDRE снимается после чтения UDR, поэтому, разрешение прерывания в самом начале приведет к попе.

Спасибо за уточнение. Я понял, что Вы про RXC в первую очередь.

Код

.def Auxreg=r15; все-таки украли регистр
rxc_isr:
             lds     AuxReg,Udr0
             push  AuxReg; избавились от дабл-буфера
             sei
             pop   AuxReg
; дальше по тексту
             push  r0
...................................

Это уже плохо. Медленно.
Может, альтернативы есть?
Насчет UDRE - еще хуже. Думать надо

З.Ы. Придумал как правильно передавать
У нас AuxReg уже украден.

Тогда первым действием отправляем в UDR
Потом sei
потом ужЕ адресуем след. байт и он хранится в AuxReg до прерывания.
Все ОК, тем более, что первый байт совершенно не сложно отправить в основном процессе

[Rst7]

Я понял, что Вы про RXC в первую очередь.

Да, безусловно. Описался.

Практически >= 1 секунды.Если посмотреть на те же преобразователи частоты - от 100мс до 10 секунд.

А не дофига ли? Это же если пару-тройку девайсов отпали, то на круг будет добавка по пол-минуты...

Это уже плохо. Медленно. Может, альтернативы есть?

Да там единственная альтернатива - опрос не по прерываниям, причем в отдельном цикле и внутри приема/передачи пакета из/в эзернет. Иначе - никак, ведь пакет длинной 254 байта из эзернета (а на самом деле 254+8(преамбула макс.)+4(возможный тег VLAN)) = 212мкс да плюс еще выход из прерывания - больше 2х байт на скорости 115200 - значит может пропускать байты.

Короче, код там хитрый получается, но получается. Думаю, до конца недели по вечерам асилю.

Кстати, вопрос про тестовые терминальные програмки еще открыт.

[_Pasha]

А не дофига ли?

Ну, я ступил - написал только про медленные устройства.
Вообще, устройства с таймаутами одного порядка группируются в один сегмент. Множественные запросы ведь не допускаются...
Я в PLC пока не копенгаген, мож кто напишет.

[galjoen]

Да там единственная альтернатива - опрос не по прерываниям, причем в отдельном цикле и внутри приема/передачи пакета из/в эзернет. Иначе - никак, ведь пакет длинной 254 байта из эзернета (а на самом деле 254+8(преамбула макс.)+4(возможный тег VLAN)) = 212мкс да плюс еще выход из прерывания - больше 2х байт на скорости 115200 - значит может пропускать байты.

Короче, код там хитрый получается, но получается. Думаю, до конца недели по вечерам асилю.

+1
Но код там не просто хитрый, а очень хитрый получается. Т.к. из 2*8 тактов между приёмом нибблов по моим прикидкам удастся высвободить только 5 тактов подряд на приём/передачу по USART. А в этих 5 тактах 3..4 такта на опрос готовности потратить придётся (это самый распостранённый случай). А уж само чтение/передачу по USART при приёме следующего байта из эзернет делать - другой вариант приёма из эзернет. И таких вариантов по моим прикидкам штук 20 или даже больше набирается. С приёмом/передачей 1 байта из USART в 5 тактов ведь не уложишся, а ещё переходить от передачи к приёму по USART при приёме из эзернет придётся - драйвер RS485 на приём переключать. При передаче в эзернет - чуть проще конечно. Там кол-во свободных тактов подряд побольше получается. Из-за этого число вариантов передачи в эзернет поменьше будет. Как и число переходов от варианта к варианту.

Если вы до конца недели всё это асилите - снимаю шляпу.

И ещё - в приеме/передаче USART прерывание разрешать нельзя. Т.к. если это прерывание прерывание от эзернет прервёт, а в нём мы с USART работать будем, то страшная каша получается. Придётся в прерывании от USART соответственно готовности от эзернет смотреть.

Или я может чего не понимаю? Может во время работы с эзернет мы на RS485 забьём (и наоборот). Тогда таких проблем конечно не будет - в таком случае всё элементарно.

Мне кажется в проетке ATmega164 оптимальнее чем ATmega168 использовать т.к. там 2 USART. И ног больше - ОЗУ подключить легче.
А ещё хотел ссылочку попросить. Где про эзернетовские пакеты+преамбулы+теги наиболее понятно и жел-но по русски написано.

[prottoss]

Где про эзернетовские пакеты+преамбулы+теги наиболее понятно и жел-но по русски написано.

Я пользуюсь вот этим http://book.itep.ru/1/intro1.htm

[_Pasha]

С приёмом/передачей 1 байта из USART в 5 тактов ведь не уложишся

Особенно добавляет пессимизма то , что UART находится черт знает где по адресам.

Кстати, про передачу - надо обеспечивать, чтобы пауза между посылками было меньше 3.5 символа.

При приеме езера и RS485 одновременно поллинг UART можно сделать 2-3 раза. Етого хватит.
В общем, решаемо.

[alexander55]

Я в PLC пока не копенгаген, мож кто напишет.

В АСУТП есть:
- коммутационный процессор -КП (это мост между различными интерфейсами и изером)
- выносные контроллеры (связаны с КП по RS485 - в разных вариантах) - типовой цикл опроса до 1с и меньше
- невыносные контроллеры (связаны с КП по интерфесу MPI - типа SPI) - типовой цикл опроса 5-20 мс.
Все локальное управление выполняется местными контроллерами.
На верхнем уровне данные архивируются, визуализируются, сигнализируются и т.д. Управления задвижками, реле, двигателями, управления циклограммами - это не функция верхнего уровня. Если есть управление - то на уровне более глобальном. Например, параллельно работают 4 насоса, потребление снизилось ночью, с верхнего уровня может прийти команда локальному контроллеру - 2 насоса отключить.
PS. Мне видится в качестве КП - LPC2106.

[galjoen]

Особенно добавляет пессимизма то , что UART находится черт знает где по адресам.

Ну это не проблема - 1 такт добавляется.

Кстати, про передачу - надо обеспечивать, чтобы пауза между посылками было меньше 3.5 символа.

Не 3.5, а 0.5 символа. А некоторые требуют вообще 1 бит. Иначе запрос игнорируют.

При приеме езера и RS485 одновременно поллинг UART можно сделать 2-3 раза. Етого хватит.
В общем, решаемо.

Решаемо, но надо помнить, что любой байт из эзернета может последним в пакете оказаться. В этом случае и кол-во вариантов завершения приёма из эзернета соответственно возрастает.
Поэтому я про ATmega164 думаю. Если FLASH не хватит - можно 324 поставить. По ножкам совпадает. И ОЗУ без фиксатора адреса подключается - ног хватает. И USART 2 шт. И стоит стоко-же если не дешевле почему-то.

Кстати, вопрос про тестовые терминальные програмки еще открыт.

А мне кажется, что наилучшим тестером для этого устройства будет ещё одно такое-же устройство. Таким образом мы и приём и передачу одновременно оттестим. Хотя посложней конечно сделать будет. А может я и ерунду конечно написал т.к. в эзернете профан.

А у меня такой вопрос - сколько тактов у нас есть с момента появления прерывания от эзернета до того, как мы первый нибблл данных прочесть ОБЯЗАНЫ? Если это 8 тактов - не вложимся. Т.к. из-за асинхронности 1 такт добавляется, потом 4 такта команды которую прерываем (макс), 4 такта переход на саму таблицу прерываний и в самой-же таблице чтение с данных с порта 1 такт. Итого 10 тактов получается.
Или у нас 15 тактов есть? Или больше из-за преамбул и т.п.?

В АСУТП есть:
- коммутационный процессор -КП (это мост между различными интерфейсами и изером)

А тут у меня такой вопрос - если нам на запрос по модбас (мы мастер) не ответили или ответ с ошибкой CRC пришёл - надо-ли запрос повторять? И если надо, то скоко раз?

[Rst7]

А мне кажется, что наилучшим тестером для этого устройства будет ещё одно такое-же устройство. Таким образом мы и приём и передачу одновременно оттестим.

Не, не годится. Во первых - я сейчас делаю гейт Modbus TCP <-> Modbus serial, значит для RS485 устройство будет мастером. Во вторых - надо именно с чужим проверять, а то можно потом обнаружить, что со своим пашет, а с чужим - нет.

А у меня такой вопрос - сколько тактов у нас есть с момента появления прерывания от эзернета до того, как мы первый нибблл данных прочесть ОБЯЗАНЫ?

Ну вот у RTL8201BL задержка от появления сигналов до выставления CRS 600нс макс, и до RXDV 3200нс (хотя это уже не суть важно). А до последнего ниббла преамбулы (его надо точно прочитать, чтобы быть уверенным в начале пакета) 7.5*800=6000нс. Значит, от установки CRS у нас есть время в 120 тактов до чтения байта, но еще надо сохранить все регистры и засинхронизироваться с RXCLK - это еще накладных расходов на 50 тактов примерно.

[galjoen]

Не, не годится. Во первых - я сейчас делаю гейт Modbus TCP <-> Modbus serial, значит для RS485 устройство будет мастером. Во вторых - надо именно с чужим проверять, а то можно потом обнаружить, что со своим пашет, а с чужим - нет.

Да я-то имел в виду - специальную тестовую програмку для генерации всяких хитрых пакетов туда прописать. Таких пакетов, которые другим путём получить проблематично. Например с повреждённым CRC и т.п.

Значит, от установки CRS у нас есть время в 120 тактов до чтения байта, но еще надо сохранить все регистры и засинхронизироваться с RXCLK - это еще накладных расходов на 50 тактов примерно.

Ну при таком раскладе я полон оптимизма. Т.к. в других частях программы никаких особых извращений не надо делать будет. Если что-то не относящееся к собственно эзернет нужно сделать - подключусь. Да хоть ту-же генерацию глючных пакетов под управлением от RS485 в режиме слейва - если вообще это нужно конечно.

[_Pasha]

Не 3.5, а 0.5 символа. А некоторые требуют вообще 1 бит. Иначе запрос игнорируют.

ЧИТАЕМ ВНИМАТЕЛЬНО. (Это относится и ко мне )
Modbus_over_serial_line_V1_02.pdf, p13

In RTU mode, message frames are separated by a silent interval of at least 3.5 character times. In the following sections, this time
interval is called t3,5.

If a silent interval of more than 1.5 character times occurs between two characters, the message frame is declared incomplete and should be discarded by the receiver.

Итого мы оба неправы.
< 1.5 символа

[alexander55]

А тут у меня такой вопрос - если нам на запрос по модбас (мы мастер) не ответили или ответ с ошибкой CRC пришёл - надо-ли запрос повторять? И если надо, то скоко раз?

Зависит от требований.
Modbus обеспечивает только правильность принятой информации, а достоверность прихода не гарантирована. Это уже вопрос второй, надпротокола.
Например, IP обеспесчивает правильность принятой информации, а уже TCP - гарантирует приход (а для примера, UDP - не гарантирует).

[Rst7]

Например, IP обеспесчивает правильность принятой информации

Не гарантирует, т.к. нет подсчета контрольной суммы данных, только заголовка. Хотя если через Ethernet - то гарантия есть.

[zltigo]

уже TCP - гарантирует приход..

Не гарантирует . Только попытается повторить доставку. Причем плата за этот "сервис" зачастую совершенно неадекватна - таймауты и буфера в массовых реализациях, как правило жуткие - через много десятков секунд и десятков-сотен переданных килобайт узнаете, что "ну не шмогла"... повторите .

[alexander55]

Не гарантирует, т.к. нет подсчета контрольной суммы данных, только заголовка. Хотя если через Ethernet - то гарантия есть.

IP - интернет прококол. Содержит IP адреса получателя, отправителя, инфо и КС. На принимающей стороне пакеты с неверной КС просто отбрасываются.
TCP - протокол передачи. Делает разбиение (и сбор принятых) данных по небольшим пакетам (они могут идти по разным маршрутам) и организует диалог для контроля принятых пакетов.

[Rst7]

IP - интернет прококол. Содержит IP адреса получателя, отправителя, инфо и КС. На принимающей стороне пакеты с неверной КС просто отбрасываются.

Контрольная сумма там только заголовка

[alexander55]

Не гарантирует . Только попытается повторить доставку. Причем плата за этот "сервис" зачастую совершенно неадекватна - таймауты и буфера в массовых реализациях, как правило жуткие - через много десятков секунд и десятков-сотен переданных килобайт узнаете, что "ну не шмогла"... повторите .

Тут ничего не поделаешь. Тише едешь ... Закон жизни.
Тем не менее, связка TCP/IP в данный момент основная.

[alexander55]

Для автора темы.
Варианты конвертора Ethernet-RS485 выпускает www.moxa.com
Цены у наших продавцов от 20 до 30 евро.
Варианты http://www.moxa.com/product/Serial_to_Ethernet_Products.htm.
Мы ипользовали NPort 6110. Сейчас объект под пуско-наладкой.
Документацию и утилиты конфигурации и тестирования можно у них найти на сайте через поиск.
Это вариант организации мастера на уровне OPC-драйвера или мастер отделен по сети TCP/IP.

[MrYuran]

Для автора темы.
Варианты конвертора Ethernet-RS485 выпускает www.moxa.com
Цены у наших продавцов от 20 до 30 евро.

Насчет 20-30 евро ничего не попутали? может быть 120-130?

Нам NPort5150 обошёлся с доставкой в 4000р.
Не может быть, чтобы такая разница в ценах.

20-30 это скорее похоже на RS-232 <-> RS-485

Сообщение отредактировал MrYuran - Mar 27 2008, 06:15

[alexander55]

Насчет 20-30 евро ничего не попутали? может быть 120-130?

Нам NPort5150 обошёлся с доставкой в 4000р.
Не может быть, чтобы такая разница в ценах.

20-30 это скорее похоже на RS-232 <-> RS-485

Попробуйте efind.ru и посмотрите текущие цены. Вообще-то они уже сняты с производства, наши тоже покупали под объект штук 50-70 по хорошим ценам, но все течет и изменяется.
PS. А вообще-то они нам не очень понравились. По изеру все пингуется без проблем (хотя длины типа 800 м-1200м, до 3000 м, правда по волокну), а модбасом танцы с бубном (хоть и 10-20м).

[MrYuran]

PS. А вообще-то они нам не очень понравились. По изеру все пингуется без проблем, а модбасом танцы с бубном.

Мне наоборот оччень понравилось. Даже сам чё-то подобное хочу сделать (по мотивам данной темы)
А с модбасом понятно почему проблемы.
Не любит он тайм-ауты. А в езернете тайм-ауты не нормируются и могут достигать нескольких миллисекунд (а то и больше).
Правда, в NPort по-моему, есть настройки пакетов, то есть фикс. длина, отправлять каждый байт, автомат и т.д.
То есть смысл в том, что пакет модбаса (RTU) надо отправлять одним пакетом езернета, без разрывов.
Либо использовать аски, там таймауты до 1 с.

У нас такой случай был с модулями RealLab от конторы НИЛ АП (RLDA).
Из-за таких случайных задержек на NPort 2 модуля друг за другом ушли в какое-то 4-е измерение и перестали отвечать на внешние раздражители.
Потом оказалось, что они вошли в какой-то недокументированный режим калибровки и самостоятельно вернуться уже не смогли.

[alexander55]

На объекте типа "Таможенный склад" стоит порядка 10 КРУ. На каждом КРУ стоят Sepam от 4 до 6 штук и еще Deif овские счетчики. На верху сервер данных с оркестром и АРМ InTouch.
Штуки 4 КРУ уже запустили. А с другими пляски продолжаются.
Подумалось. Может, мы говорим об одном и том же объекте в Питере ?

Не любит он тайм-ауты. А в езернете тайм-ауты не нормируются и могут достигать нескольких миллисекунд (а то и больше).

Как раз вчера, я консультировал ребят и рассказывал им как настроить таймауты NPort. Завтра уже будут результаты. Может придется ехать с осциллом смотреть сигналы.
Очень опасное место, там кранами на большой скорости перетаскивают грузы. Надо смотреть в оба. Задавят легко.

[Rst7]

Для автора темы.
Варианты конвертора Ethernet-RS485 выпускает www.moxa.com
Цены у наших продавцов от 20 до 30 евро.

Хоть убейте, ну $165 минимум (специальный сентябрьский лохотрон от Вектора ) нашел за этот NPort. Что-то Вы попутали, да и вообще, любой АСУшный чих (любой модуль, я имею в виду) стоит от 100 евро.

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

[prottoss]

Не помню сайт, откуда скачивал



Еще бы посоветовал, для отладки со стороны сети CommView. Положил на местный ftp в upload

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

 rs232pro.rar ( 565.67 килобайт ) Кол-во скачиваний: 325

 

[alexander55]

Хоть убейте, ну $165 минимум (специальный сентябрьский лохотрон от Вектора ) нашел за этот NPort. Что-то Вы попутали, да и вообще, любой АСУшный чих (любой модуль, я имею в виду) стоит от 100 евро.

Может, я что-то попутал. Я закупками не занимаюсь, а в голове как-то отложилось ...
PS. Впрочем, для Вас такие цены очень даже хорошо.
А утилиты и документацию NPorta скачайте, будете знать, что надо делать.

[Rst7]

Еще бы посоветовал, для отладки со стороны сети CommView.

О да, без этого - как без рук. Давно пользуюсь с удовольствием.

К сожалению, это все не совсем то, что я просил. Я просил рабочий эмулятор модбас-устройства с последовательным портом. И терминал для MODBUS-TCP, который умеет создавать и посылать именно пакеты модбас. Я, конечно, могу скрипты понаписывать, но не хотелось бы ошибиться.

[sensor_ua]

В NModbus был эмулятор слейва

[alexander55]

О да, без этого - как без рук. Давно пользуюсь с удовольствием.

К сожалению, это все не совсем то, что я просил. Я просил рабочий эмулятор модбас-устройства с последовательным портом. И терминал для MODBUS-TCP, который умеет создавать и посылать именно пакеты модбас. Я, конечно, могу скрипты понаписывать, но не хотелось бы ошибиться.

Лучше взять реальное устсройство, например Deif или счетчик СЭТ-4ТМ или что-то (от родоначальника Modicon). Для Sepam 1000+ серии 40 Merlin Gerin пакеты расписаны с CRC.
На все есть хорошие pdf.
Не ошибетесь.

[Rst7]

В NModbus был эмулятор слейва

А можно мордой лица ткнуть? Ссылку в смысле...

[sensor_ua]

www.nmodbus.com

[alexander55]

[galjoen]

Под Win невозможно слейв сделать (или какой-то страшный драйвер придётся писать). Дело в непредсказуемых задержках. А тут задержки в доли милисекунды нужны. Даже переключать приём-передачу в RS485 и то проблема. Я эту проблему в Win обходил использованием драйвера CAN (вместо драйвера RS485). Драйвер CAN только 0 передаёт, а 1 за счёт резисторов устанавливается. Уровни-то у CAN и RS485 не сильно отличаются - на короткой линии всё работает. Т.е. передатчик 1 выставил и приём - это одно и тоже. Т.е переключать приём и передачу вообще не нужно. Конечно самопереданные байты приходится принимать, а потом отбрасывать. Но вобщем мастера реализовать можно, а вот со слейвом проблема. Быстро ответить не получится - время не гарантируется. Кстати с переключением между передачей и приёмом RS485 у контроллера тоже проблемка есть. После передачи последнего байта запроса мастером надо СРАЗУ-ЖЕ на приём переключаться. Иначе, если слейв СРАЗУ-ЖЕ отвечать начнёт, в сети RS485 2 устройства одновременно передавать будут. Причём одно 1 (стоп-бит и паузу после него), а другое 0 (стартовый бит). Я эту проблему управлением приёмом-передачей с помощью таймера решаю. Когда последний байт в передачу пишу - таймер в соответствии со скоростью/форматом запускаю. И он (таймер) своим выходом автоматом с передачи на приём RS485 драйвер переключает.
Кстати рекомендую Rst7 платку с учётом этого разводить.

[sensor_ua]

если слейв СРАЗУ-ЖЕ отвечать начнёт

Зачем-то существуют обозначенные паузы, являющиеся маркерами фрейма RTU

[A.l.e.x.]

О да, без этого - как без рук. Давно пользуюсь с удовольствием.

К сожалению, это все не совсем то, что я просил. Я просил рабочий эмулятор модбас-устройства с последовательным портом. И терминал для MODBUS-TCP, который умеет создавать и посылать именно пакеты модбас. Я, конечно, могу скрипты понаписывать, но не хотелось бы ошибиться.

Может ModbusPoll_4.3.1 подойдёт?

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

 ModbusPoll_4.3.1.rar ( 610.35 килобайт ) Кол-во скачиваний: 949

 

[galjoen]

Зачем-то существуют обозначенные паузы, являющиеся маркерами фрейма RTU

И устройства существуют, творцы коих про существование этого не знают.
Вообще с паузами в модбасе полный бардак. Я встречался как с такими устройствами, которые при скорости 115200 в режиме слейва через 16 милисекунд отвечает. И с такими которые через 50 микросекунд отвечает. Но заявлять "это устройство нестандартное - поэтому мы с ним работать не будем" глупо. Ты работать не будешь - купят у того кто будет.
А вобще про модбас я в этой теме уже своё мнение высказывал: убогий протокол. Поэтому в своих разработках на CAN перехожу.