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 - если не трудно изложите идею чтения данных из изернета пожалуйста, так чтобы чайники вроде меня поняли.

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

[_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.