nabbla (nabbla1) wrote,
nabbla
nabbla1

Categories:

"МКО через UART" часть 4: чиним ответное слово

Шлю я, шлю я ей за пакетом пакет,
Только, только нет мне ни слова в ответ

Песняры, "Вологда"

У нас ответное слово формируется когда надо, правильно указывается, что это не слово данных (значит, передатчик сделает паузу перед началом передачи, и выставит правильную полярность синхроимпульса), вот только содержание передаётся "какое попало". Это и надо исправить.

Заодно и разобраться, что за флажки передаются в ответном слове...

Повторим картинку:
GOST.png


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

Далее, самый весёлый признак "ошибка в сообщении"

В буржуйском Mil-Std 1553 повсюду маячат слова Invalid и Illegal. У нас они переведены как "недостоверное" и "недопустимое".

Если в командном слове какая-то фигня с синхроимпульсом, или не сошлась чётность, его обзываем "недостоверным" и НАЧИСТО ИГНОРИРУЕМ. Ведь мы не можем быть уверены, что оно вообще было адресовано нам! И устраивать коллизию на шине, когда в ответ на какой-то откровенный мусор сразу несколько устройств пытаются ответить "чего это вообще за хрень вы мне прислали!" нет никакого смысла.

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

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

Вообще, описано всё это весьма расплывчато, и есть разночтения относительно того, как это реализовывать. По счастью, конкретно у нас РКК Энергия написали: "отсутствие ответа будет восприниматься точно так же, как ответ с ошибкой в сообщении", т.е можно особой разницы не делать.

Далее идёт признак Передача ОС. Это некий "рудимент": предлагалось с помощью этого бита делать явное разграничение между командным и ответным словом, в командном тут всегда будет единица, а в ответном всегда нолик. Правда, число подадресов тогда падает с 30 до 15. Судя по всему, потом сообразили, что особой нужды в этом нет, но на всякий случай здесь надо передавать нолик.

Запрос на обслуживание - наверное, самое близкое, что в этом протоколе есть к "прерыванию", ну или в целом к инициации обмена со стороны "оконечного устройства". То есть, на любом этапе информационного обмена (шлют ли данные нам или запрашивают у нас) есть возможность выставить этот признак - и если контроллер шины запрограммирован на него реагировать, он может отправить команду управления "Передать векторное слово", в котором можно сформулировать свой запрос более конкретно, аж в 16 битах :) Потому оно и "векторное", как в "векторе прерываний".

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

Резерв - так и не придумали за 50 лет (Mil-Std 1553 где-то в 70-х появился), для чего эти биты применить, просят передавать нолики.

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

В нашем протоколе говорится, что контроллер шины никогда не будет посылать команду "Передать ОС", так что можно здесь не заморачиваться - всегда передавать нолик.

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

В нашем протоколе говорится, что "Абонент занят" будет трактоваться точно так же, как "Ошибка в сообщении" или просто отсутствие ответа: несколько раз нас ещё запросят, могут ещё и по резервной шине спросить (вдруг на основной шине у нас что-то отвалилось), и не получив ответа, сочтут "мёртвыми" и выключат. Так что буду здесь передавать нолик.

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

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

Принято управление интерфейсом - очень специфическая вещь, где контроллер шины может "слагать с себя полномочия" и назначать другое устройство контроллером шины, и оно в ответ должно выдать здесь единичку, подтверждая, что отныне будет новым контроллером шины. Даже в ГОСТе прописано, что применять в авиации данную команду (и соответствующий флажок) не стоит.

Ну и у нас в протоколе такое не предусмотрено, во всяком случае не с нашим приборчиком. Буду передавать нолик.

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

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

Дело тёмное, но в нашем протоколе обо всём этом ни слова, передаём нолик - и бед не знаем!

Пора уже это дело реализовать!

У нас, как будто бы "на будущее", была оставлена строка:

assign Q = TxMux;


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

Можно написать взамен:
assign Q = State[0]? TxMux : {OurAddr, MessageError, 10'b00_0000_0000};


Вот и выйдет ответное слово. Если мы не выводим "адресную заглушку" наружу (за пределы ПЛИС), то вообще 15 из 16 бит ответного слова известны заранее, сейчас и MessageError всегда в нуле, из-за чего у нас вообще число ЛЭ не прибавилось! Впрочем, это потому что передатчик "фиктивный", там очень простая защёлка стояла, и добавить в неё "вход синхронной установки" довольно легко.

Проверяем:


Да: раз за разом отправляем ответное слово 0x3000. Нетрудно сообразить, что так и есть: старшие 5 бит это адрес оконечного устройства, "6". Четыре старших бита, 0011, записываются как "3", а все последующие уже нулевые.


С этим разобразлись. Теперь нужно реализовать логику MessageError, хотя бы при получении неверной комбинации "приём/передача" и подадреса. А ещё домучать "команды управления". Ещё бы сделать автоматическую проверку заголовков сообщений и CRC, а также формирование CRC как последнее слово при передаче. Ну, потихоньку всё это провернём.

По уже реализованному, нам, возможно, не хватает провода Timeout с приёмника, чтобы при возникновении недопустимой паузы мы сбрасывались в начальное состояние sIdle. Всему своё время.
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 

  • 0 comments