CP2200: конфликт RXAUTORD и RAMRXDATA, прошу помощи Опции

[Konstantin Ilich...]

Добрый день,

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

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

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

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


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

[Konstantin Ilich...]

Прошу помощи с 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]

При входе в прерывание по приему пакета проверяю RXVALID и RXOK и если они оба =1...

У вас не все TLB очищаются именно с этими битами и была проблема, в старом даташите вообще эти биты по другому описывались и у меня глюки тоже были. Потом вышел новый даташит и я все поборол. Но это уже было давно может сейчас даташит еще свежей. Сейчас под рукой нет исходников...
Но, на память надо делать RXSKIP не только когда оба бита установлены! (А вроде когда хотя бы один).

[Konstantin Ilich...]

Но, на память надо делать 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