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

 

[galjoen]

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

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

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

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