Вводная:
В CAN контроллере STM32 предусмотрено 3 мэйлбокса для отправки сообщений. В зависимости от бита TXFP мэйлбоксы передаются либо в зависимости от приоритета id либо в порядке поступления запросов на передачу.
А теперь вопросы:
* если было заполнено несколько мэйлбоксов и на момент проверки регистра CAN_TSR они все уже успешно передались как определить фактический порядок в котором пакеты ушли в линию ?
* если включен режим отправки в порядке поступления запросов (TXFP=1) пакеты на самом деле отправляются точно в порядке запросов, независимо от номера используемых мэйлбоксов ? Просто в библиотеке мэйлбоксы заполняются строго последовательно 0-1-2. Что получится если я буду заполнять мэйлбоксы в произвольном порядке, например 2-1-0 или вообще случайно ?

Так если у вас включен режим "By transmit request order" то логично заполнять по очереди и использовать как фифо (собственно в даташите так и указано)
Потому что после того как заполнены все 3 мейлбокса первый фрейм уйдет из 0, соотв. он пернвый освободится и туда надо класть следующий и т.д.

Да, у меня включен режим By transmit request order и мне нужно чтобы мэйлбоксы работали как фифо на 3 сообщения.
На данный момент с последовательностью сообщений выходит полная фигя.
Заполняю мэйлбоксы по порядку начиная с 0, т.е. 0-1-2. Освободившийся мэйлбокс сразу же загружается свежим пакетом.
Получил такой лог работы при попытке отправить 4 пакета::

Кан анализатор показал что фактически в линию пакеты ушли в порядке 0-1-3-2, т.е. так же как по логам tx done ***
Исходя из фактов получается что приоритет отправки мэйлбоксов определется их номером. 0 - самый высокий и 2 самый низкий, мэйлбокс 2 не будет отправлен до тех пор пока не освободятся 0 и 1.
Пока не понял как с такой работой приоритетов сделать fifo .

Я когда даташит смотрел, тоже удивился, как они реализовали именно в порядке запросов...
В подобной реализации с 3 мейлбоксами у NXP можно выбрать приоритет или по ID или по номеру мейлбокса!

почти fifo (вернее double buffer) можно попробовать сделать используя только 0 и 1 mailbox!
Т.е. если оба свободны класть в 0, если 0 еще не отправился класть в 1. Потом можно класть в 0 раньше 1 он не уйдет потому что после отправки 0 сразу на отправку пойдет 1...

По моему так не получится.
В RM0008 на диаграмме Figure 227. Transmit mailbox states показано что из состояния SCHEDULED возможен переход в PENDING если появился мейлбокс с более высоким приоритетом.

Надо пробовать, может в режиме By transmit request order, они частично его реализовали и раз уж мейлбокс перешел в SCHEDULED он отправится, а ошибка у них при выборе нового мелйбокса для отправки - берут с наименьшим номером.

Я честно говоря всегда использовал только один mailbox для отправки.

С отправкой сообщений в хронологическом порядке разобрался. Она работает как и описано в даташите.
У меня последовательность нарушалась из-за того что не был установлен бит TXFP в регистре CAN_MCR. После установки TXFP в 1 хронологический порядок отправки мэйлбоксов заработал.
С анализом флагов окончания передачи пришлось разбираться "врукопашную" - завел историю использования мэйлбоксов и проверяю статус мэйлбокса начиная с самого старого.