Перейти к содержанию
Поиск
    

USB своими руками для sam7x256

Ответить

e0000    0

e0000
Опубликовано · Жалоба

Доброе время суток, всезнающий All!

Возвращаюсь к теме, так как своих мозгов уже не хватает:

Устойство ожило и работает вполне коректно.

Появилась следующая необходимость: гонять пакеты размерностью больше чем размер конечной точки...

И тут затык.

Влетаем по прерыванию в обработку приема конечной точки, считываем от дуда данные в количестве RXBYTECNT...

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

Ладно - делаем буферезацию и ждем следующего куска и... следующего прерывания не происходит :(

Может кто сталкивался с подобной проблемой, может у кого-то есть опыД в подобных вещах...

 

В целом вопрос заключается в двух вопросах:

1. Как принять данные больше чем конечная точка?

2. Возникает ли рерывание, когда должен прилететь второй(третий, пятый) блок данных одного пакета данных?

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

kovigor    5

kovigor
Опубликовано (изменено) · Жалоба
В целом вопрос заключается в двух вопросах:

1. Как принять данные больше чем конечная точка?

2. Возникает ли рерывание, когда должен прилететь второй(третий, пятый) блок данных одного пакета данных?

Не помню, хоть расстреляйте. Делал весной. деталей не помню. Есть проект - отлаженный и рабочий, для AT91SAM9XE512 (mass-storage). Посмотрите, как там сделано. Дать ?

 

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

Изменено пользователем kovigor

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

e0000    0

e0000
Опубликовано · Жалоба

в том-то и дело, что прерывание не возникает :(

 

Но если не сложно, то пришлите - гляну, может я что-то не так делаю...

(мейл отправил в личку)

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

kovigor    5

kovigor
Опубликовано · Жалоба
Но если не сложно, то пришлите - гляну, может я что-то не так делаю...

(мейл отправил в личку)

 

Отправил. Очень прошу не распространять !

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

t25a3    0

t25a3
Опубликовано (изменено) · Жалоба

А у меня наоборот проблема с отправкой пакета размером больше конечной точки :rolleyes:.

А вот прием идет шустро) посылаю 1023 байта все за кадр приходят)

Не забывайте что хост когда отправляет пакеты чередует данные DATA0 и DATA1 это разные прерывания RX_DATA_BK1 и RX_DATA_BK0 от одного источника (и разные буферы).

мой кусок обработки прерывания:

//---Обработка прерываний от конечной точки-------------------------------------
void USB_EP_INT()
 {
 switch ((AT91C_BASE_UDP -> UDP_CSR[POINT]) & UDP_CSR_STATUS)
	  {
	  case AT91C_UDP_RXSETUP:
		   {
		   send_byte(0xF1);//для отладки по RS-232
		   USB_READ_FIFO_EP((unsigned char *) pSetup_Packet, POINT);//переход на функцию сохранения байтов в память
		   RXSETUP_CLEAR(POINT);//Сброс бита RXSetup (данные из буфера прочитал)
		   switch ((pSetup_Packet -> bmRequestType) & USB_TYPE_REQUEST)
				{
				case USB_TYPE_STANDARD:
					 {
					 switch (pSetup_Packet -> bRequest) //че комп от меня хочет?
						  {
						  case GET_DESCRIPTOR:
							{USB_GET_DESCRIPTOR(); break;}//запрос дескриптора
						  case SET_ADRESS:
							{USB_SET_ADRESS(); break;}//установка адреса
						  case SET_CONFIGURATION:
							{USB_SET_CONFIGURATION(); break;}
						  case CLEAR_FEATURE:
							{USB_CLEAR_FEATURE(); break;}
						  default:
							{USB_STALL(); break;}
							//если запрос не известен то выход из оператора switch
						  }
					 break;
					 }
				case USB_TYPE_CLASS:
					 {
					 switch (pSetup_Packet -> bRequest)//че комп от меня хочет?
						  {
						  case SET_LINE_CODING:
							{k = 1; break;}
						  case GET_LINE_CODING:
							{pData[POINT] = (unsigned char *) pLine_Control;
							 dLenght[POINT] = 7;
							 USB_WRITE_FIFO_EP(POINT); break;}
						  case SET_CONTROL_LINE_STATE:
							{ZERO_PACKET(); break;}
						  default:
							{USB_STALL();
							 break;}
							//если запрос не известен то выход из оператора switch
						  }
					 break;
					 }
				default: {USB_STALL(); break;}
				}
		   break;
		   }
//------------------------------------------------------------------------------
	  case AT91C_UDP_TXCOMP:
		   {
		   send_byte(0xF2);
		   TXCOMP_CLEAR(POINT);//сбрасываем бит TXCOMP
		   if (pStatus[POINT])
				{
				USB_WRITE_FIFO_EP(POINT);
				}
		   break;
		   }
//------------------------------------------------------------------------------
	  case AT91C_UDP_ISOERROR:
		   {
		   send_byte(0xF3);
		   STALL_CLEAR(POINT);
		   FORCESTALL_CLEAR(POINT);
		   break;
		   }
//------------------------------------------------------------------------------
	  case AT91C_UDP_RX_DATA_BK0:
	  case AT91C_UDP_RX_DATA_BK1:
		   {
		   send_byte(0xF4);
		   if (k) {k = 0; USB_READ_FIFO_EP((unsigned char *) pLine_Control, POINT); RX_DATA_BK_CLEAR(POINT); ZERO_PACKET();}
		   else   {USB_READ_FIFO_EP(DATA, POINT); RX_DATA_BK_CLEAR(POINT);}
		   break;
		   }
	  default: break;
	  }
 }
//==============================================================================

Этот обработчик написан для CDC конфигурации USB устройства (находится в стадии оптимизации).

Проблемы с приемом не возникали, но... Возникали проблемы с открытием порта. Открывался некорректно! Подвисал програмки для работы с COM портом. Потом разобрался сейчас не вспомню в чем проблема была.

 

Вспомнил в чем проблема. Проблема в корректной обработки запроса SET_LINE_CODING. Я с начала отправлял пустой пакет подтверждения после приема запроса, но потом оказалось пустой пакет надо отправлять после приема данных по запросу SET_LINE_CODING 

 if (k) {k = 0; USB_READ_FIFO_EP((unsigned char *) pLine_Control, POINT); RX_DATA_BK_CLEAR(POINT); ZERO_PACKET();}

При этом бит DIR контрольной точки менять не нужно...

Изменено пользователем IgorKossak
[codebox]

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

e0000    0

e0000
Опубликовано (изменено) · Жалоба

Хм....

если у нас прилетает пакет равный размеру конечной точки, прилетит ли после этого нулевой пакет?

Изменено пользователем e0000

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

t25a3    0

t25a3
Опубликовано · Жалоба

нулевой по идее прилетит последним в кадре если размер пакета кратен конечной точке. Так жеж и с отправкой. Если отправляешь пакет кратный размеру конечной точки то последним надо отправлять пустой байт. Вот в принципе поэтому 1023 байта можно отправить через bulk точку, чтобы не отправлять нулевой байт (видать не хватает времени устройству чтобы отправить все за кадр).

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

e0000    0

e0000
Опубликовано (изменено) · Жалоба

но у меня не прилетает "нулевой пакет" если я принимаю 64 байта :(

(размер конечной точки 64 байта)

Изменено пользователем e0000

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

t25a3    0

t25a3
Опубликовано (изменено) · Жалоба

хотя в принципе в моем обработчике прерываний как то все равно придет или не придет нулевой байт) :rolleyes:

Вам этот нулевой байт сильно нужен?)

Нулевой байт по идее в конце кадра должен приходить. Кадр 1 мс. В течении 1 мс можно принять 1023 байта для FS устройств. Вот нулевой байт по идее должен прийти если число байт в кадре кратно размеру конечной точки. Вот 1023 байта пакет. Нулевой не прилетит. А вот 960 байт по идее должен.

Изменено пользователем shrek

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

e0000    0

e0000
Опубликовано · Жалоба

Ситуация какова...

Я не знаю сколько мне прилетит данных и вычисляю их по ходу в первом пакете

Но если ко мне летит

 

 

Обработчик следующий:

void BulkOut (void) {
U32 i;
U8 temp;

  BulkLen = USB_ReadEP(EP_OUT_L, &BulkBuf[0]); //смотрим длинну пакета

  switch (BulkStage_OUT){  //проверяем на каком мы свете
    case BS_CBW: {Get_CMD(); break;} 
    case BS_DATA_OUT: {GoonGet_CMD(); break;}  
            }
}

 

так вот в состояние BS_DATA_OUT он не попадает, хотя длины пакетов вычисляются правильно - проверил дебагером

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

t25a3    0

t25a3
Опубликовано · Жалоба

Вообще для того чтобы узнать сколько байт прилетело к какой-то конечной точке достаточно прочитать поле RXBYTECNT регистра UDP_CSRx. Я обычно это поле читаю перед тем как прочитать данные из буфера. А перед этим смотрятся флаги которые вызвали прерывание.

За что отвечает BulkStage_OUT?

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

e0000    0

e0000
Опубликовано · Жалоба

Обнаружил следующее:

1. Если пакет меньше 64 байта - все ок!

2. Если пакет кратен 64 байта - все ok!

3. Если пакет не кратен 64 байта и при этом больше чем 64 (например 255 байт) то первые 3 по 64 прилетают и я их вижу, а последние 63 не прилетают..

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

t25a3    0

t25a3
Опубликовано · Жалоба

а если 65 байт?)

у некоторых программ для работы с com портом (тест типа netweak) могут быть ограничения в размере буфера...

 

Если 65 байт или например 129 принимает то в принципе то ваше устройство работоспособно)))

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
×
  • Создать...