Самой железки пока нет. Пробую в Proteus и AVR Studio такой код для AT90USB1286:

Прерывания VBUSTI нет. Ставил и VBUS и VBUSTI. В чем проблема? Спасибо.

А где код обработчика?


В догонку. Что WDT, что с разрешением прерывания, и.... , а как ПРОТЕУС на это смотрит?

Код обработчика USBINT = 0;, да хоть любой другой.
Вызывает сомнения Proteus? Можно рассматривать только AVR Studio. При установке бита VBUS и даже VBUSTI прерывания не происходит.

Только предположение. Далеко не вся переферия полностю моделируется симуляторами, и система прерываний в том числе. И все же вопрос про WDT актуален, явно запретите его, т.к. глюк с его симуляцией в студии раньше был.

В моем случае с WDT все в порядке. В коде, указанном выше, я могу заменить данное прерывание на тоже асинхронное INT0 по Low Level и симуляция прекрасно работает. Вопрос именно к тем, кто работает с AT90USB. Может в коде чего-то не хватает? Или проблема симуляторов?

36. Errata
37. AT90USB1287/6 Errata.

37.4. AT90USB1287/6 Third Release
• Incorrect CPU behavior for VBUSTI and IDTI interrupts routines

5. Incorrect CPU behavior for VBUSTI and IDTI interrupts routines
The CPU core may incorrectly execute the interrupt vector related to the VBUSTI and IDTI interrupt flags.

Problem fix/workaround
Do not enable these interrupts, firmware must process these USB events by polling VBUSTI and IDTI flags.

Сообщение отредактировал Xenia - Jan 8 2009, 19:43

Спасибо, Xenia!
Вас то я и ждал! Буду теперь иметь ввиду, что Datasheet надо читать от корки до корки. Все равно странно Atmel пишет. Зачем мне опрашивать флаг VBUSTI, если все равно потом придется опрашивать VBUS? Так бы и писали.
Встречный вопрос. Но в Вашем проекте USB_AT90 Вы как раз используете это прерывание, или код уже исправлен?
И еще, почему во всех примерах сначала инициализируют USB блок (тем самым увеличивая энергопотребление), потом ждут подключения к шине и делают ATTACH. Почему сначала не определить подключение к шине, потом запустить USB блок и сделать ATTACH?
И еще везде непонятная фишка с UECFG0X = 0x02; - там же бит номер 1 не значащий. Это опечатка Atmel, которую все копируют?
Спасибо!

Сообщение отредактировал harper - Jan 8 2009, 22:57

avr-libc/iousbxx6_7.h:

#define UECFG0X _SFR_MEM8(0XEC)
#define EPTYPE1 7
#define EPTYPE0 6
/* #define ISOSW 3 */ /* Reserved */
/* #define AUTOSW 2 */ /* Reserved */
/* #define NYETSDIS 1 */ /* Reserved */
#define EPDIR 0

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

Анатолий.

PS:


PSS: хотя в даташите написанно:
• 1 - Reserved
The value read from this bits is always 0. Do not set this bit.

Сообщение отредактировал aesok - Jan 8 2009, 23:39

VBUSTI приходится опрашивать, т.к. этот флаг нужно снимать программно. Вот и приходится интесоваться тем, стоит этот флаг или нет. А VBUS приходится опрашивать по другой причине - чтобы своевременно устанавливать или снимать DETACH.
Смысл потивопоставления этих двух дел я не поняла. Звучит как "зачем ложиться спать, если все равно зубы чистить?"



Проект в общем-то не мой, я его лишь использую в "усовершенствованном" виде. Однако и сам автор проекта, в свою очередь, тоже "усовершенствовал" какой-то источник.
А в проекте "это прерывание" не используется - там прерывание только по EORSTE.



Энергопотребление увеличивается только из-за включения PLL, остальные флаги на него заметно не вляют. Однако включение PLL - долгая процедура (не в смысле программирования, а в физическом смысле), именно из-за чего приходится ждать, пока не установится PLOCK. Поэтом у вы можете просто не успеть активировать PLL, если сделаете это слишком поздно.
В проекте подключение к шине тестируется в блоке обработки прерывания EORSTI (End of reset). И я так поняла, что PLL должно быть включено до того, чтобы "End of reset" начал распознавался.
Ваша идея сначала "ждать подключения к шине", и только потом делать все остальное, вполне жизнеспособна. Весь вопрос только в том, как ждать этого события.



Тут используется поле "EPTYPE1:0" регистра UECFG0X:

7-6 - EPTYPE1:0 - Endpoint Type Bits
ATmega32U6/AT90USB64/128
00b: Control
10b: Bulk
01b: Isochronous
11b: Interrupt

0x02 это ошибка, но она затем исправляется на стадии инициализации всех конечных точек: usb_user_endpoint_init(). Там макрос usb_configure_endpoint() заполняет этот регистр новым занчением. А строку UECFG0X = 0x02 из того места можно удалить.

Сообщение отредактировал Xenia - Jan 9 2009, 10:27

Xenia, извините, не понял связь. VBUSTI я должен снимать если использую прерывание, чтобы сработало следующее прерывание. Atmel говорит - не используй это прерывание. Я не использую. Зачем мне его снимать? И почему VBUS приходится опрашивать по другой причине? Причина та же, что и для VBUSTI - установить, подсоединен device к host или нет. Только по прерыванию было бы удобнее, чем опросом. Что-то не так?



Вот отрывки кода по Вашей ссылке. Вижу, что ставите VBUSTE, а затем в прерывании определяете подключение устройства.





Не успею до чего. Вот воткнул я device в host. Devise по опросу VBUS определил, что он подключен, сконфигурировал и включил USB модуль (время потратилось 100mS из-за PLL), после этого сделал ATTACH. Вот только теперь host увидел, что есть device и начал с ним работать. Вроде никто никуда не опоздал.

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

Я и сама мало что в этом понимаю



Флаг VBUSTI устанавливается при ИЗМЕНЕНИИ (!) VBUS, поэтому только по его наличию нельзя судить об его уровне. Этот флаг аппаратно устанавливается не только при появлении +5 вольт на VBUS, но и при его исчезновении! Тут надо проверять бит VBUS порта USBSTA. Именно это и делается в процитированном вами участке кода. Прерывание по VBUSTI призвано привлечь внимание, когда VBUS изменилось, чтобы тут же проверить статус, в противном случае вам пришлось бы непрерывно проверять бит статуса .



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



Не факт, что не опоздали. 100 миллисекунд вы где ждали? Там где VBUS определяли? А это, между прочим, процедура обработки прерывания - там так долго торчать нельзя, т.к. своим поступком всё это время не давали работать остальным прерываниям. Представим, что у вас были бы включены часы на 1-милисекундном таймере (в обработке прерывания от таймера добавляется единичка в счетчик). Тогда вы своим поступком пропустили 100 штук таких прерываний, за что вам 100 щелбанов в лоб.



Жизнь такова, что все мы начинающие в новом деле. Меня сначала от этого USB просто тошнило , потом потихоньку стала привыкать. По поводу кода у меня сложилось впечатление, что люди тупо юзают эти тексты, даже не пытаясь вникнуть в их суть. Мол, работает, и хорошо. В книге Агурова почти те же названия функций. Похоже на то, что все это списано с какого одного места, а конкретные процедуры расшифрованы через спецрегистры данного микропроцессора. В этой кодировке вся работа по адаптации кода к конкретному микропроцессору. а специфику, похоже, никто не учитывает, а уж тем более еррату.

Сообщение отредактировал Xenia - Jan 9 2009, 22:19

Спасибо, Вам большое, Xenia, за внимание! Разговор, правда, иногда был похож на беседу слепого с глухим, отчасти из-за того, что я сразу поверил Atmel и решил не использовать прерывание VBUSTI, а Вы в своих объяснениях исходили из использования VBUSTI. Но все равно было интересно! Буду грызть дальше.