МИКРОСХЕМА ИНТЕГРАЛЬНАЯ К1921ВК01Т. Руководство пользователя (от 10.09.2019)

177

П р и м е ч а н и е – Если требуется перераспределить объекты сообщений в списки

повторно, необходимо приостановить работу узлов CAN (установить бит INIT регистра
NCR), а после занесения объектов в списки возобновить ее (сбросить бит INIT).

18.5

Прием и передача сообщений

Прием сообщения

После завершения приема сообщение сохраняется в объекте сообщения в

соответствии с установленным алгоритмом (см. рисунок 18.19).

Рисунок 18.19 – Алгоритмы приема и передачи сообщения

178

Помимо сохранения данных в объекте сообщения, контроллер CAN осуществляет

обмен данными с ЦП.

При приеме сообщения информация сохраняется в объекте сообщения только в том

случае, если установлен бит MSGVAL регистра MOSTAT. Если ЦП очищает бит
MSGVAL, контроллер CAN останавливает запись в объект сообщения, и далее объект
может быть реконфигурирован центральным процессором с последующей записью в него
информации без участия контроллера CAN.

Полученное с шины сообщение может быть сохранено в объекте сообщения только в

случае,  если  установлен  бит  RXEN.  Контроллер  CAN  проверяет  состояние  бита  RXEN
только  во  время  фильтрации  принимаемого  сообщения.  После  того,  как  сообщение
принято,  состояние  бита  не  имеет  значения  и  не  оказывает  влияния  на  дальнейшее
сохранение данных в объекте сообщения.

Бит RXEN позволяет управлять блокированием объекта сообщения – после сброса

бита RXEN полученное сообщение сохраняется в объекте сообщения, который получил
приоритет, но в сохранении последующих сообщений этот объект не принимает участия.

Реконфигурация объекта сообщения центральным процессором во время работы

контроллера CAN (например, сброс бита MSGVAL, изменение объекта сообщения и
повторная установка бита MSGVAL) происходят следующим образом:

- объект сообщения получает приоритет;
- ЦП очищает бит MSGVAL для реконфигурации объекта сообщения;
- после реконфигурации ЦП снова устанавливает бит MSGVAL;
- завершается получение сообщения;
- если установлен бит MSGVAL, полученные данные сохраняются в объекте

сообщения, генерируется запрос на прерывание, устанавливается соответствующий флаг;

- если сконфигурировано, производятся шлюзовые и FIFO операции.

П р и м е ч а н и е – После реконфигурации объекта сохранение данных по завершении

получения сообщения может быть нежелательным. Запретить запись данных в объект
сообщения можно посредством бита RTSEL.

После получения объектом сообщения приоритета его бит RTSEL устанавливается

контроллером  CAN,  открывая,  таким  образом,  объект  сообщения  для  записи.  После
приема  сообщения  контроллер  CAN  дополнительно  проверяет  возможность  записи  в
объект сообщения, а именно – установлен ли все еще бит RTSEL. И только в том случае,
если  бит  RTSEL  установлен,  полученные  данные  сохраняются  в  объекте  сообщения
(вместе со всеми последующими действиями, которые указаны выше).

Если во время операций контроллера CAN объект сообщения становится

некорректным (сброс бита MSGVAL), бит RTSEL должен быть сброшен до того, как бит
MSGVAL будет установлен снова, или, по крайней мере, одновременно с ним. Это
необходимо для предотвращения сохранения старой информации в объекте сообщения.

Реконфигурация объекта сообщения должна происходить следующим образом:
- сброс бита MSGVAL;
- реконфигурация объекта сообщения, пока бит MSGVAL сброшен;
- сброс бита RTSEL и далее установка бита MSGVAL.

Индикатором процесса сохранения (изменения) данных в объекте сообщения

является флаг RXUPD, который выставляется с началом процесса сохранения (изменения)
и сбрасывается с его окончанием.

После сохранения полученного сообщения (идентификатора, бита IDE, кода длины

данных, поля данных, в случае сообщения данных) выставляется флаг NEWDAT. Если к
моменту выставления (завершение сохранения/изменения данных) флаг NEWDAT был

179

уже установлен, выставляется флаг MSGLST, который говорит о том, что произошла
потеря данных.

Флаги RXUPD и NEWDAT позволяют произвести чтение корректных данных из

объекта сообщения во время текущих операций контроллера CAN. Рекомендуемая
последовательность действий следующая:

- сброс флага NEWDAT;
- чтение данных (идентификатор, данные и т. д.) из объекта сообщения;
- проверка флагов NEWDAT и RXUPD – оба флага должны быть сброшены. В

случае невыполнения этого условия возвращение к первому действию;

- если флаги NEWDAT и RXUPD сброшены, то содержимое объекта сообщения

корректно и не используется контроллером CAN в течение операции чтения.

Поведение флагов RXUPD, NEWDAT и MSGLST идентично как для сообщений

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

Передача сообщения

Алгоритм передачи сообщений показан на рисунке 18.19. Одновременно с

копированием  данных  (идентификатора,  бита  IDE,  бита  RTR,  равного  биту  DIR,  кода
длины данных и собственно данных) из объекта сообщения, содержимое которого должно
быть  передано  во  внутренний  передающий  буфер  соответствующего  узла  CAN,  для
контроля  соблюдения  четкой  последовательности  выполнения  всех  операций
устанавливаются биты состояния.

Сообщение может быть передано только в случае, когда все четыре бита MSGVAL,

TXEN0, TXEN1 и TXRQ установлены.

Бит RTSEL выставляется после того, как объект сообщения получает приоритет для

передачи своего содержимого. Когда данные объекта сообщения копируются в
передающий буфер, бит RTSEL проверяется, и если он установлен, сообщение передается.
После успешной передачи сообщения бит RTSEL проверяется снова, и если он
установлен, осуществляются дальнейшие операции.

Для полной и завершенной реконфигурации корректного объекта сообщения

должны быть выполнены следующие шаги:

- очистка бита MSGVAL;
- реконфигурация объекта сообщения, пока бит MSGVAL сброшен;
- сброс бита RTSEL и установка бита MSGVAL.

Сброс бита RTSEL гарантирует как полное отключение объекта сообщения от

текущей передачи, так и то, что никакие операции (копирование данных в передающий
буфер, включая сброс бита NEWDAT, очистка бита TXRQ, прерывание сообщения и т. д.),
относящиеся к старой конфигурации этого объекта сообщения, не повлияют на новую
конфигурацию после установки бита MSGVAL.

После завершения передачи содержимого объекта сообщения в передающий буфер

узла CAN, флаг NEWDAT аппаратно сбрасывается, тем самым обозначая, что объект
сообщения открыт для записи новых данных.

Если после успешной передачи сообщения (на CAN-шину) флаг NEWDAT все еще

остается сброшенным (в объект сообщения не были записаны новые данные), флаг TXRQ
аппаратно сбрасывается. Если же флаг NEWDAT был установлен программно (в связи с
необходимостью передачи новых данных), флаг TXRQ не сбрасывается, тем самым
разрешая передачу новых данных.

180

18.6

Фильтрация сообщений

Фильтрация при получении сообщений

При получении узлом CAN сообщения определяется объект сообщения, в котором

будут сохранены получаемые данные в случае успешного приема.

Объект сообщения считается корректным для приема, если одновременно

соблюдаются условия:

- объект сообщения распределен в список объектов сообщений узла, который

принимает сообщение;

- бит MSGVAL установлен;
- бит RXEN установлен;
- бит DIR равен биту RTR принимаемого сообщения. Если бит DIR установлен,

объект сообщения (объект передачи) может принять только сообщение удаленного
запроса. Если бит DIR сброшен (объект приема), объект сообщения может принять только
сообщение данных;

- если бит MIDE установлен, то бит IDE получаемого сообщения оказывает

следующее влияние:

- если бит IDE (регистр MOAR) установлен, то бит IDE принимаемого

сообщения должен быть равен единице (расширенный идентификатор);

- если бит IDE сброшен, бит IDE принимаемого сообщения должен быть равен

нулю (стандартный идентификатор);

- если бит MIDE сброшен, значение бита IDE принимаемого сообщения не

важно, т. е. допускаются сообщения, как со стандартным, так и с расширенным
идентификатором;

- идентификатор полученного сообщения полностью (побитно) совпадает с

идентификатором, хранящимся в регистре MOARn объекта сообщения, за исключением
битов, закрытых маской регистра MOAMRn, значение которых не важно. На рисунке
18.20 показан пример проверки идентификатора.

Рисунок 18.20 – Проверка идентификатора полученного сообщения

Среди всех объектов сообщений, которые отвечают указанным выше критериям, для

сохранения полученного сообщения выбирается объект с наивысшим приоритетом. Для
задания приоритета используется поле PRI в регистре MOAR. Объект сообщения, у
которого значение поля PRI меньше, имеет больший приоритет. При равенстве значений
поля PRI приоритетным считается объект сообщения, который предшествует следующему
в списке.

181

Фильтрация при передаче сообщений

Когда требуется передача содержимого какого-либо объекта сообщения, в

соответствующих управляющих регистрах выставляются флаги, указывающие на
необходимость передачи. Объект сообщения считается корректным для передачи, если
одновременно соблюдаются условия:

- объект сообщения распределен в список объектов сообщений узда CAN;
- флаг MSGVAL установлен;
- флаг TXRQ установлен;
- флаги TXEN0 и TXEN1 установлены.

Может возникнуть ситуация, когда передачи требуют одновременно несколько

объектов сообщений. Среди всех объектов, которые отвечают указанным выше
критериям, для передачи выбирается объект с наивысшим приоритетом.

Объект сообщения, у которого значение поля PRI меньше, имеет больший

приоритет. При равенстве значений поля PRI разных объектов приоритет определяется
следующим образом:

- при PRI = 10b – согласно правилам арбитража передачи сообщения;
- при PRI = 01b/11b приоритет имеет объект сообщения, который предшествует

следующему в списке.

Объект сообщения, являющийся корректным для передачи и имеющий приоритет,

будет осуществлять передачу первым. Остальные объекты сообщений будут переданы по
очереди, согласно их приоритетам.

Объект сообщения определяется как стандартный объект сообщения, если в регистре

MOFCR значение битового поля MMC равно нулю. Стандартный объект сообщения
может принимать и передавать сообщения, согласно правилам, описанным выше.

На рисунке 18.21 показано формирование запроса на передачу объекта сообщения.

Рисунок 18.21 – Формирование запроса на передачу объекта сообщения

18.7

Удаленные запросы

После получения узлом CAN сообщения удаленного запроса и сохранения его в

объекте сообщения, выставляется бит запроса передачи для ответа на удаленный запрос
(отправка сообщения данных) или для автоматического повторения запроса.

В зависимости от состояния бита FRREN объекта сообщения, который принял

сообщение удаленного запроса, возможны два варианта действий:

- если бит FRREN сброшен, то устанавливается флаг TXRQ этого объекта;
- если бит FRREN установлен, то устанавливается флаг TXRQ того объекта, на

который указывает поле CUR объекта, принявшего удаленный запрос. При этом поле
CUR не меняет своего значения.

182

Состояние регистров объекта сообщения, передающего сообщение удаленного

запроса

У объекта сообщения, передающего сообщение удаленного запроса, в регистре

MOSTAT  должен  быть  сброшен  бит  DIR  (объект  передает  сообщение  данных) и
установлены  биты  TXEN0,  TXEN1,  MSGVAL  и  TXRQ.  Значение  идентификатора  в
регистре  MOAR  передающего  объекта  сообщения  должно  быть  равно  значению
идентификатора принимающего объекта сообщения (или совместно с регистром MOAMR
обеспечивать успешное прохождение фильтрации), чтобы сообщение удаленного запроса
было принято принимающим объектом другого узла. Само сообщение удаленного запроса
должно содержать идентификатор принимающего объекта сообщения, поэтому значение
регистра  MODATAL  передающего  объекта  сообщения  должно  быть  равно  значению
регистра MOAR принимающего объекта.

Состояние регистров объекта сообщения, принимающего сообщение

удаленного запроса при FRREN = 0

У объекта сообщения, принимающего сообщение удаленного запроса, должны быть

установлены биты DIR (объект принимает сообщение удаленного запроса), TXEN0 и
TXEN1 (если отвечать на запрос будет сам), RXEN и MSGVAL. Регистры MODATAL и
MODATAH должны содержать данные, которые будут переданы в ответ на запрос.

Состояние регистров объекта сообщения, принимающего сообщение

удаленного запроса (при FRREN = 1) и содержащего данные для ответа на запрос

У объекта сообщения, принимающего сообщение удаленного запроса, должны быть

установлены биты DIR, RXEN и MSGVAL. Битовое поле CUR должно указывать на номер
объекта сообщения (должен находиться в том же узле, что и объект принявший
сообщение удаленного запроса), содержащего данные, предназначенные для передачи в
ответ на поступивший удаленный запрос.

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

запрос, должны быть установлены биты DIR, (объект передает сообщение данных),
TXEN0, TXEN1 и MSGVAL. Бит TXRQ устанавливается автоматически при приеме
сообщения удаленного запроса принимающим объектом сообщения.

Прием ответа на запрос (переданного сообщения данных) осуществляется

стандартным объектом сообщения запрашивающего узла CAN (обмен данными
происходит между объектом сообщения, хранящим данные для отправки в ответ на
запрос, и объектом сообщения запрашивающего узла).

18.8

Дополнительные режимы передачи

Дополнительно имеются два режима, каждый из которых может быть выбран

индивидуально:

- режим передачи данных с защитой от повторений;
- режим однократной пересылки данных.

Режим передачи данных с защитой от повторения

Выбирается установкой бита SDT регистра MOFCR.
После приема сообщения данных и сохранения его в объекте с установленным

битом SDT, бит MSGVAL этого объекта аппаратно сбрасывается, чтобы исключить
возможность повторного приема и записи в этот объект. Этот режим нельзя использовать
для базового объекта FIFO структуры.

В ответ на сообщение удаленного запроса, принятое объектом с установленным

битом SDT, будут отправлены данные из объекта сообщения, на который указывает поле

183

CUR объекта, принявшего удаленный запрос. После этого бит MSGVAL объекта
принявшего сообщение удаленного запроса сбросится.

П р и м е ч а н и е – Объект, принявший сообщение удаленного запроса, не может быть

источником данных, передаваемых в ответ на запрос. Это означает, что в данном режиме
бит FRREN объекта, принявшего удаленный запрос, обязательно должен быть установлен.

Режим однократной пересылки данных

Выбирается установкой бита STT.
Бит TXRQ сбрасывается, когда содержимое объекта сообщения копируется в

передающий буфер узла CAN. Таким образом, в дальнейшем, при неудачной (вследствие
ошибок) пересылке сообщения по CAN-шине, повторной передачи не будет.

18.9

FIFO структура объектов сообщений

Регистр MOFGPRn объекта сообщения n содержит установки указателей на объекты

сообщений, которые используются при операциях FIFO и шлюзовых операциях.

В случае сильной загрузки ЦП обработка серии сообщений может быть затруднена –

например,  вследствие  получения  и/или  передачи  большого  числа  сообщений  за  малые
промежутки времени. Для таких случаев предусмотрена система буферов быстрого ввода-
вывода, так называемая FIFO структура, которая может функционировать  автоматически
и  позволяет  избежать  потери  принимаемых  сообщений,  минимизировать  время
подготовки  сообщений  к  отправке,  а  также  генерировать  прерывания  по  окончании
операций.

Допускается организация нескольких параллельных FIFO структур. Число структур

и их составляющих зависит только от количества доступных объектов сообщений. FIFO
структура может быть создана, изменена и удалена в любой момент времени, даже во
время операций контроллера CAN.

На рисунке 18.22 представлена основная FIFO структура. Она состоит из одного

базового объекта и n-ого числа вспомогательных объектов.

Рисунок 18.22 – FIFO структура с базовым объектом и n вспомогательными

объектами

184

Вспомогательные объекты объединяются последовательно в списки (подобно

спискам объектов сообщений). Базовый объект передающей FIFO-структуры может быть
занесен  в  любой  список.  Хотя  на  рисунке  базовый  объект  не  относится  ни  к  одному  из
списков,  он  может  быть  вставлен  в  любую  последовательность  вспомогательных
объектов.  Это  означает,  что  базовый  объект  одновременно  является  и  вспомогательным
объектом  (шлюзовые  операции  не  возможны).  Порядковые  номера  объектов  сообщений
(0, 1, 2 и т. д.) не имеют никакого значения при FIFO операциях с объектами.

Вспомогательные объекты должны быть определены в общий список (так как они

последовательно связаны). С помощью указателей (битовые поля BOT, CUR и TOP)
можно присоединять базовый объект к вспомогательному объекту, независимо от того,
принадлежат базовый и вспомогательный объекты одному списку или разным спискам, но
базовый должен быть первым в списке в таком случае.

Минимальная FIFO структура может состоять из одного объекта сообщения,

который будет одновременно являться и базовым, и вспомогательным (фактически не
используется). Максимальная FIFO структура может включать в себя все 256 объектов
сообщений.

В базовом объекте FIFO границы установлены: поле BOT указывает на самый

младший элемент FIFO структуры, поле TOP – на самый старший элемент, поле CUR – на
вспомогательный  объект,  который  в  настоящий  момент  выбран  котроллером  CAN  для
передачи  сообщения.  Как  только  начинается  передача,  в  CUR  записывается  номер
следующего  по  списку  вспомогательного  объекта  сообщения  (CUR = PNEXT
используемого  объекта).  Если  значение  битового  поля  CUR  достигло  номера  старшего
элемента  списка  (CUR = TOP),  то  следующим  значением  будет  BOT  (реализация
автоматического перехода в начало списка). Таким образом, реализуется замкнутая FIFO
структура,  в  которой  битовые  поля  TOP  и  BOT  устанавливают  связь  между  началом  и
концом списка.

Битовое поле SEL позволяет определить вспомогательный объект в пределах списка,

для которого генерируется прерывание всякий раз, когда указатель CUR достигает
значения указателя SEL. Также битовое поле SEL позволяет отследить окончание
запланированной передачи серии сообщений или выдать прерывание, предупреждающее о
том, что FIFO структура становится заполненной.

Вспомогательные объекты приемной FIFO-структуры могут принадлежать списку

любого узла.

FIFO структура для приема

Используется для буферизации входящих сообщений данных и удаленных запросов.
FIFO структура для приема активируется записью значения 0001b в битовое поле

MMC регистра MOFCR базового объекта. Эта запись автоматически определяет объект
как базовый объект приема FIFO. Типы вспомогательных объектов FIFO не имеют
значения при операциях.

Когда базовый объект FIFO получает сообщение от узла CAN, которому он

принадлежит,  сообщение  сохраняется  не  в  этом  базовом  объекте,  а  во  вспомогательном
объекте  сообщения,  на  который  указывает  битовое  поле  CUR.  При  этом  по  умолчанию
предполагается,  что  для  вспомогательного  объекта  MMC = 0000b  (действительное
значение MMC игнорируется), и никаких операций фильтрации принимаемого сообщения
не производится.

Одновременно с приемом сообщения текущее значение указателя CUR базового

объекта меняется на номер следующего по списку вспомогательного объекта FIFO
структуры. Этот вспомогательный объект будет использован для приема следующего
сообщения.

Если установлен флаг OVIE регистра MOFCR базового объекта и значение указателя

CUR становится равным значению указателя SEL, генерируется прерывание
переполнения. Это прерывание генерируется на узле прерываний с указателем TXINP

185

базового объекта сразу после сохранения полученного сообщения во вспомогательном
объекте. Прерывания генерируются, если это разрешено битом TXIE.

Следует помнить, что сообщение сохраняется в базовом и вспомогательном

объектах FIFO, только если установлен бит MSGVAL.

Во избежание непосредственного приема сообщения вспомогательным объектом,

как если бы он был независимым объектом и не принадлежал FIFO структуре, флаги
RXEN всех вспомогательных объектов должны быть сброшены. Состояние флага RXEN
неважно в случае, когда вспомогательный объект занесен в список, не связанный с узлом
CAN.

FIFO структура для передачи

Используется для буферизации серий сообщений данных или удаленных запросов,

которые должны быть отправлены. FIFO структура для передачи состоит из базового
объекта и одного или более вспомогательных объектов.

FIFO структура для передачи активируется записью значения 0010b в поле MMC

регистра MOFCR базового объекта. В отличие от FIFO структуры для приема, в битовые
поля MMC вспомогательных объектов (FIFO структуры для передачи) должно быть
записано значение 0011b. Указатели CUR всех вспомогательных объектов должны
указывать на базовый объект FIFO передачи (чтобы инициализироваться программно).

Флаги TXEN1 всех вспомогательных объектов сообщений, за исключением одного,

на который указывает указатель CUR базового объекта, должны быть программно
сброшены. Флаг TXEN1 указанного объекта должен быть установлен. Указатель CUR
базового объекта может быть инициализирован для любого вспомогательного объекта.

При определении корректности объектов сообщений FIFO структуры для начала

FIFO-операций базовый объект должен быть определен первым как корректный, т. е.
MSGVAL должен быть установлен.

В случае необходимости удаления FIFO структуры, прежде чем начнется операция

удаления, все вспомогательные объекты, принадлежащие этой FIFO структуре, должны
быть определены как некорректные (биты MSGVAL должны быть сброшены).

FIFO структура для передачи использует флаги TXEN1 всех своих объектов для

выбора сообщения для передачи. В результате фильтрации право передавать сообщение
получает тот объект, у которого выставлен флаг TXEN1. После передачи сообщения флаг
TXEN1 аппаратно сбрасывается, а в указатель CUR записывается номер следующего
объекта, требующего отправки сообщения, для которого уже выставлен (аппаратно) свой
флаг TXEN1, и так далее для всей FIFO структуры.

Если установлен флаг OVIE регистра MOFCRn базового объекта и значение

указателя CUR становится равным значению указателя SEL, генерируется прерывание
переполнения. Это прерывание генерируется на узле прерываний с указателем RXINP
базового объекта после завершения операций получения сообщения. Прерывания приема
базового объекта генерируются, если это разрешено битом RXIE.

Программирование регистров для FIFO структуры

1 Для передающего базового объекта:
- сбросить бит MSGVAL;
- задать поля CUR, BOT, TOP, SEL;
- записать значение 0010b в поле MMC, задать DLC, установить биты OVIE и RXIE

(если необходимо).

П р и м е ч а н и е – Состояние регистров MOAR и MOAMR передающего базового

объекта не важно, поскольку в передаче участвуют передающие вспомогательные
объекты и принимающий базовый объект. Поле RXINP указывает линию, на которую
будет выдаваться прерывание переполнения (CUR = SEL).

2 Для передающих вспомогательных объектов:

186

- сбросить бит MSGVAL;
- установить биты DIR, TXEN1 (только для того вспомогательного объекта, на

который указывает поле CUR передающего базового объекта, у остальных
вспомогательных объектов бит TXEN1 должен быть сброшен), TXEN0;

- записать в поле CUR номер передающего базового объекта;
- записать значение 0011b в поле MMC, задать DLC.

П р и м е ч а н и е – Значения регистров MOAR передающих вспомогательных

объектов  должно  совпадать  (или  совместно  с  регистрами  MOAMR  обеспечивать
успешное  прохождение  фильтрации)  со  значением  регистра  MOAR  принимающего
базового  объекта,  так  как  процесс  передачи  фактически  происходит  между  ними  (или
иного принимающего объекта, если на приеме используется не FIFO структура).

3 Для принимающего базового объекта:
- установить бит RXEN;
- задать поля CUR, BOT, TOP, SEL;
- записать значение 0001b в поле MMC, задать DLC, установить биты OVIE и TXIE

(если необходимо).

П р и м е ч а н и е – Значение регистра MOAR принимающего базового объекта должно

быть равно значению регистров MOAR передающих вспомогательных объектов передачи
(или совместно с регистром MOAMR обеспечивать успешное прохождение фильтрации).
Поле TXINP указывает, на какую линию будет выдаваться прерывание переполнения
(прерывание после операции сохранения полученного сообщения во вспомогательных
объектах при CUR = SEL).

4 Для принимающих вспомогательных объектов:
- сбросить бит RXEN (не требуется, если вспомогательные объекты занесены в

список, не связанный с узлом CAN);

- задать поле DLC (состояние поля MMC не важно).

П р и м е ч а н и е – Состояние регистров MOAR, принимающих вспомогательные

объекты, не важно.

5 Установить бит MSGVAL в первую очередь у передающего базового объекта, а

затем у всех остальных объектов.

6 Установить бит TXRQ для всех передающих вспомогательных объектов, начиная с

того, на который указывает поле CUR передающего базового объекта.

18.10

Режим шлюза

Режим позволяет реализовывать автоматическую передачу информации через шлюз

между двумя независимыми шинами CAN без участия ЦП.

Шлюз можно сформировать на уровне объектов сообщений и осуществлять

передачу информации между узлами CAN. Шлюз может быть сформирован между двумя
любыми объектами сообщений, принадлежащими разным узлам CAN. Количество
шлюзов зависит только от количества объектов сообщений, допускающих формирование
шлюзов.

Режим шлюза активируется записью значения 0100b в битовое поле MMC регистра

MOFCR  объекта  сообщения  n,  инициализирует  его  как  шлюзовый  объект-источник.
Объект  сообщения,  который  будет  являться  шлюзовым  объектом-приемником,
выбирается  указателем  CUR  объекта-источника.  Для  формирования  шлюза  достаточно,

187

чтобы объект-приемник был корректным (установлен бит MSGVAL). Остальные
параметры не влияют на возможность осуществления передачи между объектами от
источника к приемнику.

Рисунок 18.23 – Передача через шлюз от источника к приемнику

Шлюзовый объект-источник (см. рисунок 18.23) функционирует как обычный

объект сообщения с тем отличием, что возможны дополнительные действия контроллера
CAN при приеме и сохранении сообщения в объекте-приемнике:

1 Если установлен флаг DLCC регистра MOFCRn объекта-источника, код длины

данных DLC копируется из шлюзового объекта-источника в шлюзовый объект-приемник.

2 Если установлен флаг IDC объекта-источника, идентификатор ID и расширение

IDE копируются из шлюзового объекта-источника в шлюзовый объект-приемник.

3 Если установлен флаг DATC объекта-источника, байты данных, хранящиеся в двух

регистрах MODATAL и MODATAH объекта-источника, копируются из шлюзового
объекта-источника в шлюзовый объект-приемник. Копируются все 8 байт данных, вне
зависимости от значения поля DLC.

4 Если установлен флаг GDFS объекта-источника, то устанавливается бит запроса

передачи TXRQ объекта-приемника.

5 Устанавливаются флаги RXPND и NEWDAT регистра MOSTAT объекта-

приемника.

6 Если установлен флаг RXIE регистра MOSTAT объекта-приемника, то

генерируется запрос на прерывание.

7 Указатель CUR объекта-источника переводится на следующий объект-приемник

по правилам FIFO структуры. Сформировать шлюз между объектом-источником и одним
объектом-приемником (значение указателя CUR будет оставаться неизменным) возможно
программированием:

TOP = BOT = CUR = номер объекта-приемника.
Организация шлюза «объект-источник – объект-приемник» аналогична организации

FIFO структуры «базовый объект – вспомогательный объект», что указывает на

188

возможность  формирования  шлюза  с  интегрированным  FIFO-приемником.  При
получении  сообщения  данных  (объект-источник  является  объектом  приема,  т. е.  его  бит
DIR сброшен)  и  при  получении  удаленного  запроса  (объект-источник  является  объектом
передачи) через шлюз используется один и тот же механизм.

Несмотря на то, что механизм удаленных запросов работает независимо от типа

объекта сообщения, он наиболее полезен при использовании шлюзов, для формирования
удаленных запросов на шине шлюзового объекта-источника после получения удаленного
запроса на шине шлюзового объекта-приемника. В зависимости от значения бита FRREN
шлюзового объекта-приемника, есть два варианта обработки удаленного запроса,
возникшего с той стороны шлюза, где расположен объект-приемник (при условии, что
происходит передача из объекта-источника в объект-приемник, т. е. DIR (источника) = 0 и
DIR (приемника) = 1).

1 Обработка запроса шлюзового объекта-приемника с FRREN = 0b:
- сообщение удаленного запроса принимается шлюзовым объектом-приемником;
- бит TXRQ шлюзового объекта-приемника устанавливается автоматически;
- сообщение данных с текущей информацией, хранящейся в объекте-приемнике,

передается на шину приемника.

2 Обработка запроса шлюзового объекта-приемника с FRREN = 1b:
- сообщение удаленного запроса принимается шлюзовым объектом-приемником;
- бит TXRQ шлюзового объекта-источника (объект должен быть указан в поле CUR

объекта-приемника), устанавливается автоматически;

- сообщение данных передается объектом-источником на шину CAN источника;
- получатель удаленного запроса в ответ выдает сообщение данных на шину

источника;

- сообщение данных сохраняется в объекте-источнике;
- сообщение данных копируется в объект-приемник (через шлюз);
- выставляется

бит TXRQ объекта-приемника (при условии, что GDFS

источника = 1);

- новые данные, сохраненные в объекте-приемнике, передаются на шину приемника,

в ответ на удаленный запрос на шине приемника.

Рекомендации по записи в регистры в режиме шлюза при передаче удаленного

запроса с FRREN = 1.

Обмен запрос – данные происходит в данном случае между стандартным объектом

сообщения одного узла и объектом-приемником шлюза другого узла. Но при этом данные
для  ответа  на  запрос  в  шлюзовый  объект-приемник  поступают  по  шлюзу  от  объекта-
источника.  При  получении  удаленного  запроса  от  объекта  сообщения  объектом-
приемником  флаг  TXRQ  устанавливается  не  у  самого  объекта-приемника,  а  у  объекта-
источника, благодаря установленному биту FRREN и битовому полю CUR (указывает на
объект-источник)  объекта-приемника.  Данные  из  MODATAL  и  MODATAH  объекта-
источника  копируются  в  MODATAL  и  MODATAH  объекта-приемника  (установлен  бит
DATC  регистра  MOFCR  объекта-источника),  вследствие  чего  автоматически
устанавливается  бит  TXRQ  регистра  MOCTR  объекта-приемника  (установлен  бит  GDFS
объекта-источника  шлюза),  и  осуществляется  передача  сообщения  данных  (ответ  на
запрос) запрашивающему объекту сообщения.

После успешного приема/передачи сообщения ЦП получает уведомление о

завершении операции для задания дальнейших действий, связанных с объектом
сообщения.

18.11

Прерывания объектов сообщений

После сохранения принятого сообщения в объект сообщения или успешной

передачи формируется соответствующее прерывание. Каждый объект сообщения может

189

формировать  прерывания.  Каждое  прерывание  направляется  на  одну  из  16  выходных
линий  прерываний.  Прерывания  приема  (после  сохранения  сообщения)  также
формируются  после  операций  FIFO  и  шлюзовых  операций.  Флаги  TXPND  и  RXPND
всегда  устанавливаются  после  успешной  операции  передачи/приема,  независимо  от
состояния соответствующих флагов разрешения прерываний.

Объект сообщения может формировать FIFO прерывания. Если флаг OVIE регистра

MOFCR установлен, то формирование FIFO прерывания будет зависеть от типа объекта
сообщений (см. рисунок 18.24):

- если объект сообщения является принимающим базовым объектом, то выходная

линия прерываний для этого объекта определяется битовым полем TXINP регистра
MOIPR;

- если объект сообщения является передающим базовым объектом, то выходная

линия прерываний определяется битовым полем RXINP.

Рисунок 18.24 – Распределение прерываний

Ждущие сообщения

Когда генерируется запрос на прерывание (после приема/передачи сообщения), в

одном из восьми регистров ждущих прерываний MSPNDx (x от  0 до 7) выставляется флаг
ждущего  сообщения.  Восемь  регистров  образуют  область  из  32  ×  8 битов  –  по  два  бита
(один  бит  для  операций  приема  и  один  бит  для  операций  передачи)  для  каждого  из
объектов

сообщений.

Позиция

флага

ждущего

сообщения

определяется

демультиплексорами DMUX, см. рисунки 18.25 и 18.26.

В зависимости от значения поля MPSEL регистра MCR, реализуется один из двух

режимов выбора и установки флагов, ждущих сообщения:

- режим 1 в случае MPSEL = 0h;
- режим 2 в случае MPSEL = Fh.
Если нет необходимости в определении источника прерывания (прием или передача

сообщения), то можно использовать любой из двух режимов, в противном случае, следует
использовать второй режим.

В первом режиме установка флага ждущего сообщения происходит следующим

образом:

- 7, 6 и 5 биты поля MPN выбирают регистр MSPNDx, в котором будет установлен

флаг ждущего сообщения;

- пять младших бит поля MPN (на рисунке 18.25 выделены серым цветом) выбирают

позицию флага (от 0 до 31), который будет установлен в выбранном регистре MSPNDx.

190

Рисунок 18.25 – Режим выбора и установки флагов при MPSEL = 0h

Рисунок 18.26 – Режим выбора и установки флагов при MPSEL = Fh

Во втором режиме при определении позиции флага ждущего сообщения

принимаются в расчет значения поля MPN, полей RXINP (для приема) и TXINP (для
передачи). При этом для флагов могут использоваться любые биты выбранного регистра
MSPNDx. Установка флага ждущего сообщения происходит следующим образом:

- 3, 2 и 1 биты поля TXINP/RXINP выбирают регистр MSPNDx, в котором будет

установлен флаг по окончании передачи/приема сообщения;

- четыре младших бита поля MPN (на рисунке 18.26 выделены серым цветом)

совместно с нулевыми битами полей TXINP и RXINP выбирают позицию флага
(от 0 до 31). Фактически нулевой бит поля TXINP/RXINP выбирает старшее или младшее
слово выбранного регистра MSPNDx, а четыре бита поля MPN задают позицию в
выбранном слове.

191

Регистры MSPNDx могут быть записаны программно. Биты, в которые

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

Каждый регистр MSPNDx связан с соответствующим регистром индекса сообщения

MSIDx,  который  отражает  позицию  самого  младшего  бита  из  всех  установленных  в
регистре  MSPNDx.  Регистры  MSIDx  доступны  только  для  чтения  и  обновляются
незамедлительно  после  изменения  (как  аппаратного,  так  и  программного)  содержимого
соответствующих регистров MSPNDx.

Регистр маски индекса сообщения MSIMASK содержит маску для регистров

MSPNDx.  Только  незакрытые  маской  биты  могут  обслуживаться.  Регистр  MSIMASK
используется  одновременно  для  всех  регистров  MSPNDx  и  соответствующих  им
регистров MSIDx.

18.12

Программирование контроллера CAN

Для корректной работы контроллера CAN следует соблюдать порядок

программирования регистров.

Для запуска контроллера:
- записать регистр CLC;
- проверить, что сброшен бит DISR, регистр PANCTR = 00000000h и после этого

записать регистр FDR.

Далее для конфигурирования узла CAN с номером х (от 0 до 3) выполнить:
- в регистре узла NCRx установить биты INIT и CCE, после чего регистры NBTRx и

NPCRx станут доступны для записи и чтения, а регистр NECNTx – только для чтения;

- записать регистр NPCRx;
- записать регистр NIPRx;
- записать регистр NBTRx;
- записать регистр NFCRx (если необходимо);
- в регистре NCRx сбросить биты INIT и CСE, после чего регистры NBTRx и NPCRx

будут не доступны для записи;

- распределить объекты сообщений в списки посредством регистра PANCTR.
Для корректной работы объектов сообщений регистры каждого из них должны быть

проинициализированы. Для объектов, использование которых не предусматривается,
достаточно записать ноль в бит MSGVAL регистра MOCTR.

Рекомендуемый порядок инициализации регистров объекта сообщения:
- установить бит DIR в регистре MOSTAT для передачи сообщения данных/приема

удаленного запроса или сбросить бит DIR для приема сообщения данных/передачи
удаленного запроса; установить биты TXEN0 и TXEN1 (для передачи) или RXEN (для
приема) в регистре MOCTR;

- записать регистр MOFCR;
- записать регистр MOAR;
- записать регистр MOAMR (если необходимо);
- записать регистр MOFGPR (если будут использоваться FIFO структуры);
- записать регистр MOIPR;
- записать регистры MODATAL и MODATAH;
- установить бит MSGVAL корректности объекта сообщения в регистре MOCTR

(для неиспользуемых объектов этот бит должен быть сброшен);

- для активирования передачи установить бит TXRQ регистра MOCTR.

192

Контроллер интерфейса Ethernet 10/100

Контроллер Ethernet 10/100 реализует стандарт IEEE 802.3. Он осуществляет

прием/передачу  данных  по  интерфейсу  MII  на  скорости  10/100  Мбит/с.  Прием/передача
данных  по  интерфейсу  MII  осуществляется  в/из  буфера  блока  32-разрядной  памяти
объемом 16 Кбайт.

Контроллер Ethernet 10/100 использует 32-разрядный интерфейс для связи с

процессором  или  памятью  и  осуществляет  обмен  транслируемыми  данными  с
процессором  или  памятью  через  32-разрядную  оперативную  память  объемом  16  Кбайт.
Для накопления и формирования принимаемых и передаваемых пакетов имеются 2 FIFО:
для  приема  –  36-разрядное  объемом  4  Кбайта,  для  передачи  –  40-разрядное  объемом
2 Кбайта.  Обмен  данными  с  процессором  или  памятью  осуществляется  на  частоте  до
50 МГц.  Обмен  данными  с  устройством,  работающим  на  физическую  линию  PHY:  для
100-Мбитного режима на частоте 25 МГц, для 10-Мбитного режима на частоте 2,5 МГц.

Интерфейсный блок контроллера Ethernet 10/100 содержит один контроллер прямого

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

Типовая передача данных в любом направлении использует кольцевой буфер в

пределах  назначенной  для  контроллера  Ethernet  10/100  памяти.  Кольцевой  буфер  для
передачи определен закрытым связанным списком Tx-дескрипторов. Кольцевой буфер для
приема определен закрытым связанным списком Rx-дескрипторов. Два кольцевых буфера
формируются  из  равных  32-разрядных  сегментов  памяти,  способных  сохранять  пакет
максимальной длины. Эти кольцевые буферы должны быть кратными 1-Кбайтной области
памяти (максимальный размер пакета данных), и должны располагаться последовательно,
не  затрагивая  области  других  компонент  (область  дескрипторов  и  область  кольцевых
буферов)  контроллера  Ethernet 10/100.  Предварительно  проинициализированный
контроллер  ПДП  может  автономно  и  непрерывно  заполнять/освобождать  кольцевые
буферы.  Программное  обеспечение  может  использовать  систему  прерываний  или  опрос
флагов  дескрипторов  для  поддержания  синхронизации  потоков  данных  между
контроллером Ethernet 10/100 и процессором или памятью.

На рисунке 19.1 показан пример построения кольцевого буфера из трех

дескрипторов. Адрес первого дескриптора задается регистром DMATXCTRL.

Рисунок 19.1 – Кольцевой буфер с Tх-дескрипторами

МИКРОСХЕМА ИНТЕГРАЛЬНАЯ К1921ВК01Т. Руководство пользователя (от 10.09.2019) - часть 12