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

По просьбе многих, открываю новый тред отпочковавшийся от
http://www.sukhoi.ru/forum/showthrea...&page=32&pp=25
----------------------------------------------------------------
Я тут практически закончил разработку USB контроллера для самодельщиков. Штука эта будет такая:

Модель 1:
http://www.lbodnar.dsl.pipex.com/joystick/
8 аналоговых входов по 10бит разрешения каждый
12 кнопок либо независимых, либо матрицей 6x6
(вариант 10 аналоговых 10битных входов + 10 кнопок или 5x5 матрица, но Win не видит больше 8 осей на одном джойстике, поэтому он будет виден под Виндами как два джойстика)


Модель 2:
6 квадратурных декодеров, два из которых с оцифровкой до скорости 150кГц (для кодеров типа 2000линий на оборот) с разрешением 20бит
8 цифровых кнопок

Модель 3:
100 кнопок в конфигурации матрицей 10x10.

Общие для всех трех:
Чип с 28 ножками в обычном DIP корпусе (Microchip PIC18F2550)
Все что нужно для подключения: 4MHz кварц, два конденсатора и USB разъем (или сразу кабель)
Питание от USB порта
Full-speed USB (12Mbit), частота обновления всех каналов - 1000 раз в секунду (период 1мсек)
Драйверы не нужны (стандартное устройство в Win/Mac/Linux)

Я не хочу делать плату контроллера потому что цены подкрадываются со спины: плата, кварц, сборка, упаковка, тестирование, etc.

Цена чипа: $15.

Где-то в середине года у меня будет просто ОДНА модель - чип, которых можно переключать в любую конфигурацию из интерфейсной программки под Win/Mac/Linux.

Честно говоря, я cтолько времени потерял с мышиными декодерами... это просто убийство времени, а результат - 30 импульсов на оборот. Самое мерзкое, что они теряют импульсы из-за фиговых сенсоров. Для мыши это не имеет значения, а в кодере после прогона 1000 импулсов в одну сторону обратно возвращаются только, например, 996, поэтому центровка джойстика постоянно дрейфует в процессе.

И тут я открыл глаза! Есть готовые декодеры типа http://www.encoder.com/model755a-shaft.html с разрешением 2000 импульсов на оборот (до 10000 если очень нужно) это уже что-то т.к. 2000 импульсов дают разрешение в 8000 позиций на оборот (считаем-то фронты). Аналоговые потенциометры отдыхают! Купить их можно на eBay за $20-30. Проблема в том, что если человек крутанет этот декодер (или все-таки энкодер?) с приличной скоростью, импулсы посыпятся с такой частотой, что даже хороший контроллер, если он еще хоть чем-то занят просто их не успевает обработать и все работа - насмарку, центровка опять съезжает. В ATMega16 нет USB контроллера, поэтому MJoy использует аппаратную работу с USB - разбирает его по битам и собирает обратно. Это занимает безумное количество времени и делает применение крутых кодеров невозможным. Собственно поэтому я и ввязался в то, что у меня получилось в итоге.

Идея такая - продавать самодельную плату типа MJoy16 людям, которые потом все равно все выходные с паяльниками сидят глупо. Поэтому я убиваю время над мудрым софтом внутри (USB - это не RS232!), а все остальное любой самодельщик может сделать буквально за 15минут и потратить на это $2-3. Вот такая вот идея.

Уффф, пальцы отваливаются!

P.S. Кстати, если все-же хочется сделать квадратурных кодер самому, то лучше раскурочить старый струйных принтер. Там часто используется осевой кодер на ~500 линий/оборот и линейный - такая прозрачная полоска с тоненькими линиями (720dpi?). Сенсоры (обычно Agilent) как бы обхватывают их и выдают уже хороший квадратурных сигнал TTL уровня. У них 4 ножки и им только нужно +5v для питания и все.

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

Окончательный вариант версии с аналоговыми входами получился такой:

8 x 10-битных входов от резисторов 10к-100к
32 кнопки
HAT селектор вида (отдельные четыре кнопки)
частота отсчетов - 300Гц

Проверен под Виндами и Мас ОС Х. Краткие чертежики здесь -
схема подключения выводов
матрица кнопок
USB разъем
просто переменник
Винды
Мак

Я, также, сделал модель с 10 аналоговыми входами и 25 кнопками, но из-за традиционного ограничения в DirectX на только 8 осей, пришлось один контроллер отображать как два виртуальных джоя - один с 6 осями, другой - с 4мя. Работает прекрасно, но как-то не нравиться мне. 8 осей и 32 кнопки, по моему - самое то.

В конце концов их можно несколько прицепить, т.к. у них у всех разные серийные номера. %)

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

Я тоже могу сделать точность в 15бит подмешав в оцифровываемый сигнал белый шум и просто сложив результат 32 измерений. Задержка времени реакции гарантирована! Кстати, я оцифровываю четыре раза и потом усредняю сохраняя 10бит точности, хотя можно было бы и до 12 раздуть. Сейчас за 2 миллисекунды вполне хватает времени четыре раза оцифровать 8 каналов, усреднить результаты, отсканировать кнопки и отправить результат в компьютер через USB. C честными 10 битами и 3 миллисекундами "задержки" можно жить. :thx:

Кстати, тут кто-то ссылку на дорогущий кодер приводил. Они бывают двух типов - разностные (квадратурные) и абсолютные.

Абсолютный кодер в любой момент может точно сказать свое текущее состояние, например +23469234. Разностный - только +1 и -1 да и то в квадратурном коде. Абсолютные кодеры напичканы умной электроникой, часто имеют внутри батарейку и часто подключаются через одну из промышленных шин (Fieldbus, CAN, и тп) хотя есть и монстры с 20 битным параллельным выходом. Они не только дороже, но и с ними труднее работать из контроллера, хотя и нет проблемы с потерей ипмульсов - контроллер всегда узнает точное положение кодера даже если он был занят чем-то другим (например, работал с USB)

Да, так вот ссылка была на абсолютный кодер, поэтому он такой и дорогой!

Microchip PIC18F2550 - его прошивать надо?

Больше конроллеров шустрых и разных! :)

Я не очень понял принцип распространения проекта: полностью открытый? Аля MJoy8? Али прошивку/мс покупать надо?

А на счёт энкодеров не врубился: их можно приспособить? А из принтеров?
IMHO, на тримерах самое то, особенно относительные. Какое ещё применение?

Проект (пока, во всяком случае) не открытый т.к. его будущее не совсем ясно.

Что касается кодеров (как же они все-же по-русски правильно зовуться?!) из принтеров то нет никаких проблем - вот они, эти два из HP 2000 вытащены. Линейный очень удобен тем, кто гражданский штурвал делает. Серые полосы по краю диска и на полоске на самом деле это очень плотно расположенные штрихи. А у блока считывания четыре контакта - земля, +5в и два квадратурных выхода уже TTL уровня. Мечта самодельщика.

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

И сколько цена сего девайса вырисовывается?

Цитата:

---

Сообщение от Orion33

И сколько цена сего девайса вырисовывается?

---

Пока - не более $15.

Вот для развлечения - два из моих кодеров. Первый - многооборотный абсолютный на 1024 позиций на оборот (кажется, несколько сотен оборотов.) Вывод позиции - последовательный синхронный интерфейс на скорости 125кбит. Каежется, его можно было перепрограммировать на 4096 поз/оборот т.к. физически там плотность штрихов именно такая внутри, просто он загрублен программно.

Второй - обычный квадратурный на 2000 импульсов. Да еще и в водонепронецаемом корпусе %)

Прошу заметить - абсолютный кодер выдает уже готовую вычисленную позицию, так что 1024 они и есть 1024 позиции, больше не выжать. У квадратурного на выходе две последовательности импулсьов, так что после декодирования точность отсчета увеличивается в четыре раза, так что 2000 импульсов превращаются в 8000 позиций.

Надеюсь, не утомил! :expl:

Цитата:

---

Сообщение от sergeyk

Больше конроллеров шустрых и разных! :)

Я не очень понял принцип распространения проекта: полностью открытый? Аля MJoy8? Али прошивку/мс покупать надо?

А на счёт энкодеров не врубился: их можно приспособить? А из принтеров?
IMHO, на тримерах самое то, особенно относительные. Какое ещё применение?

---

Больше-то оно больше, тока было бы лучше. Пока ничем конкретным от МJOY Миндога не отличается. Кроме одного - за прошивку еще даже сам автор не знает сколько запросит (((((

P.S. Матрица из диодов для кнопок - не самое правильное и технологичное решение.

Цитата:

---

Сообщение от lbodnar

Пока - не более $15.

---

Дайте две! %)

Рассуждения на тему "1024 отсчета - это много или мало?"
Может не совсем по теме, но в соседней этот вопрос поднимался.

На какой угол отклоняется среднестатистическая палка? Напольники не в счет! 30 градусов. В сумме туда-сюда получается 60 град. Т.о. на один отсчет приходится примерно 0,06 град. или 0,06*pi/180 = 0,001 радиан.
Если отклонить ручку на такой угол, то наружная точка оси джоя совершит перемещение r*sin(0,001). r - радиус оси джоя. Для малых углов справедливо равенство sin(x) = x, поэтому величина этого перемещения составляет примерно 5*0,001 = 5 мкм (диаметр оси берется порядка 1см - на Еве такие. Если он меньше, то все гораздо хуже %)).
Из чисто логических соображений ясно, что механический люфт должен быть меньше, чтобы почувствовалось это перемещение...

ВНИМАНИЕ, вопрос! В каком серийном джое люфты меньше 5 микрон??? Правильно, таких джоев нет! %) И даже с 50мкм тоже нет. Минимум - 0,1 мм. То есть 128 значений более чем достаточно...

Вывод таков: не верным путем идете, товарищи! Механику надо сначала хорошую иметь!
:thx:

Цитата:

---

Сообщение от Orion33

Рассуждения на тему "1024 отсчета - это много или мало?"

---

Я вообще-то все это дело под штервал делал. На маленькой Цессне ход штурвала - 165мм вперед-назад и 90 градусов в обе стороны. При тихой погоде на посадке обычно крутишь его туда-сюда буквально градусов на пять. В следующий раз на машине будете рулить - посмотрите насколько на трассе руль отклоняется из двух полных оборотов. Так вот, 5 градусов от 180 составляет около 3%. Мне хочется чтобы это были плавные 3 процента а не как на лифте - вверх/вниз. "Плавные" означает состоять они должны из 25-30 шагов. Вот и получаем в итоге 1000 шагов на весь ход штурвала - это минимум для комфорта. Конечно, на штурмовиках можно и с 2 битным джойстиком летать делая ШИМ правой рукой. :D

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

А штурвал на кодере делается абсолютно элементарно без всякого люфта - сам кодер и является осью вращения и одной из опор штурвала. Там подшипники очень высого класса точности стоят без люфтов и нагрузку он держит киллограм 10-20. Еще один подшипник на ось крена ставится и все. С джойстиком - больше возни, это правда.

Цитата:

---

Сообщение от Orion33

Дайте две! %)

Рассуждения на тему "1024 отсчета - это много или мало?"
Может не совсем по теме, но в соседней этот вопрос поднимался.

На какой угол отклоняется среднестатистическая палка? Напольники не в счет! 30 градусов. В сумме туда-сюда получается 60 град. Т.о. на один отсчет приходится примерно 0,06 град. или 0,06*pi/180 = 0,001 радиан.
Если отклонить ручку на такой угол, то наружная точка оси джоя совершит перемещение r*sin(0,001). r - радиус оси джоя. Для малых углов справедливо равенство sin(x) = x, поэтому величина этого перемещения составляет примерно 5*0,001 = 5 мкм (диаметр оси берется порядка 1см - на Еве такие. Если он меньше, то все гораздо хуже %)).
Из чисто логических соображений ясно, что механический люфт должен быть меньше, чтобы почувствовалось это перемещение...

ВНИМАНИЕ, вопрос! В каком серийном джое люфты меньше 5 микрон??? Правильно, таких джоев нет! %) И даже с 50мкм тоже нет. Минимум - 0,1 мм. То есть 128 значений более чем достаточно...

Вывод таков: не верным путем идете, товарищи! Механику надо сначала хорошую иметь!
:thx:

---

Я вот еще в догонку хочу спросить сколько бит та переменная которая отвечает за положение штурвала в Иле ???
Я могу с 200% уверенностью сказать что в FS эта переменная всего 8 бит и там хоть суй ему 16-ти битную переменную , все равно позициЙ ручки с симе будет 256 !!!... Как дела в ИЛ2 обстоят ? Ктонибудь считал количесво ступеней полного хода виртуальной ручки с кабине ? ПОвторю , что в FS - всего 256 ступенек на полный ход ЛЮБОЙ АНАЛОГОВОЙ ОСИ !.. ПОэтому что на входе сима из ви нды будет диапазон оси 1024 , что 65536 - все автоматом перемасштабируется в диапазон 256 ступенек..

если честно то я тоже пока не вижу существенной разници от миндоговского , энкодеры . вещь дорогая и не всем доступная , линейность . я уже говорил , на угловых датчиках она почти линейная , какойто процент не в счет . все одно крмвые отклика ставят свои , шумы ?7.. ну незнаю , что еще.. а х.з. ! как я вижу следующий вариант..
вариант для эстетов :) 2 оси на энкодерах (тока на осях джоя) остальные аналоговые , и самое главное ! возможность изменять кривые отклика на ходу !ведь согласитесь что каждый крафт требует сомх крмвых , да и ситуации разные , на посадке надо очень плавно рулить , бой по другому , бомбадировщик - третье , штурмовик . четвертое , гражданский - пятое , пусть это будет незначительное усложнение , или добавить опционально , тоесть потом в основную схему добавляеш чтото и она уже работает . ну и можно еще че добавить . типа индикации режима или номер загруженого профайла откликов

Цитата:

---

Сообщение от Ezdok

Я вот еще в догонку хочу спросить сколько бит та переменная которая отвечает за положение штурвала в Иле ???
Я могу с 200% уверенностью сказать что в FS эта переменная всего 8 бит и там хоть суй ему 16-ти битную переменную , все равно позициЙ ручки с симе будет 256 !!!... Как дела в ИЛ2 обстоят ? Ктонибудь считал количесво ступеней полного хода виртуальной ручки с кабине ? ПОвторю , что в FS - всего 256 ступенек на полный ход ЛЮБОЙ АНАЛОГОВОЙ ОСИ !.. ПОэтому что на входе сима из ви нды будет диапазон оси 1024 , что 65536 - все автоматом перемасштабируется в диапазон 256 ступенек..

---

Я уже говорил и еще раз повторю: ручка - это одна модель, плоскости - другая, а отработка поведения - совсем другая. И у каждой имеет место быть своя дискретность.

Цитата:

---

Сообщение от Ezdok

Я вот еще в догонку хочу спросить сколько бит та переменная которая отвечает за положение штурвала в Иле ???
Я могу с 200% уверенностью сказать что в FS эта переменная всего 8 бит и там хоть суй ему 16-ти битную переменную , все равно позициЙ ручки с симе будет 256 !!!

---

Я - железо делаю и мне не очень интересно какие у софта сейчас ограничения - это не должно стать тормозом прогресса.

Я точно знаю что под Mac OS X у X-Plane, например, как минимум 16-битное разрешение для всех осей. Вообще-то там плавающая точка с двойной точностью используется, поэтому если и есть какое ограничение - так это только ограничение выхода данных с HID устройства (не более 32 бит на одну переменную.) Хотя тот же X-Plane под Виндами почему-то с лету устанавливает пределы переменных в DirectInput в +-100 и т.к. результат используется в целочисленном виде, получаем всего 200 шагов. Я этот кусок кода долго смотрел, но так и не понял, зачем Остин это сделал - наверное он его сто лет назад написал, не зная, что DirectInput все сводит к целым числам, а т.к. это было под Виндами, то ему не особо на глаза попадалось потом. Я этот вопрос у него выясню.

Хотя, кто X-Plane видел, знают, что там любую переменную физики процесса можно вытащить из программы или туда же загнать либо через плагин либо через UDP. Я посылал 16битную позицию штурвала на кодере по сети через UDP и все было просто супер, как маслянное! Поэтому заметил глюк только после того как джойстик напрямую подключил. Так что кто очень хочет может написать программульку на питоне, которая считывает позицию джойстика и напрямую впрыскивает это в X-Plane с любым разрешением (на том же компьютере) - для многих это не составляет труда, нужно только один раз сделать. То же, наверняка, можно и в FS.

Заморочки софта не должны сдерживать хард. И делать хард из расчета на то, что софт все равно кривоватый тоже не гоже (это я про китайский ширпотреб.) Вот так я себе думаю...

А то что я делаю я все равно не брошу, пусть оно никому и не нужно. :thx:

- железо делаю и мне не очень интересно какие у софта сейчас ограничения - это не должно стать тормозом прогресса.
---
Это понятно , порддерживаю и сам придерживаюсь такой политики. Софт-софтом , а жележо - совсем другая песня...

К чему весь разговор :
Наухо шипну общественности сухого - сейчас разрабатывается целый комплекс управляющего железа для FS .. Точнее для его части ПТ..
Хотелось бы его юзать не только в FS2004
Некоторые из скромных возможностей комплекса:

128 модулей по 8 10-ти битных осей. Общее количество осей - 128*8...
128 модулей кнопок/тумлеров. 1 модуль = 184 тумблера. общее количество кнопок в комплексе 128*184....

128 модулей стрелочных индикаторов. 1 модуль стрелочников = 20 приборов.
Общее количество стрелочных приборов 128*20....

128 модулей 8-ми сегментных индикаторов. 1 модуль = 28 индикаторов по 8 цифр.
общее количество индикаторов 128*28...

128 модулей ламп накаливания, светодиодов , другой нагрузки.. 1 модуль = 30 ламп.. общее количество лам 128*30....

128 модулей энкодеров. 1 модуль = 16 настоящих честных реал-тайм энкодлеров. ( кручу , мгновенно вижу результат с какойбы скоростью бы я не крутил энкодер). Общее количество 128*16....

128 модулей прямого физического бинарного ввода в сим. 1 модуль = 1 32-х битная переменная. (нах нужен - незнаю , но пока в планах) общее количество модулй 128*1......

Помимо помимо всего в планах нормальная конфигурация модулей в системе прямо из сервисного софта , и как всегда минимум контроллеров и обвязки..

Вот чего и спрашиваю про переменные.. Хотелось бы этот комплекс не только под ПТ юзать , а скажем в X-PLANE или IL2 или LockOn.. с FS переменными вроде как понятно.. для этого есть FSUIPC и знающие головы , а вот с другими симами - пока темный лес. Еще интересует подключение внешнего железа к x-plane и протоколы обмена. Слишком обнадеживает x-plane как нормальный сим после выхода анонса FSX.. Покрайней мере в движке иксов гораздо больше фитч чем в FSX.

Отличная идея - через какой интерфейс подключается и сколько будет стоить? Я куплю одну штучку!

Что касается X-Plane все просто - любой параметр из приведенных на экране можно вывести наружу или ввести обратно в программу динамически в любой момент. Конечно, те величины, которые собственно вычисляются внутри смысла вводить нет - для этого сим и создан.

А протокол очень простой - UDP по сети или черз плагин непосредственно на том же компе. Вот например, как я считывю данные из СОМ1 и посылаю данные штурвала через UDP (моя очень старая программка - еще через компор работающая, но уже с 16битным положением штурвала). Если сравнить рисунок и текст, то видно, что что в седьмой позиции (там где стоит галка) - данные джойстика. Их восемь, но я посылаю только два - крен и тангаж. Данные x-plane кушает с плавающей точкой. Точно также и выводит - любую комбинацию из 900 параметров. Например, если поставить галку в позиции 50, то через UDP на указанный адрес сети будет выводится напряжение до восьми бортовых батарей. Ну и далее в том же духе.

Удачи!

Цитата:

---

# X-Plane 8.15 UDP Client

import win32file
import socket
import struct
import time
import serial

HOST = '' # Symbolic name meaning the local host
PORT = 49000 # Arbitrary non-privileged port
xplaneHost = ('192.168.0.61', 49000)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind((HOST, PORT))

ser = serial.Serial('COM1', 2400, timeout=1)

while 1:

byte1 = struct.unpack("1B", ser.read())
byte2 = struct.unpack("1B", ser.read())
byte3 = struct.unpack("1B", ser.read())
byte4 = struct.unpack("1B", ser.read())

pitch = byte1[0]*256+byte2[0]
roll = byte3[0]*256+byte4[0]

pitch = pitch / 32000.0 - 1.0
roll = roll / 32000.0 - 1.0

sendPacket = struct.pack('>5si8f', "DATA\n", 7, pitch, roll, 0, 0, 0, 0, 0, 0)
s.sendto( sendPacket, xplaneHost )

ser.close()

---

Э-х-х, блин.
Я лично себе такую систему( в смысле комерческую) представлял полностью независимую от софта, повязаную скажем через CANaerospace или Arinc-429, к которой через враппер данные льет хоть МСФС, хоть ЛокОН. Как у больших все.

Чтобы потом наработки и для реальных бортов переносить/отлаживать можно было, а получается опять пять-десять писюков с почти бытовыми УСБ-глюкалами натыкано, под управлением дельфийно/киликсовских заплаток. :-(

Цитата:

---

Сообщение от LazyCamel

Э-х-х, блин.
Я лично себе такую систему( в смысле комерческую) представлял полностью независимую от софта, повязаную скажем через CANaerospace или Arinc-429, к которой через враппер данные льет хоть МСФС, хоть ЛокОН. Как у больших все.

Чтобы потом наработки и для реальных бортов переносить/отлаживать можно было, а получается опять пять-десять писюков с почти бытовыми УСБ-глюкалами натыкано, под управлением дельфийно/киликсовских заплаток. :-(

---

Без проблем, присылай спецификацию - в CAN или любой другой бас тебе закатаю что хочешь! Только платить тоже как большие будешь! :p

Цитата:

---

Сообщение от LazyCamel

Э-х-х, блин.
Я лично себе такую систему( в смысле комерческую) представлял полностью независимую от софта, повязаную скажем через CANaerospace или Arinc-429, к которой через враппер данные льет хоть МСФС, хоть ЛокОН. Как у больших все.

Чтобы потом наработки и для реальных бортов переносить/отлаживать можно было, а получается опять пять-десять писюков с почти бытовыми УСБ-глюкалами натыкано, под управлением дельфийно/киликсовских заплаток. :-(

---

Для реальных бортов, есть реальные люди. Которые и занимаются серьёзным делом.

В нашем случае, народные умельцы развлекаются как могут.

Э-х-х, блин.
Я лично себе такую систему( в смысле комерческую) представлял полностью независимую от софта, повязаную скажем через CANaerospace или Arinc-429, к которой через враппер данные льет хоть МСФС, хоть ЛокОН. Как у больших все.
---

Поясни , ты про что ? как понять полностью независимую от софта ??
Поясни что есть враппер ? И как данные со штурвала и ли с какогонить батона попадают в переменную сима ? И кто её туда пихает , если в самом симе нет механизма запихивания переменных извне ? Неесть ли это как раз та заплатка ?


Чтобы потом наработки и для реальных бортов переносить/отлаживать можно было, а получается опять пять-десять писюков с почти бытовыми УСБ-глюкалами натыкано, под управлением дельфийно/киликсовских заплаток. :-(
---
Ну незнаю какие там глюкалки USB имееш в виду.. То что планируем и разрабатываем не совсем бытовая штука. И не совсем USB.. Это достаточно уникальная и наращиваемя почти до бесконечности система управления со своим достатоно уникальным протоколом.

Дело в том что все HUD устройства в том числе Mjoy это всеже привязка к дровам винды. Ну незахотел БГ сделать больше 8-ми осей и 32-х батонов.. Незахоетл - ненадо. Выбрасываем в зад вообще всю идею USB HUD устройств и делаем свою. Под управлением дельфийной заплатки данные с такой системы льются непосредственно в сим минуя всю хрень и все ограничения которыми упихана винда. Я про то и спрашиваю можно ли добратся до переменных LockOn и IL2 как добираемся до переменных FS , чтобы написать 'заплатку' нетолько для FS... Есть железка и юзай её в любом симе. Вот идея .. Да и дело то всего в обслуживающем софте..

Цитата:

---

Сообщение от Ezdok

Дело в том что все HUD устройства в том числе Mjoy это всеже привязка к дровам винды. Ну незахотел БГ сделать больше 8-ми осей и 32-х батонов.. Незахоетл - ненадо. Выбрасываем в зад вообще всю идею USB HUD устройств и делаем свою. Под управлением дельфийной заплатки данные с такой системы льются непосредственно в сим минуя всю хрень и все ограничения которыми упихана винда. Я про то и спрашиваю можно ли добратся до переменных LockOn и IL2 как добираемся до переменных FS , чтобы написать 'заплатку' нетолько для FS... Есть железка и юзай её в любом симе. Вот идея .. Да и дело то всего в обслуживающем софте..

---

Ezdok, вы и вправду там USB делаете? И насколько уже продвинулись?

Могу сказать что у меня джойстик занял 5% времени, остальное - сделать так, чтобы стек польностью все тесты USB2.0 стандарта проходил. А HID работает на любой OC так что я бы не стал его так с разворота отбрасывать. Как только вы HID отключаете так тут то вот как раз и надо писать драйвера низкого урованя дла всех возможных ОС. HID это очень общий стандарт, в него даже медицинская аппаратура и UPS входят, а прелесть в том, что драйверная прослойка между аппаратурой и приложениями уже в любой системе есть. А ограничения DirectX никакого отношения к HID не имеют. Устройство HID, например может иметь 65000 кнопок и столько же 32 битных осей. А написать прослойку между ним и симулятором можно за один вечер, так как драйвера HID в ОС уже есть и DirectX тут не причем.

Вы там вправду всерьез что-то делаете или пока так?.. Я бы с удовольствием купил добротный USB интерфейс сам.

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


---
Вобще мы планируем делать на USB2COM.. Разогнать COM до 250кбит и не парится с прослойками.. 250 кбит это мм.. 0.3 мс длительности пакета из 10-ти байт. 10 байт это обслужить ооочень много железок.. Но у нас протокол еще меньщей длины.. Поэтому нет никакого смысла напрягятся и юзать достаточно не покотоемкую систему на USB.... ПОТОК ТО какой ??? Нажал батон - раз в 5 минут , или дергнул рудами - раз в 1 час.. И то проблема реалтайма не в самом комплексе и скорости передачи пакетов , а в реакции самого сима , которая зависит ковсему прочему от рэнда видеокарты и других причин.. Так что передать поток непроблема . А вот с HID надо конечно в дальнейшем разобратся..... Но меня пугают цены на контроллеры с аппаратным USB.. Не с програмным а с аппартным. А поскольку цена одного контроллера с аппаратным USB порядка 15-17$ , отсутствует напроч прошивка контроллеров сторонними самопальными программаторами , затею с USB считаю пока делом каждого..... Мне лично пока ненравятся цены на USB комплектующие.. Дороговато. Тем более что в системе планирются использовать порядка 10-ти контроллеров. Самые скромные расчеты показывают , для полного реал-тайма сгодится скорость COM порта 115к... КУДА БОЛЬШЕ ? Примером тому уже обкатанная система EZ_BUS или FS_BUS .. как угодно.. скорость общения 19.2 через COM .. все работает как часы.. Кроме энкодеров , потому как сам сим очень медленно обрабатывает входящую инфу. У нас планируется повышенная частота опросов энкодеров и десятикратное увеличение скорости предачи пакетов в симулятор. Максимум обсчетов происходит в контроллерах.. Итак FPS нехватает..
---
А HID работает на любой OC так что я бы не стал его так с разворота отбрасывать.
--
Недоверие... в первую очередь к HID.. Задача просто передать данные из железки в комп и обратно.. Через какой путь проходит бедный пакет от железки я могу только догадыватся. Мы используем настоящий человеческий протокол с контрольными суммами , надежный , поверенный на многих железках и повторюсь , тратить время на то чтобы изучать весь USB с HUD вместе взятыми просто нет.. COM проверен до безобразия , весь расковырян вдоль и поперек. Слабые места изучены и изучены нюансы его работы... Контроллеры которые нам больше всего подходят для реализации затеи с аппартным USART стоят 3.5$ и поцене 1-го контроллера со встроенным USB можно будет собрать всю систему целиком.. USB не панацея.. Очень много очень дорогих и очень быстрых приборов до сих пор работают через COM или через его эмуляцию.. Комплекс на COM делаем исключительно для себя и если будем продавать то только полный пакет - тоесть софт+спаянные платы в корпусе.. с USB разъемом :-)).. Дешево не будет.. Однако прекрасно понимаем , что дорого COM железку продать уже не получится. Везде USB...

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

Про 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.

Про протоколы:

Речь же вроде шла про процедурный тренажер для больших, а не про наши поделки для флайт-симщиков? Все-таки найдите в сети стандарт на CANaerospace. Это протокол верхнего уровня. Используется в ЕвроВертушке и А380. Принят НАСА и МО США для новых БПЛА и перспективных самолетов.
Совершенно не обязательно использовать CAN в качестве физшины, можно хоть rs232 c опторазвязкой. Возможно и не придется собственные протоколы изобретать. Там как раз идет передача РЕАЛЬНЫХ полетных данных, как то курс, координаты, высота, вплоть до магнитного склонения, частот радиокомпаса и температуры газов перед и за турбиной.

ЗЫ:
По крайней мере я свой кокпит для Черной Акулы уже на его базе начинаю делать.

Цитата:

---

Сообщение от Ezdok

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

---

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

Цитата:

---

Сообщение от Ezdok

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

---

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

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

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

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


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

Цитата:

---

Сообщение от LazyCamel

прочитайте стандарт насчет 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 делал.

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

Цитата:

---

Сообщение от Ezdok

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

---

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

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

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

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

Цитата:

---

Сообщение от lbodnar

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

---

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

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

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

Цитата:

---

Сообщение от lbodnar

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

---

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

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

Цитата:

---

Сообщение от lbodnar

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

---

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

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

Цитата:

---

Сообщение от LazyCamel

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

---

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

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 точки больше.

---

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

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

Цитата:

---

Сообщение от LazyCamel

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

Про 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 Мбит/сек выдает???!!! ИМХО да!!!

Цитата:

---

Сообщение от ArGer0

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

---

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

Цитата:

---

Сообщение от lbodnar

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

---

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

Цитата:

---

Сообщение от lbodnar

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

---

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

Цитата:

---

Сообщение от LazyCamel

Изначально был. Описан в стандарте на хабы.
Если я ничего не путаю примерно так:
Под контрол-ендпоинт резервируется 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 байта в миллисекунду всегда приедут.

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

Цитата:

---

Сообщение от LazyCamel

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

---

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

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

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

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

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

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

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

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

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