Форум РадиоКот

Я если честно даже не знаю где спросить, попробую здесь. Вдруг встречу того кто ковырялся сталкивался и разбирается.
50% успеха это хорошо сформулированный вопрос. И я понимаю что мне его подробно сформулировать сложно. Делаю устройство в котором важна последовательность пакетов кан.
Два дня дебажил ловил баг. Проблема у меня в том что из-за быстрой передачи ловлю баг, и два пакета меняются местами.
Попробую визуально текстом c простого.
Вот это работает: < Пакет ID1 летит ко мне ловлю, вычитываю по spi, меняю айди, отправляю по spi в mcp2515 и она его в кан отправляет >Пакет ID2
А тут баг: летят два пакета ко мне < Пакет ID1 (1), < Пакет ID1 (2) ловлю оба? ( не пойму как, не знаю какой размер у буфера приема MAB - Message Assembly Buffer). Вычитываю по spi первый пакет, меняю айди, по spi шлю пакет и команду RTS TXB0 в MCP2515(и она пытается отправить > Пакет NewID1 (1)) НО в этот момент кан шина занята там летят другие пакеты от меня не зависящие, поэтому MCP2515 логично не отправляет этот пакет в кан, а ждет. Пока она ждет я делаю тоже самое со вторым пакетом который прилетел шлю пакет и команду RTS TXB1 по spi. В этот момент кан шина освобождается, и MCP2515 что первым делом делает? По моей логике должна отправить в кан сообщение из буфера TXB0 который был в режиме ожидания. Pending. Но так как я отправил команду RTS TXB1 в момент когда шина освободилась, MCP2515 взяла и отправила сначала TXB1, и за ним сразу TXB0.
Хотя я "расставлял" задачи в порядке TXB0 => TXB1
В общем без очереди залез пакет с TXB1
Че делать ума не приложу.
Еще все усложняет что среда у меня MikroC со встроенной библиотекой которая закрыта, ничего не поправить. Так то наверно еслиб библиотеку использовать стороннюю, наверно можно предусмотреть этот момент, и например сделать проверку чист ли буфер TXB0 перед тем как слать команду RTS TXB1

Ответ простой - используй очередь на отправку пакетов и жди подтверждения отправки предыдущего.

zombie47 писал(а):По моей логике должна отправить в кан сообщение из буфера TXB0 который был в режиме ожидания.

Советую еще почитать в даташите, как оно по логике производителя чипа. Все же у него мэйлбоксы - это не очередь, это просто пул на отправку. А вот правила выбора приоритетов должны быть описаны. Не знаю, как там конкретно у 2515, поэтому посмотрите. Обычно в первую очередь отправку делают по правилам арбитража - чем меньше ID, тем выше приоритет. Если ID одинаковые - тогда уже будет еще какая-то логика.
Как выше написали, если нужно изменить эту схему - делайте очередь в МК.

[uquote="GARMIN",url="/forum/viewtopic.php?p=4586818#p4586818"]Ответ простой - используй очередь на отправку пакетов и жди подтверждения отправки предыдущего.[/uquote]
Да но как получить это подтверждение отправки предыдущего?

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

ID одинаковые. Я тоже сначала думал дело в арбитраже)
Чтоб сделать очередь мне нужна инфа о том что пакет отправлен, а у меня этой инфы нету. Так как библиотека закрытая, нужно только искать и прикручивать библиотеку на отправку открытую и в ней уже регистры брать.
Ну или просто читать какой то адрес регистра второй раз.

zombie47 писал(а):Ну или просто читать какой то адрес регистра второй раз.

И что в этом плохого, ещё раз прочитать у себя регистр? Главное- это настроить приём пакетов из сети, а не из внутреннего буфера, тогда такое чтение будет не беЗполезным: проверишь, что в сеьт нет КЗ, а в программе запущен механизм приёма-отправки через CAN.

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