Здрасте всем. Есть такие кто собирал FSBUS NG?
Меня вот пара вопросов интересует по схемотехнике (в аттаче схема COM-платы из оригинального PDF).
Собрал пока COM и Display-платы. Стоит сказать, что платы не оригинальные, а разведенные по новой (на SMD-компоненты), но схемы, по которым разводилось все это дело — 100% оригинальные, без какой-либо самодеятельности.
Так вот. Берем COM-плату, китайский тестер (в режиме звонилки, для проверки эл.контакта. Также показывает сопротивление между точками, если оно меньше 1000 Ом), подключаем питание к плате. Пробуем тестером между двух точек — землей и питанием. Тестер звенит и показывает -560 (странно что именно с минусом). При этом замыкания между землей и питанием нет (красный светодиод горит, а второй тестер показывает ток в 25мА). Когда питания нет — тестер не звенит. Обкатал тестер на других схемах — вроде не глючит сам по себе. Такое ощущение, что у питания и земли контакта нету, но потенциалы у них одинаковые… Странно, ведь плата была много раз (и не одним человеком) проверена на предмет плохого монтажа и замыканий дорожек, а echo-тест в FSBUSadmin и HyperTerminal показал, что все ОК.
Далее. Несмотря на первую траблу, удалось запустить дисплей. Сначала он показывает свой CID, потом то, что выставлю в FSBUSadmin (включая яркость). Но есть одно НО. Дисплей работает, если не подключать RESET-линию. Если ее подключить — собственно сброс и происходит. Померял напряжение на линии — так и есть, на RESET-е есть где-то 4.8В. Там же вроде не должно быть столько (если только перемычка на COM-плате не замкнута)??? Проверил еще раз монтаж на COM, особенно около перемычки — все нормально. Может какой компонент попался нерабочий? И вообще, объясните плиз принцип работы всего того куска для сброса. Зачем там так много всего? Я, есчессно, не особо по микроконтроллерам спец, но мне кажется, там можно было все проще сделать…
Питание — 5В стабилизированное. D2 (нечто ZF 3.9) заменен на smd-стабилитрон на 3,9В (то ли BZV, то ли BZX, не помню точно).
|
|
Сообщение отредактировал Screw — 15.06.2006 23:14
Кто-нибудь знает что значат «network error 10038», «… 10049», «… 10093» в FSBUSRouter (2.4.3.1, fsuipc)?
Сообщение отредактировал Screw — 16.06.2006 00:53
Вообще оригинальный FSBUS это тот пример который нестоит повторять при нынешней элементной базе.
Хотя кому как.
Тем более на носу выход FSX..
Сообщение отредактировал Ezdok — 16.06.2006 02:27
Если дело в цене, то не скажу, что мне этот проект обошелся в круглую сумму. Даже наоборот. Но тут свою роль играет и то, что каких-то компонентом у меня было в достатке. Если со стороны доступности каких-то элементов, то и тут ничего сложного — ничего труднодоступного и сложнодоставаемого я не увидел. Ну разве что ATmega8535-16PI, удалось достать только 8PI…
А вот по поводу ФСХ, простите, может не в курсе, что-то кардинально новое намечается? И интерфейсы к нему надо будет разрабатывать с нуля?
—
Не в деньгах дело.
Если по схеме есть какойто нюанс и он не описан в мануале , то 90% вероятности что схема не заработает , или заработает криво.. В схемотехнике FSBUS слишком много «придумано на коленке».. Особо с некоторыми модуляи ( FS Stepper например) …
Отсутствие прямого контакта с разработчиком недаст решить те или иные проблемы… Это касемо нетолько FSBUS.. А прямого контакта небыло .. Точнее был но вяло и неинформаьивно.. Поэтому и пришлось разрабтать альтенативную эелектронику для FSBUS. И как мне кажется более простую чем оригинал и более удачную в плане надежности .
—
А вот по поводу ФСХ, простите, может не в курсе, что-то кардинально новое намечается? И интерфейсы к нему надо будет разрабатывать с нуля
—
Да.. с нуля. ПОтому что все переменные будут находится совсем в других местах. Пройдет неменьше года как найдут нужные переменные.. В симе их около тысячи. За 3 года сторонними разработчиками для FS2004 проведена огромная работа. С выходом FSX придется делать все сначала. Немногие согласятся делать одно и тоже 2 раза. Для интереса — посмотри развитие FSUIPC.
По поводу FSBUS .. Сбор данных в этой системе завязан на FSUIPC . после выхода FSX это модуль долго будет в ауте , и соответственно все остально с ним связанное. FSROUTER тоже.. Это вот маленький пример. Поэтому расчитывать что роутер заработает с FSX ближайший год после его выхода , наивно .. Есть вообще информация что автор FSBUS больше небудет делать версий роутеров .. Соответственно FSBUS привязана пожизни к FS2004.. нО это слухи , хотя и правдоподобные.
Сообщение отредактировал Ezdok — 16.06.2006 14:52
У FSBUS, конечно, мягко говоря фиговая документация. Но на это обречены все проекты, в разработке и реализации которых участвует один человек, выдающий на гора, скажем, раз в пару месяцев, скудную пдф-ку и софт. Прослеживалось бы хоть какое-то участие «народных масс», как например в проекте PHCC (там хоть форум есть), так и дело бы не стояло на месте — одному надоело, другой инициативу перехватил… Хоть и за это автору FSBUS нужно большое спасибо сказать, однако такой вот, ммм, «closed-source», не всегда (вернее даже редко) означает «качество».
Пока ФСХ выйдет и прочно обоснуется у большого количества пользователей, пройдет немало времени. Мне, например, пока не светит капитальный апгрейд железа, дабы хоть как-то соответствовать средним «железным» спецификациям для ФСХ. Уж толком пока не знаю, что там будет такое супер-мега навороченное (окромя графики и луж на ВПП, судя по давним скринам), но меня пока и 2004й с довесками устраивает. Тем более FSBUS не на 2004й сим завязан, а на fsuipc и fsdconnect. А уж с чем они завязаны, это дело пользователя. К тому же, принимая во внимание, что FSDConnect — проект open-source, у него больше шансов быстрее и полнее приспособиться к ФСХ, нежели у fsuipc, продукта, поддерживаемом одним человеком, извлекающим из этого прибыль. Так вот, пока доживем до массового пользования ФСХ, глядишь и интерфейсы (всмысле фсдконнект и т.д.) к нему появятся… Не будет автор FSBUS дальше новых версий выпускать, ну и ладно, может парни из PHCC все же прикрутятся к МСФС (пока они только к FlightGear привязаны).
Ну а пока ни ФСХ не вышел, ни кризис среди интерфейсов не наступил, можно и с FSBUS поковыряться.
. Большое спасибо. И от друга тоже 😉 ). На что денег хватило, то и собрали, и уехал друг домой счастливый…
Кстати, собирали с другом ему FSBUS по Вашему варианту (а за тот вариант так и не поблагодарил в той ветке, где просил. ай-яй-яй
Ну а я решил еще и NG попробовать. Вот и возникла пара вопросов. Если есть пару комментариев по ним — буду очень признателен.
1. Кто тебе сказал что переменные будут в других местах???? (сам придумал?)
2. Зачем интерфейсы с нуля разрабатывать, если нужно только новый всуйпик ?
3. Ты думаешь FSUIPC разработал простой сельский парень никак не связанный с микрософтом?
4. А новый FSUIPC он скорее всего уже делает и на момент выхода будет продавать (что кстати у него неплохо получается)
5. Новый FSUIPC скорее всего так-же будет работать с фсбусом.
6. А фсбусу вообще пофигу чего куда гонять.
—
Новая компиляция EXE файла и около лежащих DLL библиотек — изменяет адреса ВСЕХ переменных. Новая версия сима — новый FSUIPC. Даже одна единственная лишняя строчка в исходном коде , смещает все адресное пространство и делает совсем другое расположение переменных……
—
2. Зачем интерфейсы с нуля разрабатывать, если нужно только новый всуйпик ?
—
Нефакт что FSUIPC вообще будет.. Ты читал планы разработчикка юпика ? Он прямо говорит — будет новый сим , тутже сделаю новую версию ? Я лично невидел…. Я не из последних слов знаю что такое искать переменные. Это ТИТАНИЧЕСКИЙ труд.. Сами разработчики софта в самом майкрософте НЕЗНАЮТ где конкретно и по каким смещениям лежат переменные. Потому что специально карту переменных для ввод-вывод операций для FS2004 НИКТО НЕ ДЕЛАЛ НИКОГДА. Это уже дело разработчика стороннего софта находить адрес той или иной переменной , переназначать в свое адресное пространство (упорядочивать) и делать на все это мануал.. Если майкрософт сделает карту переменных в новом симе (давно пора) то юпик нафиг ненужен будет вообще… Юпик — это достаточно хорошая помощь программеру для работы с переменными сима. Переменная которая находится черт знает где , перенаправляется по известному адресу.. И вся его работа. Такое вот упорядочивание… Но от FSUIPC повторюсь надо избавлятся. Это такой посредник между порядком и хаусом. Pro-tu154 тому поример как надо софт писать. Юпик ему ненужен…. У нас сейчас тестовая версия новой управлялки для сима прекрасно работает без FSUIPC напрямую с процессами сима где лежат переменные. Например сейчас активно ищем переменные ПТ.. Можно свой юпик написать.. Невопрос
—-
4. А новый FSUIPC он скорее всего уже делает и на момент выхода будет продавать (что кстати у него неплохо получается)
—
Продавать то будет , только ты уверен что FSROUTER будет заточен для работы с новым юпиком !? У меня по роутеру инфа несколько иная 🙁
Автор доконца доделать никак неможет начатое. А тут новый сим , новый юпик , новые адреса.. Проекто то БЕСПЛАТНЫЙ… Какой нафиг ему смысл сидеть и делать все заново.. подумай ?
——
Ты думаешь FSUIPC разработал простой сельский парень никак не связанный с микрософтом?
—
Именнно. Простой сельский парень юзает софт для поиска переменной ( есть такой) , играет в «загадочный черный ящик» или «хакера» , это когда дергаеш тумблер и смотриш c помощью этой софтины в каком куске памяти изменилась величина.. дальше анализируеш логику работы , пишеш мануал.. итак 1000 переменных… Представляеш объем работы ? Юпик постоянно обновляется на протяжении 3-х лет. Потосянно.. Думаеш там глюки с дымкой чувак исправляет ? … Нет .. находит новые переменные и обновляет версию.
Или ты хочеш сказать что майкрософт предоставил ему адресное пространство где конкретная переменная находится в памяти ?? Там сегмент , смещение .. Майкрософт сам незнает этого..
Юпик за последние 2 года стал стандартом. Сама идея — это уже не ноухау. майкрософту и приборостроителям давно пора складывать и обрабатывать переменные по известным заранее подготовленным адресам как сделано в X-Plane….
Тогда будет стандарт и работа внешних желез без предваорительного упорядочивания переменных.
А вообще ты сам знаеш что этот модуль делает кроме как дымку включет ?
Опиши , мне интересно..
—
Сообщение отредактировал Ezdok — 16.06.2006 19:55
или где про это можно почитать?
или где про это можно почитать?
В скромном приближении выглядит так: когда запускается программа, ей выделяется кусок памяти. Он делится на два блока (приближенно!): блок кода и блок данных. Соответственно все данные, которыми оперирует МСФС лежат в блоке данных.
Каждая ячейка памяти имеет свой номер (адрес). Однако используется не абсолютный адрес, а относительный. Тогда, определяется адрес начала сегмента памяти данных, а относительно него используются смещения (offsets), по которым адресуются находящиеся в данном блоке памяти ячейки.
Получается переменные лежат по смещениям (грубо говоря), по которому можно высчитать ее истинный адрес (что, собственно будет малополезно). Используются именно смещения, т.к. неизвестно по какому адресу блок данных МСФС окажется при следующем запуске. Иначе можно сказать, что смещения — это внутренняя адресация переменных внутри блока данных, т.к. внутри блока данных адресация переменных сохраняется от запуска к запуску.
В общем-то, это не единственная причина использования смещений…
Для чего, от чего, почему так, а не иначе можно почерпнуть практически в любой книге типа «Архитектура ПК» (или где есть одноименная глава, напр. в книге по ассемблеру).
Вообще-то интерфейс к переменным сима описан в SDK. В частности, все, что касается управления и индикации, описано в Gauges.h, который является частью Panels_SDK.
или где про это можно почитать?
В скромном приближении выглядит так: когда запускается программа, ей выделяется кусок памяти. Он делится на два блока (приближенно!): блок кода и блок данных. Соответственно все данные, которыми оперирует МСФС лежат в блоке данных…..
спасибо!!!
—
Это да , но на основе этих данных можно делать приборы , в которых переменные все равно будут зарыты в недрах сима. Нужны не сами переменные , а их точные адреса в памяти .. Если эти переменные из приборов напрявлять в COМ порт , то это уже меняет ход событий. Но я лично невидел чтобы хотябы 1 прибор выводил свои данные во внешнюю среду. Поэтому и нужны такие проги как FSBUS , для того чтобы переменные извлекались из недр сима и перенаправлялись по известным адресам..
А точные (абсолютные?) адреса совершенно не нужны. Все равно память приложениям выделяется динамически и не только после каждой компиляции, но и при каждом запуске абсолютный адрес той же переменной будет другим. Само же приложение прекрасно знает где у него чего и как это чего достать. Остается только попросить у приложения aka ФС показать или изменить некие данные под соответствующими именами, описанными в SDK.
Что же касается систем самолета, то рули высоты, направления, элероны, триммеры, закрылки, спойлеры, тормоза, РУД, всевозможные выключатели и другие элементы управления описаны в Gauges.h и доступны как для считывания, так и для установки в нужные значения. Panels_SDK охватывает не только тему приборов и индикации, но и управления воздушным судном вообще. Чего я действительно пока не нашел это динамики полета — линейных и угловых скоростей и ускорений, которые присутствуют в FSUIPC. Может просто плохо искал. Да и интересно это наверное в основном тем, кто задумывался над изготовлением подвижной платформы.
Кстати, только что глянул — управление обзором так же описано в Panels_SDK, так что и это не секретная информация. Рекомендую внимательно просмотреть список токенов (TokenVar.doc) и событий (EventIDs.doc). Думаю, что многие вопросы отпадут сами собой.
Сообщение отредактировал Stranger — 21.06.2006 18:00
—
Это описание штатного вращения головой. КОторое нивкакое сравнение не идет с качеством вращения Active Camera. Эт я так к слову.
—
Погодой не занимался, не скажу. Да и вообще, это скорее относится к сценарию, чем к управлению ВС. FSBus вроде как тоже ни к погоде, ни к динамике, ни к верчению головой отношения не имеет.
—
Чем и хороша идея внешнегно роутера — из него моджно добратся абсолютно до любой пременной сима ( правда которая описана в текущей версии FSUIPC) … А переменных там раз в 5 больше чем описано в SDK.. Базовые переменные в SDK описаны , но они никому не интересны по большому счету. Постому как если мутить систему I/O то должена быть большая универсальность , наче овчинка выделки нестоит.. Хотя лично я неподдерживаю эту идею.. Должен быть стандарт , протокол единый для всех разрабв железа , должно быть описание , SDK , модуль ввода-вываода должен находится в разделе Modules и запускатся вместе с симом и быть единым целым с ним.. А так всё это по большому счету самодеятельность.
Сообщение отредактировал Ezdok — 22.06.2006 11:42
Как можно откалибровать данные для использования в приборах с нелинейными шкалами?
Ну да, если верить бумажкам, то возможности у нового роутера почти безграничные
Однако заставить работать приборы через собстно «бейсик» а не routings в Ini у меня так и не получилось.
Кстати скорее всего калибровку можно использовать только при создании систем на C++ DLL. Вот тут нет ни слова про Basic: http://www.mycockpit.org/forums/showthread.php?p=82806