USB контроллер на Микрочипе

[lbodnar]

Знаем , слышали , а входит ли драйвер для HomeConstructors - просто передать пакет определенной длины.. И все ! ?????? Ненужны нам дрова для медицинской аппаратуры и прочей не симмерской лабуды. Просто передать пакеты.. А куда их всовывать и как кодировать - сами разберемся..

Ребята, вам нужно подтянуть матчасть. Самый большой недостаток HID - его название. Никакого отношения к human interaction он на самом деле не имеет. Задача его проста - принимать и доставлять в хост данные с заданной периодичностью и с интервалом от 1мс. ВСЕ! Остальное - мишура типа намеки хосту что эти данные содержат. Не хотите чтобы ОС ваши данные видела - скажите, что это vendor defined data и все. Гарантированная доставка данных через один HID интерфейс - 64килобайта в секунду на полноскорстном 12мбит устройстве (у меня в основе такой контроллер) Если мало - один чип может прикинуться до 15и устройствами одновременно. 64кбайт/сек - это 512кбит причем дуплексно в обе стороны.

Дешево не будет.. Однако прекрасно понимаем , что дорого COM железку продать уже не получится. Везде USB...

Цена определяется конечным результатом а не типом интерфейса. Если это будет готовое отлаженное работающее устройство - я его первый у вас куплю. А интерфейс мне по боку какой если он на PC и на Mac'е будет работать.

Удачи вам! Но по-моему вы слишком высоко замахнулись. Я решил - упрощать. Надо 80 осей? Втыкается 10 независмых контроллеров, а не один монстр. Моя идеология - создвавать простые и независимые в применении кирпичики.

[Ezdok]

Но по-моему вы слишком высоко замахнулись. Я решил - упрощать. Надо 80 осей? Втыкается 10 независмых контроллеров, а не один монстр. Моя идеология - создвавать простые и независимые в применении кирпичики.
---
Идея такая - есть PIC16F874... Стоит 3.5$...К шине IO подрубается 2-мя сигнальными проводами Rx и TX.. Сколько модулей надо - столько и подключаем...

[Ezdok]

Цена определяется конечным результатом а не типом интерфейса.
---
На ткаие довольно уникальные устройства цена определяется в первую очередь - из времени и сил на разработку этого устройства.. Конечный результат может быть простой - например 2+2=4 с выводом результата впорт , однако чтобы это произошло , иногда тратиш месяцы. Интерфейс тоже играет роль .. Например никому ненужны флешки или фотоаппараты с COM разъемом. Сегодня это просто хамство со стороны разрабов.....
Так что USB - это всегда на порядок дороже , потому что современеей..
---


Аппаратный контроллер с УСБ 2.0 12Мбит(фулл-спид) стоит от 6 баксов в розницу и самошьется по УСБ. Кодовое слово LPC41xx.
За 10-15 можно купить такой же с поддержкой CAN и Ethernet
---
не , я такие программить неумею :-(( Тем более нет нисреды разработки , ни отладчика , ничего под этот чип... Ж-(( Отсается делать на то м на чем умеем..
А так разбиратся в новом - это ооочень дорогое устройство будет , у которого цена несоизмерима с функционалом.

[lbodnar]

прочитайте стандарт насчет Feature Report и гляньте системные вызовы WinXP HidDGetFeature/HidDSetFeature. В этом режиме даже не надо вторую endpoint заводить. Все будет работать через control endpoint0.
...
Про протоколы:

Речь же вроде шла про процедурный тренажер для больших, а не про наши поделки для флайт-симщиков? Все-таки найдите в сети стандарт на CANaerospace. Это протокол верхнего уровня.

Feature report не предназначен для передачи живых данных а для конфигурации - для данных просто в INput report определяется свой собственный тип вывода (или ввода):
USAGE_PAGE(0xFF00 - vendor-defined)
USAGE(любой)
и все - никто кроме вашей программы их не тронет (и не увидит). Читайте непарсенный репорт делайте с ним что хотите. А приезжает он автоматично каждые 1мс через EP1.

Такой детский протокол как USB занимает в сжатом виде документик в 700 страниц. От него до реально действующего безглючного устройства еще столько же как до луны. Представляю какой кровью реально рабочий CANaero аппаратик достанется. Один! Больше ни у кого нет. И подключать его не к чему кроме настоящией Акулы... Не все что лучше, то - лучше. Вспомните Betamax/VHS.

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

[Ezdok]

Вот по этому и существуют USB2COM адаптеры. Ибо COM еще жив и будет жить , поскольку там живые данные , которые можно обрабатывать сразу без всяких заморочек.....

[lbodnar]

Вот по этому и существуют USB2COM адаптеры. Ибо COM еще жив и будет жить , поскольку там живые данные , которые можно обрабатывать сразу без всяких заморочек.....

Кто же спорит что он жив - знаешь что буква S в USB означает? Дайте мне аппаратный контроллер берущий на себя весь протокол нижнего уровня, обработку ошибок и поддержку OSа и я вернусь, мама!

[Ezdok]

Ну USB - Universal Serial Bus. Чем слово Serial неустраивает.
Просто COM - онже RS232 , онже USART ... Везде serial - тобиш последовательно..Да и аппаратный контроль четности тоже есть вроде...

[lbodnar]

Люди старались в первую очередь замену COM порту придумать. Что-то мы отклонились от темы (а она была вообще?!)

[Ezdok]

Кто , тема или замена COM ???

[sergeyk]

Мне вот тут указали, что второй мджой нам не нужен. Так вот, я стыдливо повторю свой вопрос. Есть ли реальный интерес в контроллере с честным 12-и мбитным USB в 40пиновом корпусе с
13 аналоговыми осями по 10бит и с 91 кнопкой/кодером или
8 аналоговыми осями по 10бит и со 144 кнопками?

Т.к. проекты MJoy, судя по всему замерзают или переходят в коммерческое русло, ответ ДА.

Особенно меня заинтересовали энкодеры: насколько у них стандартизовн интерфейс?

Идея в следующем: покупать новые оригинальные енкодеры малоцелесообразно. А вот использовать из старых принтеров/плотеров это без проблем, сейчас б/у'шной техники навалом. Вопрос только в том сколько надо потратить на использование этой холявы?

Зашитый, гарантированно работающий чип. Внешняя обвязка - кварц, два кондера и резистор. Цена - мммм, $20 максимум.

За готовое изделие цена неплохая.
Доставка, оплата? Я сам по себе немного ленивый, хотя и бывший радиолюбитель, но подумывал купить MJoy16, по старым ценам, но сейчас это выливается уже в покупку изделия, а не радиокнструктора.

P.S. Решил ответить в твоей ветке т.с. в тему

[LazyCamel]

Feature report не предназначен для передачи живых данных а для конфигурации - для данных просто в INput report определяется свой собственный тип вывода (или ввода):
USAGE_PAGE(0xFF00 - vendor-defined)
USAGE(любой)
и все - никто кроме вашей программы их не тронет (и не увидит). Читайте непарсенный репорт делайте с ним что хотите. А приезжает он автоматично каждые 1мс через EP1.

Неправда ваша. Это его обычно применяют для конфигурированя. Но тем не менее его можно применять и по другому.

Отличие Features от INPUT/OUTPUT только в том, что вторые работают на interupt точках и поэтому гарантированно опрашиваются. Зато первые можно запросить только тогда когда хосту захочется и передавать через него данные не ограниченные размером endpointa. Плюс приоритет у 0 точки больше.

[lbodnar]

Неправда ваша. Это его обычно применяют для конфигурированя. Но тем не менее его можно применять и по другому.

Цитирую библию:

An Input item describes information about the data provided by one or more
physical controls. An application can use this information to interpret the data
provided by the device.
Feature items describe device configuration information that can be sent to
the device.

Плюс приоритет у 0 точки больше.

Это с каких пор у эндпоинтов приоритет появился?!

[z36]

Если есть возможность заказать контролер под себя, например:
4 оси по 256 или 512 отсчетов, 12 кнопок+хатка или министик, на резюках все оси, я готов на 20$ но контролер должен чисто и быстро отщелкивать эти 256 отсчетов, а не как у Ево 1024 со скачками до 10% и при низком быстродействии.
Охота фотку глянуть, чтобы габариты определить.

[ArGer0]

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

Про HID.
Очень часто недоверие - просто недостаток опыта работы с чем-то.
HID спокойно передает произвольные (сырые) данные, прочитайте стандарт насчет Feature Report и гляньте системные вызовы WinXP HidDGetFeature/HidDSetFeature. В этом режиме даже не надо вторую endpoint заводить. Все будет работать через control endpoint0.
Не совсем понятно какое отношение ограничения DirectX имеет к Hid-протоколу ? Ва м никто не запрещает читать данные с hid-устройств и помимо него.
Рекомендую курить вот эту книжку http://www.natahaus.ru/2005/09/16/in...p__agurov.html до просветления

Про аппаратуру.
Аппаратный контроллер с УСБ 2.0 12Мбит(фулл-спид) стоит от 6 баксов в розницу и самошьется по УСБ. Кодовое слово LPC41xx.
За 10-15 можно купить такой же с поддержкой CAN и Ethernet.

USB 2.0 разве не 480 Мбит/сек выдает???!!! ИМХО да!!!

[lbodnar]

USB 2.0 разве не 480 Мбит/сек выдает???!!! ИМХО да!!!

USB2.0 - это свод правил дорожного движения в которых введена новая скорость. Старые никто не отменял. Т.е. стандарт USB2.0 заменяет предыдущие USB1.x которые теперь устарели. Новое 1,5Мбит устройство разработанное недавно должно декларировать себя как USB2.0 так что мджой должен по идее объявлять себя 2.00 если он использует стек Игоря написанный после 27 апреля 2000 года. Хотя я не уверен, что он тесты пройдет - кто нибудь пускал мджой под Command Verifier'ом?

[LazyCamel]

Это с каких пор у эндпоинтов приоритет появился?!

Изначально был. Описан в стандарте на хабы.
Если я ничего не путаю примерно так:
Под контрол-ендпоинт резервируется 10% канала ВСЕГДА. даже если по нему пересылок не будет, а остальные будут стоять в очереди эти 10 процентов зарезервированы. Потом строится граф для изохронной передачи, раскидываются интеррапты и остаток добивается балком.
При необходимости контролы и изохроны могут задерживать интеррапты и балки.

[LazyCamel]

Хотя я не уверен, что он тесты пройдет - кто нибудь пускал мджой под Command Verifier'ом?

Я пускал - как минимум валит стресс-тест на многократные переподключения. Плюс не отрабатывает suspend state по bus inactivity.

[lbodnar]

Изначально был. Описан в стандарте на хабы.
Если я ничего не путаю примерно так:
Под контрол-ендпоинт резервируется 10% канала ВСЕГДА. даже если по нему пересылок не будет, а остальные будут стоять в очереди эти 10 процентов зарезервированы. Потом строится граф для изохронной передачи, раскидываются интеррапты и остаток добивается балком.
При необходимости контролы и изохроны могут задерживать интеррапты и балки.

А-а-а, вот вы о чем! Дело в том что на эти 10% пользовательское приложение вряд-ли может гарантирванно рассчитывать:

5.5.4
...The USB System Software can, at its discretion, vary the rate of control transfers to a particular endpoint. An endpoint and its client software cannot assume a specific rate of service for control transfers. A control endpoint may see zero or more transfers in a single (micro)frame. Bus time made available to a software client and its endpoint can be changed as other devices are inserted into and removed from the system or also as control transfers are requested for other device endpoints.
...
Because the USB system uses control transfers for configuration purposes in addition to whatever other control transfers other client software may be requesting, a given software client and its function should not expect to be able to make use of this full bandwidth for its own control purposes.

Очень мутно и никаких гарантий даже на пустой шине. С прерываниями, во всяком случае свои честные 64 байта в миллисекунду всегда приедут.

Главное - не пытаться притянуть протокол к использованию, на которое он не предназначен. Лучше вовремя сменить лошадей, чем загнать их досмерти!

[lbodnar]

Я пускал - как минимум валит стресс-тест на многократные переподключения. Плюс не отрабатывает suspend state по bus inactivity.

У нас - твердая пятерка по всем и в старом USBCHK тоже

Две недели долбился!

[LazyCamel]

На железном-то USB с этим больших проблем нет, у меня на АРМах тоже все проходит, хотя со стрессом тоже пришлось покопаться.

[Ezdok]

Вопрос , на который я несмог найти ответ..
Может ли USB передавать пакет заданной длины не разбивая его на байты по 8 бит ? Например мой протокол содердит 64 бита в пакете. Могу ли я передавать целиком пакеты ? Это первое.
Как происходит контроль ошибок . Может ли контроллер USB восстанавливать потерянные биты в пакете ( если их немного конечно ) и есть ли там понятие аппаратное CRC ? Или чтонить в этом духе..

[LazyCamel]

Аппаратное CRC16 и прозрачный для программиста перезапрос битых пакетов. Передача информации только кратно байтам, интерпретировать полученые байты можешь как угодно. В HID протоколе предусмотрена битовые значения, но общий их размер все равно должен быть выравнен на границу байта.
Исправление одиночных и двойных ошибок хеммингом не предусмотрено, битые пакеты просто аппаратно перезапрашиваются. (Для софтовой реализации на Меге при приеме от хоста CRC входящего пакета не проверяется и соответсвенно битые пакеты не перезапрашиваются, при передаче - все работает нормально)

[Ezdok]

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

[LazyCamel]

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

ЗЫ: Извините, я настойчиво рекомендую пройти по ссылке что я дал и скачать указанную книгу.

[Ezdok]

Не , неподходит для наших задач.. тоесть теже яйца только с боку , только еще и книгу читать.. Но ссылку все равно прочту... пасибо..