Отсылаются данные в цикле. (AT90CAN128)
Опрашиваю свободные Mob по состоянию из CANEN.
Загружаю в свободный данные и отправляю.

На приемной стороне порядок следования перемешивается.
Отправленный ранее моб извлекается позже, данные не теряются, тестовый последовательный счётчик выглядит так: ...0, 2, 1, 3, 6, 4, 5 итд.
Вопрос, надо ли софтово сортировать данные из приемных мобов по штампу времени прихода или это происходит аппаратно?
Может что-то не верно сконфигурил?

Не скажу точно про AT, А в Silabs сделано так:
есть 32 буфера, часть из них настраивается на прием, часть на передачу.
Так вот при передаче данных наибольшей приоритет имеет буфер с меньшим номером.
Если в буфера пачкой записать 3-4 сообщения, а потом (скажем по прерыванию от передатчика) дописывать в освободившиеся. то получиться аналогичная картина.
Пример пусть буфера 1,2,3,4 содержат для отправки сообщения с соответствующими контрольными счетчиками.
После передачи данных в канал из буфера 1 возникает прерывание, если в этом прерывании искать освободившийся буфер и записать в него следующее сообщение (а это будет буфер 1 со счетчиком 5), то будет следующее: поскольку уже началась передача из буфера 2, тогда сперва отправиться сообщение с номером 2, затем сообщение из буфера 1, как более приоритетного, с номером 5. На приемной стороне и получиться, что сообщения отправлены все, но порядок их прихода не соответствует порядку передачи (точнее записи в CAN контроллер).
Может это наведет на мысли по аналогии. Поскольку это относится к SiLabs/

Да... именно так.
Если оправлять unsigned char счётчик, загружая по 1 байту в Mob(0) сразу отправляя его.
И затем ждать пока передатчик его отправит, то всё работает абсолютно правильно.

Но если не дожидаться окончания отправки и начинать загружать следующий тик счётчика в Mob(1) и т.д., то в зависимости от различных факторов, данные на приемной стороне начинают перемешиваться.... вот засада.
По идее, приемник как-то должен аппаратно сортировать данные или нет? Иначе получается серьёзная загрузка ядра на приемной стороне.

Сообщение отредактировал sevstels - Dec 5 2012, 08:55

Данные должны передаваться в порядке приоритета (ID) может воспользоваться этим?

CAN контроллер ПРИ ВЫБОРЕ сообщения для передачи не сортирует сообщения по ID. Для него приоритетом является номер буфера, из которого надо отправить сообщение. Приоритет ID отслеживается на фазе арбитража ВО ВРЕМЯ ПЕРЕДАЧИ.
Кстати для приемника при применении фильтров то же самое. Принятое сообщение копируется в буфер с меньшим номером, для которого подходит маска фильтра.

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

Ошибка происходит приблизительно таким образом:

1. Загрузили Mob(0), поставили флаг "Передать".... данные начали аппаратно передоваться.
2. Процедура поиска свободного Mob(n) с наиболее высшим приоритетом.
3. Нашли Mob(1), тк он свободен и имеет наивысший приоритет на данный момент.
4. Начали загрузку Mob(1), затем поставили флаг "Передать".... данные Mob(1) ждут окончания передачи из Mob(0).
5. Аналогично загрузили: Mob(2), Mob(3) итд
6. В это время освободился Mob(0) и процедура поиска свободного Mob(n) с наиболее высшим приоритетом выбирает именно его.
7. Загрузили Mob(0), поставили флаг "Передать".... данные начали аппаратно передоваться.
НО... мы ещё не успели передать данные из младших по приоритету Mob!!!

Поэтому и выход - передавать только из одного буфера, например Mob(1).

И соответственно на приеме не тормозить, поскольку возможна та же ситуация
1. Приняли в Mob(2),
2. Приняли в Mob(1),
3. При опросе поиск занятого Mob(n) с наиболее высшим приоритетом.
3. Нашли Mob(1), тк он имеет наивысший приоритет, но данные в него пришли и позже чем Mob(2)

>> выход - передавать только из одного буфера
Это не выход.
С передатчиком можно решить, например опрашивая наличие стоящих в очереди на передачу Mob.
Если они есть, то брать последний свободный с высшим приоритетом.
Но тогда получается пауза при переходе от нижнего обратно к Mob(0), те пока нзкоприоритетный не передаст пакет, заполнять Mob(0) нельзя. Вернее заполнить можно, но запускать на передачу нельзя... хитрый менеджер отправки надо писать.

А еще этот менеджер должен будет помнить последовательность в которой он заносил данные: 1- пакет в 3-й Mob попал, 2-й в 4-й, 3-й в 6-й

Если других передач нет, то можно использовать все Mоb, а в менеджере смотреть, все свободны, тогда запускаем новую партию посылок (максимально заполнить по порядку).
Если помимо нумерованых пакетов надо отправлять еще и прочие данные, тогда проще реализовать менеджер с параметром - отправлять через фиксированный Mob для нумерованых пакетов, все прочие данные через любой свободный.
Я бы реализовывал второй вариант.

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

>> может стоять репитер
Это уже трудности реализаторов репитера.