Здравствуйте!
На этом форуме я новичок, поэтому прошу прощения, если разместил вопрос не в том топике.

Ситуация следующая - есть многопроцессорная система (на базе процессоров семейства ST10), обмен данными между ними ведется по протоколу CAN 2.0B.

Каждый процессор выдает через КАН информаци, необходимую для расчетов другому. Выдача настроена на частоту 100Гц (выставление данных на шину КАН производится по прерыванию от таймера).

Другие процессора сравнивают принятые значения с измеренными ими самими и производят вычисления.

Проблема в том, что наблюдается потеря кадров при выдаче по шине при работе нескольких микропроцессоров одновременно. Второй процессор ведет счетчик обновления данных от первого (к примеру) и наблюдает потери (для теста МК1 выдает инкрементирующийся каждые 100Гц счетчик циклов, второй обрабатывает его прием с частотой 800Гц - второй процессор наблюдает в итоге "разрывы" по пришедшему счетчику - приходят значения 1000, 1001, 1002, 1003, 1005, 1006 - пропущено 1004).

Если включен только один передатчик(передача вдется только с одного из МК - потерь фактически не наблюдается). Если на шину выдает два передатчика - идут потери.

Обьясните пожалуйста чайнику, вследствие чего могут возникать потери при приеме\передаче по CAN 2.0B?

UP!

можно долго апать, но это дело не сдвинет с места.
Ваш вариант описания ситуации мало что говорит.
По всей видимости дело в программе или в протоколе, который вы пытаетесь огранизовать.
Каким образом распределены ID CAN-сообщений по устройствам?

Прошу прощения, апнул исключительно от безысходности.

Описывать весь алгоритм слишком долго, возможно кто либо еще сталкивался с ошибками в CAN'e иил есть причины для наиболее часто встречаемых багов (в этой теме я новичок - но тема то как раз для новичков).

Используется расширенный формат кадров (29 бит). В ОЗУ каждого процесора содержатся одинаковые таблицы с описанием кадров (номер кадра, что заполняется в поля данных кадра и прочее).
11 бит идентификатора определяют номер строки в этой таблице (определяют уникальность идентификатора кадра), распределение по процессорам ведется по этому номеру - т.е. МК1 выдает кадры например от 0 до 50, МК2 - от 51 до 100 и тп.
Остальные биты могут быть не уникальными, но в целом ситуация, когда 2 процессора пытаются выдать кадр с одним идентификаторам невозможна (проверял, хотя учитывая, что я чайник может быть что то прозевал)

Процедуры чтения/записи написаны по алгоритму, указанному в документации на процессор (блок схема), так что логически в этом ошибки быть не должно.
Из 15 обьектов CAN контроллера CAN процессора обьект №15 используется для приема (он буферизированный), обьекты 0-7 - для передачи.

Процессоры могут стартовать асинхронно, выдачу кадров осуществляют (всех, которые предназначены к выдаче с этого МК) с частотой 100 Гц. Тесты показали, что контроллер успевает выставить все данные на шину до наступления следующего цикла.

Перегрузки на шине тоже не наблюдается, сокращали поток выдачи до 1 кадра с частотой 100Гц - количество пропусков снизилось, но осталось на высоком и неприемлимом уровне.

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

А частота у генераторов достаточно одинаковая ?

И не нужно...
Вот тот скажите лучше ... тот контроллер, который передавал потерянное сообщение - сколько попыток передачи этого сообщения он сделал?
Ах, не знаете ....

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


Частота по идее абсолютно одинаковая

У вас восемь каналов у каждого узла сконфигурированы как передатчики, используется ли реально более одного для отправки сообщений?

Практически не проверялось.
При срабатывании в основном канале функции (моей) SendFrame кадр ставится в очередь (стек FIFO).
Очередь орбрабатывается при каждом вызове SendFrame, процедура обработки циклически проверяет CAN обьекты 0-7, являются ли они свободными, если да - кадр из очереди ставится на передачу в этот обьект.
Теоретически вероятна ситуация когда в очереди всегда 1 кадр (при малой нагрузке) и для передачи используется только обьект 0. В данном случае он просто справляется со всем потоком.
Однако даже в таком случае упомянутые в первом сообщении ошибки остаются.

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

Перегрузка легко считается.
Какая скорость используется?
Сколько байт данных в сообщении?
Какие драйвера применены?
Какие расстояния?
Терминаторы на месте?
Контролируете ошибки в контроллере CAN?

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

Если соотношение тактовой частоты контроллера и шины большое, возможна ситуация, когда при последовательной отправке двух и более сообщений один канал начнет передачу первого сообщения, а флаг занятости передатчика (либо канала) будет выставлен позднее, чем будет выполнена его проверка для возможности передачи второго сообщения. В итоге пойдет запись второго пакета в тот-же канал, он будет частично переписан, т.е. комбинация двух сообщений (CRC будет верна). Сообщение м.б. отфильтровано приемником (если это выполняется по каким-либо признакам), т.е. получится пропуск.
Вообще причину легко будет понять, если проанализировать статусные регистры can-контроллера после каждой отправки/получения.

В CAN сообщение считается переданным только тогда, когда все "сказали" что все до них дошло без ошибок.

Здесь говорилось про "проверяет CAN обьекты 0-7" - до передатчика еще далеко, не то.



!!!!!!!!!!!!!! Не _все_, а _хоть один_ кто-то !!!!

Для передатчика достаточно, чтобы хотя-бы один узел сказал "да" (поставил доминанту в слот подтверждения).

upd.
ответ синхронно про одно и то-же

Если контроллер так криво работает, то как вообще тогда можно работать с ним?

1) Максимальная - 1 Мбит/сек
2) 4 слова - 8 байт
3) ? Что имеется в виду под драйвером? Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET).
4) Расстояния между процессорами на плате - меньше 10 см, расстояние от контроллера, осуществляющего передачу "вовне" (на ПК) - меньше 2 м.
5) на месте
6) нет, ошибки не контролируются в связи с тем что автор чайник и не знает как это делать)))



Имеется в виду, выставлять один и тот же кадр на выдачу несколько раз за цикл? Но по какому алгоритму это делать?


Какие имено поля CSR (CAN Status/Control Register) анализировать? LEC?


Как это можно определить?
Выставляется ли контроллером какой нибудь флаг в CSR или Message Control Register, сообщающий о том, что именно все адресаты получили сообщение?


Да, мне тоже так казалось
Но после цати тестов моего бага я уже ни в чем не уверен))

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




Почитайте стандарт, там все доходчиво сказано, даже с картинками и в переводе

Учитывать это. Уже наступал на эти грабли.

Ну так и формулируйте яснее: " когда все "сказали" " - вот "все" Вас и поняли...

Под однократной передачей я имел ввиду вот что. У Infineon-a (прочитав в посте-вопросе про message objects я подумал, что CAN-контроллер тот-же) в CAN-контроллере можно задать однократный режим передачи, когда контроллер будет только один раз пытаться передать телеграмму не обращая внимание на ощибки и отсутствие подтверждения приема удаленной стороной.
Если выключить однократную передачу - будет ждать подтверждение (точнее пытаться передать "до посинения").

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



Это где такие грабли?

Тоже самое будет в любом другом, если используется TTC.


У Атмэла. На сабжевом не проверял.

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

Если передача потерянного пакета производилась один раз, значит подтверждение на него дал не основной получатель. Значит, не то что-то с этим основным получателем, которое вроде бы на шине, а на самом деле непонятно чем занимается. Может, чтение буферов редко происходит. Скорость передачи и загрузка шины должна соотноситься с быстродействием устройства. Можно сделать 1 Мб/с, а проверять буфер(ы) раз в 10 мс, и ффсе.
Ага, так похоже и происходит :
"Для регистрации данных на ПК используется устройство IXXAT CAN II с драйвером третьей версии (с поддержкой .NET)."
Типичная реакция у Windows - 10 мс. Один передатчик тянет, а два уже нет.
"Приплыли"?

Если не трудно подскажите, в каком месте это выставлялось у Infineon-a?
В описании CAN-контроллера своего процессора вообще такого не видел.

Нет, тут должно быть все достаточно чисто. Работает же USB и т.п. ;-)
В устройстве свои буфера должны быть достаточного размера.
Мы пользовали древний USB-CAN, все пахало на 1Мбит под виндами без потерь и напрягов.

В дивайсе (IXXAT CAN II) стоит Freescale MCF5235, 150 MHz + SJA1000
а если это PCI-плата, то SAB XC16x
до виндов, думаю, далеко.

У Infineon-a было так:
Single Transmission Try
0 Single transmission try is disabled.
1 Single transmission try is enabled. The
corresponding TXRQ bit is reset immediately
after the transmission has started.

Нет, пока "плаваем"))
немного поясню.
У устройства есть внутренняя шина (для обмена данными между МК). Третий МК является своеобразным "шлюзом" - он транслирует все принятые внутренней шине кадры через контроллер CAN №2 на внешнюю шину - где приемник - ПК.

Но ошибки ловятся именно на внутренней шине (счетчики процессоров анализируются в 800 Гц цикле МК3, процедурка просто смотрит сколько пропусков по счетчикам МК1 и МК2, инкрементирует какой то свой внутренний счетчик ошибок ErrorCounter и выдает его на внешнюю шину, где мы его видим на ПК - в данном случае скорость работы ПК на винде не критична ИМХО).

Кстати драйвер IXXAT сам накапливает данные в буфер, считывать их программно можно хоть с частотой 10Гц - выдаст все накопленные сообщения программе за милую душу

Получение данных через обьект №15 в процессоре производится через прерывание на обьекте CAN.
Опять таки замечу что при снижении потока до 1 кадра каждые 100 Гц с трех процессоров ошибки не исчезли, ошибки сводятся почти к нулю при оставлении на шине 1 передатчика (МК1) и одного приемника (МК3)

Такие пояснения добавляют неопределенности
Вы бы нарисовали что же у вас там и как, что и хотите, что получается...
А так какие-то метания.

1) надо бы изучить матчасть поплотнее - протокол и используемый контроллер.
2) четко и ясно описать задачи каждого устройства и системы в целом.

PS:
В хорошем вопросе содержится большая доля ответа. Так уже начните задавать вопрос с чувством, с толком, с расстановкой. Когда будете все по местам расставлять, ответ должен сам и найтись.

Жаль
Тем не менее ничего не меняется. В шлюзе то не фрискэйл?
Мы тут ничего не выясним сейчас. Все можно проверить осциллографом - нужно передавать одинаковое сообщение, синхронизироваться от него и убедиться, что шлюз выдает подтверждение. Если да, то значит данные теряются внутри. А если нет... Тогда думать.
А так это гадания.

Задача устройства - регулирование исполнительного механизма в соответствии с показаниями датчиков.
Например, обьясню на одном из регулируемых параметров:
МК1 читает данные с датчика температуры, получает значение Т1 и выставляет его на шину CAN.
МК2 читает данные со второго датчика температуры, получает значение Т2, выставляет на шину.

Процессор МК3 получает по шине оба значения, расчитывает результирующее Трез = (Т1+Т2)/2 с частотой 100Гц.
Каждый кадр имеет так называемый "счетчик обновляемости".
в 100Гц-м цикле счетчик обновляемости каждого кадра уменьшается на 1, если кадр пришел - устанавливается в первоначальное значение. Для Т1 и Т2 счетчик равен 10. Если счетчик кадра = 0 (значит кадр "не приходил" 10 стогерцовых циклов подряд) - устройство генерирует отказ по контролю температуры.
Так в принципе и отловили баг - периодически генерировался данный отказ (редко достаточно).
Потом уже стали процерять по инкрементирующимся счетчикам.

Можно конечно и скопом битики сравнивать, но проще все на бумаге разложить по полочкам. ИМХО

Или подключить на "внутреннюю" шину USB-CAN в качестве снифера и смотреть что-же там делается на самом деле.




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

Данные теряются именно внутри
Отказы считают сами процессора, через шлюз выдают при тесте ТОЛЬКО счетчик ошибок (то есть сколько сам процессор насчитал пропусков). при передаче данных через шлюз эффект ошибок "удваивается" - так как в итоге две шины. Но на ошибки на шлюзе плевать - критичными являются ошибки на внутренней шине



Прошу прощения. Попробую конкретизировать на CAN'e.
Мы пришли к выводу, что ошибка при передаче через CAN (неизвестно в каком месте, при передаче, при приеме или ошибка на шине) следующим образом - выключили все остальные функции процессоров, оставив одну - передавать с частотой 100Гц инкрементирующийся счетчик с МК1 и МК2 и принимать их в МК3.
МК3 регистрирует пропуски по счетчикам.

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

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




И снова не договариваете
Сколько пропусков на каком количестве посылок, стабильно ли это возникает?
Как регистрирует, N1 != N2 или анализируется линейность изменения каждого счётчика по-отдельности?

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

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

Третий процессор проверяет так:

if (cnt1 - cnt1_old > 1) {errorMK1++;}
if (cnt2 - cnt2_old > 1) {errorMK2++;}

cnt1_old = cnt1;
cnt2_old = cnt2;

cnt1 и cnt2 - счетчики, принимаемые от МК1 и МК2.
И все это проверяется в 800 Гц (для верности воткнули на макс. частоту) цикле (в 8 раз чаще чем выдается).
Если новое значение счетчика еще не пришло - errorMK не изменится.

errorMK1 и errorMK2 даже приблизительно не равны друг другу. на значение счетчика 10000 (т.е. выдалось от 0 до 10000) errorMK1 может насчитать 10, а errorMK2 - 500. И наоборот.
Тенденция - счетчики растут лавинообразно - то есть могут не изменятся достаточно долго, потом резко растут, и снова "затыкаются".

Хм, это странно, что счетчики изменяются нелинейно.

Надо проверять успешно ли завершается отправка из МК1 и МК2.

Но скорее всего ошибка в другом:

Если ваш контроллер не использует режим FIFO то следует работать по прерыванию.
Все сообщения принимается в один приемный слот?
Фильтры каким-то образом используются?

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

Нельзя полингом работать при таких скоростях, даже если вы сделаете 1600 или 3200 Гц опроса.

Еще раз перечитал первые ваши посты. Сообщалось что пользуете буфера приема (несколько слотов настроены на прием). Но работает ли этот буферизованный прием?
Можно одним МК1 отправлять не одно, а несколько сообщений (последовательно и без паузы) в течении 100 мс и так же проверить на линейное изменение счетчика. Если будут ошибки, то буферизация не работает и в этом кроется ошибка.

Даже если буферизация у вас и работает, восемь слотов вы опрашиваете восемь раз за период отправки сообщений от источников, то без потерь вы будете обрабатывать только в том случае, если отправки формируются в строгой синхронизации и в 1/8 периода формирования сообщений по шине проходит не более 8 сообщений.
У вас синхронизации нет, поэтому без ошибок вы получать сообщения не сможете по определению (их количество будет увеличиваться с увеличением абонентов на шине).

Так что CAN не виноват, ошибочны подходы построения взаимодействий в системе.

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

На приеме только один слот, который буферизированный (обьект №15).
Чтение из него производится по прерыванию (у обоих контроллеров есть по прерыванию в таблице векторов).

Есть мнение что когда мы производим чтение из обьекта, приходит второй кадр - а обьект №15 в это время "заблокирован".
Может ли увеличение числа обьектов-приемников помочь или не стоит даже пытаться?
Или нужно менять весь алгоритм в целом и вводить синхронизацию?

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

Введение большего кол-ва приемников приведет к другим вопросам и проблемам ... проще сделать синхронизацию.

Вектора то может быть и есть, а обработчики прерываний есть?
Раньше речь шла только о полинговом вычитывании с частотой в 8 раз больше, чем посылки.


Станет лучше, но полностью ошибку не исправит.

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


А это как вы программу напишите, должно конечно успеть ;-)

PS:Я бы не использовал слово "объект", слот больше подходит.

Какому прерыванию? Сколько времени занимает обработка?


Вы же молчите как партизан - не говорите ни сколько буферов в приемнике задействовано, ни про фильтрацию. Синхронизация абсолютно не нужна.
Получается, мы должны рассказывать, что у Вас происходит.
Буфер у Вас один. Из-за несинхронности наступает момент, когда кадры идут один за другим. Первый принимается, а второй нет, потому как буфер занят. А на второй кадр подтверждение дает то устройство, что передало первый кадр, поэтому второе устройство считает, что оно успешно приняло. А шлюз и не подозревает, что был еще кадр.
Даже в старом MCP2515 три буфера приема. И обрабатываются они примерно так:


Успехов

Конечно есть))
Обработчик прерывания считывает данные из слота в переменные в ОЗУ.
А контроль на 800Гц уже сверяет значение в этих ячейках.
Исходим из логического предположения, что кадр с одним и тем же ID приходит реже 800Гц


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

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


Подозрение попало также на передатчик, но мы "новички" не можем понять, то ли мы не осознаем гениальности автора процедуры передачи, то ли он накосячил. Приведу на всякий краткий алгоритм передачи:
Передача:
1) Находим свободный КАН-слот
проверяем комплементарные биты TXRQ и NEWDAT слова Message Control Register (13 и 9 биты - старшие биты TXRQ и NEWDAT) соответственно. Слово - в R2
BAND R2.13, R2.9
JNB R2.13, CAN_IS_FREE
Если нет, переходит к следующему слоту. Крутимся пока не найдем свободный (из слотов 0-7).

2) Начинаем обновление данных в ячейках слота, выставляем флаг "обновляем".
MOV R2, #0x5A7D ; set CPUUPD, reset MSGVAL

3) Устанавливаем регистры арбитража, конфигурационный регистр сообщения и копируем данные.
4) Завершаем апдейт данных и выдаем.
MOV R2, #0x66BD ; reset CPUUPD, set MSGVAL, TXRQ, NEWDAT

Все, передача 1 кадра завершена.

Обработка прерывания по приему занимает 10-15 мкс.
В худшем случае

Как такое возможно? Кадр передается по шине со скоростью 1МБит/сек порядка 100 мкс (примерно), а ассемблерная процедура приема успевает считать гораздо быстрее (просто посчитали количество инструкций, посмотрели сколько времени выолняется каждая, например MOV выполняется за 2 такта - 50 наносекунд). Значит до прихода следующего кадра уже точно слот №15 (приемник) освободится? или я ошибаюсь?

Если вы не можете гарантировать правильность процедур, автора которых уже не отыскать, то надо исследовать процессы более наглядными вещами
1) снифер (USB-CAN) включенный на просмотр сообщений.(подключите уже шлейф от ПК на внутреннюю шину);
2) осциллограф;
3) светодиодик отображения времени выполнения процедуры.

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

Перепишите все на Си и голову не ломайте, должно успевать. А то может вы что-то просто путаете в асме. Когда заработает можно будет оптимизировать.


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

Еще предположение:
Может у вас что-то не то с записью/вычитыванием из буфера при получении больше чем одного сообщения за 1/8.

Ошибаетесь принципиально.
Вы почему-то считаете время от начала первого кадра до начала второго. Но нужно считать от конца приема первого до начала приема второго! То есть время не сотни мкс, а в лучшем случае одна-две!
Ну поймите же - речь идет о промежутке времени, когда первое сообщение ПРИНЯЛОСЬ и тут НАЧИНАЕТ передаваться второе. Ему некуда приниматься - буфер занят, прерывание не успевает обработаться за это время.

Не вводите людей в заблуждение.
Буфер можно обрабатывать до завершения прихода следующего. Иначе бы ничего вообще не работало. Такой CAN ни кто бы не мог использовать. Даже в UARTе обработать надо не до начала поступления следующего, а до завершения передачи.



Сообщение складывается в буфер только после того, как будет завершена операция передачи (причем без ошибок) и выполнена фильтрация по ID.

У нас, наверное, разная терминология.
Я использовал слово буфер как набор регистров, осуществяющих прием или передачу. Напрмер, в MCP2515 два буфера на прием и три на передачу.
"The MCP2515 has three transmit and two receive buffers, two acceptance masks ( one for each receive buffer)..."
Насколько я понял, автор использует один буфер на прием сообщений от двух источников.

В таком контексте использования этого слова тоже возражения?

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

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