Не соглашусь, хотя, может чего и не понял. По Натшелу и у Агурова четко сказано, что в первом SETUP пакете bmRequestType равен четко 0x80 (запрос дескриптора устройства). В этот момент хост USB ещё не знает, что присоединили (HID или MassStorage какой), но очень хочет узнать . И поэтому в первом SETUP-запросе нулевой байт ( bmRequestType) всегда стандартен и равен 0x80. (0x81 0x60...) судя по Натшеллу - это запрос дескриптора интерфейса, но.. он приходит вторым. А вот третий (0x82 0x06 .. бла-бла-бла) - уже запрос на дескриптор конечных точек. С последним не знаю. Надо перечитать.
Все испробовал. Понятия не имею почему второй запрос не идет. Как только регистры и адреса уже не вертел, но в приемник залетает только дескриптор устройства.
Спойлер
Код:
void USB_LP_CAN_RX0_IRQHandler(void) {
if (USB->ISTR & USB_ISTR_CTR) { while ((USB->ISTR & USB_ISTR_CTR) != 0) {
if ((USB->EP0R & USB_EP_CTR_RX) != 0) { USB->EP0R &= ~USB_EP_CTR_RX;
switch (*(__IO uint32_t*)(0x40006101)) { case 0x6:
} if ((USB->EP0R & USB_EP_CTR_TX) != 0) { USB->EP0R |= USB_EP_RX_VALID; } i = 0; }
if (USB->ISTR & USB_ISTR_RESET) { USB->ISTR = 0; USB->CNTR |= USB_CNTR_CTRM | USB_CNTR_RESETM | USB_CNTR_ESOFM | USB_CNTR_SOFM; USB->BTABLE = BTableOffset; // таблица начинается с 0x0000
*(__IO uint32_t*)(0x40006000) = (uint16_t) 0x40; // начальный адрес USB_ADDR0_TX (такой адрес позволяет в дальнейшем добавить все 8 возможных контрольных точек, каждая имеет размер 1 байт) *(__IO uint32_t*)(0x40006004) = (uint16_t) 0x40; // размер исходящих данных - 32 байта USB_COUNT0TX *(__IO uint32_t*)(0x40006008) = (uint16_t) 0x80; // начальный адрес USB_ADDR0_RX *(__IO uint32_t*)(0x4000600C) = (uint16_t) 0x8400; // 32 байта входящих данных USB_ USB_COUNT0RX_BL_SIZE
USB->EP0R |= USB_EP_CONTROL; // режим - CONTROL
USB->EP0R |= USB_EP_TX_NAK; // Готовы к передаче, но данных для передачи нет USB->EP0R |= USB_EP_RX_VALID; // К приему готов test1 = *(__IO uint32_t*)(0x40006100);
USB->DADDR |= USB_DADDR_EF;
}
}
Вот дескриптор, который я отправляю (брал в интернете, проверял его, но вреде все нормально):
Спойлер
Код:
const uint8_t Virtual_Com_Port_DeviceDescriptor[] = { 0x12, // размер данного дескриптора 0x01, // тип данного дескриптора - device descriptor 0x00, 0x02, // 2 байта - версия usb 2.0 0x02, // класс устройства cdc 0x00, // подкласс 0x00, // протокол 0x40, // USB_MAX_PACKET0, // max размер пакета для нулевой конечной точки 0x83, 0x04, // 2 байта - VID 0x40, 0x57,// 2 байта - PID 0x00, 0x02,// 2 байта - версия (ревизия) устройства 0x01, // индекс строки с названием производителя 0x02, // индекс строки с названием устройства 0x03, // индекс строки с серийным номером устройства 0x01 // количество поддерживаемых конфигураций };
Подскажите пожалуйста, что делать. Я уже перепробовал все, что в голову пришло....
isx. Я тоже столкнулся с такой проблемой. Хотя пока нет, но скоро, думаю. Пока вожусь с туглами. Может, слишком много передаете? Остальные данные содержаться могут в других дескрипторах (дескрипторы интерфейса и контрольных точек). Но на эти дескрипторы идут уже другие запросы (прочтите мои посты, я чуть выше писал). Могу предположить, что где-то всетки ошибка в каком-то байте. И при запросе передаете не то, что предполагает увидеть хост. Хост вас "не понимать". Главный вопрос!! - Команда SET_ADRESS после отправки дескриптора от хоста идет? Если да, тогда дело не в дескрипторе. При кривом дескрипторе хост адрес вам не назначит.
Скрин ниже. Но это для HID (внимательнее. Это для HID в режиме PnP). В PnP Там вообще 8 байтовая структура. Это из Агурова (2006г издание. стр 70)
И опять по поводу приема первого SETUP. Хост мне постоянно присылает вот это:
Код:
0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00
Всё как и у Radist_M..) И теперь вопрос по поводу дальнейшего. После принятия SETUPа, как я понял из прочтенного STAT_TX выставляется в NACK??!! Т.е. сейчас мне нужно запихнуть в передающий буфер данные дескриптора и поставить STAT_TX в VALID?? Что делать со STAT_RX. Запрещать его на время передачи дескриптора, или оставить навсегда VALID?
После 21 должно время появится, так как я буду на работе
Что у Вас за работа такая, на которой есть время сидеть на форумах?
Z_h_e писал(а):
Проверьте флаг успешной отправки, которого я думаю нет
Его и нет - прерывание по CTR не возникает. Только вот не ясно почему... Последнее, что удается отследить в отладке - это как USB_EP_TX становится в VALID, а потом в 0. При этом флаг ошибки тоже не срабатывает (тоже включал прерывание по ERR для диагностики). Буду ждать следующей недели, а пока попробую еще куда-нибудь ковырнуть .
По поводу отправки нарыл ещё инфу интересную. Чтобы было понятнее, перевел: "Значения дескриптора, сохраненные в многократных байтах, должны придерживаться “прямого порядка байтов” , где наименьшее значение занимает старший байт (сохранен сначала). Например, значение 300 или 0x012C в idVendor или других многобайтовых переменных дескриптора, должно передаваться хабу как 0x2C01."
Может в этом проблема? Я правильно понял, что 2-х байтные константы надо "переворачивать".?? Хрень какая-то... Ведь их можно ещё на этапе написания дескриптора повернуть как надо, чтобы не усложнять функцию обработчика.
Ну допустим, отправляю я хосту дескриптор. Не судите строго. Даешь быдлокод )))) Просто, дешево и сердито.) Спойлер
Что должен сказать на это хост, при условии того, что он этот дескриптор "понял" ?? SET_ADRESS или что-то ещё? И ещё? Как перевести тугл из NACK в Valid? Не получается и всё тут.
И опять по поводу приема первого SETUP. Хост мне постоянно присылает вот это:
Код:
0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00
Всё как и у Radist_M..) И теперь вопрос по поводу дальнейшего. После принятия SETUPа, как я понял из прочтенного STAT_TX выставляется в NACK??!! Т.е. сейчас мне нужно запихнуть в передающий буфер данные дескриптора и поставить STAT_TX в VALID?? Что делать со STAT_RX. Запрещать его на время передачи дескриптора, или оставить навсегда VALID?
Сразу скажу, что работаю по прерываниям. Как только будет принят SETUP пакет: железо USB выставляет и STAT_TX и STAT_RX, в NAK для того чтобы прошивка затем решила что ей делать - принимать или передавать. А пока прошивка думает - хост будет получать на запросы RX/TX - NAK. NAK это 10, VALID - 11. Т.е. нужно выставить нулевой бит. Что происходит у меня: 1. После того как хост определит устройство он посылает RESET. 1.1 В обработчике прерывания смотрю регистр ISTR, проверю не резет ли это и если да, то делаю вот что: (примечание - по сигналу резет регистры USB сбрасываются в исходное состояние) USB->ISTR = 0;//очищаем сбытие резет //регистр нулевой КТ девственно чист - заполняем его. USB->EP0R = USB_EP0R_EP_TYPE_0|USB_EP0R_STAT_RX|USB_EP0R_STAT_TX_1;// тип control, STAT_RX в VALID и STAT_TX в NAK. 2. Затем хост присылает SETUP пакет:
Код:
0x80 0x06 - запрос дескриптора какого-то 0x00 0x01 - а точнее дескриптор устройства 0x00 0x00 0x40 - хост просит 64 байта 0x00
смотрю первый принятый байт 0x06, ага - запрос дескриптора. Остальные байты не смотрю и так знаю что это запрос дескриптора устройства
1. Загружаю в пакетную память дескриптор устройства, который представлен ниже (хотя это можно сделать заранее)
Т.е . в регистр нулевой конечной точки пишу как бы два значения - USB_EP0R_EP_TYPE_0 - этим я оставляю без изменений тип конечной точки Control USB_EP0R_STAT_TX_0 - ну и выставляю 0-й бит STAT_TX, т.е. перевожу из NAK в VALID. STAT_RX так и останется в NAK - это нисколько не мешает жить.
дальше происходит событие CORRECT TRANSFER
далее RESET
далее приходит опять SETUP пакет - смотри
Код:
0x00 0x05 - SET ADDRES 0x05 - это собсно адрес, который нам присвоил хост 0x00 0x00 0x00 0x00 0x00
Это запрос SET ADDRESS, тогда делаю вот что: 1. помещаю во временную переменную со спецификатором static полученный адрес (2-й принятый байт) +USB_DADDR_EF(это из заголовочного файла на МК, означает ENABLE FUNCTION) . Теперь это значение будет храниться между вызовами прерывания. 2. в регистр COUNT0TX пишу 0x00 - тем самым, сообщая что будем передавать 0 байт - этот тот самый ZLP (zero length packet). Так хост поймет, что мы приняли адрес 3. и последнее USB->EP0R = USB_EP0R_EP_TYPE_0|USB_EP0R_STAT_TX_0;//STAT_TX - valid передаем, короче
далее происходит событие CORRECT TRANSFER и вот тут я беру значение из временой перемнной и пишу в регистр USB->DADDR.
Код:
if (temp!=0) { USB->DADDR = temp; temp=0; }
Только с этого момнта контроллер будет откликаться на присоенный адрес хостом.
далее получаю опять SETUP пакет
Код:
80 06 00 01 00 00 12 00
Видали? то же самое, только теперь хост просит не 0x40 а 0x12 байт дескриптора
Повторяю процедуру отправки, получаю событие CORRECT TRANSFER и далее получаю 3 резета от хоста. Печаль. Дальше пока не продвинулся((.
И еще вопрос. Как вы определяете момент прихода SETUP пакета (какие флаги об этом сообщают)?
дык в регистрах конечных точек есть соответствующий флаг. Загляните в даашит на страницу описания регистров конечных точек. 11 бит регистра USB_EPnR сигнализирует о том что была завершена sutep транзакция.
Видали? то же самое, только теперь хост просит не 0x40 а 0x12 байт дескриптора
Повторяю процедуру отправки, получаю событие CORRECT TRANSFER и далее получаю 3 резета от хоста. Печаль. Дальше пока не продвинулся((.
А после получения инструкции SET_ADRESS биты в USB_DADDR_ADD точно устанавливаются?
Стоп. Надо разобраться. 1. Сразу после SET_ADRESS биты в USB_DADDR_ADD не должны устанавливаться. Точнее должны но не сразу. Если это сделать сразу, то хост будет обращаться к устройству с адресом 0 для получения статус пакета (ZLP), а наш адрес уже изменится. Посему хост ответа не получит.
2. Если бы было что-то не то с адресом устройства, то я не получил бы 2-го запроса с измененным количеством запрашиваемых байт.
P.S. Специально закомментил
Код:
if (temp!=0) { //USB->DADDR = temp; temp=0; }
и все сломалось.
В моем случае: 1. Первый Reset 2. Запрос дескриптора устройства 3. Второй Reset 4. Set address 5. Второй запрос дескриптора 6. Reset - теперь запросы не проходят и я получаю reset за reset-ом 7. Reset
Уф. Совсем замучался. По ходу разбирательств с USB перешел на Keil. Несмотря на некоторую сложность в настройке. До этого мучался в Coocox. Там столько глюков в отладке всплыло, что.. Переменные не показывает, память просишь показать - одни нули.. Зато в Кейле всё норм, удалось отследить все ресеты и запросы. Кокос с сегодняшнего вечера для меня - говно! Халява не может быть качественной. Не пользуйтесь этим бесплатным дерьмом (на то оно и бесплатное), если конечно, ваша цель - не просто поморгать диодами. А так.. Ой, че-то я отвлекся от темы..
Radist_M писал(а):
и все сломалось.
В моем случае: 1. Первый Reset 2. Запрос дескриптора устройства 3. Второй Reset 4. Set address 5. Второй запрос дескриптора 6. Reset - теперь запросы не проходят и я получаю reset за reset-ом 7. Reset
Таже ерунда. Отправляет второй ресет и SET_ADRESS. Хотя.. вроде как второго ресета быть не должно. Вообще дескриптор устройства один раз требуется, насколько я понял из сегодня прочтенного.
Таже ерунда. Отправляет второй ресет и SET_ADRESS. Хотя.. вроде как второго ресета быть не должно. Вообще дескриптор устройства один раз требуется, насколько я понял из сегодня прочтенного.
Вроде-бы описанная там последовательность верна. И после второго запроса дескриптора устройства должен прийти запрос дескриптора конфигурации. А тут резет. Наверное хосту что-то не нравится.
Вроде-бы описанная там последовательность верна. И после второго запроса дескриптора устройства должен прийти запрос дескриптора конфигурации. А тут резет. Наверное хосту что-то не нравится.
Да, верно. Посмотреть бы неплохо было на стороне хоста - как он распознает эти дескрипторы.?? Да вряд ли такие утилиты есть.
Есть программы, позволяющие взглянуть на пакеты между устройством и хостом. Но эти пакеты будут видны только после успешной энумерации. Поправьте, если ошибаюсь.
Есть программы, позволяющие взглянуть на пакеты между устройством и хостом. Но эти пакеты будут видны только после успешной энумерации. Поправьте, если ошибаюсь.
Пока времени нет, но надо посмотреть будет. да и вопрос. После того как мы отправляем дескриптор, STAT_TX у нас выставляется в NACK (RX после приема также в NACK, его мы не трогаем.), а по событию успешной передачи выставляется ещё и CTR_TX. После этого приходит второй RESET. Перед вторым RESETом обязательно выставлять RX в VALID?? Или можно всё в NACK оставить до Резета?
Есть программы, позволяющие взглянуть на пакеты между устройством и хостом. Но эти пакеты будут видны только после успешной энумерации. Поправьте, если ошибаюсь.
Пока времени нет, но надо посмотреть будет. да и вопрос. После того как мы отправляем дескриптор, STAT_TX у нас выставляется в NACK (RX после приема также в NACK, его мы не трогаем.), а по событию успешной передачи выставляется ещё и CTR_TX. После этого приходит второй RESET. Перед вторым RESETом обязательно выставлять RX в VALID?? Или можно всё в NACK оставить до Резета?
Второй резет сбросит регистры в исходное состояние, посему надо будет заново вставить STAT_TX в NAK, STAT_RX в VALID . Я так делаю при каждом резете. Т.е. после резета я готов к приему команд.
Карма: 29
Рейтинг сообщений: 651
Зарегистрирован: Сб май 14, 2011 21:16:04 Сообщений: 2708 Откуда: г. Чайковский
Рейтинг сообщения:1 Медали: 1
isx писал(а):
Это понятно, только вот после отработки установленного значения TX/RX они автоматически обнуляются.
Они не автоматически обнуляются, это Вы их обнуляеете. Еще раз поглядите упрощенный пример условного 4х битного регистра EP. По Вашей логике его конечное значение должно было быть 0b1111, но по факту 0b0011. А если Вам понятно почему 0011, то непонятно почему не понимаете почему у Вас вместо valid стоит disabled. Тут гляньте еще раз и тут. Такое впечатление, что Вы считаете будто бы у Вас перед каждым присваиванием регистру EPnR какого-то значения его начальное состояние всегда ноль, даже если Вы только что ему что-то присвоили или будто бы Вы пишите в него не слово целиком, а какие-то выборочные биты. Кстати, побитный доступ есть в STM, воспользуйтесь тогда им что ли. Я не знаю как еще Вам объяснить , может кто другой поможет.
Serg1987 писал(а):
Не соглашусь, хотя, может чего и не понял. По Натшелу и у Агурова четко сказано, что в первом SETUP пакете bmRequestType равен четко 0x80 (запрос дескриптора устройства). В этот момент хост USB ещё не знает, что присоединили (HID или MassStorage какой), но очень хочет узнать . И поэтому в первом SETUP-запросе нулевой байт ( bmRequestType) всегда стандартен и равен 0x80. (0x81 0x60...) судя по...
А я разве где то писал, что запрос дескриптора репорта HID будет первым? И вообще, какая разница в каком порядке идут запросы, функция USB должна ответить на запрос хоста правильными данными.
Radist_M писал(а):
... ...
У меня похожий алгорим, судя по Вашему описанию. Обязательно проверяйте неизвестный запрос, там можно установить точку останова. При запросе дескриптора 8006, проверяйте поле wValue.
Serg1987 писал(а):
Уф. Совсем замучался. По ходу разбирательств с USB перешел на Keil. Несмотря на некоторую сложность в настройке. До этого мучался в Coocox. Там столько глюков в отладке всплыло, что..
Согласен, глюков много, хотя часть глюков у меня как обычно оказались кривыми ручками. Но я пока в кокосе: "мыши плакали и кололись, но все равно продолжали жрать кактус".
isx писал(а):
Скиньте пожалуйста обработчик CTR.
Данный код все время менялся, комментарии могут несколько не соответствовать (перетаскивались при копипасте из другого места кода и не всегда исправлял, а зря), возможно иногда ругательные (когда особенно все "получалось"), часть кода заремарчено, т.к. были для теста или ошибочны или еще почему-то. А так, это кусок кода, проекта выкладывать который я не собираюсь, так что возможно там есть что-то от него, просто не обращайте внимание. Мне кажется что у меня не плохо получилось, хотя возможно и далеко не лучшим способом (не без быдлокодства), к сожалению табуляции несколько в форуме искаженыСпойлер
Код:
case 0:{ //прерывание от нулевой конечной точки
//что то успешно отправили //CopyMemUsb(); if ((USB_REGISTR->EP0R&bit7)){
Clear_Flag_EPR(0,TX);
if (FlagAddress){USB_REGISTR->DADDR+=ConfigPacket.wValue;FlagAddress=0;} //назначаем полученный адрес
Set_Status_EPR(0,Valid,RX); // будем что нибудь принимать
}
//Успешно приняли данные
if ((USB_REGISTR->EP0R&bit15)) { //если пришел пакет Сетуп и приняты данные для нулевой точки
Clear_Flag_EPR(0,RX); //сброс флага об успешном приеме
//---------- //если мы ждали данные, то обрабатываем их и не проверяем на запросы if (FlagEventUSB==NadoPrinyatDannie) { //заполняем массив и опять готовы принять данные //uint8_t *pRXBuf,*pTarget; //pTarget=&Data_USB_Out; //указатель куда бум ложить данные //pRXBuf=(*((uint32_t*) 0x40006008))*2+0x40006000;//указатель откуда бум брать данные //pRXBuf++; //т.к. в первом байте буфера будет 0, типа номер репорта толи для 0 точки
case 0x8006:{//ЗАПРОС ДЕСКРИПТОРА //выбор типа дискриптора switch(ConfigPacket.wValue) { case 0x0100:{ //Запрос дескриптора устройства Buffer_Fill_Tx (0,Device_Descriptor,18); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор устройста, break;}
case 0x0200://Запрос конфигурации и сразу интерфейса и сразу точеГ lenn=41; if (ConfigPacket.wLength<41) lenn=ConfigPacket.wLength; Buffer_Fill_Tx (0,Config_Descriptor,lenn); //заполнение буфера отправки дескриптором устройства //CopyMemUsb();
case 0x0300: //Запрос строкового дескриптора 0 Buffer_Fill_Tx (0,Stroka0,Stroka0[0]); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор break;
case 0x0301: //Запрос строкового дескриптора 1 Buffer_Fill_Tx (0,Stroka1,Stroka1[0]); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор break;
case 0x0302: //Запрос строкового дескриптора 2 Buffer_Fill_Tx (0,Stroka2,Stroka2[0]); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор break; case 0x0303://Запрос строкового дескриптора 3 Buffer_Fill_Tx (0,Stroka3,Stroka3[0]); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор break; case 0x0304://Запрос строкового дескриптора 4 Buffer_Fill_Tx (0,Stroka4,Stroka4[0]); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор break; case 0x03EE://Запрос строкового дескриптора EE //Buffer_Fill_Tx (0,StrokaEE,StrokaEE[0]); //заполнение буфера отправки дескриптором устройства //Set_Status_EPR(0,Valid,TX); // отправим Set_Status_EPR(0,Stall,TX); break;
default: //Неизвестный тип дескриптора //USB_CfgSendStall(); //CopyMemUsb(); Set_Status_EPR(0,Stall,TX); break;
} //конец switch(ConfigPacket.wValue)
break;}//конец case 0x0680: //_____ case 0x8106:{//ЗАПРОС ДЕСКРИПТОРА интерфейса switch(ConfigPacket.wValue) { case 0x2200://запрос РЕПОРТА //Set_Status_EPR(0,Stall,TX); //Ostatok=84-0x40; //pAddressData=&HID_ReportDesc[84-0x40-1]; Buffer_Fill_Tx (0,HID_ReportDesc,23); //заполнение буфера отправки дескриптором устройства Set_Status_EPR(0,Valid,TX); // отправим дескриптор
break;
default://Неизвестный тип интерфейса Set_Status_EPR(0,Stall,TX); break;
}//switch(ConfigPacket.wValue) break; }// case 0x8106:{//ЗАПРОС ДЕСКРИПТОРА интерфейса //_____ //_____ //---------- case 0x0005://УСТАНОВКА АДРЕСА SET_ADDRESS { Buffer_Fill_Tx(0,0,0); //заполним буфер отправки пустотой //Set_DTOG(0,TX); //установить дтог ТХ . Т.е. отправка пустой ДАТА1 Set_Status_EPR(0,Valid,TX); // отправим в ответ ZLP еще как от безадресного устройства //CopyMemUsb(); FlagAddress=1; //Флаг о том что пришла команда установки адреса
break; } //---------- case 0x0009://УСТАНОВКА конфигурации { Buffer_Fill_Tx(0,0,0); //заполним буфер отправки пустотой Set_Status_EPR(0,Valid,TX); // отправим залупу в ответ ZLP break; } //---------- case 0x210A://Спец запрос ХИД. Set Idle { Buffer_Fill_Tx(0,0,0); //заполним буфер отправки пустотой Set_Status_EPR(0,Valid,TX); // отправим залупу в ответ ZLP //Set_Status_EPR(0,Stall,TX); break; } case 0xA101: {//Запрос ФЬЮЧА (HidD_GetFeature от компа) Т.е надо отправить на комп Фуча
__disable_irq (); //запр. прерывания SysTick->CTRL&=~SysTick_CTRL_TICKINT; Buffer_Fill_Tx (0,&Data_USB_In,41); //заполнение буфера отправки для точки 0 __enable_irq (); //разр. прерывания SysTick->CTRL|=SysTick_CTRL_TICKINT;
default:/*неизвестный запрос для нулевой точки*/ //CopyMemUsb(); Set_Status_EPR(0,Stall,TX); // отправим сталл break; } } //скобка Ифа о том что именно чтото пришло а не ушло break;}// CASE 0 конец кейса запрос от нулевой конечной точки
_________________ Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Согласен, глюков много, хотя часть глюков у меня как обычно оказались кривыми ручками. Но я пока в кокосе: "мыши плакали и кололись, но все равно продолжали жрать кактус".
Ну тогда может вы объясните, может знаете, почему Кокос при отладке не показывает значения записываемых регистров?? В Кейле с ними проблем нет. Ладно, шут с регистрами. Думал по другому сделать.. Создал переменную, чтобы посмотреть, чего у меня там пишется.. И опять В режиме отладки Кокос эту переменную добавлять ("Add global variable" или как-то так) отказывается , с чем в Кейле проблем не было. Скрин во вложении. Где значения?? Итого, я не могу посмотреть, что у меня записалось. А оно записывается. В Кейле всё прекрасно.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
. И поэтому в первом SETUP-запросе нулевой байт ( bmRequestType) всегда стандартен и равен 0x80.
.
Халява не может быть качественной. Не пользуйтесь этим бесплатным дерьмом (на то оно и бесплатное), если конечно, ваша цель - не просто поморгать диодами. А так.. Ой, че-то я отвлекся от темы..
(когда особенно все "получалось"), часть кода заремарчено, т.к. были для теста или ошибочны или еще почему-то. А так, это кусок кода, проекта выкладывать который я не собираюсь, так что возможно там есть что-то от него, просто не обращайте внимание. Мне кажется что у меня не плохо получилось, хотя возможно и далеко не лучшим способом (не без быдлокодства), к сожалению табуляции несколько в форуме искажены
