Xenia

SET_LINE_CODING передает от хоста в МК dwDTERate, bCharFormat, bParityType, bDataBits; т.е. скорость в бодах, формат, четность и число стоп-бит. Все это передается затем, чтобы МК повторил эти установки на своем RS-232-порту, т.к. для обмена по USB эти данные не нужны. GET_LINE_CODING запрашивает эти же данные (обычно те же самые, что были раньше пререданы хостом командой SET_LINE_CODING). Есть еще SET_CONTROL_LINE_STATE, посредством которого хост может выразить желание изменить уровни DSR и RTS. И это всё! Никакого аппаратного хендшейкинга здесь нет! Практика показывает, что все эти три команды подаются только при открытии USB-порта (виртуальный COM), а в процессе передачи никогда не подаются. Поэтому нет и никакой возможности подать сигнал о том, что линии изменили полярность в процессе передачи. Т.е. раз хост не спрашивает, то и ответить ему не представляется возможным. ==================================================================== ACK'ом или NAK'ом можно отвечать на запросы от НУЛЕВОГО эндпоинта, на специфические ЗАПРОСЫ. Однако поток данных идет по эндпоинту RX_EP и не требует никаких ответных реплик. Там только бит FIFOCON устанавливают, чтобы показать, что буффер опустошен. Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом. А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

У меня появился новый животрепещущий вопрос по теме: как можно со стороны МК попросить хост сделать паузу в посылке данных? Те данные, которые уже пришли, МК готов безоговорочно принять, но хочет попросить хост, чтобы оставшиеся данные он пока не присылал, попридержав их у себя до тех пор, пока МК не будет к этому готов. Рассмотрим конкретный пример, чтобы моя задача не казалась слишком абстрактной. Положим у нас имеется устройство не с USB-портом, а с обычным COM-портом (RS-232), которое работает "периодически": сначала набирает к себе в буфер данные, а затем что-то со всеми этими принятыми данными начинает делать, из-за чего нуждается в паузе, пока это дело не будет сделано. Сейчас не суть важно, что это за дело - может быть отправляет эти данные пакетом куда-то дальше, или записывет на диск, или отправляет по e-mail, - только приходится ждать, пока принятые данные не будут утилизированы, и лишь после этого устройство снова будет готово к приему новой порции данных. Причем подразумевается, что устройство не имеет в своем распоряжении столько памяти, чтобы сохранить весь поток данных, пришедшых во время исполнения дела. Если это RS-232, то такая задача решается исключительно просто - данные передают с хэндшейкингом, используя линию DSR, как признак готовности к приёму данных. Тут устройство попросту устанавливает отрицательный уровень DSR, что является сигналом для хоста преостановить передачу данных. Когда устройство закончит "переваривать" принятые данные, оно снова установит на линии DSR положительную полярность, что побудит хост продолжать передачу с момента вынужденной остановки. Но вот мы присоединили это устройство не к родному COM-порту компьютера, а через USB/COM-конвертор, выполненный на нашем МК. И вот видит наш МК, что устройство запросило паузу линией DSR, - что тогда ему делать? Собственная память у него есть, но ее не так много, чтобы сохранить все то, что отсылать устройству ему запрещено. Кроме того, он не знает точно, как долго продлится эта пауза. Единственным разумным выходом из этой ситуации было бы, в свою очередь, поступить аналогичным образом - тоже попросить USB-хост об отсрочке передачи. Возможно ли такое в принципе, а если да, то каким образом делается? Ведь наш МК является ведомым, зависящим от посылок со стороны хоста. Как ему сигнализировать о том, что у него будет временный напряг с приемом? DETACH снять я не могу - тогда USB-хост его попросту потеряет. FREEZE сделать? Но поймет ли хост? Что положено в этом случае делать?

И про это я уже думала. HEX-прошивки действительно можно объединить вручную. Только есть одна закавыка. В программе приложения имеется команда, которая АКТИВИЗИРУЕТ загрузчик. Т.е. фактически это простой вызов функции из boot-области, откуда возврата больше не будет до окончания прошивки. И вот этот вызов мне будет сложно реализовать, т.к. при раздельном приготовлении проектов такие вызовы делать нельзя. В противном случае будет непонятно, как мне активизировать загрузчик в случае возникшей необходимости. С этим же вопросом связан еще и другой: функции поддержки обмена по USB-каналу (а они достаточно объемные!) можно было бы держать ТОЛЬКО в загрузчике (boot-области), а приложение попросту бы ими пользовалось. Но такое можно организовать только в том случае, если приложение и загрузчик удастся объединить в одном проекте. Может у вас все-таки появятся какие-нибудь мысли, чтобы не разъединять программу на два проекта? Тем более, что мне от верхней таблицы прерывания нужны всего лишь 2 вектора: USB_General_vect и USB_Endpoint_Pipe_vect. Остальные прерывания я на время прошивки блокирую, включая таймеры. Понимаете? Всего-то два джампа на нужных местах решило бы мою прблему.

Как сделать два проекта, я и сама знаю. Но моя проблема именно в том, что мне нужна СРАЗУ ПОЛНАЯ прошивка с нижней и верхней областью. В этом и состоял мой вопрос. На ассемблере могу сделать это играючи, а вот на IARе возникают непреодолимые проблемы из-за того, что тому никак нельзя растолковать, что таблиц прерывания может быть две. Еще раз повторяю, что в данном разделе обсуждаются возможности применения компилятора IAR, и мой вопрос целиком относится к этой теме. Перевод моего вопроса в плоскость "зачем всё это мне нужно" - флейм не по теме. Тем более что я уже достаточно подробно объяснила причины, по которым мне нужно работающее приложение и одновременно возможность его перепрошивки в будущем, когда оно устареет или в нем обнаружатся ошибки. Такой подход не технологичен. Микропроцессоры можно прошивать скопом еще до стадии впаивания в плату, после чего изделия сразу становятся рабочими и доступными для тестирования. А мертвые изделия, с каждым из которых надо потом индивидуально возиться с допрошивкой, создают массу проблем. Опять же я не смогу перед руководством доказать необходимость программирования за два этапа. Мне резонно скажут, что я дура, если не могу прошить микропроцессор за один раз (в трудозатратах мое руководство толк понимает, а в программировании не сечет).

Ну, а я создала сегмент с названием BOOT, а не MY_BOOT - велика ли разница? Вот что я уже раньше писала: Как видите, размещать код в boot-области я умею, и сразу про это написала, чтобы не вызывать лишних разговоров. Но судя о вашему ответу, это все-таки произошло. За совет использвать директиву __root спасибо, попробую с ней разобраться. Тем не менее, не ясно как писать эту таблицу. Если вам это кажется очевидным, но напишите хотя бы начало такой таблицы на первые два вектора прерывания. Как это должно выглядеть, чтобы компилятор не послал меня далеко и надолго? ==================== Такое решение не годится, т.к. сегмент INTVEC (как и любой другой сегмент) являтся НЕПРЕРЫВНЫМ, а мне по условию задачи нужны две РАЗНЫЕ таблицы прерывания в РАЗНЫХ областях памяти. Вопреки вашим словам, компилятор "стандартным образом" все кладет в начало одного и того же INTVEC-сегмента, а система проекта не позволяет одному модулю назначить один INTVEC-сегмент, а другому другой. Причина в том, что расположение сегментов определяется в опциях линкера и является ОБЩИМ для всего проекта, на сколько бы текстовых файлов он ни был поделен. Поэтому я никак не могу одну функцию-обработчик асооциированть с нижнией областью flash-памяти, а другую с верхней. Компилятор понимает только одну ЕДИНСТВЕННУЮ таблицу прерываний, всегда соответствующую сегменту INTVEC, которых не может быть две штуки.

IAR: как создать таблицу векторов прерываний в boot-области? Обычно таким вопросом не задаются, т.к. таблица прерываний создается автоматически в самом начале CODE-сегмента. Устанавливая перед фунциями-обработчиками прерываний прагму "#pragma vector=", мы тем самым вызываем заполнение ячейки этой таблицы, соответствующей указанному номеру вектора. Но как быть, если таких таблиц нужно две? Для самого приложения (расположенного в нижних адресах flash-памяти) и загрузчика (расположенного в boot-области). Когда загрузчик перепрошивает приложение (нижние адреса), то он нуждется в своей собственной таблице прерываний, т.к. своими действиями он затирает таблицу векторов, обслуживающую приложение. Т.е. в данном случае должен иметь автономию от приложения. Ситуация усугубляется еще и тем, что объем application-области на всех видах микропроцессоров превышает объем оперативной памяти (SRAM), из-за чего невозможно сначала принять новую прошивку целиком, а потом заняться прошивкой, не используя прерываний. Вот и приходится прошивать по-странично: страничку (256 байт) принимаю, записываю, читаю по USB прошивку для следующей страницы и т.д. К сожалению, загрузчик у меня USB-ый, а без использования прерываний работать по USB-каналу, по-видимому, невозможно. Вот и получается, что загрузчику нужна собственная таблица векторов прерываний, независимая от таблицы того приложения, которое он перепрошивает. Из описания микропроцессора (ATmega647) вроде бы следует, что переключение между нижней и верхней таблицами прерываний осуществляется битом IVSEL регистра MCUCR: С этим, кажется, проблем нет. Дело осталось за малым - как создать такую таблицу средствами IAR? На ассемблере у меня такой проблемы просто бы не возникло. Как помещать функции в boot-область я поняла - пишешь перед каждой из них прагму "#pragma local="BOOT"", предварительно создав кодовый сегмент с именем BOOT в опциях линкера или конфигурационном файле. Но как создать таблицу векторов прерываний, состоящих из одних команд rjmp? Даже, если я напишу такие команды, и компилятор их откомпилирует, то линкер их все равно не поставит на место, т.к. на них нет внешних ссылок (этот случай интерпретируется им, как неиспользуемый код, и исключается из компоновки). А кроме того, язык Си не позволит мне писать джампы вне тела функций, хотя макрос для создания самих джампов имеется. Думала над возможностью сделать два отдельных проекта для приложения и для загрузчика, в каждом из которых CODE-сегмент определен по-разному. И таблицы векторов прерываний тогда будут отдельные. Но возникает проблема объединить обе прошивки в одну, а я таких средств не знаю. Тем более что мой программатор не позволяет дописывать прошивку в кристалл, а полностью стирает всю предыдущую информацию перед прошивкой. Кроме того, опции линкера одни и те же для всех модулей проекта, а потому в одном проекте я объединить обе программы не могу. Возникшие затруднения самостоятельно разрешить не смогла, а потому обращаюсь к вам за советом.

Я и сама мало что в этом понимаю :unsure: Флаг VBUSTI устанавливается при ИЗМЕНЕНИИ (!) VBUS, поэтому только по его наличию нельзя судить об его уровне. Этот флаг аппаратно устанавливается не только при появлении +5 вольт на VBUS, но и при его исчезновении! Тут надо проверять бит VBUS порта USBSTA. Именно это и делается в процитированном вами участке кода. Прерывание по VBUSTI призвано привлечь внимание, когда VBUS изменилось, чтобы тут же проверить статус, в противном случае вам пришлось бы непрерывно проверять бит статуса . Да, я разрешаю прерывания по VBUSTE. Если я этого не делаю, то ничего не работает. Поэтому мне кажется, что это прерывание все-таки работает. А то что я процитировала вам еррату, то там не было ни одного моего слова. А, значит, и у вас не должно быть ко мне притензий по этому поводу. Не факт, что не опоздали. 100 миллисекунд вы где ждали? Там где VBUS определяли? А это, между прочим, процедура обработки прерывания - там так долго торчать нельзя, т.к. своим поступком всё это время не давали работать остальным прерываниям. Представим, что у вас были бы включены часы на 1-милисекундном таймере (в обработке прерывания от таймера добавляется единичка в счетчик). Тогда вы своим поступком пропустили 100 штук таких прерываний, за что вам 100 щелбанов в лоб. :unsure: Жизнь такова, что все мы начинающие в новом деле. Меня сначала от этого USB просто тошнило :unsure:, потом потихоньку стала привыкать. По поводу кода у меня сложилось впечатление, что люди тупо юзают эти тексты, даже не пытаясь вникнуть в их суть. Мол, работает, и хорошо. В книге Агурова почти те же названия функций. Похоже на то, что все это списано с какого одного места, а конкретные процедуры расшифрованы через спецрегистры данного микропроцессора. В этой кодировке вся работа по адаптации кода к конкретному микропроцессору. а специфику, похоже, никто не учитывает, а уж тем более еррату.

VBUSTI приходится опрашивать, т.к. этот флаг нужно снимать программно. Вот и приходится интесоваться тем, стоит этот флаг или нет. А VBUS приходится опрашивать по другой причине - чтобы своевременно устанавливать или снимать DETACH. Смысл потивопоставления этих двух дел я не поняла. Звучит как "зачем ложиться спать, если все равно зубы чистить?" :rolleyes: Проект в общем-то не мой, я его лишь использую в "усовершенствованном" виде. Однако и сам автор проекта, в свою очередь, тоже "усовершенствовал" какой-то источник. А в проекте "это прерывание" не используется - там прерывание только по 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 из того места можно удалить.

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.

Тот проект сложноват для понимания, и тем более переложения на ассемблер. Если вам host-режим не нужен, то можете посмотреть проектик по-проще (подшила архив). Там кое-какие ошибки нашла, но в гпаза они не сильно бросаются. Этот на ассемблер легко переложить - упрощен до предела. Если у вас плата - самоделка, то проверьте еще напряжение на UVCC (3-я ножка) - USB Pads Internal Regulator Input supply voltage - туда 5 вольт надо подавать. USB_AT90.zip

Снимите флаг DETACH и устройство обнаружится как "новое". Вот так: UDCON &= ~(1<<DETACH); // Attach Это и есть включение подтяжки D+. Только сразу это делать неположено, а положено делать тогда, когда появляется напряжение на шине VBUS. Обычно изменение VBUS генерит general usb interrupt, при обработке которого флаг DETACH либо устанавливают, либо снимают. Т.е. опасаются подавать напряжение на обесточенный USB-разъем. Но если ваша схема питается прямо от USB, т.е. именно от этого VBUS, то Attach можно делать сразу. В проекте, который рекомендовал Visor, все это есть.

А может, все-таки, будет проще, если вы сами прочтете тему "AT90USB1286, виртуальный COM-порт"? Там и на рабочий проект есть ссылки и еще много чего.

У меня всё в кучку соединено, как в даташите изображено тут: Figure 21-3. Typical Bus powered application with 5V I/O. А вы проверьте, как у вас фуза CKDIV8 стоит. Фабрично ее устанавливают, из-за чего МК работает в 8 раз медленнее кварца - вот частота PLL и получается не такая, как нужно. Я тоже мучалась, пока не поняла, что на кварце предустановлен делитель. Его надо либо фузой погасить или программно (CLKPR=0x80, а потом сразу CLKPR=0).

У меня вот так и вроде работает: PLLCSR = (1<<PLLP2) | (1<<PLLP0) | (1<<PLLE); UHWCON = (1<<UIMOD) | (1<<UVREGE); USBCON = (1<<USBE) | (1<<OTGPADE) | (1<<VBUSTE);

Да-да, именно про это я и спрашивала. Только диаграммы в этом смысле бывают не совсем понятны, т.к. из них не всегда ясна причина, отчего тот или иной сигнал изменил уровень. Например, до того, как вы объяснили, мне было неясно: падает ли TXINI на диаграмме сам (аппаратно) из-за того, что в буфер стали пихать байты, или же его сбросили программно перед запихиванием первого байта. Теперь ситуация проснилась, за что вам от меня большое спасибо :). Visor Вообще-то сочиненный мною код подобен вашему, только я писала в буфер не по признаку Is_usb_write_enabled(), а просто заталкивала туда столько, каков был его размер, т.е. чисто по штукам. Из-за того, что это было в прерывании из-за пустоты буфера, то я могла быть уверенной, что он пуст и, стало быть, в него можно записать на полную катушку. Однако я, хотя и пишу на Си, однако прямо на регистрах, а не этими мнемоническими функциями, которые никак не могу запомнить.

Мда... Тут не мудрено и запутаться. А TXINI вы где сбрасываете? По-вашему это будет Usb_send_control_in().

Ваш Usb_send_in() - это и есть мой FIFOCON: #define Usb_send_in() (UEINTX &= ~(1<<FIFOCON)) То, что вы делаете - ужасно! Каждый байт оправляете отдельным пакетом.

А может быть вы в нем сильно не разбирались - работает и ладно, а на TXINI и FIFOCON начхать? :) Вы на меня, пожалуйста, не обижайтесь, но меня совершенно не устраивает фукция передачи, которая заставляет меня ждать в цикле while, пока не закончится передача. Мне нужно, как и в случае USART - отсылка по прерыванию опустошения передатчика. Т.е. здесь - по прерыванию освободившегося FIFO-буфера. У меня АЦПы очень быстро передают, и если я стану отправки ждать, то не смогу их вовремя обслуживать. Потому меня и волнует вопрос отправки буфера.

Здесь разница только в номере конечной точки: запрос дескрипторов идет по нулевой, а передача и прием данных - по 1-ой и 2-ой. Неужели эти два случая разняться настолько, что в первом случае FIFOCON не нужен, а в двух других он необходим? Или вот пустой пакет (ZLP) когда отправляют, то FIFOCON'ом не пользуются. Вроде как только дрыгнут TXINI и пакет отправился. Почему же тогда при отправлении блока данных я должна использовать помимо TXINI еще и FIFOCON? Ведь TXINI формально относится к передаче данных, хотя CONTROL отправляет с его помощью дескрипторы. А FIFOCON тот и вовсе ничейный. Почему же, когда в даташите демонстрируют примитивное отправление байта по USART, которое и так каждому понятно, то приводят пример кода, который это делает. А USB во сто крат сложнее, а примерчика нету. Или может бы знаете где найти такой примерчик? Только не отсылайте меня к тому дурацкому проекту, в котором разобраться невозможно. И книжка Агурова не в помощь, т.к. на его процессоре FIFOCON'а нет, а все флаги в регистрах вывернуты наоборот. Хотелось бы все-таки из первых рук получить инфу, а не от индийских программистов :), которые тот проект написали. P.S. Тот параграф, что вы указали, я посмотрела, но из той диаграммы не поняла, который из сигналов все-таки отправляет FIFO-буфер на линию. Мне бы чего по-проще - последовательность ШАГОВ, как отправить FIFO-буфер с данными наружу. Натолкала я в него байтов, а потом чего? Обязательно ли TXINI и FIFOCON друг за дружкой, или достаточно одного? Опять же скидывать TXINI до заполнения буфера данными или можно после?

Народ! Кто-нибудь из вас пробовал писать прошивку для USB САМОСТОЯТЕЛЬНО? А то от демонстрационного проекта буквально уши вянут. Или на крайний случай, хотя бы пытался разобраться что там к чему? А то есть у меня вопрос про отсылку пакетов - никак не пойму из описания, как положено FIFO-буфер отсылать - стиранием флага TXINI или FIFOCON? Из описания вроде бы надо через FIFOCON, но в демо-проекте все дескрипторы отсылаются без использования FIFOCON. Вот что писано по этому поводу в даташите:

Так вы на меня больше не сердитесь? :)

Это не оффтоп, а вопрос как раз по теме. За основу брала "USB библиотеку под AT90USBxxx" выложенную на Сахаре OlegPowerC: http://caxapa.ru/128010.html Затем я ее переписала под себя, вычистив замеченные ошибки: http://caxapa.ru/136120.html Vendor ID и Device ID остались от Atmel'я, примеры на сайте которого скорее всего послужили OlegPowerC прототипом.

Разбралась в причине "зависания" МК при понижении напряжения питания ниже 4.4 вольта. Причина оказалась настолько же дебильной, как и сопротивление в соединительном кабеле. Даже признаваться неловко. Начну по-порядку. Осциллографом кварц замерила - ниже 4.4 вольта генерация наличествует. Предположение о том, что не тянет кварц, не оправдалось. Эх, зря я 16 Мгц на 8 Мгц сменяла! Следуя данному мне здесь совету, написала самую простейшую программку типа: main() { Lamp_on(); // включаю светодиод for(;;); // бесконечный цикл } При напряжении ниже 4.4 вольта и эта программка, как и ожидалось, не сработала - светодиод не зажегся. Однако самым интересным оказалось то, что при понижении напряжения из работающего состояния в неработающее светодиод гас! Это означало, что МК не зависает, а ресетится! Померила напряжение на ножке RESET - так оно и есть! Напряжение всего 0.4 вольта - при таком значении МК работать не может. Нашла в интернете даташит на микросхему супервизора (MCP100T-450), который формирует сигнал RESET. Так оно и есть - у него Vtrip = 4.5 вольта, а гистерезис от 4.25 в до 4.50 в (в среднем). Как у меня напряжение падало ниже этого уровня, он и вставлял ресет. Судя про всему, быть мне великим электронщиком, когда я своё устройство усмирю! :):):)

Проблема с напряжением на USB разрешилась совершенно неожиданным образом. Оказалось, что с программированием драйвера было всё в порядке, о чем свидетельствовало значение тока, которое можно посмотреть на вкладке Power устройства USB Hub в девайс-менеджере. Проблема была ... в кабеле! Каждая жила которого имела сопротивление 2.6 ома. Итого в цепи питания (Ubus+Gnd) набиралось 2.6+2.6=5.2 ома, которые при токе 150 мА сажали на себя 5.2*0.15=0.78 вольта. В результате устройство имело для питания 5-0.78=4.22 вольта. Большего с этим кабелем получить было нельзя даже теоретически. Кабель покупала на Буденовском рынке, был в полиэтиленовый мешочек запаян. Продавался как кабель типа A-B для USB 2.0, длина 1 метр (реально оказалось 90 см). Отчего у него такое высокое сопротивление не понимаю. Еще более удивительно, что сопротивление между внешними экранами разъемов достигает 20 ом! Мне и в голову не приходило, что такой короткий кабель может иметь такое большое сопротивление. Кабель попал под подозрение тогда, когда я однажды забыла его отключить во время прошивки через LPT-порт. Еще не начав прошивку, а только лишь присоединив шлейф, я увидела, что мое устройство весело замигало лампочкой. Померив напряжение на МК, я обнаружила, что оно повысилось до 4.6 вольта, на которых устройство уже работало. Стала искать причину прибавки и сильно удивилась, не обнаружив на шлейфе никаких напряжений. Присоединяя все жилы шлейфа по очереди, удалось выследить, что напряжение возрастало в то момент, когда к устройству присоединяли ... землю! Вот тут-то уж померила напряжение между землями компьютера и устройства, которая оказалась как раз равна этой прибавке. В дальнейшем, выясняя ее происхождение, я неминуемо наткнулась на высокое сопротивление жил в соединительном кабеле. Проклиная нехорошими словами злополучный кабель, а отодрала USB-кабель от принтера, с которым тот продавался в комплекте. Тот кабель был вдвое длиннее (2 метра), большего про него узнать не удалось. Принтер же определялся операционкой, как USB 1.1 девайс. Измерив сопротивление принтерного кабеля, я с удовлетворением обнаружила, что оно составляет всего 0.2 ома на жилу, несмотря на то, что жилы в нем вдвое длиннее. Присоединив посредством этого кабеля свое устройство к компьютеру, я получила свои вожделенные 4.9-5.0 вольт, о которых мечтала. Устройство равномерно подмигивало лампочкой, но ... компьютером не определялось. Вообще не видел компьютер моего устройства в упор. Подозреваю, что это потому, что этот кабель не был рассчитан на USB 2.0. И вот сижу я теперь, перед этими двумя кабелями, как старуха у разбитого корыта. Один пропускает USB-сигналы, но пожирает напряжение питания, а другой пропускает напряжение питания, но пожирает USB-сигнал. На дворе воскресенье, магазины, где продают компьютерные прибамбасы, закрыты. А в понедельник куда мне идти, искать этот проклятый провод? Может кто-нибудь в курсе, регламентируется ли где-нибудь омическое сопротивление USB-кабелей в расчете на один погонный метр? Или мне с авометром по магазинам ходить? И еще один вопрос по теме - может ли AT90USB647/1286 работать по протоколу USB 1.1? Т.е. с меньшей скоростью, чем тот рассчитан? Если да, то что для этого нужно? В даташите на этот счет никакой информации не нашла.

А чем питание от USB не кошерно? :) Я могу запретить, а точнее - вообще не инициализировать USB-сервис, используя чип, как обычный микропроцессор, а не как USB-контроллер. Тогда от USB-порта только одно питание и останется. Если питать от внешнего источника, то происходит тоже самое - как только питание падает до 4.40-4.35 вольта - признаки жизни пропадают. А ткнуть осцильчиком в кварц - моя мечта :). К сожалению, я - программист, а не электронщик. Осциллографа у меня нет. Но надеюсь найти место, где мне удастся им воспользоваться.