nabbla (nabbla1) wrote,
nabbla
nabbla1

Category:

"МКО через UART", часть 6, синхронизация (с СД)

Пора заняться командами управления (КУ). "Для общего образования" выпишем их все, чуть обсудим - и потом выполним ровно ту, которая нужна в моём приборчике.


Чтобы задать команду управления, нужно указать подадрес 00000 или 11111 - это одно и то же, мы должны реагировать на оба варианта.

А 5-битное поле "количество слов данных" тогда будет задавать одну из команд. Старший бит является признаком наличия слова данных, т.е команды 0x00 .. 0x0F вообще не требуют слова данных, а команды 0x10..0x1F используют ОДНО слово данных, а передаёт ли его контроллер шины (КШ) или передаём в ответ мы - определяется признаком "приём/передача", как и обычно. Каждой команде управления соответствует вполне конкретное значение этого признака, даже если слово данных не используется! Во всех командах без слова данных, этот признак равен единице ("передача"), не знаю почему, вот захотелось.

За почти что 50 лет, прошедших с первой версии Mil-Std 1553, так и не придумали все 32 команды. На деле получается 9 команд без слова данных, и ещё 6 команд со словом данных. Перечислим их:

00000 - Принять управление интерфейсом (не может быть групповой, без слова данных). Контроллер шины может отправить эту команду оконечному устройству, а оно в ответном слове скажет, принимает ли управление интерфейсом (превращаясь в новый контроллер шины) или нет. Если да, то "старый" контроллер шины должен замолкнуть, чтобы не создавать коллизий.

Не знаю, применялось ли это хотя бы разок? Понятно, что контроллер шины - это "точка единичного отказа", если он замолкнет - то информационный обмен прекратится, и должен быть какой-то механизм включения резервного контроллера шины. Но зачем передавать управление, пока имеющийся функционирует - не очень ясно.

Ещё и сказано: в авиации подобное не применять!

Ну и нам в этом приборе данная команда ну совсем не нужна! Что интересно, если нам её пошлют - мы вернём вполне себе корректное ответное слово с ноликом в признаке "принято управление интерфейсом", то бишь с НАШИМ ОТКАЗОМ СТАТЬ КШ.

00001 - Синхронизация (может быть групповой, без слова данных). Чёткого описания, как именно реагировать на эту команду, ГОСТ не приводит. Некие общие слова "например возврат в исходное состояние синхронизирующего устройства, запуск последовательности импульсов". То есть, это уже в конкретной задаче придумывается назначение. У нас это именно что синхронизация часов и есть, только чуть другая команда, "со словом данных".

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

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

00011 - Начать самоконтроль ОУ (может быть групповой, без слова данных). В ГОСТе 52070-2003 (равно как и в Mil-Std 1553) описание расплывчатое. "Начать самоконтроль" - и всё тут. На удивление подробно указано, что на этот самоконтроль должно уйти не более 100 мс, и в это время имеем право не реагировать на прочие сообщения, либо на всё отвечать признаком занятости (а можем и работать в штатном режиме, если есть такая возможность). Но что такое самоконтроль - тайна великая есть.

Для интересу можно посмотреть, что под этим понимается в микросхеме 1895ВА2Т. Посылая ответное слово на эту команду, микросхема проверяет, что образовалось на приёмнике - он продолжает принимать даже отправляемое слово. Если пришло ровно то, что было отправлено (синхроимпульс правильный, чётность правильная, данные совпадают), самоконтроль считается пройденным. В противном случае устанавливается признак "Неисправность ОУ", хотя это можно отключить.

Насколько это полезно - меня опять терзают смутные сомнения! Это должны быть очень специфические неисправности, что мы-таки умудряемся принять эти команды, и даже корректно отправить ответ! В большинстве случаев мы либо ничего не получим, либо ничего не передадим.

00100 - блокировать передатчик (может быть групповой, без слова данных). Идея примерно в том, что на одном из каналов (то ли основном, то ли резервном), кто-то хулиганит, приводя к коллизиям. И тогда контроллер шины посылает сообщение по другому каналу, с просьбой выключить передатчик на том, проблемном канале, в надежде, что оно тогда заработает получше. Особенно весело, что можно вообще всех повыключать через групповое сообщение!

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

У нас, насколько я знаю, эти команды использоваться не будут.

00101 - разблокировать передатчик (может быть групповой, без слова данных). Видимо, когда КШ наконец-то поймёт, кто же это мусорил, он потихоньку включит всех остальных назад.

00110 - блокировать признак неисправности ОУ (может быть групповой, без слова данных). Получив эту команду, мы больше не должны выдавать признак "Неисправность ОУ", даже если считаем себя неисправными. Объясняется, чтоб "глаза не мозолило" - дескать, да, приняли к сведению, вы неисправны, а теперь заткнитесь, не до вас сейчас.

Не понимаю, зачем, если можно было просто на стороне КШ игнорировать этот конкретный бит.

00111 - разблокировать признак неисправности ОУ (может быть групповой, без слова данных). Отменяем команду, описанную чуть выше :)

Может, здесь имелось в виду организовывать систему наподобие прерываний, когда любой "нештатный" ответ контроллеру шины (будь то "ошибка в сообщении", "абонент занят", "неисправность абонента", "неисправность ОУ") вызывает прерывание процессора, и он вместо работы "по накатанному" (озадачить этого, озадачить того, получить данные отсюда, послать их туда) начинает громко думать, что же делать. И такая вот "маскировка" прерываний. Сложно сказать...

У нас этих команд не будет. А даже и были бы - пока мы формировать признак неисправности ОУ всё равно не собираемся...

01000 - установить ОУ в исходное состояние (может быть групповой, без слова данных). Своеобразный "сброс". Из упомянутого в ГОСТе - нужно разблокировать передатчики (если их заблокировали) и разблокировать признаки неисправности ОУ. А "дополнительные" фичи уже придумываются в каждом конкретном случае.

У меня, к примеру, есть команды по передаче изображения и по передаче дампа памяти. И то, и другое явно не лезет в 32 слова, поэтому будет идти счётчик слов. Первый раз запросили изображение - получили первые кусочки. Второй раз запросили - пошли дальше, и так далее. А если прислать команду "установить ОУ в исходное состояние" - то все эти счётчики сбросятся в ноль. Вроде бы логично :)

В ГОСТе даже упомянуто, что данная команда должна выполниться за 5 мс. Не возражаю.

01001..01111 - РЕЗЕРВ. Что-то мне подсказывает, что "навеки".

Теперь команды со словом данных!

10000 - передать векторное слово (передача от ОУ к КШ, не может быть групповой). Эта команда должна посылаться, если в ответном слове был послан запрос на обслуживание. В векторном слове должна быть некая расшифровка, чего именно мы хотим.

В микросхеме 1895ВА2Т, если я правильно понял написанное, будет передан один из подадресов (т.е число от 1 до 30), в котором вот-вот переполнится буфер на передачу, в надежде, что сейчас эти данные наконец-то запросят. Ну, это один из вариантов реализации. Так-то ГОСТ молчит, как оно работает. Как говорится, "на своё усмотрение".

10001 - синхронизация (с СД) (передача от КШ к ОУ, может быть групповой). То же самое, что синхронизация (команда 00001), но со словом данных :)

Эта команда у нас реализуется: в слове данных содержится число от 0 до 99 - "номер вычислительного такта", и мы должны его занести в свои "часы реального времени". Потом на основе этого числа будет формироваться метка времени для целевых данных.

10010 - передать последнюю команду (передача от ОУ к КШ, не может быть групповой). В качестве слова данных передаётся содержимое командного слова (но синхроимпульс от слова данных, разумеется). По сути, "расширенная версия" команды "передать ОС" - здесь также в ответном слове должны находиться все "накопленные" признаки (принято групповое сообщение, ошибка в сообщении), но ещё мы указываем, на какую же команду мы так отреагировали.

Наверное, полезная вещь, но у нас пока использоваться не будет.

10011 - передать слово ВСК ОУ (передача от ОУ к КШ, не может быть групповой). ВСК означает "Внутренняя Система Контроля". Имеется в виду, что данная команда передаётся через некоторое время после команды "Начать самоконтроль ОУ", и это и есть результаты самоконтроля.

Что именно должно содержаться в этом слове - не уточняется, это уже при разработке конкретной системы нужно договариваться. Микросхема 1895ВА2Т передаёт 16 признаков ошибок, которые он обнаружил: невыключившийся передатчик (Transmitter Timeout), несовпадение полученной и переданной команды по основной и по резервной шине (Loop Test Failure A, Loop Test Failure B), сюда же информация, какие из передатчиков сейчас заблокированы, стоит ли блокировка признака "неисправность ОУ", по какому из каналов последний раз шёл обмен, и т.д.

Наверное, что-то в этом есть. Но мы пока такое реализовывать не будем, у нас и не просят. А то будет как у пилота Пиркса, где корабль так увлёкся самоконтролем, что не смог нормально приземлиться.

10100 - блокировать выбранный (i-й) передатчик (передача от КШ к ОУ, может быть групповой). Это уже задел на многократно резервированные линии данных, где шины не ДВЕ, а БОЛЬШЕ. В таких системах, команда "заблокировать передатчик" привела бы нас в замешательство - "какой именно"? В случае двух шин - понятно - "соседний". А здесь - передадим номер передатчика в слове данных.

Снова не знаю, использовалась ли эта команда хоть раз. У нас - точно нет, т.к шин ровно две, "основная" и "резервная".

10101 - разблокировать выбранный (i-й) передатчик (передача от КШ к ОУ, может быть групповой). То же самое.

10110..11111 - РЕЗЕРВ, скорее всего уже "навеки".

Что ж, пора реализовать "Синхронизацию (с СД)".

Мы уже вводили "провод" isServiceCommand (выбраны команды управления, т.е подадреса 00000 либо 11111). Введём регистр isSyncDWCommand:

always @(posedge clk) if (isIdle)
	isSyncDWCommand <= isServiceCommand & (curWordWordsCount == 5'b10001);


Как водится, он имеет право принимать "любое значение", пока в состоянии ожидания (sIdle), но переходя в sReceive, мы получим правильное значение: 1 только если была прислана команда "Синхронизация (с СД)".

И теперь формируем сигнал sync, поступающий в часы реального времени:
assign sync = DataValid & RXisData & State[0] & isSyncDWCommand;


Итак, сигнал будет послан, когда мы принимаем слово данных, находясь в состояниях sReceive либо sTransmit. Но поскольку sTransmit мы проходим за один такт, там мы ничего не получим (к тому времени новое слово при всём желании не успеет прийти), остаётся лишь одно слово данных, полученное в состоянии sReceive.

Вот, как бы, и всё. Вход данных для часов реального времени напрямую соединён с выходом приёмника, тут всё хорошо.

Теперь вся штуковина (протокольный контроллер + "адресная заглушка" + часы реального времени + "фиктивный" передатчик) синтезируется в 147 ЛЭ (без декодирования данной КУ выходило 138 ЛЭ). В общем-то, стало больше ЛЭ, поскольку отсинтезировались те части часов реального времени, которые до этого "выкидывались" из-за всегда нулевого значения sync. Хотя дополнительная логика, разумеется, появилась. Пока сойдёт. Предельная частота 75,19 МГц, нормально.

На уже проверенных посылках никогда не возникает sync=1, что и ясно: это всё были другие команды.

И давайте опробуем широковещательную (групповую) команду "Синхронизация (с СД)" и слово данных, где лежит значение 0x0042:


Да: при поступлении слова данных у нас срабатывает sync=1, данные "защёлкиваются" в часы реального времени. Потом я ещё даю Mark=1, как будто бы в этот момент у нас прошла экспозиция кадра. Как результат, на выходе TimeStamp появилось 0x8400. Да, мы так и хотели: значения от 0 до 99 влезают в 7 бит, и мы решили, это будут старшие 7 бит, а в младших будут лежать "доли вычислительного такта", чтобы максимально точно отметить время поступления данных. Вот 0x42 и переехал на 9 бит влево, всё правильно.

Как видно, попутно ещё прошла запись слова данных в оперативную память по адресу 0x000. Ну и ладно, я считаю. Все команды управления будут направляться на адреса либо 0x000, либо 0x1E00, ровно два слова могут быть ими затёрты. Пущай это будут "жертвенные" слова, не хочу пока логику усложнять.


Принцип, как обрабатывать команды управления, надеюсь, понятен. Через некоторое время ещё реализуем команду "Установить ОУ в исходное состояние". Но прежде хочу разобраться с заголовками массивов и CRC.
Tags: ПЛИС, работа, странные девайсы
Subscribe

Recent Posts from This Journal

  • Тестируем atan1 на QuatCore

    Пора уже перебираться на "железо" потихоньку. Решил начать с самого первого алгоритма, поскольку он уже был написан на ассемблере. В программу внёс…

  • Формулы приведения, что б их... (и atan на ТРЁХ умножениях)

    Формулу арктангенса на 4 умножениях ещё немножко оптимизировал с помощью алгоритма Ремеза: Ошибка уменьшилась с 4,9 до 4,65 угловой секунды, и…

  • Алгоритм Ремеза в экселе

    Вот и до него руки дошли, причина станет ясна в следующем посте. Изучать чужие библиотеки было лениво (в том же BOOSTе сам чёрт ногу сломит), писать…

  • atan на ЧЕТЫРЁХ умножениях

    Мишка такой человек — ему обязательно надо, чтоб от всего была польза. Когда у него бывают лишние деньги, он идёт в магазин и покупает какую-нибудь…

  • Ай да Пафнутий Львович!

    Решил ещё немного поковыряться со своим арктангенсом. Хотел применить алгоритм Ремеза, но начал с узлов Чебышёва. И для начала со своего "линейного…

  • atan(y/x) на двух умножениях!

    Чего-то никак меня не отпустит эта тема, всё кажется, что есть очень простой и эффективный метод, надо только его найти! Сейчас вот такое…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 4 comments