Укажите, пожалуйста, где вы это исправили! У меня та же проблема, только я ошибки в упор не вижу.

В config.h переопределила на частоту 16 МГц:
#define FOSC 16000

В хидере pll_drv.h все написано совершено правильно:
#elif (FOSC==16000)
#define Pll_start_auto() Start_pll(PLLx03)
где PLLx03 определено выше как:
#define PLLx03 ( (1<<PLLP2) | (0<<PLLP1) | (1<<PLLP0) )

Так и быть должно согласно даташиту:
Табл. 6-13
XTAL=16 MHz
Clock Devision Factor=8
PLLP2=1
PLLP1=0
PLLP0=1

Где здесь ошибка?

Сообщение отредактировал Xenia - Apr 1 2008, 13:31

Ошибка оказалась в даташите, а не в софте.


В даташите (в моём по крайней мере):
Table 6-13. PLL input prescaler configurations

А у вас какой МК?

Скачала последний даташит с сайта ATMEL:
[PDF] AT90USB1286, AT90USB1287, AT90USB646, AT90USB647 (455 pages, revision G, updated 03/08)

Действительно, в марте появились изменения. Однако вот что там сказано:

External XTAL required for USB operation (MHz) = 16
Clock Division Factor = 8

PLLP2=1, PLLP2=0, PLLP2=1 (1)
Note: 1. For AT90USB128x only. Do not use with AT90USB64x.

PLLP2=1, PLLP2=1, PLLP2=0 (2)
Note: 2. For AT90USB64x only. Do not use with AT90USB128x.

У меня AT90USB647, значит я и виновата, что использовала программу для AT90USB1287. Но ведь и в голову не могло придти, что в этом месте может быть расхождение!

Сообщение отредактировал Xenia - Apr 2 2008, 12:09

Я работаю с AT90USB1286 (в теме указан )
Использую даташит 7593D–AVR–07/06, т.е. ревизия D, когда я начинал была последняя.
Дак вы поправили, заработало?
У меня пример заработал, проблема была хардверная.

А я действовала по ревизии А (7593A-AVR-02/06) - там было 101. Вашу ревизию D я тоже нашла, и действительно в ней написаное иное - 110. Но ведь ревизия G (7593G-AVR-03/08) - последняя и только что вышла, и согласно ей для AT90USB128 права ревизия А, а для AT90USB64 права ревизия D.
Но ведь у вас AT90USB128 и по ревизии D у вас заработало. Выходит, что последнняя ревизия снова вернулась к первоначальному ошибочному утверждению относительно AT90USB128?



Да, заработало. Вам огромное спасибо!

Сообщение отредактировал Xenia - Apr 2 2008, 22:09

Нет, у меня работает с 101.


Я то причём.

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

На WinXP работает, а на Vista не загружается драйвер. Что делать?

В обеих случаях CDC использует фирменный драйвер от Microsoft под названием UsbSer.sys. При стандартной установке системы этот драйвер не ставится, но он имеется в базе driver.cab и оттуда при необходимости ставится в директорию System32\drivers\. Обычно этот драйвер используют многочисленные USB-модемы, для коих целей он и составлялся.
Проект at90usb128-demo-cdc-1_0_3.zip тоже базируется на этом драйвере, поэтому для его установки прилагается только inf-файл, который использует стандартный драйвер UsbSer.sys. Но вот беда - под Vista этот inf-файл не срабатывает.
Вот здесь - http://forums.microsoft.com/MSDN/showpost....51&siteid=1 - на микрософтовском форуме, народ ругается про то же самое. А кто-то составляет свои версии inf-файла - http://blog.bigreat.org/2007/11/25/at91sam...-windows-vista/ (правда не для AT90USB128, а для AT91SAM7).
Вопреки опасениям, UsbSer.sys в системе Vista имеется - его дата 02.11.2006 и он длинее на 2560 байт того, который поставляется с WinXP.

Отзовитесь, кому удалось запустить CDC-проект под Vista или помогите советом, где раздобыть подходящий inf-файл для этой цели.

===============
P.S.: Кажется в другом проекте at90usb162-cdc-1_0_1.zip есть inf-файл, в заголовке которого поминается Vista:

; Windows 2000, XP & Vista setup File for AT90USBxx2 demo

Пока не успела проверить заработает с ним или нет.

Сообщение отредактировал Xenia - Apr 4 2008, 11:16

Вы решили проблему? Интересует тот-же вопрос.

Проблема разрешилась тем способом, каким я и предполагала. INF-файл, взятый из проекта at90usb162-cdc-1_0_1.zip, способен работать под Vista со всеми МК типа AT90USB, а не только AT90USBxx2, как сказано в его заголовке.

Сообщение отредактировал Xenia - May 14 2008, 04:09

Спасибо!

Обнаружилось следующее:
Когда размер принимаемого либо отправляемого пакета данных кратен размеру ENDPOINT, он застревает в хосте. Пакет любой другой длины передаётся без проблем.
Подскажите в чём дело? И нужно хорошее описание по USB.

После такого пакета нужно посылать хосту пакет нулевой длины - это сигнал о завершении передачи

Совершенно верно.
Но это происходит только в том случае если хост "не знает" длины передаваемых данных. Если длина известна хосту - передача завершается без посылки пакета 0й длины. В случае bulk передачи проблем нет - можно послать пакет 0й длины. А в случае передачи через контрольный канал (EP0) наличие в передатчике EP0 пакета 0й длины разрешённого для передачи, но незапрошенного хостом, может привести к сбою. Это если мы не успеем очистить передатчик EP0 после получения пакета OUT 0й длины с DATA1 (управляющая запись на эту транзакцию), а хост пошлёт следующий пакет SETUP (следующая транзакция) и сразу-же прочтет из передатчика EP0 пакет IN 0й длины (оставшийся) т.е. получится управляющее чтение (на следующую транзакцию). Я с такой ошибкой сталкивался. Пришлось слать пакет 0й длины по NAK-ам (если данные были кратны пакету EP). А заморочек с обработкой посылки NAK-ов хосту немало. Но я ничего лучше не придумал.
А вы как узнаёте, что нужно пакет 0й длины хосту слать? Без обработчика NAK-ов удаётся обойтись?

Я не использовал AT90USBxxx, но по большому счету это относится ко всему, что работает по USB. Хост в любом случае не знает, сколько данных ему забирать, потому что он железяка. Так же не знает об этом и ПО, которое хостом управляет. ПО может только думать, ЧТО, если количество данных меньше, чем размер буфера конечной точки (EP), значит функция больше не будет передавать данные. Если количество принятых хостом данных равно размеру буфера ЕР, значит функция передала не все данные, и хост будет опрашивать функцию на предмет присутсвия пакета в ЕР. Чтобы сообщить хосту, что данных для передачи больше нет, мы пишем в ЕР нулевой пакет.