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

t25a3

Участник
  • Постов

    125
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о t25a3

  • Звание
    Частый гость
    Частый гость
  • День рождения 09.06.1984

Информация

  • Город
    Array

Посетители профиля

1 382 просмотра профиля
  1. Ревизия чипа at91sam7x512 судя по errata поддерживает RMII. Приобрели пару платок c чипами lan8720a и пару dp83848. Настроил at91sam7x512, подключил платку с dp83848 (только питание, MDC, MDIO), проверил по осциллограммам что по MDIO идет обмен (запрашивал чтение PHYID1) и mac принимает корректно. Вторая платка с dp83848 так же отвечает. Обе отозвались на PHYA 0x1. Подключал платки с lan8720a. Молчат в диапазоне PHYA 0x0-0x1F. По идее внутренние подтяжки должны были сконфигурировать после подключения питания платку в режим MODE[2:0]=3'b111 (All capable. Auto-negotiation enabled.), nINTSEL = 1 (подтяжка через LED2 по схеме рис. 3.11 из даташита, на платке внешний генератор 50 МГц раздает на mac и phy, на осциллографе присутствует частота и там и там), PHYAD0 = 0. То есть по SMI на PHYA 0x0 phy должен был откликнуться. Но молчит как партизан. Схема платки.
  2. Возможное решение проблемы Точнее ответы на вопросы, но не решение проблемы ;)
  3. забыл добавить какой бы не ставил размер конечной точки в дескрипторе (8, 16, 32, 64) прием данных например 512, 256, 128 байт идет с чередованием буферов (в принципе как и должно быть) но нулевой байт хост мне не отправляет. добавлю что и 1023 байта отправляет Device Monitoring Studio говорит что 1023 байта, и 1024 байта отправляет прога говорит 1024 байта.... и 2048 байт... :blink: прога ответила что в девайс ушли 2048 байт... и 4096 байт....... :blink: :blink: :blink: также 4096 байт.... и 8192 байта.... :krapula: говорит за раз отправил одной транзакцией в девайс.... но гад ни разу нулевой байт не прислал!!! :angry2:
  4. Добрый день! Реализовал самостоятельно CDC устройство на at91sam7x512. Порт открывается драйвера устанавливаются. Вроде все ничего (то есть нормально). Открываю порт чем нибудь. Посылаю 1 байт. Смотрю отправился (в отладке) посылаю 63 байта (размер конечной точки 64 байта) отправились. посылаю 64 байта - отправились. НО нулевой пакет не приходит... не могу отследить конец ли это передачи или будет следующая... Меняю размер конечной точки на 8 байт. отсылаю 7 байт девайс принял. 8 байт девайс принял. Но опять же не приходит нулевой пакет. и опять же не могу отследить конец ли передачи или нет. Когда опрашиваются дескрипторы нулевой пакет хост присылает. Когда работа ведется с конечными точками для CDC устройства нулевой байт не приходит... Раньше это все работало.... Изменилось только то что винду переустановил
  5. USB CDC

    Нулевой пакет нужен только если пакет кратен размеру конечной точки. Оказаось что это у меня косяк работы с dual буфером bulk конечной точки.
  6. CDC класс на AT91SAM7X512

    Победил прием пакетов большого обьема. В процессе вылез один косяк... Когда девайс пытается отправить из функции main, то есть под userом когда все прерывания разрешены (вложенных перываний нет я их не реализовывал), пакет размером больше 64 байт (больше конечной точки), то примерно после размера пакета 70 - 80 байт передача в хост отваливается... Долго думал и искал почему... Оказалось что контроллер не успевал работать с DUAL буфером BULK конечной точки. Когда контроллер начинал писать во второй буфер, еще не успев записать туда возникало прерывание TXCOMP по которому контроллер должен был записать данные размером с конечную точку в добавок к тому колву недозаписанных байт и передача в хост отваливалась. Решилось все запрещением прерываний на этапе первой записи данных в конечную точку. Еще кое что... Для "универсальности", так как число байт которое может прийти в девайс величина случайная, организовал работу USART и PDC_USART по прерываниям ENDRX и TIMEOUT. По первому инициализировался NEXT буфер и NEXT счетчик (после того как регистр счетчик основного буфера заканчивается возникает прерывание ENDRX, а из регистров PDC_RNCR и PDC_RNPR (если не ошибаюсь) значения автоматом копируются в PDC_RCR и PDC_RPR. А когда возникало прерывание TIMEOUT необходимо было дослать оставшиеся байты в Host. Возникала ситуация при которой контроллер еще не успевал отослать 1023 байта в Host как возникало прерывание TIMEOUT и в довесок пыталось запустить новую передачу. Так как первый косяк обнаружился вместе со вторым не мог разрулить когда досылать оставшиеся байты))) Днем пробовал на скорости 6 Мбит/с пересылать 16кбайт в Host за раз. Девайс без проблем переваривал))) Теперь самая сложная проблема!!! Как мигать диодиком при приеме-передаче данных?)))) В атмеловских примерах нашел только макросы для включения, выключения и переключения диода, где, как и когда эти операции делаются не обнаружил)))
  7. CDC класс на AT91SAM7X512

    Сегодня тестил устройства на основе USB_CDC самопальной сборки) Пытался с USARTом общаться) Так вот сделал по приему TIMEOUT, чтобы устройство могло принимать случайное число байт) Ну организовал весь обмен через PDC и прием и передачу. Даже сделал чтобы светодиодик моргал еще прикрутил настройку USARTа к запросу SET_LINE_CODING. Так вот открываю порт любой прогой для работы с ком портом, закольцевал USART, закольцевал через приемопередатчики для RS422 (не помню название микросхемы), посылаю случайные байты и случайное их колво все супер работает!!! :disco: !!! Отдаю платку парню для его устройства) Он к вечеру разобрал все косяки с неработой своего девайса и моей платки с приемопередатчиками RS422))) Когда он пересылает с компа в свое устройство пакет все нормально без проишествий) Когда он дает команду на "сьемку" в мою платку летит пакет 4096 байт... Я думал что моя платка сможет переварить такой пакет... Однако не переварила)))) Переварила только 3000 с копейками байт))) Вот!!! Я думаю... Надо подумать как этот пакет переварить...
  8. CDC класс на AT91SAM7X512

    опытным путем установленно путем закоментирования части обработки запроса SET_CONTROL_LINE_STATE (контроллер его отклоняет) /*case SET_CONTROL_LINE_STATE: { //AT91C_BASE_US0 -> US_CR = AT91C_US_RXDIS | AT91C_US_TXDIS; ZERO_PACKET(); break; }*/ что какой то косяк в обработке этого запроса... по умолчанию отправлял нулевой пакет на AT91SAM7A3 это срабатывало... После закомента пытался открыть порт... Посыпались спецефические запросы (в принципе это очень хорошо, так как раньше они при открытии порта запросы не сыпались)... Оказалось что обработка запроса SET_CONTROL_LINE_STATE тут не при чем!... Почему то косяк в конечных точках! Еще кое что выяснилось... Косяк именно в точке BULK_IN!!! На этапе конфигурации конечную точку с этой конфигурацией закоментировал и порт начал корректно открываться! Еще где бы я ни ставил дескриптор конечной точки BULK_IN, менял номера конечной точки BULK_IN и соответственно в дескрипторе менял все равно! Драйвер почему то не любит именно BULK_IN конечную точку... Проблема оказалась в конечной точке с атрибутами BULK_IN. Комп упорно отказывался работать с этой конфигурацией. Поменял атрибут на ISO_IN все заработало!!!... По спецификации CDC конечные точки могут быть либо изохорными либо BULK точки. С изохорной точкой не работает прием (передача данных в хост). Менял все булк точки на изохорные и передача в девайс отвалилась... С изохорными точками нифига не работает, а с BULK_IN точкой порт не открывается. что за хрень... Дескриптор устройства static const USB_DEVICE_DESCRIPTOR Device_Descriptor = { sizeof(Device_Descriptor), DEVICE_DESCRIPTOR, DEVICE_USB1_1, 2, 0, 0, 8, 0x03EB, 0x0110, 0x0110, INDEX_MANUFACTURE, INDEX_PRODUCTID, INDEX_SERIAL_NUMBER, 1, }; Дескриптор конфигурации static const USB_Configuration Configuration = { { sizeof(USB_CONFIGURATION_DESCRIPTOR), CONFIGURATION_DESCRIPTOR, sizeof(Configuration), 2, 1, 0, 0x80, 0xFA, }, { sizeof(USB_INTERFACE_DESCRIPTOR), INTERFACE_DESCRIPTOR, 2, 0, 1, 2, 2, 0, 0x00 }, { 0x05, 0x24, 0x00, 0x10, 0x01, 0x04, 0x24, 0x02, 0x00, 0x05, 0x24, 0x06, 0x00, 0x01, 0x05, 0x24, 0x01, 0x03, 0x01, }, { sizeof(USB_ENDPOINT_DESCRIPTOR), ENDPOINT_DESCRIPTOR, ENDPOINT_IN | 3, ENDPOINT_INTERRUPT, 8, 10, }, { sizeof(USB_INTERFACE_DESCRIPTOR), INTERFACE_DESCRIPTOR, 3, 0, 2, 0xA, 0, 0, 0x00 }, { sizeof(USB_ENDPOINT_DESCRIPTOR), ENDPOINT_DESCRIPTOR, 0x02, 0x02, 64, 0, }, { sizeof(USB_ENDPOINT_DESCRIPTOR), ENDPOINT_DESCRIPTOR, 0x81, 0x02, 64, 0, }, }; Все варианты исчерпал... АААААААААААААА!!!! ПОБЕДИЛ!!!!!! :cheers: :cheers: :cheers: :cheers: Все на выходных надо напиться.... Вся соль была в... #define AT91C_UDP_EP0 ((unsigned int) 0x1 << 0) // (UDP) Reset Endpoint 0 #define AT91C_UDP_EP1 ((unsigned int) 0x1 << 1) // (UDP) Reset Endpoint 1 #define AT91C_UDP_EP2 ((unsigned int) 0x1 << 2) // (UDP) Reset Endpoint 2 #define AT91C_UDP_EP3 ((unsigned int) 0x1 << 3) // (UDP) Reset Endpoint 3 #define AT91C_UDP_EP4 ((unsigned int) 0x1 << 4) // (UDP) Reset Endpoint 4 #define AT91C_UDP_EP5 ((unsigned int) 0x1 << 5) // (UDP) Reset Endpoint 5 #define AT91C_UDP_EP0 ((unsigned int) 0) // (UDP) Endpoint 0 #define AT91C_UDP_EP1 ((unsigned int) 1) // (UDP) Endpoint 1 #define AT91C_UDP_EP2 ((unsigned int) 2) // (UDP) Endpoint 2 #define AT91C_UDP_EP3 ((unsigned int) 3) // (UDP) Endpoint 3 #define AT91C_UDP_EP4 ((unsigned int) 4) // (UDP) Endpoint 4 #define AT91C_UDP_EP5 ((unsigned int) 5) // (UDP) Endpoint 5 Библиотеках на AT91SAM7A3 и AT91SAM7X512. Первую я собственно и подковырял немного)))
  9. CDC класс на AT91SAM7X512

    Добрый день. Суть проблемы вот в чем... Есть КИТ AT91SAM7A3 на нем CDC класс работает без сучка и задоринки! Переношу тот же код без изменения на AT91SAM7X512 (поменьял только параметры для ПЛЛ цепочки, ну и библиотеку для AT91SAM7X512)! Дескрипторы устройства конфигурации конечных точек принимаются и обрабатываются, то есть устройство определяется компом и ставится драйвер с последующими спецефическими запросами для класса CDC. Пытаюсь открыть порт любой прогой! Смотрю что ничего не приходит (в AT91SAM7A3 дескрипторы пачками шли в основном GET_LINE_CODING, SET_LINE_CODING и SET_CONTROL_LINE_STATE, причем у каждой проги для ком порта порядок и кол-во дескрипторов разные ). Так вот не пойму в чем проблема...
  10. USB CDC

    Исходники USB_CDC.ZIP Вот однако хост негодяй :maniac: ! Он от устройства понимаешь требует нулевой пакет типа конец передачи! А вот сам ничего не присылает! Привязаться не к чему... Пришлось привязать конец транзакции OUT к прерыванию SOFINT... (Пробовал петлю внутреннюю по интерфейсу сделать). Обнаружилось что и передачу данных в хост (транзакция IN) тоже необходимо связать с этим же прерыванием. Когда отправляет в хост данные разбивает их на блоки между соседними кадрами! Смотрел USBMonitorом...
  11. USB CDC

    Но тут проблема в том что в конце транзакции IN, то есть передачи в хост, кратен пакет не кратен пустой пакет в конце пакета отправлять надо...
  12. USB CDC

    Проверил... В транзакции OUT хост присылает нулевой пакет если размер конечной точки кратен 8!!!!....
  13. USB CDC

    Добрый день, возникла проблема по данной реализации. Написал все с нуля. Порты открываются данные передаются. Смотрю usbmonitorом(триал) и прогой для работы с ком портом. Так вот... Когда девайс в хост отправляет меньше 64 байт!!! то транзакция проходит. Когда девайс пытается отправить больше 64!!! то транзакция не проходит!!! Опытным путем установил что если хочешь передавать больше 64 байт то в конце всего пакета нужно отправить нулевой байт!... Причем нулевой байт обязательно нужно отправить! даже если пакет не кратен размеру конечной точки. Странно... Хост когда отправляет данные вроде не присылает нулевые пакеты... Но это надо проверить...
  14. abit Поэтому надо (желательно) писать все самому! Месяц другой, третий, четвертый, пятый... провозишься зато сначала будет 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.
  15. Это получается что Intelу по барабану?) :blink: У меня есть вопрос... Третья конечная точка нужна для работы с RTS CTS сигналами COM порта? В работе она у меня никогда не задействовалась. Только bulk точки и контрольная точка.
×
×
  • Создать...