[KA_ru 0]

EWAVR,

 

если есть возможность, прошу проверить работоспособность экспериментальной версии порта USBDRV на аппаратном tiny контроллере (tiny26, 90s2313 или т.п.). Ссылка на порт в PM. Это приватный билд, его нет смысла хранить (тем более, в нем есть кое-что неучтенное). Если будет все нормально, то будет официальная версия с поддержкой tiny.

 

У меня оно работает и в small, и в tiny на ATmega32 (код отличается на 101 байт на очень малой программе), но на маленьких контроллерах не тестировал.

 

Особенности: необходимость определения регистров работы с прерываниями для разных контроллеров (см. файл usbconfig-prototype.h в конце). К сожалению, #ifdef в IAR не работает для SFR, потому придется явно задать нужные регистры. Что можно задать - можно посмотреть в коде usbdrv.h, где возможность определения уже учтена.

 

Просьба не распространять эту версию - если с ней проблем не будет, то на следующей неделе будет официальная на сайте.

 

Прошу сообщить результат по мере возможности, или если такой возможности нет - то тоже сообщить, чтобы передать автору.

 

Добрый день.

 

возможно ли получить AVR-USB порт(Proj) for IAR

распространять не собираюсь.

мне для сына. как учебное пособие.

чтоб мог с чем сравнивать.

заранее спасибо.

я его уже STK500 снарядил.

самому интересно что у него выйдем.

утонет или сможет плавать.

 

Андрей.

 

[email protected]

[lazycamel 0]

Никто не пробовал в ИАРовском порте в usbdrv.c заменить цепочку If-else на стандартный case ? Насколько я понял - это было сделано из-за того что GCC case всегда как "int" обрабатывает, но ИАР case"ы весьма эффективно раскручивает.

[osnwt 0]

возможно ли получить AVR-USB порт(Proj) for IAR

распространять не собираюсь.

Я писал про экспериментальную версию до ее официального появления. Сейчас она уже не актуальна, так как все предложенное вошло в состав официальной. Получить ее можно непосредственно с сайта автора obdev.at - там в проекте PowerSwitch всегда присутствует самая свежая версия драйвера.

 

В новой версии от 26.03 добавлена (исправлена) поддержка tiny модели памяти для IAR, добавлены опции для выбора регистров, связанных с используемым прерыванием без изменения кода драйвера, а также исправлено размещение вектора прерывания через COMMON INTVEC вместо ASEG (все доработки - с подачи EWAVR, за что ему спасибо).

 

Обращаю внимание, что в варианте с ASEG (предыдущая версия) обнаружилась серьезная проблема с размещением векторов при использовании дополнительных прерываний - вся таблица "съезжала". Потому настоятельно рекомендуется обновиться до текущей версии.

 

Насчет замены if на switch: вероятнее всего, это вполне возможно. Есть еще ряд мест, где можно было бы сэкономить. Я верю, что можно минимизировать размер кода драйвера до степени GCC, если не более. Но этим нужно заниматься. Для себя это сделать можно, но знаю точно, что особая оптимизация размера кода для IAR автора не беспокоит, и официальных изменений в этом направлении ждать почти бесполезно. Он вообще недоумевает, почему наши люди не используют бесплатный компилятор gcc...

 

Если же задаться целью существенно оптимизировать код драйвера, то самое оптимальное - это просто переписать часть C на ассемблер. Тогда бы можно было уложиться килобайта в 1.1-1.2, я думаю. Это было бы совсем хорошо, но я лично не готов этим заниматься. Тем более, что потом возникнет вопрос поддержки и обновления при внесении изменений в оригинал.

Изменено 29 марта, 2006 пользователем osnwt

[733259 0]

Насколько я понял - это было сделано из-за того что GCC case всегда как "int" обрабатывает, но ИАР case"ы весьма эффективно раскручивает.

 

Так было в gcc 3 версии, 4.0.3 у меня case нормально обрабатывает.

 

Он вообще недоумевает, почему наши люди не используют бесплатный компилятор gcc...

 

Аналогично, тоже недомеваю.

Изменено 29 марта, 2006 пользователем 733259

[osnwt 0]

Так было в gcc 3 версии, 4.0.3 у меня case нормально обрабатывает

Там написано, что версия драйвера оптимизимрована под gcc 3. Последующие могут быть оптимизированы под 4.

 

А насчет использования IAR я уже писал: код лоадера от Atmel компилируется в 1400 байтов под gcc 3 (4 не проверял), и в 1000-1050 - под IAR. Для ATmega128 не критично, для 2313 или т.п. - очень даже. Да и привычка русского человека....

[aleksey_gregul 0]

EWAVR, опять глюки zero sized reply :(

PM получил?

[aleksey_gregul 0]

TestPowerswitch.rarВсе! Сделал управление Powerswitch_ем из-под Дельфи через USBIO от http://www.thesycon.de :)

Осталось найти свежую не демо версию драйвера.

Ато дает поработать только 4 часа :(

[lazycamel 0]

TestPowerswitch.rarВсе! Сделал управление Powerswitch_ем из-под Дельфи через USBIO от http://www.thesycon.de :)

Осталось найти свежую не демо версию драйвера.

Ато дает поработать только 4 часа :(

 

НАФИГА ? Чем тебя LibUSB-win32 не устроила ? Халявная кстати.

[aleksey_gregul 0]

НАФИГА ? Чем тебя LibUSB-win32 не устроила ? Халявная кстати.

 

Тут ключевое слово - Дельфи.

Ну тяжел для меня С. А по поводу LibUSB-win32, так Паскаль с ним работать не будет!

Так сказали разработчики.http://libusb-win32 .sourceforge.net

Правда, здесь мне подсказали лежит одно извращение, чтобы заставить работать под

Паскалем именно LibUSB, но оно оказалось не рабочим.http://www.xs4all.nl/~ynlmns/

Может дело в версиях драйверов?, не знаю.

Просто хочется использовать более знакомый инструментарий.

Если под силу, выясните причину неработоспособности. Там acces violation под дебагом.

Да, Lazycamel, не вы ли где-то здесь говорили, что адаптировали USB Игоря Ческо под С да еще

на меге48-24? Сможете USBDRV от http://www.obdev.at/products/avrusb/index.html

переписать на мегу48-24 для ИАР_а? 24MHZ подкупает!

[aleksey_gregul 0]

:santa2:

Закончил управление Powerswitch_em на Дельфи.

http://www.obdev.at/products/avrusb/powerswitch.html

Для любителей. Может кому-то будет в пользу.

Реализовано все, что может авторский commandline.с

Необходим драйвер USBIO http://www.thesycon.de

Там в комплекте инсталятор драйвера на usb-устройства.

Исходники и откомпилированный проект.

DELPHI5.

Проверено на WINXPSP1_RUS

Из багов: Иногда долго закрывается. Причин не знаю. Может из-за демовости драйвера?

 

DELPHI_SOURCE.zip

exefile.zip

[lazycamel 0]

Да, Lazycamel, не вы ли где-то здесь говорили, что адаптировали USB Игоря Ческо под С да еще

на меге48-24? Сможете USBDRV от http://www.obdev.at/products/avrusb/index.html

переписать на мегу48-24 для ИАР_а? 24MHZ подкупает!

 

Было дело, но по сравнению с Objective Development мой вариант выглядит поделкой студента первокурсника :-( Я по их коду теперь практически учусь правильному написанию исходника с прицелом на кастомизацию да пытаюсь безуспешно счаз въехать в ИАР-совместимость.

 

А по поводу 24 Мгц есть две заковыки.

1) Атмел понизил скорость Мег до 20МГц. Слишком много они жрут в 24 Мгц режиме и с флешем что-то не то на такой частоте проиходило.

2) по результатам профилирования - выигрыша по сути в движке нет, только уровень приложения ускоряется.

 

Я по поводу драйвера, я давно уже всем советую - делайте обычное HID устройство только с 0 конечной точкой и 8 байтным фьючерепортом. В результате получаете бесплатный враппер в тоже самое стандартными драйверами виндоуз, начиная с 2000. И операции ReadFile/WriteFile.

[osnwt 0]

Я по их коду теперь практически учусь правильному написанию исходника с прицелом на кастомизацию да пытаюсь безуспешно счаз въехать в ИАР-совместимость.

По поводу IAR-совместимости готов ответить на конкретные вопросы, поскольку это - моих рук дело. Правда, мои мысли и патчи Кристиан выразил просто блестяще, переписав это в своем стиле.

 

2) по результатам профилирования - выигрыша по сути в движке нет, только уровень приложения ускоряется.

Есть возможность спросить автора, не получится ли при этом добавить проверку CRC "на лету". Как известно, сейчас этого не делается при приеме вообще. Хотя, если официально 24 MHz версий уже нет, то заниматься этим он не станет.

 

Я по поводу драйвера, я давно уже всем советую - делайте обычное HID устройство только с 0 конечной точкой и 8 байтным фьючерепортом. В результате получаете бесплатный враппер в тоже самое стандартными драйверами виндоуз, начиная с 2000. И операции ReadFile/WriteFile.

Есть информация, что HID без Interrupt In работает не со всеми Windows (а с ней работает, в том числе, с Win98SE). Причем, можно не реализовывать код для обработки этой самой точки (не описывать INPUT в Report Descriptor). Дотаточно того, что она просто есть. А обмен информацией организовывать через Feature Reports (фиче, кстати, а не фьюче). Только с ним ReadFile/WriteFile не работают - это для Input/Output. Для работы с Feature используются API функции GetFeature/SetFeature.

[lazycamel 0]

Я по их коду теперь практически учусь правильному написанию исходника с прицелом на кастомизацию да пытаюсь безуспешно счаз въехать в ИАР-совместимость.

По поводу IAR-совместимости готов ответить на конкретные вопросы, поскольку это - моих рук дело. Правда, мои мысли и патчи Кристиан выразил просто блестяще, переписав это в своем стиле.

 

Ок, спасибо.

 

2) по результатам профилирования - выигрыша по сути в движке нет, только уровень приложения ускоряется.

Есть возможность спросить автора, не получится ли при этом добавить проверку CRC "на лету". Как известно, сейчас этого не делается при приеме вообще. Хотя, если официально 24 MHz версий уже нет, то заниматься этим он не станет.

 

Там в том то и проблема, что в месте где в движке лимитирована производителность сейчаз свободно толи 5 толи 8 тактов, при переводе на 24 высвободиться еше порядка 40. В эти полсотню тактов CRC все равно не впихнуть ИМХО. Т.е. получается что вроде и есть ресурсы, но ни для чего серьезного их просто не хватает.

 

Я по поводу драйвера, я давно уже всем советую - делайте обычное HID устройство только с 0 конечной точкой и 8 байтным фьючерепортом. В результате получаете бесплатный враппер в тоже самое стандартными драйверами виндоуз, начиная с 2000. И операции ReadFile/WriteFile.

Есть информация, что HID без Interrupt In работает не со всеми Windows (а с ней работает, в том числе, с Win98SE). Причем, можно не реализовывать код для обработки этой самой точки (не описывать INPUT в Report Descriptor). Дотаточно того, что она просто есть. А обмен информацией организовывать через Feature Reports (фиче, кстати, а не фьюче). Только с ним ReadFile/WriteFile не работают - это для Input/Output. Для работы с Feature используются API функции GetFeature/SetFeature.

 

Ну не будем к словам придираться. :-)

Тем не менее Features Report только с Win XP начали читаться через HidD_GetFeature/HidD_SetFeature, а до этого использовался обычный Read/Write.

[osnwt 0]

Есть возможность спросить автора, не получится ли при этом добавить проверку CRC "на лету". Как известно, сейчас этого не делается при приеме вообще. Хотя, если официально 24 MHz версий уже нет, то заниматься этим он не станет.

 

Там в том то и проблема, что в месте где в движке лимитирована производителность сейчаз свободно толи 5 толи 8 тактов, при переводе на 24 высвободиться еше порядка 40. В эти полсотню тактов CRC все равно не впихнуть ИМХО. Т.е. получается что вроде и есть ресурсы, но ни для чего серьезного их просто не хватает.

Ответ неверный.

 

Рекомендую почитать замечательную статью на сайте автора avr-usb о том, как оптимизировался код.

 

В двух словах: код avr-usb от obdev писался с нуля, а не по мотивам других ассемблерных реализаций. Его особенностью является то, что весь прием usb пакетов выполняется в реальном времени, в том числе, bit stuffing, - в отличие от ассемблерного драйвера, сначала принимающего, а потом декодирующего. Этим выигрывается как время, так и объем.

 

Нетрудно подсчитать (что и сделано в той статье), что при скорости low-speed девайса 1.5MBit и тактовой контроллера 12MHz мы получаем 8 машинных циклов на принимаемый бит, которыми нужно распорядиться и для манипуляций битами, и для продвижения указателя, и для подсчета принятого количества бит. И ровно 8 циклов использовано в алгоритме. Как к этому шел автор - тоже приведено в статье на уровне исходного кода с комментариями. Отсюда намного лучшая производительность этого драйвера, его предсказуемость и документированность.

 

Удвоение тактовой добавит всего 8 (свободных) тактов, совсем не 40. Хватит ли их на CRC calculation - надо смотреть. Но это уже другой вопрос.

 

Тем не менее Features Report только с Win XP начали читаться через HidD_GetFeature/HidD_SetFeature, а до этого использовался обычный Read/Write.

Факт, взятый с широкоизвестного HID FAQ, подтверждаемого также MSDN. Цитата:

 

How can an application send a report using a control transfer?

 

Under Windows 98 Gold (original version), WriteFile sends Output reports using control transfers with Set_Report requests. Under later Windows editions, WriteFile uses control transfers if the HID interface doesn't have an interrupt OUT endpoint. Otherwise, WriteFile uses interrupt transfers for Output reports. Beginning with Windows XP, you can use HidD_SetInputReport to send an Output report with a control transfer and a Set_Report request. Under all Windows editions, HidD_SetFeature sends a Feature report using a control transfer with a Set_Report request.

Похоже, в ранее приведенном Вашем утверждении были перепутаны Feature и Output reports. Такая совместимость для Feature, кстати, очень удобна для всяких загрузчиков и т.п. дел.

Изменено 13 апреля, 2006 пользователем osnwt

[lazycamel 0]

Ответ неверный.

Рекомендую почитать замечательную статью на сайте автора avr-usb о том, как оптимизировался код.

 

В двух словах: код avr-usb от obdev писался с нуля, а не по мотивам других ассемблерных реализаций. Его особенностью является то, что весь прием usb пакетов выполняется в реальном времени, в том числе, bit stuffing, - в отличие от ассемблерного драйвера, сначала принимающего, а потом декодирующего. Этим выигрывается как время, так и объем.

 

Ась ? У нас по-моему некоторое взаимонепонимание. Я говорю про ту часть которая разбирает адрес и формат пакета (от метки se0) , а не про SIE (получение последовательности битов) и превращение их в байты.

 

 

Похоже, в ранее приведенном Вашем утверждении были перепутаны Feature и Output reports. Такая совместимость для Feature, кстати, очень удобна для всяких загрузчиков и т.п. дел.

 

Крайне на это похоже. Точнее я попутал вот с этим:

 

"HidD_GetFeature requests a Feature report using a control transfer with a Get_Report request. Beginning with Windows XP, you can use HidD_GetInputReport to request an Input report with a control transfer and a Get_Report request."

 

Чтож и на старуху бывает проруха. Спасибо.

Изменено 13 апреля, 2006 пользователем lazycamel