Если солидные - это управляемые свичи, то там уж как руками наконфигурили. И, кстати, всегда переконфигурить можно. А мыльницы - они, в основном, все шторм дропают по умолчанию. Там либо резистор бутстрепа перепаивать, либо припаивать EEPROM'ку с необходимой конфигурацией. Лично я припаиванием епромки пользуюсь без зазрения совести, конечно, не для банального отключения штормконтрола

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

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

А что, в Вашем проекте было так необходимо пролить такой объем броадкаста? Или тонкости поведения свичей выяснились, когда уже было поздно что-либо менять?

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

С ADM самодельные железки пользуем.

Надо было мультикаст зашарашить



Которые себе такого не позволяют по умолчанию Вопросов больше не имею

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

Не для этой задачи, а для TDM<->Ethernet

Итак,гуру пообщались о своем о "гуровском",теперь можно и нам простым смертным о наших делишках покалякать.
Вроде победил я этого ежика,2 часа сыплю в него чем не попадя, зависаний нет.
Должен сразу извиниться перед zhevak,пришлось все-таки "махать"флагом разрешения прерывания Меги.Это по времени и стабильности работы оказалось выгодней,чем как рекомендует мелкочип,при входе в обработчик запрещать выдачу прерываний на пин INT ENC,а при выходе разрешать.Больно медленно-4 транзакции SPI на установку банка регистов и 2 на сброс EIE.INTIE.И вдобавок временами все-таки висло.
У меня сделано следующим образом-вход внешнего прерывания меги настроен на работу по низкому уровню,а не как рекомендует мелкочип по падающему.В обработчике запрещаю прерывания и устанавливаю флаг наличия данных в буфере ENC.SPI тоже работает по прерываниям,т.к поллинг SPI с его многочисленными while(!(SPSR&(1<<SPIF))) на 8Мгц Меги жрет ну очень много времени.
В главном цикле подбираю флаг и запускаю процедуру чтения буфера.Если нет ошибок-анализ,чего там прилетело.Если что-то нужное(ARP,пинг или запрос сервера)-отвечаю.Если нет никаких операций с ENC-разрешаю внешнее прерывание от ENC.Если пин стоит в 0,значит есть еще пакеты и все повторяется.Если пакеты летят быстрее,чем успеваем их забирать,то при достижении EPKTCNT==255 ENC начинает их дропать. Как-то так...
А вообще конечно медленный чип,чтобы забрать пакет и подготовиться к приему следующего надо сделать кучу телодвижений.И даташит полное г-но или рассчитан на телепатов,весьма мутно изложено и на все про все на все режимы работы с пяток примеров в несколько строк на псевдокоде.

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

Типа, например такого (писано несколько лет назад для SLIP, но идея должна быть ясна)


Кстати, _sliprx сразу и контрольную сумму IP считает на ходу.

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

Кстати, я бы на Вашем месте озадачился правильной обработкой Flow-Control'а.

это типа всякие там back pressure?я книжку по ethernet еще до этого места не дочитал,на форматах пакетов остановился

Ага. Без этого будут потери пакетов.

Насколько я ничего не понимаю,Flow-Control делается только при TCP-обмене?А если у меня в сети на серваке ломаная итальянская прога для расчета антенн ARP-request -ами флудерастит,то что я могу сделать кроме как пожаловаться админу?
З.Ы. Я реализовал разбор заголовков на лету,спасибо.В общем-то сейчас меня все устраивает,ходовые испытания прошли успешно.С одной машины непрерывно пинговал девайс,с другой ARP слал-пакеты не дропались и девайс не вис.

Нет. Это необходимо именно на уровне L2. TCPшный флоуконтрол - это совсем отдельная жизнь.



А Вы вот так сделайте в коммандной строке:


100 - это количество потоков пингов (можно и больше), x.x.x.x - адрес Вашего девайса. И тогда уже смотрите, дропает или нет пакеты. При рабочем Flow-Control не должно.

Всем доброго времени суток!
А кто куда RESET у ENCшки цепляет? Пока вертятся в голове мысли:
- подвести его к CS через сопротивление
- оставить висячим
- "подкачивать" его питанием ч\з резистор
Подскажите, как лучше сделать?

Вы будете, судя по представленым 'вариантам', очень удивлены, но он подключается к подходящему GPIO микроконтроллера.

Ну я про этот вариант знал, только забыл его написать.
Благодарю за ответ

А кто-нибудь использовал 74HCT08 для поднятия уровней у ENCшки? Я так понимаю, можно напрямую подвести, например, [SO] с ENC28J60 к замкнутым между собой [A] и у 74HCT08 и ловить с [Y] 5V tolerant уровень?

Цитата(kernel @ Apr 19 2009, 00:59)

А кто-нибудь использовал 74HCT08 для поднятия уровней у ENCшки? Я так понимаю, можно напрямую подвести, например, [SO] с ENC28J60 к замкнутым между собой [A] и [B] у 74HCT08 и ловить с [Y] 5V tolerant уровень?

Или на один из входов (А или В) нужно подводить питание?

Попробую объяснить яснее.

[b]Задача: необходимо согласовать уровни ENC28J60 и 5-вольтовой Меги.

Судя по даташиту ENC28J60, согласовать уровни можно с помощью 74HCT08 вот так:


Функциональная схема 74HCT08 выглядит так:


Вопрос: могу ли я просто замкнуть между собой [A] и [B] у 74HCT08, подводя к нему выход ENC28J60 и получать на выходе [Y] у 74HCT08 "съедобный" для 5v ATMEGA уровень?

PS: уже всю схему нарисовал, а на этой 74HCT08 застрял

Уважаемые, ну неужели никто не поднимал уровень ENC28J60 до 5V ?

Тема немного постарела, но все же.
Удалось ли кому нибудь победить подвисание ожидания отправки пакетов или нет?
Пробую и так и сяк, кроме как принудительным прерыванием ожидания по таймауту, не выходит (кстати так же сделано в микрочиповском стеке).
На всякий случай сделал повторную отправку пакета, если первый так и не ушел, интересно, что со второй попытки операция всегда успешно проходит. В таком варианте обмен по TCP стал поживее (исходящие пакеты перестали теряться).

Уточните, проблему и что сделали. О какой ветке, напимер, микрочиповского стека идет речь?

Всем доброго времени суток.
при работе с enc28j60 возникла проблема.
сперва висла из-за огромного к-ва входящих пакетов (на каждый формировался ответ), но странным образом - пакеты принимались, а вот отсылать отказывалась (mega подмигивает на каждый входящий и исходящий пакет). полез в эррату, начал потихоньку править код в соответствии с рекомендациями. и вот дошел до пункта, где говорится о потери указателя на новый пакет в буфере enc. рекомендуют поменять местами входящий и исходящий буфера. сделал и в итоге получил ситуацию с точностью до наоборот - при зависании перестает принимать, но стабильно по таймеру раз в 3 секунды шлет пакеты.
по началу все устраивало, т к программа опрашивала устройство раз в 15 секунд и контроллер следил за интервалами между запросами - если их не было в течении минуты, то enc получала софтовый ресет и работа возобновлялась. теперь же появилась необходимость в web-интерфейсе (заказчик хочет контролировать состояние девайса через мобильный браузер), а полинг девайса программой ушел на второй план (т е не факт, что программулина всегда будет включена). соответственно выходом из ситуации стал принудительный сброс каждые 30 минут.
подскажите, есть ли выход из ситуации?
мега тактируется от enc (1/4), SPI соответственно 3.125 МГц, ревизия чипа 6 (возвращает 110), выполнены требования B7 Silicon Errata (кроме пункта 15 про софтовый подсчет CRC), прерывания от enc не использую.
завтра еще попробую запустить мегу на 20МГц и ограничить скорость на порту свитча в 64к, может тогда не будет переполнения буфера.

Возникла проблема с этим ENC28J60. Почему-то через некоторое время (даже при простое) перестает принимать пакеты (о чем сообщают регистры), хотя "пакетный" светодиод моргает. Пробовал на двух разных ревизиях чипов (4 и 6), результат одинаков. У кого-нибудь была подобная проблема?

Через некоторое время EPKTCNT всегда возвращает ноль (даже при приходе пакетов), переинициализация enc28j60 иногда возвращает его к нормальной работе на некоторое время
Может быть инициализирую его как-то не правильно? От этого может быть такая проблема?
PS: похоже все про этот чип уже давно забыли...

после того как сделал абсолютно все рекомендации в эррате к 6 ревизии + прикрутил маленький шаманский бубен все работает уже вот 3 недели на подоконнике под постоянными fping'ами (100мс период, 256 байт длина) + время от времени в перекурах кнопаю его web-интерфейс. все шарашит нормально
шаманство заключалось в том, что раз в минуту проверяю к-во входящих пакетов (после выполнения последней эрраты редко зависает только прием пакетов). если их нет (а они будут, т к включено это все в офисную сеть с 50+ компутерами) то под зад его софтовым ресетом и все пучком. судя по статистике такое случалось всего 4 раза за 3 недели. клокать мегу от enc (потому ногу reset enc на мегу цеплять запрещаеца ). входные пакеты проверять только "полингом".
вот собстна после бессоных ночей только в таком режиме и заработала более-менее.

ну а если за минуту вдруг действительно не было ниодного пакета, то имхо ничего страшного, лишний ресет не помешает всеравно в эфире тишина

HALFer, большое спасибо за ответ. Из сказанного Вами возникли еще вопросы: при софтовом ресете нужно заново реинициализировать регистры контроллера или можно только подкинуть саму команду ресета и продолжать работу дальше? И проверка пакетов "полингом" - это и есть проверка (EPKTCNT > 0)?
Мегу клокать от ENC не могу, т.к. нужна высокая частота (сейчас 16, потом будет 20), хотя хотелось бы. Кстати, а ножку INT от enc кто-нибудь применяет? Я ее прицепил к меге, планировал только при стуке ногой INT по меге обрабатывать пакеты, но задумался - надо ли?

А у меня все ровно наоборот... нога ресет ENC заведена на мегу,и тактируется мега от собственного кварца и работаю я по прерываниям.
Последний раз к девайсу прикасался месяца 3 назад-ничего не виснет.Что я делаю неправильно?

У меня так же - ATMEGA16 с собственным кварцем 16MHz, к ней подведена нога INT и RESET enc28j60. Но через некоторое время EPKTCNT виснет на нуле, т.е. входящих пакетов всегда нет WHALE, а у Вас какая ревизия чипа?

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

Отправьте, пожалуйста. Почту сейчас в ЛС скину. Заранее благодарю.

отправил

Огромное спасибо, WHALE!
По схеме: уже не первый раз замечаю, что CS у ENC подтягивают резистором, а у меня не подтянут. Может быть это влияет отрицательно на ЕНКшку? У меня схема соединения ENC та же (даже все компоненты и их номиналы совпадают с Вашей схемой), за исключением резистора на CS.

Ну так повесьте резистор-минутное дело.Правда,не думаю,что это сильно поможет..

Попробовал ловить пакеты по прерыванию даже не проверяя EPKTCNT (следовал примеру WHALE, т.к. даже схема соединения ENC почти полностью совпадает), девайс работал еще быстрее, чем без INT, но ENC также продолжал виснуть через несколько минут\часов в основном после простоя Пока сделал, как предложил HALFer, рестарт и переинициализацию enc28j60 каждую минуту (только при условии, если EPKTCNT == 0), девайс работает, но это, мягко говоря, не очень хороший вариант. В выходные попробую поставить на CS резистор, но, думаю, толку от этого не будет

У вас МЕГА работает на 16Mhz.А питаете её от 5V?правильно-ли согласовали уровни с ENC.
У меня,если обратили внимание,Мега висит вместе с ENC на 3,3V и тактируется от 8Мгц.

Мега работает на 16MHz, питание 5В. Уровни согласовал с помощью 74HCT08N (который, кстати, рекомендуется в даташите самого ENC28J60), схему приводил выше, да вроде с этим не должно быть проблем (уровни воспринимаются нормально), хотя на всякий случай я пробовал менять на ходу на другую 74HCT08N (другого производителя) - результат тот же.
Только что выяснилась неприятная особенность: общение с девайсом абсолютно прекращается через некоторое время (т.е. после "зависания"). Как оказалось, не работает даже сброс, в том числе и аппаратный.
Проблем с инициализацией SPI вроде быть не должно (SPCR = (1<<SPE)|(1<<MSTR); SPSR |= (1<<SPI2X), тем более что нога RESET через некоторое время тоже не воспринимает сигнал

Что значит "не работает даже сброс"? Вы видите осцилографом,что мега ресетит ENC, и обмен при этом не
возобновляется?Или мега тоже зависает?

Каждую минуту таймер выполняет следующие действия: подается на порт со светодиодом 1 - светодиод горит; выполняется ресет (хардварный) с инициализацией ENC; подается на порт со светодиодом 0 - светодиод не горит. Результаты таймера через некоторое время немного другие: светодиод меняет свое состояние, а ENC не сбрасывается (когда ENC ресетится - это видно даже по светодиоду link`а, который должен погасать на несколько сотен миллисекунд во время сброса). После зависа пакеты ENC принимает (другой светодиод моргает при приеме пакетов), при этом не срабатывает прерывание, не заполняется положительным числом регистр EPKTCNT (который и должен сообщать о приходе пакета). Точно вспомнить не могу, но, если я не ошибаюсь, не помогает даже установка другой ревизии ENC28J60 на ходу. Складывается впечатление, что виснет SPI у ATMEGA.

я даже не представляю,что надо сделать чтобы повесить мегу-мастера spi.
а установка ревизии ENC на ходу-это как и зачем?Она-же только читается.
вы не пробовали поставить мой протокол инициализации и приема пакетов?

Очень сомневаюсь, что СПИ может зависнуть. Сам прикручиваю к мегам16-32, 48-88 цветные ЖКИ - там в одном пакете на дисплей идет 96*132*2= 25 тысяч байт, если б хотя бы 1 байт завис - были бы серьезные артефакты. А так все идеально, причем неделями напролет... Ищите косяки в коде, или глюки у ENC

подскажите люди знающие.
задача: есть простейший логер, на ATmega168, получает 50 байт по UART и пишет в AT45DB321D.
нужно эти данные (все или вновь добавленные) передать по TCP/IP на комп.
взял ENC28J60H подключил по примеру http://www.tuxgraphics.org/electronics/200...icle06111.shtml
TCP/IP их же. связка заработала.

инициатором запроса пересылки данных выступает комп в сети.

подскажите как правильно реализовать обмен данными в TCP/IP ?

сделал по примеру WEB сервера т.е. на запрос от компа в сети, отвечаю данными по 50 байт - работает.
но если за данными приходится лезть во флешку, а потом отвечать на запрос, то приложение на компе вылетает в TIMEOUT.

где почитать про обмен данными ? или как правильно реализовать механизм передачи данных из флеш в комп ?

Попытайтесь увеличить timeout в своей программе


Посмотрите в сторону Modbus over TCP/IP (например).

showone,
посмотрите в сторону UDP. проще реализация и вы властны делать что угодно. многие скажут что-то про гарантию доставки и все такое, но для работы девайса с собственным софтом намного лучше реализовать эту самую гарантию + парочку "фирменных" фишечек
конкретно у меня UDP без проблем работает на расстоянии Мариуполь(Украина)<->Москва. TCP пришлось прикрутить только из-за необходимости в web-интерфейсе.
http://91.204.198.43 - завтра после 10 запущу макетку, пусть еще пыль пособирает пару недель )) макетка набросаная проводом мгтф и совершенно не соответсвует рекомендациям. включен будет в свитч офисной сети, поэтому всякого широковещательного мусора должно хватать для создания полевых условий
там кстати и ведется статистика зависаний ENC. EthR это счетчки сброса enc (инкриментируется при зависании и при передергивании питания), startup это счетчик тех самых передергиваний питания.
логин admin
пароль 123456

Немного неверно я выразился: под установкой ревизии ENC я имел ввиду замену самого контроллера на контроллер другой ревизии (с 6 на 4) во время работы устройства. Протокол инициализации и приема пактов пробовал переносить на свой проект сразу после того, как получил Ваши исходники (у меня даже нога INT висин на том же пине меги, использовал ее вместо чтения регистра EPKTCNT) - проблема не исчезла.


Код менял уже не раз, ENC пробовал тоже разные.

это то понятно, у меня UDP реализован и работает на ура.
но необходимо получать данные именно по TCP/IP

вот и не получается пока, знаний мало.

может сперва на запрос от компа сразу ответить, потом подготовить данные, и дальше или их переслать, или передать со вторым запросом. или все делается проще. пока у меня затык в этом.

Понимая, что проблема остается только в аппаратной части и проверив плату еще раз (уже шестой раз), все же нашел достаточно серьезный косяк в плате (который увидел только через линзу) - не_контакт конденсатора (18pF) на одном из пинов кварца ENC Поставил плату на проверку, о результатах позже отпишусь.

даже если это решит вашу проблему,советую еще раз внимательно пересмотреть и ваш софт:никакие закидоны мака не должны
подвешивать хост-контроллер.

Девайс все же повис Софт использую tuxgraphics.org. Проблем с ним вроде ни у кого не было.

Ресет Меги возобновляет работу ENC.

А ничего, что я пин CS ENC приделал к пину другого порта Меги (т.е. не на тот порт, где SPI)? А то может быть я не знаю каких-то особенностей работы SPI?

WHALE, вопрос к Вам: в Вашем коде SPI инициализируется как Fosc/2, т.е., если я правильно понимаю, частота SPI = 4 MHz (т.к. кварц у Вас 8 MHz) ? Не получается ли у меня какой-нибудь разгон SPI, т.к. у меня Fosc/2 при кварце 16 MHz будет = 8 MHz (хотя, насколько мне помнится, в даташите на ENC как раз и рекомендуется клок SPI от 8 MHz при работе Меги от внешнего кварца)?

нет,это нормально.вы лучше посмотрите осцилографом, что происходит с мегой, когда она зависает.Что на ноге входа прерывания от
ENC, CS ENC и на ногах интефейса SPI?
З.Ы. Я так и не понял,вы работаете по поллингу MAC-а?Софт tuxgraphics вроде-же работает без прерываний..

Осциллографа у меня нет
Пробовал как с прерыванием, так и по поллингу.

Убрал инициализацию стека (т.е. стек отключил), поставил мигание светодиодом при приеме пакетов. Девайс работает гораздо дольше, зависа пока не было.

Нет, сразу после того как написал - завис

Плата у меня получилась какая-та аномальная
Вчера обнаружил, что диод на входе садит напряжение (т.е. скачет в пределах 4.3-4.5 В), думал, что от этого тактирование Меги может быть не стабильным на 16MHz. Сегодня после того, как убрал диод, на Мегу стало уходить 5.1 В (с импульсного БП (компьютерного)). После этого пакеты вообще перестали приниматься (точнее, в течение пары секунд сразу после включения принимаются, затем прием пакетов глохнет), иногда пропадал линк, другой светодиод ENC (который светится при приеме пакетов) моргал вообще как-то странно. Теперь я вообще в тупике. Напряжения во всех точках стали в пределах допустимого (судя по даташитам), а проблем стало еще больше.
У меня от этого девайса уже крыша скоро съедет