Итак, стоящая задача: создать кокпит Ми-8 с оживлением настоящих приборов, а при невозможности оживления — создание максимально правдоподобных имитаций. В качестве отправной точки имеется корпус кабины — останки какого-то тренажера. Строится все это даже не для себя, а для авиамузея, т.е. чистый альтруизм и практически никакого финансирования, поэтому цена комплектации — один из важных факторов.
В качестве управляющей программы выбран x-plane. Просьба этот пункт принять как данность и не обсуждать.
Архитектура системы видится следующая:
Электрически интерфейс разбит на две шины, одна для передачи данных от симулятора на индикаторы, вторая для передачи данных от органов управления в симулятор. Если прибор имеет и то и другое, то в него входят обе шины.
Поскольку на шине индикаторов только один мастер — коллизии исключены. В качестве интерфейса выбран RS485 по следующим соображениям:
1) Интерфейс полудуплексный, подходит при отсутствии коллизий.
2) Интерфейс предполагает наличие многих устройств (драйвер дешевых «обычных» SP491 рассчитан на 32 приемника), в отличие от RS232, который предназначен для соединения только двух устройств.
3) Используются диференциальные приемники и передатчики, рассчитаные на витую пару, отсюда следует хорошая помехозащищенность. Для fiyrus, комментарий на сообщение: резисторы-терминаторы на концах линии служат для согласования волнового сопротивления линии и следующего из этого исключения отражения сигналов от концов несогласованной линии. Отраженный сигнал накладывается на прямой и искажает его. Чем резче фронты сигнала, тем больше искажений внесет отраженный. Волновое сопротивление витой пары 120 Ом, именно поэтому номинал терминирующих резисторов выбирается таким, а не из соображений «чтобы ток побольше тек».
4) Недорогие драйвера, изначально рассчитанные на скорости более мегабита (SP491 — 5 Мбит). Предел для обычных драйверов RS232 — 115Кбит.
5) Интерфейс изначально рассчитан на большие расстояния.
Если не хватит пропускной или нагрузочной способности, то шина разбивается на две — приборы левого и правого пилотов.
Протокол с подтверждениями и повторами. Если устройство не подтвердило два повтора, оно считается неисправным и исключается из посылок на какое-то время (2-5 сек.).В прибор передается значение отображаемой физической величины. Поскольку каждый индикатор раз и навсегда жестко привязан к своему модулю управления, то все преобразования физ. величины в пупки, подающиеся на прибор с учетом всех калибровок происходят непосредственно в модуле.
В качестве интерфейса источников сигналов о положении органов управления, переключателей и т.п выбран CAN.
Часть причин описана в этом сообщении.
дополнительно: существуют небольшие контроллеры со встроенным модулем CAN ценой порядка 4 долл (их много у микрочипа). Снаружи требуется только драйвер розничной ценой в доллар. Это гораздо дешевле, чем реализовывать связь между контроллерами через эзернет.
На шине CAN мастеров много, но они передают свои данные с частотой 80 Гц (посоветована fiyrus в вышеупомянутой теме). Согласно моим расчетам в той же теме, все органы управления успеют передать свои состояния за 1/80 сек благодаря механизму разрешения коллизий, заложенному в CAN. Если частоты 80 Гц для каких-то датчиков будет мало, то можно разделить приборы на несколько групп, передающих информацию с разными периодами. Благодаря механизму приоритетов в CAN исключается блокирование сообщений от устройств с более высоким приоритетом устройствами с более низким. Для передачи необходимой информации достаточно 8 байтов сетевого уровня протокола CAN, поэтому никакие протоколы более высокого уровня поверх CAN не нужны.
В качестве соединителя этих шин с компьютером будет использоваться микросхема FT2232, на одном (или обоих) из UARTов которой будет висеть преобразователь UART-RS485 типа SP491 (у меня она есть, я их применяю) или MAX485 или аналогичный). К SPI-интерфейсу FT2232 будет подключаться CAN-контроллер MCP2515 и драйвер CAN MCP2551. Стоимость всех этих микросхем вместе на сегодняшний день в розницу в Риге около 10-20 долл.
Модуль управления каждым индикатором будет состоять из контроллера (ATmega8 / ATmega48/88 / АТ91SAM7S64), драйвера RS485 и выходного каскада. Для логометрических приборов — RC цепочка, для слаботочных приборов, требующих формирования трехфазного напряжания током до 1А — L293, для сильноточных — драйвера полевиков и полевики по аналогии с платой УАС из упомянутой выше ветки. По софту: софт будет состоять из двух частей — загрузчика, позволяющего обновлять прошивку прямо по интерфесу, без программатора, и собственно приложения, формирующего сигналы управления индикатором. Адрес каждого модуля будет жестко прошиваться на этапе изготовления одновременно с загрузчиком, благо программатор AVReal позволяет это делать автоматически. В протоколе планируется 5 команд: «идентификация», «посылка отображаемой величины», «чтение калибровок», «запись калибровок», «переход в режим загрузки». Загрузчик умеет отвечать только на команды «идентификация» и «переход в режим загрузки», приложение — на все. По команде «идентификация» прибор сообщает свой тип и номер версии прошивки (загрузчик сообщает номер версии ноль). Это позволяет найти все устройства на шине путем тупого перебора адресов и принять решение о необходимости обновления прошивки.
Модуль обслуживания органов управления будет состоять из драйвера CAN MCP2551, контроллера со встроенным CAN-контроллером (PIC24HJ64GP202 или аналогичного, цена около 4 долл.) или связки ATmega8/48/88 и MCP2515. Использование потенциометров для чтения положения РУ и Шаг/Газ считаю нецелесообразным из-за невысокой износостойкости потенциометров. Думаю реализовать датчики положения на том же принципе, на котором работают электронные штангенциркули.
В качестве шлюза между симулятором и FT2232 будет программа, которая со стороны FT2232 будет поддерживать протокол шин, а со второй стороны может иметь интерфейс как к x-plane, так и к MSFS или другому симулятору через любой протокол, если кто-то захочет его дописать. Хоть через IOCP,(для vitabutch: это протокол более высокого уровня и не имеет отношения к реализации шины, и я так и не понял, чему вы в нем восхищаетесь). Эта программа при необходимости будет однозначно и без всяких калибровок переводить пупки, посылаемые симулятором в физическую величину, посылаемую на индикатор. И обратно — градусы органа управления в пупки симулятора. Таким образом исключится необходимость калибровать прибор под каждый симулятор.
Все исходники будут открыты. В качестве компиляторов используется бесплатные avr-gcc (WinAVR), gcc (MinGW). Среда разработки схем и плат — планируется KiCAD, если мне удасться его освоить с моими многолетними пикадовскими привычками.
Ну и первые результаты: Судя по внешнему виду и внутреннему устройству, мне попался ИТЭ-1. Реализован загрузчик и формирование трехфазного синуса. Управление пока из терминалки (кнопками + и -) через RS232.
Макет контроллера: ATmega8, L293, 6 диодов SS12 (припаяны снизу), 78L05, 4 конденсатора, 1 резистор, светодиод. В корпусе разъема DB9 собран преобразователь UART-RS232, в боевой системе вместо него будет SP491.
Первые пуски показали следующее: при резком увеличении частоты двигатель выходит из синхронизма и либо останавливается, либо начинает вращаться с примерно втрое меньшей скоростью. Для входа в синхронизм требуется понизить частоту до ~20% шкалы. Надо будет предусмотреть в программе контроллера ограничение на скорость изменения.
Завтра попробую хитрый метод формирования фазного напряжения, позволяющий получить ту же амплитуду межфазного напряжения при на 22% меньшем питании, вот такой:
черным показано напряжение с одного из выходов драйвера, голубым — напряжение между фазами.
Сообщение отредактировано САБ: 23 September 2009 — 02:24
==
Непонятно что вы передадите этими 8-ю байтиами. И еще поди небось за одну посылку ?…
Например одна ось — это 10 бит. Это минимум 2 байта. Тоесть получается передавать нужно за два прохода ..тоесть 80/2=40 раз в сек.
А осей таких миниумм 10 в кокпите.. Итого 40 герц /10 = 4 герца на каждую ось ? ..круто.. У нас все потенциально 65536 осей передаются с частотой 80 герц. Хоть одна , хоть все сразу..
fiyrus (25 September 2009 — 20:09):
Например одна ось — это 10 бит. Это минимум 2 байта. Тоесть получается передавать нужно за два прохода ..тоесть 80/2=40 раз в сек.
Какая-то у вас интересная математика. 8 байт в одной посылке. По 2 байта на ось это 4 оси в одной посылке. Я в той ветке показывал расчет, что даже если на каждую ось будет свое устройство ввода, т.е. в каждой посылке будет передаваться всего одна ось и накладные расходы максимальные, то за один цикл 80 Гц на скорости 512КБит сможет «высказаться» 101 устройство. Т.е.это 9-кратный запас для 10 осей. 90% времени шина будет простаивать.
fiyrus (25 September 2009 — 20:09):
Нет, правда, как вы считаете? 65536 осей помножить на 16 бит (два байта) это уже 1048560, т.е. ваш мегабит, даже без всяких контрольных сумм и прочих накладных расходов. Куда тут еще 80 Гц вставить?
Сообщение отредактировано САБ: 26 September 2009 — 02:38
САБ (23 September 2009 — 00:16):
Посмотрел форму тока в обмотках — идеальный синус. Никаких следов ШИМа, т.е. индуктивность обмотки является прекрасным фильтром. Частота ШИМа 7.8КГц.
САБ (23 September 2009 — 00:16):
Работает. В расчетах немного ошибся, амплитуда увеличилась на ~11%, на 22% увеличился размах.
==
О ! Тоесть всем устройствам на шине нужно знать когда начинается этот цикл опроса так ?…
Я правильно понимаю ?
==
получаем 102 оси за цикл. Если оси группировать по 8, то int(4681/8) * 8 = 464 оси.
====
Что то совсем плохо с расчетами. 464 оси это 7424 байта ПОЛЕЗНОЙ ИНФОРМАЦИИ нужно передать в интервале 1/80=0.0125 сек. Ну никак не пролазит эторасчет в 512 кбит.
Давайте посчитаем!
Скорость 512 кбит. Тоесть за 1 секунду мы можем передать 512 тысяч бит.
Но у нас есть пресловутые 80 герц — это полный цикл сбора данных с устройств на шине.
1/80 =0.0125 сек — это время за которое происходит полный цикл. За 0.0125 сек на скорости 512 кбит мы сможем передать 6400 бит или 800 байт. Если брать пакет СAN то чуть меньше половины из них составляет служебная инфомация.Тоесть остается прмерно 448 байт полезной информации за 0.0125 сек. Это всего 25 осей без возможности принимать информацию от тумблеры ..галетники..энкодры..и тд..!!!!
забавно у вас получается, 48 бит (6 байт) служебной инфы и 8 байт полезной..мдя.
Что то я не пойму как вы за один цикл передадите все предполагаемые оси? Если все контроллеры сразу же начнут передавать оси — шина ваша встанет колом потому что все начнут прередавать пакеты одновременно… Или вы сделаете систему синхронизации? И укажете каждому стройству на шине чтобы все устройства передавали пакеты строго друг за другом ?… Что то я не улавливаю смысл всей работы шины. В мануале на CAN сказано что коллизии и решение коллизий это фактически основаная часть работы шины. Столкновения пакетов на этой шине без отдельной системы запросов или опроса устройств отдельной линией гарантировано! Для обнаружения колизий в контроллерах CAN и сделан детектор коллизий полагаясь что о начале посылке данных контроллеры CAN не будут знать заранее. Если два устройства посылают одновременно пакет,их детекторы срабатывают и устанавливается статус коллизии у обоих. В этом случае считается что пакеты не доставлены. Тогда сразу же после обнаружения коллизии одно из устройств с более высоким приоритетом немедленно отсылает пакет повтороно, второй с более низким приоритетом ждет предполагаемое время дл яотправки первым кстройством и отсылает свой пакет следом запервым. Это здорово когда всего висят 2 датчика на шине и посылают пакет раз в 2 секунды. В этом интервале система вполне справляется с повторными посылками.. А у вас же предполагается минимум 3-4 устройства осей каждый будет иметь высший приоритет, потому как оси — они требуют реал тайма и будет не приятно когда РУД опрашивается с 80-ю герцами а РУС с 10-ю , а педали так те вообще раз в секунду..Любые органы управления обделаять временем нельзя никак… Представляете что будет на вашей шине? Один из модулей (при условии отсутствия общего синхросигнала 80 герц) будет хреначить пакеты , второй тоже и третий и четвертый, пакеты будут сталкиватся от всех четырех , в результате большая часть времени будет уходить на перепосылки и ожидания в приоритетах пакетов..сколько на это потребуется время — вы примерно догадываетесь.. Гарантированно в интервале 80 герц будут доходить пакеты от устройства с высшим приоритетом , в два раза реже с приоритетомна шаг ниже и в 3-4 раза реже с приоритетом еще на шаг ниже… Во время перепосылки столкнувшихся пакетов будет готов следующий результат преобразования АЦП и нждно уже будет посылать следующую порцию пакетов.. И процесс с перепосылкой будет повторятся вновь и вновь.. Правильно никаких перезапросов нет! Есть куча пепепосылов которые ставят шину колом. Хрен редьки не слаще. Мы уже смотрели это все осциллографом изучали около месяца эту CAN на экстрим тестах.. Было ощущение что шина самовозбуждалась от этих перепосылок и пока не оставиш два модуля или не снизишь частоту опроса осей примерно до 10ти герц , по шине гуляли коллизии и перезапросы.. Учитывая то что в современных тренажерах придется еще гонять данные c компа в виде дампов блоками по 1 и более килобайт в какиенить внешние FMS или мультидисплеи — то ограничивать себя 512-ю кбитами и 8-ю байтами за 1 фрейм ну простите как то не серьезно…Вам придется как я раньше и говорил разделять шины. Ваш комплекс получается многослойный, состоящий из отдельных шин. Это точно не для симмеров. ПОскольку многие симмеры так и не сумели запустить аппаратную часть простейший EZ_bus. Просто вы сейчас уже себя ограничиваете в расширении системы и будущих возможностях выбирая CAN. Система получится сложной в повторении без промышленного изготовления печаток потому как если брать PIC контроллеры то это 30-я и 33-я серия (это которые здоровые по 50 выводов в SSOP корпусах) с расстоянием между ножек не пригодным к изготовлению ПП в домашних условиях. Проверяйте еще раз не арифметику а реал..В реале ваша система начиная с 4-х реалтайм устройств будет работать хуже мджоя. Проверено! за сим откланиваюсь. Я все чем мог тем помог.
Сообщение отредактировано fiyrus: Вчера, 05:12
fiyrus, on 26 September 2009 — 11:46, said:
10 байт это 2 мс на скорости 512кбит. Тоесть одна посылка занимает целых 2 мс. Интервал 80 герц — это 0.0125 сек. Тоесть 125 миллисек. 125/2 = 62 пакета умещается в промежуток 80 герц.
Действительно, странная какая-то. Вы бы уже с порядками определились.
===
Что то у вас арифметика какая то странная.. Вы посмотрите осцилографом какой длины ваш байт в конечном счете вместе с протоколом самой CAN находится на самой линии. Я что то н енащел в документации имстинную длину пакета и соответственно истинное время занятие шины на момент передачи пакета. Вы не берете в расчет то что будут коллизии. Чем больше устройств тем больше коллизий. Проблемы с реалтаймом начинаются примерно с 5-ти пакетов (5-ти осей ) и коллизии возрастают в арефмитической прогресии с увеличением этих утсройств. Нужно смотреть какой длительностью сам физически пакет CAN после формирования всего на свете. Не забывайте что а автопроме нет задач одновременно передавать данные с частотой 80 герц. Там событийная система — например один раз за поездку передать информацию о закрытых дверях , раз в 2 секунды передать пакет для индикатора масла и тд.. ) При длине 10 байт (именно столько может быть конечная длина вашего байта обрамленного пакетом). 10 байт это 2 мс на скорости 512кбит. Тоесть одна посылка занимает целых 2 мс. Интервал 80 герц — это 0.0125 сек. Тоесть 125 миллисек. 125/2 = 62 пакета умещается в промежуток 80 герц. Это если их четко распределить друг за другом. Но это очень мало для систем с перезапросами! Потому что если одно устройство посылает пакет и второе устройство посылает пакет в интрвале 2мс от начала первого — то пакеты сталкиваются. Уже с двумя устройствами мы гарантировано имеем коллизи в неком фиксированном интервале времени. Три утсройства — три пакета будут вываливатся. и так далее по количеству подключенных модулей. Чем выше частота передачи — тем чаше пакеты сталкиваются. .. В этом случае наступит пауза на шине на перезапрос пакетов. Это уже минимум 2 мс на каждый перезапрос. Во время перезапроса третье устройство посылает пакет и сталкивается с ответом от перезапроса. Я вообще с трудом представляю работу CAN шины в реальном времени хотя бы с 10-ю осями.. Я уже не говорю о потоковой передаче данных. Это всего два устройства. Что будет еслди вы повесите 10 устройств — легко предсказать.. Тоже самое происходит в LAN .. Но извините — там 10 мбит и длина пакета на этой скорости в 20-30 раз меньше вашего ! В этом случае можно расчитывать на реал тайм с 10-ю устройствами. И то, хабы то и дело виснут и тормозят на перезапросах.
Стройте ! Только дам совет — перед тем как тратить средства на изготовление целого копита — проведите эекстрим тест вашей системы на стенде. Зарядите туда скажем хотя бы 20 осей и покрутите все одновременно. Сделайте тестовую утилиту которая показывает все 20 осей одновременно и синхронно покрутите все эти оси…Видео с экрана монитора в студию! Я тогда достану свой стенд и продолжу с CAN шиной в качестве поднания. Может быть мы что то не так делали ?..
Сообщение отредактировано fiyrus: 26 September 2009 — 13:54
Сообщение отредактировано САБ: Вчера, 17:03
fiyrus (27 September 2009 — 20:52):
Похоже, вы не читаете того, что я старательно расписываю. Да, каждое устройство будет само генерить для себя 80Гц цикл. Ни с кем не синхронизованный. Если в момент завершения этого цикла идет передача чужого пакета, контроллер CAN ожидает окончания передачи и пытается передать свой пакет. Если он самый приоритетный из желающих — он свой пакет отправит. Если нет — проиграет арбитраж и повторит попытку. Как только отправил — начинает отсчет нового цикла. Т.е. синхронизаия получается автоматически, менее приритетное устройство «пропускает вперед» более приоритетное, но в цикле остается еще куча времени, чтобы все устройства успели передать свою информацию, выстроившись в очередь по приоритету.
Ну вот совсем на пальцах:
Есть четыре устройства: A, B, C и D. Устройство C захотело передать информацию (шина свободна) и начало передачу. Пока оно передает, захотели устройства A, B и D. Они видят, что шина занята и ожидают окончания передачи C. Передача закончилась и они все втроем ломанулись передавать. Одновременно. На этапе передачи адреса (поле арбитража) выиграло устройство A, как имеющее меньший адрес и, значит, более высокий приоритет. Оно передает свой пакет, B и D ждут окончания передачи. Передача закончилась, B и D начинают передачу. Арбитраж выигрывает B, передает свой пакет. D дожидается окончания передачи и передает свой — ему уже никто не мешает. Итого на передачу четырех пакетов затрачено время, равное длине четырех пакетов. И до конца цикла еще осталась куча времени.
Я не знаю — как еще понятнее объяснить.
Сообщение отредактировано САБ: 26 September 2009 — 21:58
Я правильно понимаю ?
Нет. Ему просто надо делать паузу 1/80 сек. между посылками.
==
Если каждое устройство будет делать паузу и каждое устройство будет стартовать без единого опорного генератора 80 гец , их фазы спауз и стартов будут совпадать кратно разнице частоты квалцевыз резонаторов. Кварцевые резонаторы всегда имеют нестабильность. Разница в 1-2 герца всегда есть. Это примерно каждый 160-й посыл будет иметь коллизию.
Вам нужно будет синхронизировать фазы отправки пакетов для всех устройств. Тогда устройство 1 оправляет пакет немедленно, устройство 2 спустя 1.6 мс , устройство 3 — 3.2 мс и так далее до конца заполнения тайм слотов или фреймов как угодно. Как только наступил синхросигнал — цикл повторяется.. Этот сигнал можно гонять по шине от какогонить задающего контроллера….Впринципе должно работать..
Я только так вижу работу такой системы. Тоесть должен быть кто то ведущий-отсчитывающий-говорящий всем устройствам о начале цикла опроса. Просто ума не приложу как вы будете обяснять устройствам что настало время нового цикла для сбора информации ? Только не говорте что у каждого устройства будет свой внутренний генератор 80 гец который синхронизируется 1 раз по подаче питания скажем..
Сообщение отредактировано fiyrus: Вчера, 23:00