Форум программистов, компьютерный форум, киберфорум
Наши страницы
Микроконтроллеры ARM, Cortex, STM32
Войти
Регистрация
Восстановить пароль
 
Рейтинг 4.53/15: Рейтинг темы: голосов - 15, средняя оценка - 4.53
RikoD
0 / 0 / 0
Регистрация: 07.10.2011
Сообщений: 127
1

CAN шина, интервал между сообщениями.

10.10.2016, 18:11. Просмотров 2726. Ответов 9
Метки нет (Все метки)

Всем привет.

Есть N модулей на CAN шине и им надо отправлять сообщения регулярно.

На каждой железке (датчики типа):
Если поставить задержку достаточно большую, порядка 1ms, то сообщения бегают редко, что видно по осциллографу и очередь на отправку не забивается (очередь - это помимо 3-х Tx буферов на чипе).
Но если поставить без задержек, то конечно же отправка не успевает и очередь забивается.
CAN разогнал до 2 Мбит/с, работает стабильно, 4-х байтовые сообщения занимают порядка ~56us (видно осциллографом), обработка сообщения на МК в худшем случае порядка ~30us (измерил с помощью DWT, всё точно).

Если по таймеру слать, то может получиться, что N железяк попытаются отправить одновременно и тогда последнее сообщение реально полетит по шине только через N * пауза_между_сообщениями.

Собственно вопросы знатокам:
Как вы решили проблему уплотнения сообщений в CAN, чтобы интервал был наименьшим?
Можно ли как-то на МК узнать, что в шине сейчас "тишина" и мы готовы отправить немедленно или железо CAN на МК это решает самостоятельно и повлиять на это решение никак нельзя?
0
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
10.10.2016, 18:11
Ответы с готовыми решениями:

Шина данных AT91
Здравствуйте! Делаю проект в IAR EW для AT91RM9200. У контроллера имеется шина...

Шина 1-Wire и термометр DS18B20
Ребята код начал ругаться на этом месте uint8_t one_wire_read_bit() {...

STM32: Шина 1-Wire и термометр DS18B20
Ребята вот тут код начал ругаться не могу понять на камне (stm32f051) оно не...

Шина между МК AVR
Появилась необходимость соединить 6 беспокойно трудящихся МК друг с другом с...

Обмен сообщениями между сокетами
Есть два приложение одно - клиент, второе - сервер. using System; using...

9
RikoD
0 / 0 / 0
Регистрация: 07.10.2011
Сообщений: 127
11.10.2016, 03:01 2
В результате "шаманизма" и разгона CAN до 2 Mbit/s достиг такой плотности сообщений (см. фото с осциллографа, там только CAN_H или CAN_L - воткнулся в один из них и землю),
т.е. на одно сообщение с DLC=4 (байта) уходит ~50 микросекунд.

Задержки делаю через DWT:
Код
#define DWT_ENABLE() \
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; \
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk

#define DWT_DELAY(us) \
DWT->CYCCNT = 0; \
while(DWT->CYCCNT < us*72)
Число 72 - это 72000000 (тактов в секунду) / 1000000 (микросекунд в секунде)
Все задержки точные, проверял на осциллографе.

N устройств в главном цикле читают свои датчики и отправляют в CAN сообщения.
Раньше скорость была не важна, поэтому стояло HAL_Delay(1) между отправками - 1ms.
Заменил на DWT_DELAY(40) - два устройства отправляют нормально, но три когда - у одного сообщения полностью теряются :(
Сделал DWT_DELAY(80) - работает три устройства, но подозреваю, что 10-к - уже не прокатит.

Опять же, в CAN есть приоритет (и разрешение коллизий) на уровне самого протокола физически - чем больше нулей в CAN ID - тем приоритетнее сообщения.
Но обратная сторона медали - если отправка идёт очень плотно, то какие-то устройства могут и вообще не смочь передать данные :(

Т.е. не понятно вот что: как рассчитать оптимально эту самую задержку, если кол-во устройств может быть переменным (hotplug, "горячая замена") ?

0
koriprokrommyst
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 1,818
11.10.2016, 04:02 3
очевидно, просчитывать наихудший случай и закладываться именно на него.
0
яверт
0 / 0 / 0
Регистрация: 15.06.2012
Сообщений: 3,097
11.10.2016, 05:19 4
Цитата Сообщение от RikoD
Опять же, в CAN есть приоритет (и разрешение коллизий) на уровне самого протокола физически - чем больше нулей в CAN ID - тем приоритетнее сообщения.
Но обратная сторона медали - если отправка идёт очень плотно, то какие-то устройства могут и вообще не смочь передать данные :(
Если мне не изменяет мой склероз, то приоритет зависит не от количества нулей (доминантных бит), а от их положения в CAN ID /пакете. Если 0 является доминантным битом, то ID 011 1111 1111 имеет больший приоритет, чем 100 0000 0000.

CAN позволяет организовать несколько уровней приоритетов. Например если ужать ID до 9 бит, то можно сделать 4 уровня: 00х хххх хххх системные сообщения, 01х хххх хххх высокий приоритет, 10х хххх хххх средний, 11х хххх хххх низкий.

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

Если жалко терять биты CAN ID, можно зарезервировать часть адресов с высоким приоритетом под системные нужды или использовать Extendid CAN ID.
0
Stiit.mi
0 / 0 / 0
Регистрация: 26.04.2010
Сообщений: 1,445
11.10.2016, 09:18 5
Цитата Сообщение от RikoD
Т.е. не понятно вот что: как рассчитать оптимально эту самую задержку, если кол-во устройств может быть переменным (hotplug, "горячая замена") ?
Немного позанудствую.
Чтобы рассчитать "оптимально" нужно знать критерий оптимума. Причем нельзя сделать так "пойди на рынок, купи как можно больше картошки и потрать как можно меньше денег". Критерии взаимоисключающие. Можно или "купи как можно больше картошки и потрать не более ххх денег" или "купи не менее ххх картошки и потрать минимум денег"

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

Модель такая - есть очередь возникших событий (в идеале пустая), есть канал с ограниченной пропускной способностью (2 Мбит)

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

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

Для адаптивной задержки нужна обратная связь. Например, головное устройство может периодически посылать пакет с информацией о загрузке шины. Если загрузка меньше определенного порога, то датчики уменьшают паузу и т.д.
0
RikoD
0 / 0 / 0
Регистрация: 07.10.2011
Сообщений: 127
11.10.2016, 12:56 6
Цитата Сообщение от яверт
Если мне не изменяет мой склероз, то приоритет зависит не от количества нулей (доминантных бит), а от их положения в CAN ID /пакете. Если 0 является доминантным битом, то ID 011 1111 1111 имеет больший приоритет, чем 100 0000 0000.
Да, абсолютно правильно. Извините, не совсем точно это описал.

Задача в общем-то такая:
1) Есть 1+32 устройства - 1 "приёмник" и 32 "датчика"/"актуатора" (но может впоследствии и больше датчиков будет, например 100).
2) "Датчики" разные - где-то 1-2 регистра uint16, а где-то 8 таких регистров (8-канальный АЦП, как пример).
3) В худшем случае по моим подсчётам имеем 32 АЦП с 32 x 8 регистрами uint16_t, т.е. суммарно 512 байт.
4) Вышеозначенные 512 байт должны все-все попадать на "приёмник" не позднее 1 миллисекунды. Получается 512 Килобайт/с или 4096000 бит/с (это только полезной нагрузки).
5) Но "датчиками"/"актуаторами" надо ещё и управлять (разное шкалирование АЦП, выставление уровней на N-канальном ЦАП и т.д.), поэтому и выбрали МК с двумя CAN на борту - один для управления (с ACK обязательно!), другой - "realtime" поток данных от датчиков.

Можно "хитрить" и если значение на датчике равно предыдущему замеру, то сообщение НЕ отправлять (а смысл?).
Но актуальная для АСУТПшников картина должна быть на "приёмнике" за 1мс и точка.

Т.е. если ПЛК что-то выставил на "актуаторе", а "датчик" это считал (проконтролировал), то RTT должен быть не более 2мс.
0
яверт
0 / 0 / 0
Регистрация: 15.06.2012
Сообщений: 3,097
11.10.2016, 14:34 7
Осётр довольно жирный - 4Мбит/с нетто не пройдёт через канал в 2Мбит/с брутто, его надо усекать. Т.е. или вводить доп. ограничение на количество устройств типа 8-канальный АЦП, или делать их настраиваемыми (интервал, кол. используемых каналов, точность).

Т.е. если ПЛК что-то выставил на "актуаторе", а "датчик" это считал (проконтролировал), то RTT должен быть не более 2мс.
Зачем это? Большинство технических процессов довольно инерционны, что бы датчик увидел изменения за 1мс. Даже в ядерном реакторе управление идёт с инерцией в минуты из-за использования "запаздывающих" нейтронов.
0
RikoD
0 / 0 / 0
Регистрация: 07.10.2011
Сообщений: 127
11.10.2016, 18:20 8
[QUOTE="яверт"]Осётр довольно жирный - 4Мбит/с нетто не пройдёт через канал в 2Мбит/с брутто, его надо усекать. Т.е. или вводить доп. ограничение на количество устройств типа 8-канальный АЦП, или делать их настраиваемыми (интервал, кол. используемых каналов, точность).

[QUOTE="Цитата:[/QUOTE]
Т.е. если ПЛК что-то выставил на "актуаторе", а "датчик" это считал (проконтролировал), то RTT должен быть не более 2мс.
Зачем это? Большинство технических процессов довольно инерционны, что бы датчик увидел изменения за 1мс. Даже в ядерном реакторе управление идёт с инерцией в минуты из-за использования "запаздывающих" нейтронов.

Там 2 x 2 Мбит/с каналы, т.е. в сумме 4 Мбит/с.
Опять же можно использовать трюк: если значения не менялись (а они не будут меняться все и сразу), то можно и не переприсылать одно и то же.

P.S.
Зачем это - написать тут не могу, но почти угадали. Такие уж требования - RTT за 2мс.
0
Ot-x
0 / 0 / 0
Регистрация: 30.12.2013
Сообщений: 192
11.10.2016, 21:47 9
[QUOTE="яверт"]Осётр довольно жирный - 4Мбит/с нетто не пройдёт через канал в 2Мбит/с брутто, его надо усекать. Т.е. или вводить доп. ограничение на количество устройств типа 8-канальный АЦП, или делать их настраиваемыми (интервал, кол. используемых каналов, точность).

[QUOTE="Цитата:[/QUOTE]
Т.е. если ПЛК что-то выставил на "актуаторе", а "датчик" это считал (проконтролировал), то RTT должен быть не более 2мс.
Зачем это? Большинство технических процессов довольно инерционны, что бы датчик увидел изменения за 1мс. Даже в ядерном реакторе управление идёт с инерцией в минуты из-за использования "запаздывающих" нейтронов.

Этим многие страдают - сначала понаделают "модулей", затем сделают кривой алгоритм обработки, где выжимают все соки из не предназначенного для этого, а потом удивляются, почему что-то важное изредко, но пропадает)))
0
x893
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 886
11.10.2016, 23:06 10
Сплошь и рядом.
0
11.10.2016, 23:06
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
11.10.2016, 23:06

Обмен сообщениями между формами
Проблема такая: есть одно окно , на нём кнопка &quot;ввести данные&quot; , при нажатии...

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

Обмен сообщениями между двумя ПК
Подскажите, как можно организовать отправку сообщений между двумя компами. Одно...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
10
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Рейтинг@Mail.ru