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

 

[Rst7]

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

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

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

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

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

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

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

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

[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 пришёл - надо-ли запрос повторять? И если надо, то скоко раз?

[alexander55]

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

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

[zltigo]

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

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