|
USB CDC (AT91SAM7S64) не работает |
|
|
|
Sep 19 2011, 19:03
|
Участник

Группа: Участник
Сообщений: 53
Регистрация: 26-07-11
Пользователь №: 66 426

|
Цитата(prottoss @ Sep 19 2011, 20:48)  ОК. Подождем, когда код заточится, но на AMD работать не будет  в моем случае я так понимаю нет никакого SAM-BA, я же прошиваю через IAR... aaarrrОгромное спасибо!!! Хотя всё опять же по моей вине не так как надо... реально там другой код ))) я опять таки взял не от той версии BasicUSB... я уже запутался в них... при том тот же файл cdc_enumerate.с в каждой новой версии такие радикальный изменения переживает... не сиделось им прям... фактически как обернуть я понял, могу применить и к этому... только в той версии что у меня сейчас - нет разбиения на эти inline... все процедуры уже такие массивные, вот пример одной из записей: Код static uint AT91F_UDP_Write(AT91PS_CDC pCdc, const char *pData, uint length) { AT91PS_UDP pUdp = pCdc->pUdp; uint cpt = 0;
// Send the first packet cpt = MIN(length, AT91C_EP_IN_SIZE); length -= cpt; while (cpt--) pUdp->UDP_FDR[AT91C_EP_IN] = *pData++; pUdp->UDP_CSR[AT91C_EP_IN] |= AT91C_UDP_TXPKTRDY;
while (length) { // Fill the second bank cpt = MIN(length, AT91C_EP_IN_SIZE); length -= cpt; while (cpt--) pUdp->UDP_FDR[AT91C_EP_IN] = *pData++; // Wait for the the first bank to be sent while ( !(pUdp->UDP_CSR[AT91C_EP_IN] & AT91C_UDP_TXCOMP) ) if ( !AT91F_UDP_IsConfigured(pCdc) ) return length; pUdp->UDP_CSR[AT91C_EP_IN] &= ~(AT91C_UDP_TXCOMP); while (pUdp->UDP_CSR[AT91C_EP_IN] & AT91C_UDP_TXCOMP); pUdp->UDP_CSR[AT91C_EP_IN] |= AT91C_UDP_TXPKTRDY; } // Wait for the end of transfer while ( !(pUdp->UDP_CSR[AT91C_EP_IN] & AT91C_UDP_TXCOMP) ) if ( !AT91F_UDP_IsConfigured(pCdc) ) return length; pUdp->UDP_CSR[AT91C_EP_IN] &= ~(AT91C_UDP_TXCOMP); while (pUdp->UDP_CSR[AT91C_EP_IN] & AT91C_UDP_TXCOMP);
return length; } возникает вопрос можно ли просто в тупую добавить store_int и disable_int в начале всей этой функции и set_interrupt_statу в конец, опоясов всю эту функцию, решив тем самым обе проблемы сразу? аналогично повесить на остальные функции - записи управляющей endpoint, конфигурирования.... или городить таки у каждого изменения CSR? извиняюсь заранее, потому что понимаю что вопрос глупый и даже подозреваю на него ответ и даже проверить просто... но... вот проверить мне тут неначем - результаты только завтра узнаем (
Сообщение отредактировал abit - Sep 19 2011, 19:10
|
|
|
|
|
Sep 19 2011, 20:37
|
Гуру
     
Группа: Свой
Сообщений: 10 713
Регистрация: 11-12-04
Пользователь №: 1 448

|
Цитата(abit @ Sep 19 2011, 23:03)  возникает вопрос можно ли просто в тупую добавить store_int и disable_int в начале всей этой функции и set_interrupt_statу в конец, опоясов всю эту функцию, решив тем самым обе проблемы сразу? Можно, если не смущает время запрещения прерываний. На самом деле, макрос или инлайн, выполненный со всеми возможными предосторожностями - это все-таки некоторый костыль. По-хорошему, нужно в каждом конкретном случае решать, запрещать ли прерывания, дожидаться ли установки/сброса битов в CRS (а это не всегда необходимо) и т.п. Хотя оверхед костыля в любом случае небольшой.
|
|
|
|
|
Sep 20 2011, 11:13
|
Участник

Группа: Участник
Сообщений: 53
Регистрация: 26-07-11
Пользователь №: 66 426

|
Цитата(aaarrr @ Sep 20 2011, 00:37)  Можно, если не смущает время запрещения прерываний.
На самом деле, макрос или инлайн, выполненный со всеми возможными предосторожностями - это все-таки некоторый костыль. По-хорошему, нужно в каждом конкретном случае решать, запрещать ли прерывания, дожидаться ли установки/сброса битов в CRS (а это не всегда необходимо) и т.п. Хотя оверхед костыля в любом случае небольшой. Все попытки провалились что внутри процедуры.... вплоть до такого: Код __disable_interrupt; while 1 do {CDC.Write(&pCDC,'1',1)} на наших компах вываливает в порт '11111.....' на этом - '1'... и тишина prottossесли дело в том, о чём Вы говорили... чем-то другим пользоваться вместо usbser.sys? и есть ли какие-то официальные признания этой ошибки? мне чтобы снять вину со своей программы... к тому же под удивление на Linux таки это заработало через CDC-ACM...
Сообщение отредактировал abit - Sep 20 2011, 11:22
|
|
|
|
|
Sep 20 2011, 12:02
|
Частый гость
 
Группа: Участник
Сообщений: 125
Регистрация: 1-12-08
Из: г. Орел
Пользователь №: 42 126

|
Посмотри по ссылке. http://electronix.ru/forum/index.php?showt...60&start=60Там есть проект "рабочий" под IAR 4.22 камень AT91SAM7A3. Данные только принимаются))) можешь попробовать дописать и отправление. Пробовал на разных компах работает. На линуксе не пробовал...
|
|
|
|
|
Sep 21 2011, 06:28
|
Частый гость
 
Группа: Участник
Сообщений: 125
Регистрация: 1-12-08
Из: г. Орел
Пользователь №: 42 126

|
Менял в своем проекте USB_CDC направление по BULK точкам и адреса точек все работало. idVendor: 0x03EB (Atmel Corporation) idProduct: 0x6124 bcdDevice: 0x0110 Из этих параметров менял только idProduct и в драйвере для девайса менял все равно все оставалось рабочим. Интервал опроса для третьей конечной точки ставил 10 мс. Дескриптор конфигурации CDC по "зеленому" варианту  Цитата Было такое, решилось. Посмотрите как в вашем проекте идет обращение к регистрам UDP->CSR и как рекомендует документация (там есть примеры макросов). В старых версиях Атмеловского фреймвока эти самые макросы не использовались, это и приводило к такому глюку. У меня был глюк с открытием порта. Не в том месте и не в то время работал с регистром UDP->CSR и не в том месте и не в то время отправлял нулевые данные (когда девайсу приходил запрос SET_LINE_CODING все глюки начинались). Когда приходил запрос SET_LINE_CODING я сразу отправлял нудевой пакет, а затем принимал данные. Из-за этого девайс при попытке открыть порт подвешивал прогу для работы с COM портом.
Сообщение отредактировал shrek - Sep 21 2011, 06:32
|
|
|
|
|
Sep 22 2011, 09:54
|
Участник

Группа: Участник
Сообщений: 53
Регистрация: 26-07-11
Пользователь №: 66 426

|
Всем спасибо) Проблема таки решена после недели мучений... Дескрипторы и прерывания не причем...
Не работало только на АМД-шках, если кто столкнется с этой проблемой, скрывать решение не буду )))
решается так: в файле cdc_enumerate.c находим кусок (это не вся строчка) UDP->UDP_CSR[3] = (wValue) ? (AT91C_UDP_EPEDS | AT91C_UDP_EPTYPE_ISO_IN) и заменяем на UDP->UDP_CSR[3] = (wValue) ? (AT91C_UDP_EPEDS | AT91C_UDP_EPTYPE_INT_IN) и вуаля... работает и на Intel и на AMD
|
|
|
|
|
Sep 23 2011, 06:36
|
Частый гость
 
Группа: Участник
Сообщений: 125
Регистрация: 1-12-08
Из: г. Орел
Пользователь №: 42 126

|
Цитата решается так: в файле cdc_enumerate.c находим кусок (это не вся строчка) UDP->UDP_CSR[3] = (wValue) ? (AT91C_UDP_EPEDS | AT91C_UDP_EPTYPE_ISO_IN) и заменяем на UDP->UDP_CSR[3] = (wValue) ? (AT91C_UDP_EPEDS | AT91C_UDP_EPTYPE_INT_IN) и вуаля... работает и на Intel и на AMD Это получается что Intelу по барабану?) У меня есть вопрос... Третья конечная точка Цитата UDP->UDP_CSR[3] = (wValue) ? (AT91C_UDP_EPEDS | AT91C_UDP_EPTYPE_INT_IN) нужна для работы с RTS CTS сигналами COM порта? В работе она у меня никогда не задействовалась. Только bulk точки и контрольная точка.
|
|
|
|
|
Sep 23 2011, 07:05
|
Частый гость
 
Группа: Свой
Сообщений: 197
Регистрация: 15-10-10
Из: г. Москва
Пользователь №: 60 179

|
Цитата(abit @ Sep 22 2011, 13:54)  решается так: в файле cdc_enumerate.c Видимо у вас совсем древняя версия demo. В свежих такого файла совсем нет.
|
|
|
|
|
Sep 23 2011, 10:13
|
Участник

Группа: Участник
Сообщений: 53
Регистрация: 26-07-11
Пользователь №: 66 426

|
shrek получается интелу по барабану... кстати в спецификации usb в режиме cdc она обозначена именно как int а не изохронная, как и где она задействуется - это к теоретикам, но интелу по барабану... и не одному а всем - от первого пенька до core2quad/itanium/xeon проверял... MrAlex да, старая 2005-2007 года.... собстна там три версии BasicUSB 1.0, 1.1 и 1.2 были проверенны - во всех внутренности резко меняются, но эта ошибка во всех трех версиях кроется... далее (после 2007г) эта демка вошла в USBCore и там вместо всего этого появились абсолютно другие файлы и куда более запутанная структура... Я все это описывал в этой теме... USBcore же не компилируется в IAR 4.11, из-за разных inc/h внутри самой IAR... а с IAR старше 4-х версий отказывается работать мой j-link cegger, который идет в комплекте всех AT91SAM7Sxxx-EK по сей день поэтому и вышла такая неприятная ситуация... так же эта ошибка содержится и в крайне свежей SAMBA, в чем я тоже убедился во время своего недельного эксперемента... с большой вероятностью она осталась и в USBCore, но в другом файле...
|
|
|
|
|
Sep 23 2011, 10:39
|
Частый гость
 
Группа: Участник
Сообщений: 125
Регистрация: 1-12-08
Из: г. Орел
Пользователь №: 42 126

|
abitЦитата да, старая 2005-2007 года.... собстна там три версии BasicUSB 1.0, 1.1 и 1.2 были проверенны - во всех внутренности резко меняются, но эта ошибка во всех трех версиях кроется... далее (после 2007г) эта демка вошла в USBCore и там вместо всего этого появились абсолютно другие файлы и куда более запутанная структура... Я все это описывал в этой теме... USBcore же не компилируется в IAR 4.11, из-за разных inc/h внутри самой IAR... а с IAR старше 4-х версий отказывается работать мой j-link cegger, который идет в комплекте всех AT91SAM7Sxxx-EK по сей день поэтому и вышла такая неприятная ситуация... так же эта ошибка содержится и в крайне свежей SAMBA, в чем я тоже убедился во время своего недельного эксперемента... с большой вероятностью она осталась и в USBCore, но в другом файле... Поэтому надо (желательно) писать все самому! Месяц другой, третий, четвертый, пятый... провозишься зато сначала будет HID USB например мышка, HID USB джойстик (аналоговый делал, еще руль делал), HID USB дигитайзер например, ну а потом можно и CDC. Компилировал атмеловские примеры с мышкой CDC во всех примерах размер прошивки зашкаливал за 20 кбайт!!! Причем примеры атмеловские для версий IAR 5.50 и выше. Самописный максимум 3 кб. С прикручиванием экранчика 6 кб. По поводу j-linkа странно... У меня с IAR ARM 4.22 j-link с seggerом нормально работает и с версией IAR ARM 5.50.1 работал и прошивался. Версия j-link 4.10f.
Сообщение отредактировал shrek - Sep 23 2011, 10:49
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|