roboforum.ru

Есть проект - графические LCD на USB с AVR контроллером. Именно USB. Пропускная способность нужна минимум 200КБайт/сек. Программный USB для AVR выжимает 5-7КБайт/сек. Не подходит. Проект открытый и расчитан на любителей, т.е. сложность пайки элементов и их количество играют роли. Надо чтобы компоненты лет 5 были доступны.

Поискал различные решения.
Вот что нашел:

PDIUSBD12

+ много готового кода
+ всего 10 проводков к АВР
+ высокая скорость (до 2МБ сек)
+ всего 28 контактов ! (Есть SO28, шаг 1.27, ножка 0.49)
- скоро умрет исчезнет или нет?
- в по надо учитывать USB специфику


USBN9604 (именно 4!)
+ MICROWIRE/PLUS Interface (всего 4 ПИНА?) НА СКОЛЬКО ЭТО СОВМЕСТМО С SPI?
+ есть какая-то дока и примеры на http://usbn2mc.berlios.de/
+ высокая скорость
+ всего 28 пин
+ широкий SOIC корпус с шагом 1.27
- использует 12 проводков к АВР
- не рекомендуется для новых дизайнов
- в по надо учитывать USB специфику
- требует кристал на 24мгц
- в каталоге производителя вообще нет, но по поиску находится вся инфа по нему, может сайт кривой просто


FTDI
(FT2232D , FT2232C)

+ на винде COM драйвер
+ на АВР нет специфика УСБ - просто данные с параллели
+ много примеров и кода
- тучу паять (48 пин)
- на авр занимает 15-16 пинов
- скорость до 1мбит - 150кб/сек
- ненастоящий USB???

AT90USB1286
- 64 контакта для пайки в ужасном корпусе
- мало примеров проектов

AT90USB82
- только как второй контроллер
- тяжело паять
- надо интерфейсить с основным чипом
- мало примеров

Есть еще варианты какие нибудь? И еще интеренсо, а вообще в PDIP корпусе есть контроллеры USB?

Я думаю FTDI для чайников самое то будет. Уж проще ничего не придумали. Да и правильно - всего 2 провода надо для последовательного канала. Правда я не уверен сможет ли МК с такой скоростью по нему все принять...

Myp писал(а):1. телепаты требуют указать ТЗ проекта. чё ты вобще хочешь то? и нафик такая скорость большая?

Скорость нужная для дисплеев побольше и цветных. Например, 320х240, 65535 цветов. Имеем: 153600 байт на кадр.
А мне надо кадров 10 в секунду! Но такое зверство - на потом, пока простые ЦБ экраны, и им для 10 кадров в сек
надо до 200 кбайт/сек.

Myp писал(а):2. почему ФТДИ - на авр занимает 15-16 пинов??? достаточно всего 2 (Rx-Tx) или я чтото упустил??

По моему на 2 пину скорость мизер у него. Я смотрел схемы более скоростных вариантов подключения - там parallel используется и туча пинов.

Myp писал(а):3. ты пишешь минус: в по надо учитывать USB специфику а потом для FTDI пишешь в минус что это ненастоящий USB. ты определись уж ты хочешь настоящий usb использовать или эмуляцию, ато тебе и то не нравится и другое не нравится

Это и есть проявление неопределенности в подходе. Ненастоящий USB плохо, так как в Винде/UN*X не будет реального устройства, что не хорошо (кое-каких приятных и удобных вещей для конечных приложений нет и сами конечные придожения писать как com-терминал писать - не корошо), а кроме этого винда походу тупит с COM портами, что ли, задержки вставляет. А сдругой стороны хорошо - так как firmware для AVR писать попроще.

-= Александр =- писал(а):10 раз в секунду обычный ЧБ мерцать будет... Надо логику строить чтоб кадры сравнивала и выводила только меняющиеся элементы...
А вообще тут уже надо думать в сторону ARM с аппаратным USB. Особенно если хотите цветные TFT-дисплеи подключать... У 8-битки просто скорости не хватит все это дело через себя пропустить даже не обрабатывая...

Что значит МЕРЦАТЬ? у дисплея свой контроллер он его и перерисовывает, так чтобы не мерцало. а я с ним иобщаюсь из AVR (ну, например KS0108). Просто если выводить анимированую картинку, скорость анимации будет не болье 10 кадров в сек. Про оптимизацию знаем и это будет, но на полный кадр надо 10 кадров /сек. И какие проблемы для atmega пропустить через себя 200КБ? И я говорю о микродисплеях. 320х240 16/24 бит - это мегамонстр, который пока даже в планах не стоит.

Ладно, не будет отвлекаться на побочные темы.

Устаналиваем, что будет AVR 8bit и 10 кадров в сек и 200КБАЙТ/сек. Нужно с USB оперделиться. чтобы давало нужную скорость.

да кстати
вот тока на днях ставил дровкип од фтди

там есь 2 варианта
простой вариант это просто виртуальный компорт
а сложный вариант это номаное usb устройство

artemm писал(а):Ну вот, вектор мнений уже понятен. ВОпрос: а почему нравится именно решение FTDI,а не на нормальном USB контрллере? Просто потому что программить меньше в МК (соответсвенно. код меньше) и в конечном приложении ненадо драйвера лепить для устройства?

Ясное дело. Разобраться с USB дело, конечно, полезное, но если потом это использовать в одной-двух конструкциях - расточительство времени.

очень просто - мне нужно чтобы было кросплатформенным, и у меня нет времени на разбор, написание
и тестирование(!) драйверов для Linux, FreeBSD, Mac OS X и Windows.
поскольку поддержка USB<->UART есть во всех этих ос, то выгоднее использовать родные драйвера.
а в программе pyserial и можно еще pyusb для определения устройств можно задействовать.

и еще советую посмотреть на чипы SiLabs (MCU x51)

TomaT писал(а):Если нужно просто к РС-хосту по USB дисплей прикрутить, то ИМХО нужно забыть об АВР и прочих ПИКах и юзать младшие FPGA, бо как насколько я понял в данном применении (что собственно нужно то?) ARM это уже перебор. Ну а если на него пререложить вункции GPU то зачем столько от USB отъедать?

FPGA принципиально трудено программировать, особенно после AVR-ок с их средствами.
GPU на него не переложишь - мало памяти. Можно конечно SRAM пиркруптить, но это будет противоречить концепции проекта, а там идея, чтобы как можно более любителей криворуких могли это сами спаять.
А в чем проблема видится с МК в данном случае? Чем они плохи для задачи?