nabbla (nabbla1) wrote,
nabbla
nabbla1

Category:

Мучаем 5576ХС4Т, часть 'hD - МКО (МКИО, Mil-Std 1553) для бедных, введение

Часть 0 - покупаем, паяем, ставим драйвера и софт
Часть 1 - что это вообще за зверь?
Часть 2 - наша первая схема!
Часть 3 - кнопочки и лампочки
Часть 4 - делитель частоты
Часть 5 - подавление дребезга кнопки
Часть 6 - заканчиваем кнопочки и лампочки
Часть 7 - счетчики и жаба
Часть 8 - передатчик UART
Часть 9 - Hello, wolf!
Часть 'hA - приёмник UART
Часть 'hB - UART и жаба
Часть 'hC - полудуплексный UART
Часть 'hD - МКО (МКИО, Mil-Std 1553) для бедных, введение.
Часть 'hE - приёмопередатчик МКО "из подручных материалов" (в процессе)
Часть 'hF - модуль передатчика МКО
Часть 'h10 - передатчик сообщений МКО
Часть 'h20 - работа с АЦП ADC124s051
Часть 'h21 - преобразование двоичного кода в двоично-десятичный (BCD)
Часть 'h22 - Bin2Bcd с последовательной выдачей данных
Часть 'h23 - перемножитель беззнаковых чисел с округлением
Часть 'h24 - перемножитель беззнаковых чисел, реализация
Часть 'h25 - передаём показания АЦП на компьютер
Часть 'h26 - работа над ошибками (быстрый UART)
Часть 'h27 - PNG и коды коррекции ошибок CRC32
Часть 'h28 - передатчик изображения PNG
Часть 'h29 - принимаем с ПЛИС изображение PNG
Часть 'h2A - ZLIB и коды коррекции ошибок Adler32
Часть 'h2B - ускоряем Adler32
Часть 'h2C - формирователь потока Zlib
Часть 'h2D - передаём сгенерированное PNG-изображение
Часть 'h2E - делим отрезок на равные части
Часть 'h2F - знаковые умножители, тысячи их!
Часть 'h30 - вычислитель множества Мандельброта
Часть 'h31 - ускоренные сумматоры
Часть 'h32 - ускоренные счётчики (делаем часы)
Часть 'h33 - ускоряем ВСЁ
Часть 'h34 - ускоренные перемножители
Часть 'h35 - умножители совсем просто
Часть 'h36 - уравновешенный четверичный умножитель


Возьмёмся, наконец, за Мультиплексный Канал (информационного) Обмена, ГОСТ Р 52070-2003 или, говоря русским языком, Mil-Std 1553B. Штука эта разработана довольно давно, в семидесятых годах, но используется до сих пор в авиации и космонавтике, причём далеко не только в России. Как говорится, работает - не лезь!


У нас была большая терминологическая путаница, когда речь шла об UART. Само слово UART означает асинхронный приёмопередатчик, тогда как "физический уровень" для этой передачи может быть разным - RS232, RS485 и другие. Когда речь заходит об RS485, произносятся слова о шине, т.е это не просто передача "точка-точка", а можно вешать на шину довольно много устройств. Но как обеспечить безотказную работу (без коллизий), как устройствам адресоваться друг к другу - в стандарте не прописано вообще, не говоря уже о формате передачи данных - всё это отдаётся на откуп разработчикам.

Примерно та же история с весьма неплохой шиной CAN - как захочешь, так и будет.

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

Как показывает практика - не так уж и хорошо. Когда отдельные изделия, подключаемые к шине, делаются разными людьми и даже разными организациями, разнесёнными в пространстве и времени (одно изделие было изготовлено 10 лет назад, но ничего принципиально нового там всё равно не сделаешь, законы физики не поменялись; другое изделие - только-только в процессе разработки), отсутствие общепринятого стандарта на эту шину, затрагивающего не только уровни напряжений и тип проводов, но и скорость передачи, форматы пакетов, способы разрешения коллизий и адресации - печальное зрелище. Например, сделанное 10 лет назад изделие работает на 9600 бит/с, ему больше и не надо, а теперь мы поняли, что скорость передачи на шине должна быть никак не меньше 256 кбит/с. Ничего не остаётся - либо дорабатывай то старое изделие, либо подключай его по выделенному каналу. Кроме скорости, наверняка изменится и формат команд - тогда сделали по-простому, ему присылают букву "A", он в ответ шлёт данные, но сейчас такое делать нельзя, был придуман новый протокол информационного обмена, где сначала идёт общий заголовок пакета с адресом устройства, количеством слов данных для передачи, кодами коррекции ошибок а-ля CRC и многое другое. Лично у нас "протокол информационно-логического взаимодействия" - ругательство, потому что его вечно не удаётся вовремя со всеми согласовать, а когда стороны уже готовы это сделать, прибегает разработчик и говорит - я передумал, это хрень какая-то, уродство, а надо ВОТ ТАК делать, и предлагает новый протокол, и всё начинается по-новой.

Ещё одна неприятная особенность что UART (RS232, RS485), что CAN - мы обязаны сохранять постоянную составляющую сигнала. Пропустить сигнал через трансформатор для гальванической развязки - не вариант. В авиационных и космических приложениях очень любят гальваническую развязку, требуют её в каждом изделии, что вынуждает ставить отдельный источник питания на 5 вольт, питающий микросхему приёмопередатчика RS485, плюс 2-3 оптрона для передачи данных взад-вперёд. Один - на приём, второй - на передачу, третий - указывать микросхемке, работать ли на приём или на передачу. Далеко не все знают, что без него можно и обойтись - хватит и диода с конденсатором, чтобы первое же "проседание" сигнала передачи до нуля включало бы передатчик и держало его включенным в течение одного байта. Затем пойдёт следующий стартовый бит - и всё повторится.

МКО от описанных недостатков свободен. У него совершенно чётко нулевая постоянная составляющая и узкий спектр сигнала - через трансформатор он передаётся легко и непринуждённо. Скорость передачи как была утверждена в 1975 году, 1 МБит/с (без учёта накладных расходов), такой и остаётся по сию пору. Если этого достаточно - вперёд, можно применять.

В МКО применён самый армейский способ разрешения коллизий - на шине есть самый главный участник, Контроллер Шины (КШ, он же BC, Bus Controller), и без его разрешения начинать разговор запрещено! Когда он к тебе обратится - вот только тогда и отвечай, причём мешкать нельзя, на раздумья отводится от 2 до 12 микросекунд, потом тебя сочтут мёртвым или пришибленным, возможно, попробуют обратиться по резервному каналу, а если и тогда ответ не последует - быть беде.

Прописана структура передаваемых данных, определено три типа слов - командные слова (КС), ответные слова (ОС) и слова данных (СД), способ адресации устройств и в целом логика информационного обмена. Об этих вещах мы ещё поговорим в своё время.

В общем, плюсов у этого стандарта достаточно много, но есть и один очень жирный минус - ЦЕНА.

Не так давно, когда мне понадобилось подключиться к устройству по RS485, я купил китайский конвертер USB в RS485 аж за 209 рублей, и он замечательно заработал на скорости 256 кбит/с. Сколько-то битов он съел, но это оказалось даже полезно - удалось выловить злой баг с обработкой пакетов, когда "неправильные" данные, передаваемые по каналу, приводили к зависанию устройства.

С МКО такой же трюк не пройдёт. PCI-плата МКО для компьютера стоит 66 000 рублей, USB-устройство (например, к ноутбуку подключить) - 73 000 рублей, а в формате pci-e mini card - и вовсе 134 000 рублей.

Отладочная плата МКО и Arinc429 от LDM-Systems стоит в лучшем случае 36 000 рублей (когда схема для Arinc429 не напаяна, есть только два канала МКО), при том, что это только лишь драйвер, без протокольной логики, которую надо реализовывать самому на ПЛИС либо микроконтроллере.

Не заказывать отладочную плату, а закупить компоненты и спаять самому - тоже не так уж просто. Трансформаторы ТИЛ-6В и микросхемы 5559ИН13У2 не купишь просто так в чип-и-дипе (или в других розничных магазинах), их надо заказывать от лица предприятия, и надеяться, что их поставят в срок. И не надо думать, что цена получится сильно ниже.

Идея такова: разработка почти что штучной продукции авиационного и космического назначения - по-любому вещь очень дорогостоящая, а плата МКО всё равно никогда не сравнится по цене с офигительным цифровым осциллографом. Это не должна быть проблема разработчика - предприятие должно осуществить закупку всего необходимого, так что и платы МКО в каждом компьютере будут находиться.

Разумеется, так оно и происходит, но как правило, с огромными задержками. Вам уже давно пора согласовать с заказчиком протокол информационного обмена и изготавливать работающий макет изделия для ЛОИ (лабораторно-отработочные испытания), который не стыдно и заказчику отвезти и попробовать "состыковать" по МКО, а у вас тупо работать не с чем, поскольку пока контракт заключат, пока финансирование откроют, пока в отдел закупок поступят ваши пожелашки, пока они закажут эти платы, пока их изготовят (а это вещь в лучшем случае мелкосерийная, если вообще не штучная), привезут, примут на баланс - уже год пройдёт, в лучшем случае!

Так жить нельзя! Каждый разработчик должен иметь в своём полном распоряжении некоторое количество приёмопередатчиков МКО, не подходящих для отправки в космос, но вполне годных на Земле, сделанных из очень дешевых частей, зачастую халявных.

Сейчас кощунство выскажу, но эти приёмопередатчики могут даже не выполнять всех требований ГОСТ. Скажем, согласно ГОСТ 52070-2003, при непосредственном подключении устройства к шине, должны стоять защитные резисторы 56 Ом на каждом из проводов. Имеется в виду, что выгоревший транзистор в выходном каскаде не должен привести к короткому замыканию на линии. На ней появится дополнительная нагрузка в 112 Ом, из-за чего распространение сигнала немножко нарушится, но в целом шина ещё не накроется, остальные устройства продолжат работать на ней как ни в чём не бывало.

Увы, наличие этих резисторов означает: на выходе трансформатора должна быть амплитуда 12..20 вольт, и в момент передачи мы будем потреблять 1,7 ватта (не считая других цепей), тут уже немудрено подпалить USB вход, наверняка нужно отдельное питание.

Но если мы делаем устройство для сопряжения с компьютером, то если оно сгорит, у нас в любом случае работа прекратится, так что можно не заморачиваться с этим принципом "один отказ не приводит к неисправности" - отказавшись от этих защитных резисторов, мы одним махом снижаем энергопотребление в 4 раза! Теперь имеем 5 вольт, 75 мА, это уже приемлемо, и транзисторы подойдут маломощные.

В следующей части перейдём к практике, покажем пару простейших схем, вполне справляющихся со своей работой.
Tags: ПЛИС, работа, странные девайсы
Subscribe

Recent Posts from This Journal

  • Огарь крупным планом

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

  • Я создал монстра!

    Вот нормальная счастливая пара разъёмов ОНЦ-БС-1-10/14-Р12-2-В и ОНЦ-БС-1-10/14-В1-2-В: У розетки кроме основного выступа, отмечающего "верх",…

  • Нахождение двух самых отдалённых точек

    Пока компьютер долго и упорно мучал симуляцию, я пытался написать на ассемблере алгоритм захвата на ближней дистанции. А сейчас на этом коде можно…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 1 comment