osnwt

Я бы не говорил о "выводах с уверенностью" :) Вывод или можно сделать, или нет. Если же уверенность не 100%, то это не вывод, а предположение. Я допускаю возможность того, что USB хаб фильтрует потоки данных устройств. Однако, это противоречит наблюдаемому и документированному свойству драйвера. Что делается на порту хаба - несложно посмотреть соответствующими аппаратными средствами. И я сказал, что уточню этот вопрос у реально знающих людей, если не закручусь. И в конечном итоге я не горю желанием просто ради спора или желания разбираться в первопричинах эффекта зарываться в документы и проводить множество экспериментов. У меня просто нет времени на это. Я вижу, что у отдельно взятых людей есть проблема. Я вижу, что автор хочет им помочь, сделать, чтобы устройство работало на максимально возможном количестве компьютеров (то есть, максимально корректно, насколько это возможно). Потому я предложил простую последовательность действий, которую нужно сделать, чтобы увидеть, есть эффект аномальной задежки или нет (я про циклы). У меня нет ни одного CDC устройства на меге, чтобы проверить это самому (также см. выше про время). В конечном итоге, цель этой темы - не дебри особенностей работы USB хабов, а стремление сделать устройство максимально универсальным. Я дал идею, а будет ее кто-то проверять или нет, - мне, в общем-то, всё равно :-)

Я тоже не интересовался схемотехникой хабов, потому не могу ответить на этот вопрос однозначно. Однако, допускаю предположение, что USB хаб сходен функционально с простыми Ethernet хабами на витой паре. Последние, в отличие от switch'ей, дублируют на свои порты всё, что летит по шине, выполняя исключительно функции электрической развязки и согласования. Свичи же действительно разделяют потоки данных, для чего им требуется часто неслабые процессоры и буферная память. Что касается наличия данных на всех портах, то я также этого не проверял. На работе есть аппаратный анализатор USB трафика, но с ним работаю не я. Если не забуду, то поинтересуюсь, как все же реализованы хабы. У нас есть люди, кто серьезно работает с USB, в том числе делает собственные хабы и устройства специального назначения. Однако, всё, сказанное мной выше в этом сообщении - мои предположения, а не утверждения. Я всего лишь обращаю внимание на эту фразу из документации (см. ниже). Автор его - явно не начинающий в этом деле, а потому у меня нет оснований ему не доверять. The driver will consume CPU cycles for all USB messages, even if they address another (low-speed) device on the same bus. Поскольку подключения нескольких устройств на одни провода не бывает (тогда бы никто не делал хабов вообще - делали разветвители из проводов), то приходится поверить, что данные дублируются. Поэтому независимо от того, понимаем ли мы причину этого или нет (и хотим ли выяснять) - с этим приходится считаться. Не могу прокомментировать, поскольку уверенности у меня нет (я не изучал этот вопрос лично, а высказывать свои предположения, ни на чем не основанные, не вижу резона). Я всего лишь обращаю внимание на то, что если 90% времени AVR занято обработкой прерываний, но очевидно, что он что-то да делает. Версия: bukl endpoint - это не interrupt endpoint. Потому, вероятно, там свои особенности. Потому, если говорить лично про меня, то создавая программу, использующую данный драйвер, особенно имея в виду проблемы bulk endpoints, я бы однозначно не использовал холостых циклов для каких-либо задержек, если там критично и максимальное время задержки, а не по принципу "не менее, чем". На это уже намекали несколькими сообщениями выше, но автору виднее. Кому надо - может сам поправить исходные тексты, не так ли (я их не правил и даже не смотрел, так что прошу по этому вопросу мне не писать ЛС). Вероятно, было бы полезным переписать задержки в более корректной форме, и сравнить, увеличится ли процент машин, на которых эта штука станет работать без проблем. Еще совет: сделать просто холостой цикл с известным периодом повторения, в котором просто менять состояние пина. Посмотреть на период изменения осциллографом при отключенном USB. После чего воткнуть в USB и сравнить, как изменится этот период в зависимости от количества прочих устройств на шине и даже без оного. С учетом 90% загрузки CPU период должен стать неравномерным и существенно увеличиться. Тогда все вопросы сразу отпадут.

Вынужден огорчить: разница есть и, увы, значительная. 1) Данный USB драйвер реализует всю обработку транзакций на USB шине в своей процедуре обработки прерывания. 2) Обработка одного прерывания может быть до 100 мкс по стандарту, но при нестандартных или кривых хабах - гораздо больше. 3) Как документировано в описании, USB драйвер обрабатывает каждую low-speed транзакцию на шине USB, даже если она не относится к нашему устройству. Следствие: если на шине много низкоскоростных устройств (мыши и т.п., например), то в прерываниях мы будем находиться намного чаще, чем необходимо именно нашему устройству. 4) Если почитать документацию (usbdrv.h), то там написано открытым текстом: Please note that the USB standard forbids bulk endpoints for low speed devices! Most operating systems allow them anyway, but the AVR will spend 90% of the CPU time in the USB interrupt polling for bulk data. Что на практике означает то, что если мы используем данный драйвер с поддержкой bulk (к CDC это также относится), то хост опрашивает наше устройство не раз в 10-20 мс (как это справедливо, например, для HID), а непрерывно раз за разом. Как писал мне автор драйвера, он так и не нашел workaround против этого, поскольку оно не противоречит стандарту, и все хосты так себя ведут. Соответственно, 90% времени AVR будет находиться в прерываниях, лишь изредка из них вылезая (причем, процент времени обработки заранее непредсказуем). И, как следствие, холостые циклы могут растягиваться и в 10 раз, и намного больше, когда после каждой 10-й команды мы снова можем улетать в прерывание и сидеть там длительное время, а после выхода - еще и еще. Это - просто факты. Рекомендации я мог бы написать, но не стану, поскольку это будет опять из серии "идеологических" вопросов о том, как следует писать программы (вроде ранее обсуждавшегося между нами вопроса "следует ли патчить исходники драйвера или же нужно использовать заложенные автором интерфейсы"). Потому выводы предлагаю сделать самостоятельно. Надеюсь, мое объяснение было полезным.

Какой ревижн чипа? Насчет неудачной разводки ничего не скажу, поскольку разводил не я, а сам не сильно силен в таких вопросах. Однако, не очень представляю, как влияет наличие установленного BOD на прерывание АЦП. А серьезно если, то прерывания в тестовом примере я вообще не разрешал, что вполне логично для выяснения причин проблемы. Как я инициализировал - уже смотреть не хочется, давно то было, и я не использую битовые константы, я обычно пишу нечто вроде вот такого: Но при этом так и не признали наличия бага. Отсюда могу предположить, что и наличие других проблем точно также будет прикрыто, если таковые реально имелись.

Лично я присоединяюсь к нижецитированному на все 100%. В этой теме я описал, фактически, такую же ситуацию с AT90PWM3. Обнаружено 3 схемотехнических глюка в кристалле, никак не отраженных в errata. Запрос на Atmel не дал никаких ответов, после чего был тихо закрыт. Он слишком много знал... или слишком много ответил... Потому и РАБОТАЛ

За основу макета была взята типовая схема ATAVRMC100, так что емкость на AREF та же - 100nF. По питанию стоит как керамика, так и электролиты. Всё достаточно близко от ног. Какая же это должна быть емкость, чтобы ТАК просадить питание :) На самом деле мне просто лень искать конкретную схему и вообще обсуждать это дело. Будет намного проще, если кто-то попрбует повторить названное и скажет - есть эффект или нет. Мне это интересно исключительно с точки зрения общего развития, но кому-то, может, поможет.

Поскольку запрос закрыт, то в закрытие моей темы привожу его полное содержание. Я так и не понял, откуда в моем запросе появились чужие вопросы, не относящиеся к теме. Спрашивать Атмел мне просто не хочется, ибо, толку мало. Кому надо - может, получится присоединиться к этому обсуждению чужого support request'а :-) Ticket 90551: "AT90PWM3 revisions and features" Исходный вопрос: Далее следует почти бесполезный ответ, на который я тут и написал в свое время, что ждем-с... Тут я уточнил, чем я пользовался и что наблюдал: И тут откуда ни возьмись, какие-то посторонние вопросы: Далее идет ответ на чужой вопрос... И какое-то уточниение с какой-то левой цитатой: Все. Запрос открыт 8 сентября 2006 года. Текущий статус - Closed. Финал. Занавес. :cheers:

Что интересно, в этом списке никак не отражены те проблемы, которые лично я наблюдал. И никто, кстати, даже те, у кого всё, как бы, работает, не подтверил и не опроверг мои наблюдения. А тихое закрытие support request на Атмеле говорит лично мне о том, что они так и не решились официально признать имеющиеся проблемы, как минимум, в версии без буквы.

Да я, вроде бы, достаточно ясно написал своё субъективное мнение. Оно состоит в том, что первая версия чипа, которая мне досталась, на мой взгляд совершенно непригодна для работы. Мне лично не удалось заставить в ней работать АЦП в режиме дифференциального входа, а при использовании BOD и определенного референса для АЦП включение последнего приводит к сбросу сразу после команды включения. Это не считая еще замеченных неточностей типа инверсии значений фьюзов. В предположении, что это я что-то не так делаю, я задал вопрос сюда и на Atmel. Последний ничего вразумительного не ответил и впоследствии тихо закрыл support request. Что мне ответили тут - можно почитать. Начиная от того, что у меня кривые руки, и заканчивая тем, как можно лихо исправлять программно аппаратные ошибки в чипе. Но ни слова по теме заданных вопросов. В связи с этим я принял для себя два решения: 1) Не использовать AT90PWM3 в своих девайсах. По работе мне это не требуется, а для своих целей я нашел другой выход, о чём уже писал. Косвенно в пользу этого же решения говорит тот факт, что я до сих пор не вижу ни аппноутов Atmel по нужной мне теме, кстати, ими же и обещанных, ни сторонних разработок на этом чипе. 2) Не обсуждать больше эту и подобные темы на публичных форумах. Не вижу смысла. То, что очевидно - я вижу и сам. А как только вопрос выходит чуть в сторону элементарных "у меня не считает счетчик" - полезный ответ получить, как правило, не удается, и всё равно приходится доходить до всего самостоятельно. Так стоит ли тратить время на пустую переписку? Пробовать очередную версию (следующий ревижн) чипа я не стал - у меня есть занятия и поинтереснее. Если кто-то напишет что-то полезное - с удовольствием прочитаю, но пока что читать нечего. Вот такой итог этой темы лично для меня. Может, Вам повезет больше.

Я всего лишь привел пример того, что необоснованное отклонение от принятой в большинстве других популярных процессоров логики способно привести к применению "правила" по привычке, когда делаешь порт некоей системы под множество различных процессоров одновременно. Названная OS существует для процессоров от AVR до ARM7 и Blackfin, и не удивительно, что можно допустить механическую ошибку при внесении изменений в несколько портов параллельно. В этом контексте процитированное высказывание выглядит просто неуважительно к человеку, будучи высказанным при незнании деталей ситуации. Я лично такое себе не позволяю. А Вы читать умеете? Я разве говорил о сложности? Я говорил о том, что механизм работы со стеком имеет существенное значение при работе с его указателем явно, а не посредством push/pop. Я не утверждал, что это как-то осложняет написание чего-либо. Я просто указал, что это вовсе не безразлично. Все с чем-то соглашаются. Осталось еще определиться, с чем именно :) Про ошибки повторяться не буду - уже было сказано. Неужели я где-то высказался за то, что нужно тащить принятую архитектуру все время только из соображений совместимости? Если говорить "в общем", то совместимость можно нарушить в тех случаях, если это дает реальный прогресс хоть в чем-то. В данном же конкретном случае я этого не вижу вообще. Я не вижу никакой логики в приведенном высказывании. Во первых, стек не обязан находиться в конце памяти до RAMEND, и выражение SP+1 может иметь физический смысл. Во вторых, никого из программистов не смущает конструкция языка C *p++ при работе с массивом в цикле. При последней итерации значение указателя точно также выходит за пределы блока памяти, выделенного массиву, и не гарантируется физическое существование чего-либо за пределами этого блока. Что при этом не мешает использовать эту конструкцию программистам, ибо, пока мы не применяем операцию разименования к полученному p, проблем не будет. В третьих, ситуация с постдекрементной схемой ничуть не лучше в плане "дополнительного риска в программах". Если область стека находится с нуля, то при постдекрементной схеме мы вообще вылезем на адрес -1 после заполнения нулевой ячейки. Чем это лучше или безопаснее преддекрементной схемы - я лично не понимаю. Итого, выходит, что изменив "стандартную de-facto" логику, мы не получаем никаких видимых плюсов. Зато получаем в пределах одного процессора две различных системы организации стеков (SP и X/Y/Z), да еще и в пределах единого адресного пространства. Вот тут я вообще не вижу никакой внешней логики (про возможные внутренние оптимизации я говорил исходно, но это знают только разработчики архитектуры). В целом, не имея желания кому-то что-то доказывать, я, тем не менее, свои соображения всегда аргументирую. Было бы интересно услышать конструктивную критику с фактами по пунктам, приведенным мною. Пока же я так и не увидел того, что положительного было внесено имплементацией двух схем работы со стеком в AVR. Ваши высказывания, уважаемые собеседники, пока лично меня не убедили в прогрессивности этого шага (что я аргументировал по пунктам). Потому пока остаюсь при своем мнении.

Писателям RTOSов должно быть грубоко фиолетово как работает стек. Главное что работает. Вероятно, Вам не доводилось писать участки переключения контекста, когда стеки процессов различны, и их нужно подменять. И ошибка по этой причине в неофициальной альфа-версии scmRTOS вылезла у меня очень даже быстро. Но это была неофициальная промежуточная версия, потому наружу она не вышла. Нет, я, конечно, согласен, что сделать можно под любую схему. Но см. ниже. Точно, молодцы - это чтобы разработчики компиляторов (типа gcc) не скучали :). Куча разных схем в одном процессоре для разных стеков - это, наверное, очень весело :). Имел в этом плане интересную беседу с Harry Zhurov'вым (автором вышеупомянутой RTOS), но переписка была личная, так что цитировать не имею полномочий.

В большинстве архитектур, с которыми мне приходилось сталкиваться, действительно используется предекрементная схема (в классической системе команд PDP-11 применяемая как MOV R1, -(SP) для push, MOV (SP)+, R1 для pop. AVR в этом плане действительно извращенно реализован. Видимо, к тому были какие-то аппаратные предпосылки. Например, проще поместить в память по адресу указателя байт, а потом параллельно с выборкой следующей инструкции уже декрементировать указатель стека. Но это только версия, а на деле имеем то, что имеем - такой подарок писателям RTOS-ов под AVR :-)

Вопрос тут в том, что не всегда проще. Дело в том, что изменение длины одного дескриптора влияет на содержимое многих других. Я это делал, потому представляю, о чем говорю. А казалось, так просто подменить только HID в моем случае, но увы... Естественно, что если вопрос только о замене VID/PID, то тут все проще на порядок. И, тем не менее, я бы, наверное, держал в EEPROM не дескрипторы, а только VID/PID, пусть даже ценой усложнения процедуры usbFunctionDescriptor(). Просто на случай, если EEPROM слетит. Обнаруженное новое устройство с FFFF/FFFF - это, наверное, более приятный исход, чем зависший девайс или вся система О последнем: некорректное содержимое передаваемого дескприптора однажды систематически вырубало мне XP на голубой экран, пока я понял, в чем дело (кто бы сомневался теперь, что парсер писали мелкомягкие). Так что я бы дважды подумал, где размещать дескрипторы, и хотя бы защитил их контрольной суммой для проверки перед отдачей. Прения - это не значит "разругаться". Просто на специфический стиль общения с одной стороны накладывается подобный с другой. Но это не означает, что общаться больше не следует. Я слежу, в т.ч., и за этой темой и все в ней читаю. Самому мне она не сильно актуальна (я до сих пор пользую COM-овский программатор - его мне хватает, а в моем ноуте есть COM порт). Но с удовольствием готов подкидывать какие-то идеи, если вижу в них потенциальную пользу. А никаких обид на самом деле нет!

Еще раз повторю, что по моему мнению в такого рода устройстве делать переменные дескрипторы я лично смысла не вижу. Смысл может быть только один - если сделать программное переключение режимов устройства. Скажем, в одном режиме программатор, а в другом - конвертор последовательного порта, видимый на другом последовательном порту (COMn). Нажал кнопочку - режим сменился, комы поменялись и лампочки на программаторе по другому засветились. Насчет серийных номеров - я, наверное, что-то смешное сказал (судя по :)), но смысл на самом деле в том, что если устройство имеет идентичные дескрипторы, но разные серийные номера, то это позволяет Windows однозначно идентифицировать устройства и различать их. Имея тот же набор дескрипторов, но разные серийники (которые однозначно проще заменить, чем менять HID дескрипторы, к примеру), можно настроить независимо номер COM порта для программатора и номер второго COM порта для отладки. Тогда терминал и программатор не будут ругаться по поводу того, что их порт уже кем-то занят.

Не думаю, что дескриптор - это то, что следует загонять в EEPROM. Туда лучше уж тогда серийный номер загонять. Но возможность такая есть в текущей версии драйвера - там можно вообще формировать все дескрипторы на лету. Правда, если такая задача ставится для HID Report, то придется на лету также формировать и кое-что другое (да почти всё), поскольку там прописана длина HID Report дескриптора. Я такое реализовал (в том числе, переменные VID/PID/HID в одном и том же девайсе, видимом как разные), но не могу сказать, что это было прозрачно - пришлось перепахать половину дефолтовых таблиц. Если разговор про вариант для AVR, то скорость в аппаратном порту можно поставить любую. Реально лимитирует не скорость порта, а скорость USB драйвера в low speed device. А если не про AVR, то CP2102 вполне выполняет свои функции. Я пользуюсь таким шнуром для всего подряд - от подключения КПК и телефонов до отладки и перешивки AVR-ов.