[harper 0]

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

ISR(USB_GEN_vect)
{ USBINT = 0;}
int main(void)
{
// разрешить VBUS detection и VBUS Transition interrupt
// то есть определение подключения или отключения устройства
USBCON |= (1 << OTGPADE)|(1 << VBUSTE);
USBINT = 0;
// Global enable interrupts
sei();
while(1){}

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

[VladimirYU 0]

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

ISR(USB_GEN_vect)
{ USBINT = 0;}
int main(void)
{
// разрешить VBUS detection и VBUS Transition interrupt
// то есть определение подключения или отключения устройства
USBCON |= (1 << OTGPADE)|(1 << VBUSTE);
USBINT = 0;
// Global enable interrupts
sei();
while(1){}

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

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

 

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

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

[harper 0]

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

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

 

Код обработчика USBINT = 0;, да хоть любой другой.

Вызывает сомнения Proteus? Можно рассматривать только AVR Studio. При установке бита VBUS и даже VBUSTI прерывания не происходит.

[VladimirYU 0]

Код обработчика USBINT = 0;, да хоть любой другой.

Вызывает сомнения Proteus? Можно рассматривать только AVR Studio. При установке бита VBUS и даже VBUSTI прерывания не происходит.

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

[harper 0]

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

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

[Xenia 38]

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.

Изменено 8 января, 2009 пользователем Xenia

[harper 0]

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!

Вас то я и ждал! Буду теперь иметь ввиду, что Datasheet надо читать от корки до корки. Все равно странно Atmel пишет. Зачем мне опрашивать флаг VBUSTI, если все равно потом придется опрашивать VBUS? Так бы и писали.

Встречный вопрос. Но в Вашем проекте USB_AT90 Вы как раз используете это прерывание, или код уже исправлен?

И еще, почему во всех примерах сначала инициализируют USB блок (тем самым увеличивая энергопотребление), потом ждут подключения к шине и делают ATTACH. Почему сначала не определить подключение к шине, потом запустить USB блок и сделать ATTACH?

И еще везде непонятная фишка с UECFG0X = 0x02; - там же бит номер 1 не значащий. Это опечатка Atmel, которую все копируют?

Спасибо!

Изменено 8 января, 2009 пользователем harper

[aesok 0]

И еще везде непонятная фишка с UECFG0X = 0x02; - там же бит номер 1 не значащий. Это опечатка Atmel, которую все копируют?

Спасибо!

 

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:

ATMEL AT90USB Datasheet (7593D-AVR-07/06)

 

There exists some errors or at least unclear statements as listed below:

...

22.16 Isochronous mode (page 278)

For Isochronous IN endpoints, it is possible to automatically switch the banks on each start of

frame (SOF). This is done by setting ISOSW. The CPU has to fill the bank of the endpoint; the

bank switching will be automatic as soon as a SOF is seen by the hardware.

!!! ISOSW is mentioned here and in the 31. Register Summary (page 414), but no where else.

!!! In Register Summary (page 414) Flags SOSW, AUTOSW, NYETSDIS are mentioned, but not explained!

 

PSS: хотя в даташите написанно:

• 1 - Reserved

The value read from this bits is always 0. Do not set this bit.

Изменено 8 января, 2009 пользователем aesok

[Xenia 38]

Зачем мне опрашивать флаг VBUSTI, если все равно потом придется опрашивать VBUS? Так бы и писали.

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

Смысл потивопоставления этих двух дел я не поняла. Звучит как "зачем ложиться спать, если все равно зубы чистить?" :rolleyes:

 

Но в Вашем проекте USB_AT90 Вы как раз используете это прерывание, или код уже исправлен?

 

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

А в проекте "это прерывание" не используется - там прерывание только по EORSTE.

 

И еще, почему во всех примерах сначала инициализируют USB блок (тем самым увеличивая энергопотребление), потом ждут подключения к шине и делают ATTACH. Почему сначала не определить подключение к шине, потом запустить USB блок и сделать ATTACH?

 

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

В проекте подключение к шине тестируется в блоке обработки прерывания EORSTI (End of reset). И я так поняла, что PLL должно быть включено до того, чтобы "End of reset" начал распознавался.

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

 

И еще везде непонятная фишка с UECFG0X = 0x02; - там же бит номер 1 не значащий. Это опечатка Atmel, которую все копируют?

 

Тут используется поле "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 из того места можно удалить.

Изменено 9 января, 2009 пользователем Xenia

[harper 0]

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

Смысл потивопоставления этих двух дел я не поняла. Звучит как "зачем ложиться спать, если все равно зубы чистить?" :rolleyes:

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

 

А в проекте "это прерывание" не используется - там прерывание только по EORSTE

 

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

 

void USB_enable(void)
{
   UHWCON = (1<<UIMOD)| (1<<UVREGE); //это надо если нужно включить регулятор напряжения для USB модуля
   //USBCON = (1<<USBE) | (1<<OTGPADE) | (1<<FRZCLK)|(1 << VBUSTE);
   //USBCON = ((1<<USBE) | (1<<OTGPADE) | (1<<FRZCLK)); // setting FRZCLK again in not necessary (see below)
   UDIEN = ((1<<EORSTE));//|(1<<WAKEUPE)); Включаем нужные прерывания
   USBCON = ((1<<USBE) | (1<<OTGPADE) | (1 << VBUSTE)); //Включаем USB
   __enable_interrupt();
}

#pragma vector = USB_General_vect
__interrupt void usb_general_interrupt()
{
 //Изменения VBUS
 if (USBINT & (1 << VBUSTI))// && (USBCON & (1<<VBUSTE)))
  {
     USBINT = ~(1<<VBUSTI);                        //Бит VBUSTI должен быть сброшен програмно
     if (USBSTA & (1 << VBUS))                     //На пине 5V
     {
        USB_GENERAL_FLAG |= (1 << USB_connected);
        USB_start();
        USB_Dev_Attach();

 

Поэтом у вы можете просто не успеть активировать PLL, если сделаете это слишком поздно

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

 

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

 

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

[Xenia 38]

Xenia, извините, не понял связь.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Изменено 9 января, 2009 пользователем Xenia

[harper 0]

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