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

Предыстория такова - давно хотел сделать дешевое и простое подключение своего устройства к 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.


Заголовочники написаны на основе заголовочников из стека 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, этот расчет выполняется медленнее приема пакета, тут ничего не попишешь)

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

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

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

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



В смысле?

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

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

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

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

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

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

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



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

Rst7
ЗачОт!

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

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

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

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

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

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

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

RESPECT !!!

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Да.


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

В 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--------------+---------+-----------+-----------+----------+---------------

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

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

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

msp430 + ENC28J60

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

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



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

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

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

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



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

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

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

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

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

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

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


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

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

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

1. Modbus_over_serial_line_V1_02.pdf

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

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

3. +1

Падаждытэ

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

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

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

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

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



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

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

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


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

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

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

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


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

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

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

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

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