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?

artemm писал(а):Есть проект - графические LCD на USB с AVR контроллером.

1. телепаты требуют указать ТЗ проекта. чё ты вобще хочешь то? и нафик такая скорость большая?
2. почему ФТДИ - на авр занимает 15-16 пинов??? достаточно всего 2 (Rx-Tx) или я чтото упустил??
3. ты пишешь минус: в по надо учитывать USB специфику а потом для FTDI пишешь в минус что это ненастоящий USB. ты определись уж ты хочешь настоящий usb использовать или эмуляцию, ато тебе и то не нравится и другое не нравится

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

ну..
мк умеет 115200 в двойном режиме судя по мастеру CVAVR
еси подобрать правильный кварц...

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

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

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

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

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

[...] Ненастоящий USB плохо, так как в Винде/UN*X не будет реального устройства [...]

Код: Выделить всё

vovan@vovan:~$ lsusb
[...]
Bus 004 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 004 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
[...]

ЧЯДНТ?

Добавлено спустя 3 минуты 59 секунд:
Старые чипы FTDI дают до 1 Миб по серийнику, новые могут больше.
авр точно нормально работают до 0,5 Миб

и вообще может хватить одной лишь фтдиайки с параллельным интерфейсом

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

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

Vooon писал(а):

[...] Ненастоящий USB плохо, так как в Винде/UN*X не будет реального устройства [...]

Код: Выделить всё

vovan@vovan:~$ lsusb
[...]
Bus 004 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 004 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
[...]

ЧЯДНТ?

Добавлено спустя 3 минуты 59 секунд:
Старые чипы FTDI дают до 1 Миб по серийнику, новые могут больше.
авр точно нормально работают до 0,5 Миб

и вообще может хватить одной лишь фтдиайки с параллельным интерфейсом

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

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

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

Так в том то и дело, что лично мное планируется 6-8 устройств на этом деле + все это будет публично опубликовано для повторения всеми желающими. Именно поэтому элементная база нужна а) которую достать можно б) максимально легкая для пайки

не нужно без дела цитировать EdGull

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

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

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

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

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