[add 0]

ADD а в ПИКАДЕ 2002 она открывается??? я просто еще не пробывал... если нет то можно выложить под 2002 конвертерную плиз

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

[ahulap 0]

Хм... А чем пустой цикл отличается от ожидания флага таймера? Объясните не разумному :)

Пустой цикл - N-ое количество тактов + все прерывания, которые возникли во время этого цикла.

А таймер идет автономно, ничто его не прерывает и максимальная погрешность (задержка) такой паузы гораздо меньше. У себя я сделал паузу примерно как в USBasp'е:

void delay10ms(void)

{

uchar startTime = TCNT0;

while ( (uchar)(TCNT0 - startTime) < 118 ) ; /* prescaler = 1024 */

}

[prottoss 0]

Пустой цикл - N-ое количество тактов + все прерывания, которые возникли во время этого цикла.

А таймер идет автономно, ничто его не прерывает и максимальная погрешность (задержка) такой паузы гораздо меньше. У себя я сделал паузу примерно как в USBasp'е:

void delay10ms(void)

{

uchar startTime = TCNT0;

while ( (uchar)(TCNT0 - startTime) < 118 ) ; /* prescaler = 1024 */

}

В USB драйвере от http://obdev.at это не принципиально ИМХО, пустые циклы могут быть хоть годовалой длительности.

[ahulap 0]

В самом драйвере - да, о вот в компьютере - принципиально. Для передачи задается тайм-аут, за который устройство должно ответить ACKом. Например, в usb_control_msg (если пользоваться libusb) этот тайм-аут идет последним параметром. У меня 10мс цикл при подключении через хаб растягивался прерываниями примерно до 30-50мс, что в некоторых случаях приводило к исходу тайм-аута.

А какие тайм-ауты установлены для стандартного CDC-класса, честно говоря, даже не знаю...

[prottoss 0]

В самом драйвере - да, о вот в компьютере - принципиально. Для передачи задается тайм-аут, за который устройство должно ответить ACKом. Например, в usb_control_msg (если пользоваться libusb) этот тайм-аут идет последним параметром. У меня 10мс цикл при подключении через хаб растягивался прерываниями примерно до 30-50мс, что в некоторых случаях приводило к исходу тайм-аута.

А какие тайм-ауты установлены для стандартного CDC-класса, честно говоря, даже не знаю...

В USB - как типе устройств есть свои тайминги, определенные спецификацией на USB, в классах устройств USB своих специфических таймингов нет. Но, так как многие USB устройства являются эмуляцией других типов устройств для "старых" программ, соответственно они должны соблюдать тайминги тех устройств, которые они эмулируют. Скорее всего это и происходит при работе программатора через ХАБ - он добавляет задержки - в итоге программа вылетает по таймауту коммуникационного порта. То, что Вам удалось преодолеть на нескольких (или на одной???) машинах проблему, не решает ее в целом - у многих это, скорее всего не сработает. А разницы в методе отсчитывания программных задержек я абсолютно не вижу. Ибо к любой задержке нужно прибавлять 20 мс. Это время получается из спецификации USB- хост обращается к низкоскоростному устройству не чаще чем раз в 10 мс

[osnwt 0]

А разницы в методе отсчитывания программных задержек я абсолютно не вижу. Ибо к любой задержке нужно прибавлять 20 мс. Это время получается из спецификации USB- хост обращается к низкоскоростному устройству не чаще чем раз в 10 мс

Вынужден огорчить: разница есть и, увы, значительная.

 

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-й команды мы снова можем улетать в прерывание и сидеть там длительное время, а после выхода - еще и еще.

 

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

 

Потому выводы предлагаю сделать самостоятельно. Надеюсь, мое объяснение было полезным.

[prottoss 0]

3) Как документировано в описании, USB драйвер обрабатывает каждую low-speed транзакцию на шине USB, даже если она не относится к нашему устройству. Следствие: если на шине много низкоскоростных устройств (мыши и т.п., например), то в прерываниях мы будем находиться намного чаще, чем необходимо именно нашему устройству.

Это мне не понятно. Я не знаком со схемотехникой хабов, но я всегда считал, что хабы разделяют свои нисходящие порты. Т.е. по шине от хоста до хаба идут все транзакции, предназначенные функциям на различных устройствах, а от портов хаба только те, которые предназначенны тому устройству, которое подключенно к порту... Или я ошибаюсь? По Вашему получается, что я могу, в буквальном смысле, на один порт моего РС, параллельно линиям D+ и D- посадить несколько устройств и они будут более-менее нормально работать (опустим вопрос о буферизации и т.п.)??? Или, если посмотреть с другой стороны, на моем компьютере 8 портов USB, объединенных в 4 концентратора, означает ли это, что на обоих портах одного концентратора присутствуют одни и те же данные в любой момент времени???

 

 

 

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 против этого, поскольку оно не противоречит стандарту, и все хосты так себя ведут.

Тоже не совсем понятно. Ясно, что опрос идет относительно непрерывно. Но это не должно противоречить спецификации USB, в которой установлен мин. период обращений в 10 мс для низкоскоростных устройств. То бишь опрос утройства идет с периодом в 10 мс и не менее.

[osnwt 0]

Это мне не понятно. Я не знаком со схемотехникой хабов, но я всегда считал, что хабы разделяют свои нисходящие порты. Т.е. по шине от хоста до хаба идут все транзакции, предназначенные функциям на различных устройствах, а от портов хаба только те, которые предназначенны тому устройству, которое подключенно к порту... Или я ошибаюсь?

Я тоже не интересовался схемотехникой хабов, потому не могу ответить на этот вопрос однозначно. Однако, допускаю предположение, что USB хаб сходен функционально с простыми Ethernet хабами на витой паре. Последние, в отличие от switch'ей, дублируют на свои порты всё, что летит по шине, выполняя исключительно функции электрической развязки и согласования.

 

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

 

По Вашему получается, что я могу, в буквальном смысле, на один порт моего РС, параллельно линиям D+ и D- посадить несколько устройств и они будут более-менее нормально работать (опустим вопрос о буферизации и т.п.)??? Или, если посмотреть с другой стороны, на моем компьютере 8 портов USB, объединенных в 4 концентратора, означает ли это, что на обоих портах одного концентратора присутствуют одни и те же данные в любой момент времени???

Что касается наличия данных на всех портах, то я также этого не проверял. На работе есть аппаратный анализатор USB трафика, но с ним работаю не я. Если не забуду, то поинтересуюсь, как все же реализованы хабы. У нас есть люди, кто серьезно работает с USB, в том числе делает собственные хабы и устройства специального назначения.

 

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

 

The driver will consume CPU cycles for all USB messages, even if they address another (low-speed) device on the same bus.

 

Поскольку подключения нескольких устройств на одни провода не бывает (тогда бы никто не делал хабов вообще - делали разветвители из проводов), то приходится поверить, что данные дублируются.

 

Поэтому независимо от того, понимаем ли мы причину этого или нет (и хотим ли выяснять) - с этим приходится считаться.

 

Тоже не совсем понятно. Ясно, что опрос идет относительно непрерывно. Но это не должно противоречить спецификации USB, в которой установлен мин. период обращений в 10 мс для низкоскоростных устройств. То бишь опрос утройства идет с периодом в 10 мс и не менее.

Не могу прокомментировать, поскольку уверенности у меня нет (я не изучал этот вопрос лично, а высказывать свои предположения, ни на чем не основанные, не вижу резона). Я всего лишь обращаю внимание на то, что если 90% времени AVR занято обработкой прерываний, но очевидно, что он что-то да делает.

 

Версия: bukl endpoint - это не interrupt endpoint. Потому, вероятно, там свои особенности.

 

Потому, если говорить лично про меня, то создавая программу, использующую данный драйвер, особенно имея в виду проблемы bulk endpoints, я бы однозначно не использовал холостых циклов для каких-либо задержек, если там критично и максимальное время задержки, а не по принципу "не менее, чем". На это уже намекали несколькими сообщениями выше, но автору виднее. Кому надо - может сам поправить исходные тексты, не так ли (я их не правил и даже не смотрел, так что прошу по этому вопросу мне не писать ЛС).

 

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

 

Еще совет: сделать просто холостой цикл с известным периодом повторения, в котором просто менять состояние пина. Посмотреть на период изменения осциллографом при отключенном USB. После чего воткнуть в USB и сравнить, как изменится этот период в зависимости от количества прочих устройств на шине и даже без оного. С учетом 90% загрузки CPU период должен стать неравномерным и существенно увеличиться. Тогда все вопросы сразу отпадут.

[prottoss 0]

Лично:-) с хабами я не знаком НО:

 

 

 

*Хаб в любом случае состоит из контроллера и коммутатора-повторителя, возможно все это в едином корпусе.

 

*Хабу не нужно иметь мощный контроллер и много памяти - все транзакции по шине USB инициируются хостом, следовательно хабу не надо думать какой нисходящий порт подключить к хосту, это все можно делать аппаратно - так же как в микросхемах USB-функций. Коммутатор же имеет средства для обнаружения подключения устройства и определения его скорости.

 

*Из вышесказанного, с большой уверенностью, можно сделать вывод, что данные на портах не дублируются - да это и противоречит спецификации USB - на шине должно быть тихо в пределах времени, установленного для данного типа устройства.

[osnwt 0]

*Из вышесказанного, с большой уверенностью, можно сделать вывод, что данные на портах не дублируются - да это и противоречит спецификации USB - на шине должно быть тихо в пределах времени, установленного для данного типа устройства.

Я бы не говорил о "выводах с уверенностью" :) Вывод или можно сделать, или нет. Если же уверенность не 100%, то это не вывод, а предположение.

 

Я допускаю возможность того, что USB хаб фильтрует потоки данных устройств. Однако, это противоречит наблюдаемому и документированному свойству драйвера. Что делается на порту хаба - несложно посмотреть соответствующими аппаратными средствами. И я сказал, что уточню этот вопрос у реально знающих людей, если не закручусь.

 

И в конечном итоге я не горю желанием просто ради спора или желания разбираться в первопричинах эффекта зарываться в документы и проводить множество экспериментов. У меня просто нет времени на это. Я вижу, что у отдельно взятых людей есть проблема. Я вижу, что автор хочет им помочь, сделать, чтобы устройство работало на максимально возможном количестве компьютеров (то есть, максимально корректно, насколько это возможно). Потому я предложил простую последовательность действий, которую нужно сделать, чтобы увидеть, есть эффект аномальной задежки или нет (я про циклы). У меня нет ни одного CDC устройства на меге, чтобы проверить это самому (также см. выше про время).

 

В конечном итоге, цель этой темы - не дебри особенностей работы USB хабов, а стремление сделать устройство максимально универсальным. Я дал идею, а будет ее кто-то проверять или нет, - мне, в общем-то, всё равно :-)

[djmixi 0]

Уважаемый PROTTOSS! Я собрал все это дело все поставилось но очень расстроился когда увиел что при запуске AVRProg в графе Device нет моих любимых микрушечек ТИНИ13 и МЕГИ48.... как мне быть... или Ваш проект новые не будет поддерживать?

[prottoss 0]

Уважаемый PROTTOSS! Я собрал все это дело все поставилось но очень расстроился когда увиел что при запуске AVRProg в графе Device нет моих любимых микрушечек ТИНИ13 и МЕГИ48.... как мне быть... или Ваш проект новые не будет поддерживать?

Дело не моем программаторе. Дело в ПО, которое его поддерживает. AVRProg очень хорошая утилита, при том что она поддерживает быстрый обмен с программатором. Но идея по воле программистов из ATMEL, ИМХО, не очень хорошая - в программаторе таблица с условными кодами поддерживаемых кристаллов. Так, по идее не должно быть. Программатор должен быть чисто инструментом, а как им работать должно знать ПО на хост-компьютере. В данном же случае попытались взвалить много забот именно на программатор. В любом случае, программатором можно шить любые кристаллы AVR. Важно лишь, что бы ПО на компьютере умело с ним работать. К сожалению, кроме AVRProg, ни одна программа, мне известная, не посылает данные блоками в следствии чего с новыми кристаллами программатор работет медленно.

 

 

 

PS: витала в моей голове идея сделать USB-программатор, с чем нибудь совместимый, на полноценном USB-чипе ( например PDIUSBD12) + AVR, да пока нет времени поднять проект, да и не знаю, нужно ли это - счас разнообразных программаторов навалОм.

[Alfa 0]

Уважаемый PROTTOSS! Я собрал все это дело все поставилось но очень расстроился когда увиел что при запуске AVRProg в графе Device нет моих любимых микрушечек ТИНИ13 и МЕГИ48.... как мне быть... или Ваш проект новые не будет поддерживать?

 

 

прошить мою версию dopera (искать в этой теме) и наслаждаться

[djmixi 0]

ОЙ вообщем не пнял нифига!

Дак что получается АРГПРОГом низя мегу48 прогить тогда чем можно??? чтобы работать с мегой48 и тини 13??? в CODEVISIONE вроде кристаллы есть 48 и 13 НО там пишется ошщибка ID программатора...что дулать?

 

ALFA а что такое ваше версию прошить??? я скачал с сатй AVR-Doper.2007-03-29.tar.gz но внутри нет ХЕКСА а все под СИ как я понял... сам я на асме пишу в СИ не работаю... как понять прошить чем прошить?? дайте хекс!

Изменено 23 апреля, 2007 пользователем djmixi(Димка)

[GDI 0]

Ищите в этой ветке прикрепленный файл MyDoper.rar или MyDoper.hex и прошивайте этим хексом ваш программатор, только не забудьте после этого заменить драйвер на тот что есть у вас в архиве AVR-Doper.2007-03-29.tar.gz, т.е. установить *.inf файл от Допера. В итоге вы получите программатор STK-500который и нужно будет выбирать в настройках CodeVision. Я сравнивал эти 2 прошивки MyDoper и AVR910USB по скорости, у меня получилось, что hex-файл 12кб в мегу32 AVR910USB с AVRProg-ом с верификацией шьет 6-7сек, MyDoper с AVR Studio тот же файл с проверкой шьет 21сек, но AVR910USB с CodeVision-ом, т.е. без блочного режима шьет гораздо медленнее, в этот раз я экспериментов не проводил, но когда то пробовал - время измерялось минутами...