А чем питание от USB не кошерно? Я могу запретить, а точнее - вообще не инициализировать USB-сервис, используя чип, как обычный микропроцессор, а не как USB-контроллер. Тогда от USB-порта только одно питание и останется.

Если питать от внешнего источника, то происходит тоже самое - как только питание падает до 4.40-4.35 вольта - признаки жизни пропадают.

А ткнуть осцильчиком в кварц - моя мечта . К сожалению, я - программист, а не электронщик. Осциллографа у меня нет. Но надеюсь найти место, где мне удастся им воспользоваться.

а есть возможность упротить программу например до:



тоже будет "стопориться" при понижении питания?

Проблема с напряжением на 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 1.1 не синоним full(low)-speed, а USB 2.0 не синоним high-speed.



Universal Serial Bus Specification; Revision 2.0
Я надеюсь она у Вас есть.

Chapter 6 Mechanical;
6.6 Cable Mechanical Configuration and Material Requirements
6.6.3 Electrical Characteristics
Page 105; Table 6-6. Conductor Resistance

Chapter 7 Electrical
7.2 Power Distribution
7.2.2 Voltage Drop Budget
Page 175; Figure 7-47. Worst-case Voltage Drop Topology (Steady State)



Первая страница даташита на AT90USB64/128:
• USB Full-speed/Low Speed Device Module with Interrupt on Transfer Completion

Анатолий.

Разбралась в причине "зависания" МК при понижении напряжения питания ниже 4.4 вольта. Причина оказалась настолько же дебильной, как и сопротивление в соединительном кабеле. Даже признаваться неловко.
Начну по-порядку.
Осциллографом кварц замерила - ниже 4.4 вольта генерация наличествует. Предположение о том, что не тянет кварц, не оправдалось. Эх, зря я 16 Мгц на 8 Мгц сменяла!
Следуя данному мне здесь совету, написала самую простейшую программку типа:

При напряжении ниже 4.4 вольта и эта программка, как и ожидалось, не сработала - светодиод не зажегся. Однако самым интересным оказалось то, что при понижении напряжения из работающего состояния в неработающее светодиод гас! Это означало, что МК не зависает, а ресетится!
Померила напряжение на ножке RESET - так оно и есть! Напряжение всего 0.4 вольта - при таком значении МК работать не может. Нашла в интернете даташит на микросхему супервизора (MCP100T-450), который формирует сигнал RESET. Так оно и есть - у него Vtrip = 4.5 вольта, а гистерезис от 4.25 в до 4.50 в (в среднем). Как у меня напряжение падало ниже этого уровня, он и вставлял ресет.
Судя про всему, быть мне великим электронщиком, когда я своё устройство усмирю!

Так BOD был внешним?
Одно из первых что проверяют после питания - ресет.
Всё у Вас получится.

А зачем она вам? AT90USB содержит встроенный BOD, параметрируемый и замечательно работающий.

Небольшой оффтоп - Xenia, а где вы берете (планируете брать) Vendor ID и Device ID? Форум по этому вопросу я просмотрел, интересует ваш способ.

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

Хорошая ссылка.
http://pdfserv.maxim-ic.com/en/an/AN3241.pdf
Особенно интересна последняя главка.
Здесь тоже кое-что есть по вашей теме.
http://www.usb.org/developers/whitepapers/...otherboards.pdf

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

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

Если Вы спрашиваете про дескрипторы, то они отправляються по CONTROL endpoint, как с ней работать нарисанно в параграфе 22.12 CONTROL endpoint management:



Та цитата что привели Вы относиться к IN endpoint.

Анатллий.

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

Почему же, когда в даташите демонстрируют примитивное отправление байта по USART, которое и так каждому понятно, то приводят пример кода, который это делает. А USB во сто крат сложнее, а примерчика нету. Или может бы знаете где найти такой примерчик? Только не отсылайте меня к тому дурацкому проекту, в котором разобраться невозможно. И книжка Агурова не в помощь, т.к. на его процессоре FIFOCON'а нет, а все флаги в регистрах вывернуты наоборот. Хотелось бы все-таки из первых рук получить инфу, а не от индийских программистов , которые тот проект написали.

P.S. Тот параграф, что вы указали, я посмотрела, но из той диаграммы не поняла, который из сигналов все-таки отправляет FIFO-буфер на линию. Мне бы чего по-проще - последовательность ШАГОВ, как отправить FIFO-буфер с данными наружу. Натолкала я в него байтов, а потом чего? Обязательно ли TXINI и FIFOCON друг за дружкой, или достаточно одного? Опять же скидывать TXINI до заполнения буфера данными или можно после?

Я на базе этого проекта написал свой, функции конечно подправил, но идеология осталась. Проблем не встретил.
Вот посылка:

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

Нет! Hулевой (control) endpoin двухнаправленный, по нему передаются пакеты и от хоста к устройства и от устройства к хосту, все же остальные endpoin-ты одноноправленные (IN или OUT), так что ничего удивительного в том что они управляються по разному нет.

Анатолий.

Ваш Usb_send_in() - это и есть мой FIFOCON:
#define Usb_send_in() (UEINTX &= ~(1<<FIFOCON))

То, что вы делаете - ужасно! Каждый байт оправляете отдельным пакетом.

Ошибаетесь, отсылка идёт при заполнении ендпоинта.

Мда... Тут не мудрено и запутаться.

А TXINI вы где сбрасываете? По-вашему это будет Usb_send_control_in().

Отсылка происходит по Usb_send_in(), т.е. сбросом FIFOCON.

В даташите же ясно написанно и нарисованно, для IN-endpoint вначале надо сбросить TXINI и только после того как в буфер помещенны все необходимые данные сбросить FIFOCON.
TXINI можно сбросить до, во время или после записи данных, но обязательно до сброса FIFOCON.


CONTROL-endpoint работают по другому. Вы про какой endpoint спрашиваете?

Анатолий.

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


Visor

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

У меня появился новый животрепещущий вопрос по теме: как можно со стороны МК попросить хост сделать паузу в посылке данных? Те данные, которые уже пришли, МК готов безоговорочно принять, но хочет попросить хост, чтобы оставшиеся данные он пока не присылал, попридержав их у себя до тех пор, пока МК не будет к этому готов.

Рассмотрим конкретный пример, чтобы моя задача не казалась слишком абстрактной. Положим у нас имеется устройство не с USB-портом, а с обычным COM-портом (RS-232), которое работает "периодически": сначала набирает к себе в буфер данные, а затем что-то со всеми этими принятыми данными начинает делать, из-за чего нуждается в паузе, пока это дело не будет сделано. Сейчас не суть важно, что это за дело - может быть отправляет эти данные пакетом куда-то дальше, или записывет на диск, или отправляет по e-mail, - только приходится ждать, пока принятые данные не будут утилизированы, и лишь после этого устройство снова будет готово к приему новой порции данных. Причем подразумевается, что устройство не имеет в своем распоряжении столько памяти, чтобы сохранить весь поток данных, пришедшых во время исполнения дела.

Если это RS-232, то такая задача решается исключительно просто - данные передают с хэндшейкингом, используя линию DSR, как признак готовности к приёму данных. Тут устройство попросту устанавливает отрицательный уровень DSR, что является сигналом для хоста преостановить передачу данных. Когда устройство закончит "переваривать" принятые данные, оно снова установит на линии DSR положительную полярность, что побудит хост продолжать передачу с момента вынужденной остановки.

Но вот мы присоединили это устройство не к родному COM-порту компьютера, а через USB/COM-конвертор, выполненный на нашем МК. И вот видит наш МК, что устройство запросило паузу линией DSR, - что тогда ему делать? Собственная память у него есть, но ее не так много, чтобы сохранить все то, что отсылать устройству ему запрещено. Кроме того, он не знает точно, как долго продлится эта пауза. Единственным разумным выходом из этой ситуации было бы, в свою очередь, поступить аналогичным образом - тоже попросить USB-хост об отсрочке передачи.

Возможно ли такое в принципе, а если да, то каким образом делается? Ведь наш МК является ведомым, зависящим от посылок со стороны хоста. Как ему сигнализировать о том, что у него будет временный напряг с приемом?

DETACH снять я не могу - тогда USB-хост его попросту потеряет. FREEZE сделать? Но поймет ли хост? Что положено в этом случае делать?

Я не знаю есть ли какой специальный механизм для этотго в CDC. Для Bulk ендпоинт это реализуеться посылкой NAK в ответ на OUT пакет.



Анатолий.

Механизм есть. Он описан в спецификации CDC, там описаны запросы. Общая идея, есть запросы SET LINE CODING. Хост запрашивает скорость, число бит и т.д. в т.ч. тип управления потоком аппаратный или программный. Когда хост узнает, что управление потоком будет аппаратное, он запрашивает как именно будет управляться поток. Форматы запросов и ответов есть в спецификации на CDC.

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 устанавливают, чтобы показать, что буффер опустошен. Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом.
А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

И не надо. Просто не выгребаете данные из RX_EP и хост будет курить бамбук сколько надо. Это поддерживает сам USB-контроллер, посылая в ответ на пакеты хоста NAK, если нет места в приемном буфере. Хост, соответственно, будет перепосылать пакет, пока девайс не ответит ACK.

Механизм NAK'ов в USB работает на любых ендпоинтах. Не ставьте FIFOCON, железка будет посылать хосту NAK'и и поток затормозится.

Упс, опередили

Вау! Так просто?! Т.е. забираю из буфера по мере использования, а заботиться о том, что он переполнится мне не надо? Так это же кайф!

А то я приметила что флэшка (виртуальный диск) тоже начинает внезапно томозить, когда в нее закачиваешь длинный файл. Я еще сильно удивлялась, как ей удается сопротивляться внешнему накачиванию данными. Ведь у нее скорость записи медленнее, чем скорость передачи по USB2.0.

Странно!!!!

На странице 221 "Universal Serial Bus Specification" параграфе "8.5.2 Bulk Transactions" написано и нарисованно что можно отвечать NAK для Bulk endpoint (также как и на Control/Interrupt endpoint). Это на Isochronous нет ACK/NAK/STALL. А откуда у вас информация что NAK работает только на controll endpoint?

Я так понимаю Вы работаете с Bulk ендпоинт. Тогда требуеться минимум действий. Расмотрим Bulk OUT endpoint, параграф "22.14 OUT endpoint management" даташита AT90USB64/128.

Когда приходит OUT пакет выставляться 2 бита:
RXOUTI - флаг прерывания по причине прихода пакета, который сразу можно сбросить и
FIFOCON - FIFO Control Bit - говорящий о том что буфер занят
пришедшим пакетом. Пока Вы не сбросите этот бит вы можете к какой угодно
скорость читать данные из этого буфура, при этом USB контроллер будет
отвечать NAK-ом на все попытки хоста передать следующий пакет. Как только Вы
полностью прочитаете буфер, Вы сбрасываете бит FIFOCON в 0. И теперь при
очередной попытке хоста передать пакет, контроллер запишет его в
освободившийся буфер, ответит хосту ACK, и выставит биты RXOUTI и FIFOCON.
И.т.д....

Другими словами сбрасывайте бит FIFOCON после того как полностью обработали пришедщий пакет, все остальное хост с USB контролером в mege все сделают сами.


Анатолий.

Тоже думал уже сильно "переосмыслить" примеры, но, как всегда, велосипед уже изобретен.
http://www.fourwalledcubicle.com/LUFA.php
Куда как болие прямой USB стек от фанатов. Под WinAVR. C кучей DEMO. Понравился.

Ну вот, новая "радость" на наши головы - Windows 7.
Не работает под ней.

Да уж... только с XP разобрался, опять новые веяния... Благо "семерка" еще не доминирует... пока...

С "вистой" не работаю принципиально, т.к. о покойниках либо хорошо, либо никак... а вот в "семерке" должны быть
предусмотрены настройки для эмуляции более ранних ОС...

Давайте пробовать вместе. Я использую AT90USB162 и основательно мной "раскуроченные" на кирпичики Атмеловские
демки... Использую в основном HID, думаю "семерка" должна поддерживать без проблем со стороны МК, а вот со стороны
PC возможно уже другие драйвера для HID... Не знаю... Надо пробовать.

С HID не знаю, не пробывал, здесь мы мучаем CDC.
Речь конкретно о at90usbxxx_cdc.inf .