harper 0 7 января, 2009 Опубликовано 7 января, 2009 · Жалоба Самой железки пока нет. Пробую в 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 7 января, 2009 Опубликовано 7 января, 2009 · Жалоба Самой железки пока нет. Пробую в 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 7 января, 2009 Опубликовано 7 января, 2009 · Жалоба А где код обработчика? В догонку. Что WDT, что с разрешением прерывания, и.... , а как ПРОТЕУС на это смотрит? Код обработчика USBINT = 0;, да хоть любой другой. Вызывает сомнения Proteus? Можно рассматривать только AVR Studio. При установке бита VBUS и даже VBUSTI прерывания не происходит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladimirYU 0 7 января, 2009 Опубликовано 7 января, 2009 · Жалоба Код обработчика USBINT = 0;, да хоть любой другой. Вызывает сомнения Proteus? Можно рассматривать только AVR Studio. При установке бита VBUS и даже VBUSTI прерывания не происходит. Только предположение. Далеко не вся переферия полностю моделируется симуляторами, и система прерываний в том числе. И все же вопрос про WDT актуален, явно запретите его, т.к. глюк с его симуляцией в студии раньше был. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
harper 0 7 января, 2009 Опубликовано 7 января, 2009 · Жалоба Только предположение. Далеко не вся переферия полностю моделируется симуляторами, и система прерываний в том числе. И все же вопрос про WDT актуален, явно запретите его, т.к. глюк с его симуляцией в студии раньше был. В моем случае с WDT все в порядке. В коде, указанном выше, я могу заменить данное прерывание на тоже асинхронное INT0 по Low Level и симуляция прекрасно работает. Вопрос именно к тем, кто работает с AT90USB. Может в коде чего-то не хватает? Или проблема симуляторов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 38 8 января, 2009 Опубликовано 8 января, 2009 (изменено) · Жалоба 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 8 января, 2009 Опубликовано 8 января, 2009 (изменено) · Жалоба 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 8 января, 2009 Опубликовано 8 января, 2009 (изменено) · Жалоба И еще везде непонятная фишка с 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 9 января, 2009 Опубликовано 9 января, 2009 (изменено) · Жалоба Зачем мне опрашивать флаг 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 9 января, 2009 Опубликовано 9 января, 2009 · Жалоба 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 9 января, 2009 Опубликовано 9 января, 2009 (изменено) · Жалоба 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 10 января, 2009 Опубликовано 10 января, 2009 · Жалоба Спасибо, Вам большое, Xenia, за внимание! Разговор, правда, иногда был похож на беседу слепого с глухим, отчасти из-за того, что я сразу поверил Atmel и решил не использовать прерывание VBUSTI, а Вы в своих объяснениях исходили из использования VBUSTI. Но все равно было интересно! Буду грызть дальше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться