Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: CP2200: конфликт RXAUTORD и RAMRXDATA
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
Konstantin Ilichev
Добрый день,

Сделал устройство на AVR+CP2200. Даташит Rev.1.0.
У меня проблемка. Хочу в прерывании по приему пакета сразу на лету посмотреть, что за пакет (ARP, UDP, порт назначения итп). И если пакет мне не нужен, то сразу тут же его и откидывать. А если нужен, то выставляю флаг и позже в основном цикле пакет считаю и буду разбирать.

Ну вот, при прерывании лезу я через прямой доступ RAMRXDATA в буфер и смотрю что нужно. А потом когда доходит дело до RXAUTORD, оказывается, что указатель авточтения инкрементировался ровно столько раз, сколько я читал из RAMRXDATA. Естественно это очень мешает, т.к. не позволяет потом читать буфер.

В даташите написано, что механизмы RXAUTORD и RAMRXDATA разделены и не влияют друг на друга.

Подскажите, в чем может быть дело?
Делает ли кто-нибудь такой смешанный доступ к буферу CP2200?


Пока решил проблему так.
В прерывании перед доступом к принятому пакету сохраняю во временной переменной RXFIFOHEAD, а по завершении записываю его значение обратно.
РАБОТАЕТ!!!
Konstantin Ilichev
Прошу помощи с CP2200!!!

При входе в прерывание по приему пакета проверяю RXVALID и RXOK и если они оба =1, то в целях отладки просто отбрасываю пакет RXCN=(1<<RXSKIP). Всё это работает очень быстро (1-2 мкс) и значительно меньше времени 51,2 мкс, указанного в даташите (время минимального пакета из 64 байт). В общем-то, я ожидаю, что никаких пакетов в FIFO накапливаться не должно, т.к. я успеваю их обработать. Однако, чтение TLBVALID перед выходом из прерывания иногда (раз в 10-20 секунд) показывает, что в буфере лежат ещё пакеты, и порой даже целых 7 штук.

Кабель подключен к роутеру, он раз в 10-20 секунд посылает какую-то кучку пакетов, я ещё полностью не разобрался что именно там за пакеты, отловить их в этом кабеле с компа не предствляется возможным.

Вопрос: могут ли действительно так быстро влететь в буфер какие-то новые пакеты и оказаться выставленными флаги в TLBVALID ? Или я всё же должен успевать обрабатывать ВСЕ пакеты в такой ситуации, т.е. чтобы FIFO не наполнялся?

Посоветуйте, пожалуйста, как правильно обрабатывать прием пакета и работать с FIFO.

P.S. Я планировал делать быстрый анализ пакета "на лету" прямо в прерывании по приему - чтобы отсеять пакеты с чужим 6-ым октетом MAC, чужим портом UDP и тп.
KRS
Цитата(Konstantin Ilichev @ Sep 22 2009, 21:57) *
При входе в прерывание по приему пакета проверяю RXVALID и RXOK и если они оба =1...

У вас не все TLB очищаются именно с этими битами и была проблема, в старом даташите вообще эти биты по другому описывались и у меня глюки тоже были. Потом вышел новый даташит и я все поборол. Но это уже было давно может сейчас даташит еще свежей. Сейчас под рукой нет исходников...
Но, на память надо делать RXSKIP не только когда оба бита установлены! (А вроде когда хотя бы один).
Konstantin Ilichev
Цитата(KRS @ Sep 23 2009, 00:21) *
Но, на память надо делать RXSKIP не только когда оба бита установлены! (А вроде когда хотя бы один).


Именно так и делаю. Если хотя бы один бит =0, то делаю RXSKIP.
А дальше, если оба бита =1, тоже делаю RXSKIP - в целях отладки. То есть в итоге откидываю ВСЕ пакеты.

И вот тут хочу понять, почему после обработки последнего прерывания (быстро, 2 мкс) вхожу в новое прерывание по приему пакета и обнаруживаю TLBVALID = 0x71, например. Откуда так быстро там появилось сразу 4 пакета???
KRS
у меня такая функция проверки есть ли пакет
Код
  if (!cpReadByte(TLBVALID)) {
    cpReadByte(INT0);
    return false;
  }
  cpReadByte(CPINFOH);
  cpReadByte(CPINFOL);
  return true;


а у даление пакета

Код
  cpWriteByte(RXCN,2)


можно для отладки проверить удалился ли пакет, считать TLBVALID или там еще есть регистр указывающий на активный TLB
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.