USB CDC (AT91SAM7S64) не работает Опции

[abit]

Здравствуйте...
Существует следующая проблема - сделал устройство на основе отладочного Evalution Kit AT91SAM7S64, внутрисхемный отладчик IAR входил в комплект и работал только со старой версией IAR 4.22 (вроде), что была на диске с Kitом, другими (старшими) версиями не определялся этот отладчик cegger IAR, а также никакие программы от более поздних версий не компилировались из-за разницы в библиотеках...
фактически - был найдет проект USB-UART, который компилировался под IAR 4.22 (но опять же с версией могу ошибиться) - плата определялась как CDC устройство... либо как класс модема, либо как usb-класс... был выбран первый случай, т.к. в этом варианте ей присваивался виртуальный COM-порт типа COM26, но хотя бы в реестре можно вынудить этот номер порта и спокойно общаться, как с обычным com-портом... и все бы хорошо... но...
У заказчика 12 компов, купленных кучей... с материнской платой GA-K8NF-9, там атлон, крякнутая винда, антивир и куча неприятностей... на нем происходит следующая картина - AT91SAM7S64 принимает сколько угодно от компа, но когда отправляет всего 1 посылку Write(&pCDC,data,leng);, далее по диодикам понятно - что он работает как надо, но в компьютер кроме первой посылки ничего больше не доходит... я испробовал кучу компов на своем предприятии - со всеми работает, включая на основе Itanium, CoreQuard и Xeon - все работает... атлонов у нас вообще нет((( но они мне принесли этот комп - реально не пашет... и как бы юридически получается что работу я не выполнил - хотя на всех компьютерах у нас это работает (включая мой домашний), на том что они принесли - нет...
Что это может быть? Может кто-нибудь сталкивался с подобным?
Огромное спасибо за ответ, ибо мне на душе тоскливо... я попытался уже из под линукса даже на их компьютере это запускать...

Сообщение отредактировал abit - Sep 16 2011, 19:44

[prottoss]

Покажите дескриптор устройства

[kovigor]

Огромное спасибо за ответ, ибо мне на душе тоскливо... я попытался уже из под линукса даже на их компьютере это запускать...

Очень трудно что-то советовать. Какой у вас макс. размер пакета для данной конечной точки ? И сколько байтов вы пытаетесь отправить в машину за один раз ?
Как вариант - взять пример CDC от того же Keil, откомпилировать и посмотреть, что будет. Еще вариант - с помощью Bushound или аппаратного USB-сниффера (конечно, аппаратный сниффер гораздо лучше) посмотреть, как именно сбивается обмен ...

[Sergey Reva]

Было такое, решилось. Посмотрите как в вашем проекте идет обращение к регистрам UDP->CSR и как рекомендует документация (там есть примеры макросов). В старых версиях Атмеловского фреймвока эти самые макросы не использовались, это и приводило к такому глюку.

[Andrey Vasilyev]

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

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

Заодно бредовая мысль для проверки: не просматривается ли закономерность: на компьютерах с контроллером UHCI все работает, а с OHCI - не работает, или наоборот?

[abit]

prottoss
взят из старого проекта Usart-USB 1.0/BasicUSB1.1, файл cdc_enumerate.c
там дескриптор длиный, поэтому прикладываю оригинальный весь проект с диска из папочки Демо-программ...
см путь... AT91SAM7S-BasicUSB/src/cdc_enumerate.c

kovigor
шлются сообщения по 14 байт (вместе с /r/n) с частотой от 1 до 4 Гц...
но это не принципиально - если даже 1 раз послать 1 байт - то все... плата
продолжает работать дальше, отправлять... а в порт компьютера ничего не приходит - уже
проверенно на Win7 и ALT Linux 4...
от Keil вряд ли что выйдет - полная несовместимсоть по библиотекам... от IAR 5 даже не удается...
но попробуем...
аппаратного сниффера нет... Bushound попытаюсь тоже изучить-проверить...

Sergey_Reva
Дело в том что весь этот проект основан на файлах, взятых с официального диска IAR... я допускал,
что там нет никаких противоречий с документацией на то время...
В новых версиях IAR не работает данный программатор впринципе, в старой Вы говорите о глюке макроса (((
Речь идет об обращениях в lib_AT91SAM7S64.h (опять же стандартный в IAR)?:

Код

__inline void AT91F_UDP_EpStall(
    AT91PS_UDP pUDP,     // \arg pointer to a UDP controller
    unsigned char endpoint)   // \arg endpoint number
{
    pUDP->UDP_CSR[endpoint] |= AT91C_UDP_FORCESTALL;
}
_inline void AT91F_UDP_EpEndOfWr(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint)  // \arg endpoint number
{
    pUDP->UDP_CSR[endpoint] |= AT91C_UDP_TXPKTRDY;
}

__inline void AT91F_UDP_EpClear(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint,  // \arg endpoint number
    unsigned int flag)       // \arg flag to be cleared
{
    pUDP->UDP_CSR[endpoint] &= ~(flag);
}

__inline void AT91F_UDP_EpSet(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint,  // \arg endpoint number
    unsigned int flag)       // \arg flag to be cleared
{
    pUDP->UDP_CSR[endpoint] |= flag;
}

__inline unsigned int AT91F_UDP_EpStatus(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint)  // \arg endpoint number
{
    return pUDP->UDP_CSR[endpoint];
}

этот файл так же есть в приложенном демо-проекте, папка include

или я и тут ничего не понимаю?

Andrey Vasilyev
Возможно и глючный, но не один же я с такой проблемой - явно где-то это должно быть описанно, мне кажется вероятнее всего
проблема всетаки в стандартных IARных библиотеках...

собстна пока нашу группу компьютеров от их одного отличает только то, что у нас везде разные варианты Intel, у них тут AMD, интерфейсы у нас есть все - OHCI,UHCI и EHCI - и все работает... ну не xHCI же у них...

p.s. спасибо за ответы
p.s.s фактически не один пример (там их три на работу с USB) с официального диска не заработал на том компьютере, включая тот, что я выкладываю... на наших - все чудесно пашет...

Сообщение отредактировал abit - Sep 19 2011, 12:22

Прикрепленные файлы

 AT91SAM7S64_BasicUSB_IAR4_11A_1_1.zip ( 475.17 килобайт ) Кол-во скачиваний: 27

 

[Sergey Reva]

http://www.atmel.com/dyn/resources/prod_do...nts/doc6175.pdf
пункт 35.6.10 стр 527

Посмотрите как необходимо устанавливать/сбрасывать флаги регистра CSRx, скорее всего у Вас действительно старый код.
Возьмите свежую версию USB framework, родную от Atmel, и проблема должна исчезнуть

Сообщение отредактировал Sergey Reva - Sep 19 2011, 13:52

[aaarrr]

Речь идет об обращениях в lib_AT91SAM7S64.h (опять же стандартный в IAR)?:

Вот так делать и нельзя. Правильный вариант:

Код

#define UDP_CSR_CLR(endpoint, flags)                    \
{                                                        \
    u_int cpsr_t = store_disable_irq();                    \
    AT91C_BASE_UDP->UDP_CSR[endpoint] &= ~(flags);        \
    while(AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags));    \
    restore_irq(cpsr_t);                                \
}

#define UDP_CSR_SET(endpoint, flags)                    \
{                                                        \
    u_int cpsr_t = store_disable_irq();                    \
    AT91C_BASE_UDP->UDP_CSR[endpoint] |= (flags);        \
    while((AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags)) != (flags)); \
    restore_irq(cpsr_t);                                \
}

Как сохранить/восстановить статус прерываний (store_disable_irq(), restore_irq()) посмотрите в хелпе на свой компилятор.

Кроме того, следует обрамить запретом прерываний связку "установка TXPKTRDY - сброс TXCOMP".

[prottoss]

prottoss
взят из старого проекта Usart-USB 1.0/BasicUSB1.1, файл cdc_enumerate.c
там дескриптор длиный, поэтому прикладываю оригинальный весь проект с диска из папочки Демо-программ...
см путь... AT91SAM7S-BasicUSB/src/cdc_enumerate.c

Я вот почему спросил про дескриптор. Аналогичная проблема возникает при работе с штатным загрузчиком ВСЕХ МК серии AT91 через SAM-BA. На INTEL-чипсетах работает, на других НЕТ. Так что все что Вам тут выше наговорили, конечно, верно, но непосредственно к проблеме не относится. Проблема возникает как раз если работать с загрузчиком через драйвер usbser.sys.

[abit]

Sergey Reva, aaarrr
Спасибо за некоторые пояснения... кажется я начинаю понимать!!!
Но чем дальше, тем труднее понимание

http://www.atmel.com/dyn/resources/prod_do...nts/doc6175.pdf
пункт 35.6.10 стр 527

Посмотрите как необходимо устанавливать/сбрасывать флаги регистра CSRx, скорее всего у Вас действительно старый код.
Возьмите свежую версию USB framework, родную от Atmel, и проблема должна исчезнуть

Удивительно какой же у вас опыт что встречали эту ошибку и нашли ее решение... Я то по наивности размышлял что в демо программе к программатору все верно... только сегодня заметил - что и демо программа то тоже не работает на этом компьютере....

перепробовал 3 различные версии lib_AT92SAM7S64.h... - все бестолку... один и тот же код в этом куске... а более новые frameworkи уже не содержат подобной библиотеки, там сделали CDCDriver.c, USBD_UDP.c, CDCLine.c и еще много чего... не так все просто и не хочет оно собираться в 4.11 как не крутил я их около часу, но опять же хочется разобраться окончательно и попытаться исправить исходную библиотеку, если конечно вы поможете...

допустим

Код

u_int cpsr_t = store_disable_irq();

я так понимаю речь идет о нечто вроде

Код

volatile unsigned int reg = AT91C_BASE_UDP->UDP_CSR[endpoint]; \
        reg |= REG_NO_EFFECT_1_ALL;
reg &= ~(flags); \
        AT91C_BASE_UDP->UDP_CSR[endpoint] = reg; \
        while ( (AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags)) == (flags)); \

[aaarrr]

Замените пока работу с флагами на корректный вариант:

Код

__inline void AT91F_UDP_EpEndOfWr(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint)  // \arg endpoint number
{
    __istate_t isate = __get_interrupt_state();
    __disable_interrupt();
    pUDP->UDP_CSR[endpoint] |= AT91C_UDP_TXPKTRDY;
    while(!(pUDP->UDP_CSR[endpoint] & AT91C_UDP_TXPKTRDY));
    __set_interrupt_state(istate);
}

__inline void AT91F_UDP_EpClear(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint,  // \arg endpoint number
    unsigned int flag)       // \arg flag to be cleared
{
    __istate_t isate = __get_interrupt_state();
    __disable_interrupt();
    pUDP->UDP_CSR[endpoint] &= ~(flag);
    while((pUDP->UDP_CSR[endpoint] & (flag)) == (flag));
    __set_interrupt_state(istate);
}

__inline void AT91F_UDP_EpSet(
    AT91PS_UDP pUDP,         // \arg pointer to a UDP controller
    unsigned char endpoint,  // \arg endpoint number
    unsigned int flag)       // \arg flag to be cleared
{
    __istate_t isate = __get_interrupt_state();
    __disable_interrupt();
    pUDP->UDP_CSR[endpoint] |= flag;
    while((pUDP->UDP_CSR[endpoint] & (flag)) != (flag));
    __set_interrupt_state(istate);
}

Надеюсь, IAR 4.33 переварит.

Ну и про TXPKTRDY-TXCOMP не забудьте.

[abit]

Sergey Reva, aaarrr
Спасибо за некоторые пояснения... кажется я начинаю понимать!!!
Но чем дальше, тем труднее понимание

http://www.atmel.com/dyn/resources/prod_do...nts/doc6175.pdf
пункт 35.6.10 стр 527

Посмотрите как необходимо устанавливать/сбрасывать флаги регистра CSRx, скорее всего у Вас действительно старый код.
Возьмите свежую версию USB framework, родную от Atmel, и проблема должна исчезнуть

Удивительно какой же у вас опыт что встречали эту ошибку и нашли ее решение... Я то по наивности размышлял что в демо программе к программатору все верно... только сегодня заметил - что и демо программа то тоже не работает на этом компьютере....

перепробовал 3 различные версии lib_AT92SAM7S64.h... - все бестолку... один и тот же код в этом куске... а более новые frameworkи уже не содержат подобной библиотеки, там сделали CDCDriver.c, USBD_UDP.c, CDCLine.c и еще много чего... на это я наткнулся здесь - http://www.at91.com/forum/viewtopic.php/p,13767/#p13767

а оно все - так просто и не хочет собираться в 4.11 как не крутил я их около часу, но опять же хочется разобраться окончательно и попытаться исправить исходную библиотеку, если конечно вы поможете... тут как бы два вопроса...

1)
допустим

Код

     u_int cpsr_t = store_disable_irq();                    
    AT91C_BASE_UDP->UDP_CSR[endpoint] &= ~(flags);        
    while(AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags));    
    restore_irq(cpsr_t);

это ничто иное как

Код

       volatile unsigned int cpsr_t = AT91C_BASE_UDP->UDP_CSR[endpoint];
        cpsr_t |= REG_NO_EFFECT_1_ALL;
        cpsr_t &= ~(flags);
        AT91C_BASE_UDP->UDP_CSR[endpoint] = cpsr_t;
        while ( (AT91C_BASE_UDP->UDP_CSR[endpoint] & (flags)) == (flags));

?

поясните, пожалуйста, тогда как эти два макроса относятся к функциям в библиотеке __inline void AT91F_UDP_XXX, где XXX - EnableEp, DisableEp, EpStall, EpEndOfWr, EpClear, EpSet, EpStatus - это вроде полный перечень где вертится UDP_CSR... и каждый раз функция - всего одна строчка (команда) над UDP_CSR...
В конце концов мне то нужно изменить эти функции... а не два макроса, которых собстна и нет в исходном коде вообще... в общем я не понимаю, что с ними (макросами) потом-то делать...
еще более точно - достаточно ли не вводя макросы просто все эти функции где происходит ковыряние UDP_CSR, обернуть в то же?

))) когда дополнил вопрос - увидел что вы ответили то же самое ))) можно не отвечать на этот, я все понял!!!


2)

Кроме того, следует обрамить запретом прерываний связку "установка TXPKTRDY - сброс TXCOMP".

не встретил (
зато встретил частичный ответ на свой первый вопрос в коде USBD_UPD.c (из набора, который у меня не собирается):

Код

// Send next packet
                if (BOARD_USB_ENDPOINTS_BANKS(bEndpoint) == 1) {

                    // No double buffering
                    UDP_WritePayload(bEndpoint);
                    SET_CSR(bEndpoint, AT91C_UDP_TXPKTRDY);
                    CLEAR_CSR(bEndpoint, AT91C_UDP_TXCOMP);
                }
                else {
                    // Double buffering
                    SET_CSR(bEndpoint, AT91C_UDP_TXPKTRDY);
                    CLEAR_CSR(bEndpoint, AT91C_UDP_TXCOMP);
                    UDP_WritePayload(bEndpoint);
                }

SET_CSR/CLEAR_CSR - это макросы удивительно сходные с тем что вы писали - UDP_CSR_CLR/SET... я бы сказал они же... но где здесь обрамление sti/cli ? (хотя я не знаю как это в AT91SAM7 выглядит...

Сообщение отредактировал abit - Sep 19 2011, 16:51

[aaarrr]

1. См. выше.
2. В примере профукано. Запрещение/разрешение прерываний в IAR - __disable_interrupt()/__enable_interrupt() соответственно.

[prottoss]

ОК. Подождем, когда код заточится, но на AMD работать не будет

[abit]

1. См. выше.
2. В примере профукано. Запрещение/разрешение прерываний в IAR - __disable_interrupt()/__enable_interrupt() соответственно.

тогда по поводу п.1....
там стоит disable_interrupt() у вас во всех функциях, enable - нет... так должно быть?

[aaarrr]

Там стоит запрос состояния->запрет->восстановление. Чтобы не разрешать, если были уже запрещены.

[abit]

ОК. Подождем, когда код заточится, но на 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

[aaarrr]

возникает вопрос можно ли просто в тупую добавить store_int и disable_int в начале всей этой функции и set_interrupt_statу в конец, опоясов всю эту функцию, решив тем самым обе проблемы сразу?

Можно, если не смущает время запрещения прерываний.

На самом деле, макрос или инлайн, выполненный со всеми возможными предосторожностями - это все-таки некоторый костыль. По-хорошему, нужно в каждом конкретном случае решать, запрещать ли прерывания, дожидаться ли установки/сброса битов в CRS (а это не всегда необходимо) и т.п. Хотя оверхед костыля в любом случае небольшой.

[abit]

Можно, если не смущает время запрещения прерываний.

На самом деле, макрос или инлайн, выполненный со всеми возможными предосторожностями - это все-таки некоторый костыль. По-хорошему, нужно в каждом конкретном случае решать, запрещать ли прерывания, дожидаться ли установки/сброса битов в 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

[shrek]

Посмотри по ссылке.
http://electronix.ru/forum/index.php?showt...60&start=60
Там есть проект "рабочий" под IAR 4.22 камень AT91SAM7A3. Данные только принимаются))) можешь попробовать дописать и отправление. Пробовал на разных компах работает. На линуксе не пробовал...

[prottoss]

prottoss если дело в том, о чём Вы говорили...

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

не верно обозвал два разных дескриптора. Исправленный файл ниже.

Прикрепленные файлы

 __________USB__________________CDC_ACM.rar ( 3.28 килобайт ) Кол-во скачиваний: 44
 __________USB__________________CDC_ACM.1.rar ( 3.29 килобайт ) Кол-во скачиваний: 211

 

[shrek]

Менял в своем проекте 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

[taoga]

Попробуйте код отсюда, может поможет?
http://electronix.ru/forum/index.php?showt...89&hl=taoga

[abit]

Всем спасибо)
Проблема таки решена после недели мучений...
Дескрипторы и прерывания не причем...

Не работало только на АМД-шках, если кто столкнется с этой проблемой, скрывать решение не буду )))

решается так:
в файле 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

[sergeeff]

А ведь стандарт USB CDC изначально определяет три точки: 2 bulk и 1 interrupt.

Это еще одна иллюстрация качества demo проектов.

[prottoss]

Не работало только на АМД-шках, если кто столкнется с этой проблемой, скрывать решение не буду )))

Ну вот в AT91-загрузчике и сидит баг.

[shrek]

решается так:
в файле 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 точки и контрольная точка.

[MrAlex]

решается так:
в файле cdc_enumerate.c

Видимо у вас совсем древняя версия demo. В свежих такого файла совсем нет.

[abit]

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, но в другом файле...

[shrek]

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