К изделию с Xmegа нужно подключить touchscreen c USB интерфейсом.
Что посоветуете?

Это готовая штука, где к ХМеге (ATxmega128A1) уже подключен touchscreen и USB-интерфейс:

Mikromedia for XMEGA

http://www.google.ru/url?url=http://www.mi...kromedia/xmega/
http://www.google.ru/url?url=http://www.mi...anual_v111b.pdf
http://www.youtube.com/watch?v=7GvxdQDbOjU

Но если фраза "подключить touchscreen c USB интерфейсом" означает, что это touchscreen имеет USB-интерфейс, и его надо подключить к ХМеге по USB-кабелю, как девайс, то с этим делом будет туго, т.к. ХМеги как хост не работают.

Если есть острая необходимость использования именно USB (очень острая !!!), то поищите МК, имеющий на борту USB - хост, запаситесь терпением и временем (с нуля - от полугода и больше) и много чем еще, и - в путь.
А если такой необходимости нет, то используйте touchscreen с более простым интерфейсом, как это сделано, например, в ноутбуках ...

Между USB-тачскрином и xmeg-ой можно поставить такой девайс: http://www.ftdichip.com/Products/ICs/VNC2.htm .
Возможно, при этом можно обойтись даже без xmeg-и. Юридическая чистота гарантирована

Подключить нужно внешнее устройство с USB LS device.
Сейчас нужен тач , позже еще что нибудь ... )
На борту разъём на котором питание 5V и uart.
Нужно на маленькой платке сделать преобразователь USBHOST->UART.
Включить её в разрыв 4-х проводного кабеля и в термоусадку.
Если использовать Vinculum то все равно придётся какой-то доп. проц ставить для Vinculum->UART.
А нет ли на мегах программных эмуляторов USBHOST?
Device же есть...

Чем рассчитывать на Vinculum, лучше повеситься . Там уникальная архитектура - 32 бит, но не ARM. Пуд соли надо съесть, пока его освоишь. И дорог - на эти деньги 4 Хмеги можно купить.

Наиболее простое решение - демоплата ATAVRXPLAIN, которую сам Atmel делает, завлекая разработчиков. Вот ее описание: http://www.atmel.com/pt/br/Images/doc8203.pdf
В составе демоплаты два МК - ATxmega128A1 и AT90USB1287, причем второй используется в качестве USB-конвертора. Последний можно перепрограммировать на HOST, поскольку он этот режим поддерживает.

Кроме того, оба МК архитектектуры AVR, а потому не так уж сложно написать программу для второго, если умеешь это делать для первого.

Похоже это как раз то что мне нужно!
Спасибо.

Не обязательно AT90USB1287, можно взять более дешевый AT90USB647. Но никак не AT90USB162, т.к. последний HOST-режим не поддерживает.

И еще. Когда дело доходит до управления дисплеями, то вариант с двумя МК, один из которых работает в роли графического контроллера, весьма привлекателен тем, что последний может буферизировать задание, избавляя основной МК от ожидания или выдерживания таймаутов. В этом случае AT90USB647/1287 использует свою память в качестве буфера, безусловно принимая присылаемые байты в нее, а уже оттуда пересылает по USB-каналу дисплею.

В этой связи вспомининается интересная тема на нашем на форуме, посвященная эмуляции игровой приставки Spеctrum (ретро) на двух ATmega128. Причем, первая играла, а вторая была при ней графическим контроллером. Это решение было вынужденным, т.к. один МК не справился бы с этой задачей, даже если бы это была Хмега.

В цену Vinculum входят лицензионные отчисления.
Проблема не только техническая, но и юридическая. Или при переходе на AT90USB1287 лицензионные проблемы снимаются?
Одно дело - клепать что-то для себя, другое - на продажу, и совсем третье - на продажу за рубеж.

AT90USB1287 от $8 и до ... что не очень то и дёшево (

Вот бы на XMEGA_E5 эмулятор Host написать Low Speed.

И что вы за эту E5 зацепились? Она ведь глючная! Или были какие-то соображения на этот счет?

Я не юзал Е5. А че глючная?
Просто корпус QFN32 понравился.

Я тоже ее не юзала, но от того, что пишут про нее на форуме AVR freaks, просто мурашки по коже.

Программный ? Хорошо все равно не выйдет. Почему сразу не взять МК с аппаратным хостом ? Программный Device и то запредельно сложен, а тут - хост ...

Конечно не полноценный HOST.
А если специально "узко заточенный" HOST под один единственный тип девайсов.
С другими пусть просто не работает.
Может вообще на уровне посылки заранее сформированных блоков полученных сниффером.
Такое возможно?

Думаю, нет (в том смысле, что хост, точно повторяющий захваченные сниффером посылки, работать не будет). Если нельзя применить МК с хостом, можно поискать ИС аппаратного хоста, хоть это и экзотика. Например, у NXP:
http://www.nxp.com/products/interface_and_...llers/#products

Еще у них была хорошая ИС хоста - ISP1160. Правда, не знаю, производится ли она сейчас.

Мой вам совет - ищите МК с настоящим хостом и готовыми примерами к его использованию. Это один путь. Причем вполне реальный. Второй путь - покупайте любую подходящую отладочную плату с соотв. МК и предустановленным Линуксом, там уже весь "нижний" уровень должен быть реализован. Все эти программные хосты - курам на смех. Не будет оно работать, как положено, только время зря потеряете ...

подключение USB мыши к atmega32: https://courses.cit.cornell.edu/ee476/Final...36_cdl28_dct23/
так что вполне возможно, особенно если физический уровень от V-USB взять,

zombi, может быть не сейчас, но в будущем, вам и мне (как поклонникам ATxmega) стоит обратить внимание на SAM D21 от того же Atmel'а, хотя формально он ARM (Cortex M0+), а не AVR. В отличие от прочих ARM'ов, выпускаемых Atmel, он страшно похож на ... Xmega'у! Т.е. не только практически та же самая периферия, но и биты признаков, управляещих ею, зачастую на одних и тех же местах и одинаково называются. А когда видишь отрывок программы для него по управлению с периферией, то создается полнейшее впечатление, что это программа для Xmega.

Я бы его назвала пост-Хмегой, отличающейся от Хмеги только заменой инструкций с AVR на Cortex M0+. Однако на С/С++ это различие почти незаметно. А таймеры, ADC, DAC, DMA и даже система событий EVSYS скопирована с Хмеги чуть ли не 1 в 1.

К тому же он обещает быть дешевым (позиционируют для детских электронных игрушек), и уже Arduino Zero на нем сделали. Да и HOST-режим он тоже в полной мере поддерживает аппаратно. И в корпусах 32-pin TQFP и QFN тоже выпускается (наряду с 48-pin и 64-pin).

А я на С и не пишу, только asm.

Но уже нутром чую что в связи с необходимостью использовать USB придётся таки осваивать и С



Ага... значит всё таки можно!
Но Си опять же ...

Как раз ради USB это необязательно. Логика USB трудно постигаема , но в программном отношении сводится к записи констант в ряд регистров и побайтовой передаче заранее сформированных структур с данными (спецификаций) через один из таких регистров (подобно передаче UART). Никакой работы, для которой бы остро потребовался язык высокого уровня, в этой задаче нет.

Конечно, сказанное относится к аппаратно реализованным USB-функциям, а про V-USB я ничего сказать не могу, т.к. никогда им не пользовалась.

P.S. Использовать язык С, когда уже знаешь ассемблер, проще простого, т.к. на этом пути есть вполне однозначные соответствия, позволяющие "переводить подстрочно". Болезненная ломка возникает только при переходе от C к C++, когда очень сильно хочется всё бросить и вернуться на ассемблер .