Перейти к содержанию
    

Большое число программных прерываний в ОС Linux при приеме информации по интерфейсу CAN на AM3517

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

 

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

 

Если вам будет интересно сделать CAN на другом процессоре, я лет 10 назад писал драйверы для RTOS SALVO на микрочипе. Причем там есть как с внутренним контроллером так и с подключенным как в статье по SPI. Mогу дать код.

 

Прерывание тупо кладет (если нет ошибок) в очередь, а тред уже забирает оттуда и обрабатывает. Система быстро выходит из прерывания, а значит имет лучше динамические характеристики.

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Ну тогда я вижу только один способ уменьшить нагрузку. Сделать меньше сообщений.

Не знаю насколько это приемлимо. Дайте ваш емайл адрес в приватном сообщении и я пошлю вам примеры кода драйвера.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати - в ванильном ядре и HECC NAPI поддерживает

http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L604

Ну и жуткий же акцент в комментариях, страх божий... Не зря весельчаки так странно контроллер назвали, от комментариев так и хочется спросить "what the heck?!"... :)))

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати - в ванильном ядре и HECC NAPI поддерживает

http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L604

 

насколько я понял

http://processors.wiki.ti.com/index.php/Si...29_Linux_Driver

 

у вас на процессоре такой контроллер используется.

 

PS я пропустил сообщение _3m

http://electronix.ru/forum/index.php?showt...t&p=1194005

он вам об этом уже говорил

 

Все верно, но как задействовать NAPI?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну тогда я вижу только один способ уменьшить нагрузку. Сделать меньше сообщений.

Не знаю насколько это приемлимо. Дайте ваш емайл адрес в приватном сообщении и я пошлю вам примеры кода драйвера.

 

Мне форум не дает послать вам сообщение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне форум не дает послать вам сообщение.

 

 

 

Я попробовал послать вам, но получил такую ошибку:

 

"Обнаружены следующие ошибки

Невозможно отправить это сообщение, так как получатель отключил свой личный ящик, или он попросту переполнен.

 

Это личное сообщение не отправлено"

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я попробовал послать вам, но получил такую ошибку:

 

"Обнаружены следующие ошибки

Невозможно отправить это сообщение, так как получатель отключил свой личный ящик, или он попросту переполнен.

 

Это личное сообщение не отправлено"

 

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

 

У меня такая же ошибка, у меня сообщений вообще нет, так же пробовал настраивать обмен сообщениями, ни к чему положительному не привело, помощь тоже не работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все верно, но как задействовать NAPI?

 

Для ARM архитектуры, я делаю так

 

В корне кернела исполнить команду:

make ARCH=arm menuconfig

 

Нажмите прмяой слеш : '/'

в строке поиска введите NAPI

 

Получите список всех возможных функций имэущих NAPI в названии ключа компиляции.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для ARM архитектуры, я делаю так

 

В корне кернела исполнить команду:

make ARCH=arm menuconfig

 

Нажмите прмяой слеш : '/'

в строке поиска введите NAPI

 

Получите список всех возможных функций имэущих NAPI в названии ключа компиляции.

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

 

Это я делал, находил две опции:

 

Symbol: TULIP_NAPI [=n]
Type  : boolean
Prompt: Use RX polling (NAPI)
Defined at drivers/net/tulip/Kconfig:79
Depends on: NETDEVICES [=y] && NET_ETHERNET [=y] && NET_TULIP [=n] && TULIP [=n]
Location:
    -> Device Drivers
      -> Network device support (NETDEVICES [=y])
        -> Ethernet (10 or 100Mbit) (NET_ETHERNET [=y])
          -> "Tulip" family network device support (NET_TULIP [=n])
            -> DECchip Tulip (dc2114x) PCI support (TULIP [=n])


Symbol: TULIP_NAPI_HW_MITIGATION [=n]
Type  : boolean
Prompt: Use Interrupt Mitigation
Defined at drivers/net/tulip/Kconfig:93
Depends on: NETDEVICES [=y] && NET_ETHERNET [=y] && NET_TULIP [=n] && TULIP_NAPI [=n] 
Location:
    -> Device Drivers
      -> Network device support (NETDEVICES [=y])
        -> Ethernet (10 or 100Mbit) (NET_ETHERNET [=y])
          -> "Tulip" family network device support (NET_TULIP [=n])
            -> DECchip Tulip (dc2114x) PCI support (TULIP [=n])
              -> Use RX polling (NAPI) (TULIP_NAPI [=n])

 

но как эти опции влияют на CAN не понимаю, я их не включал. Если их включить как они повлияют на обработку приема по интерфейсу CAN и как необходимо переписать программу приема, чтоб использовать NAPI?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

но как эти опции влияют на CAN не понимаю, я их не включал. Если их включить как они повлияют на обработку приема по интерфейсу CAN и как необходимо переписать программу приема, чтоб использовать NAPI?

 

Я не знаком с NAPI и CAN драйверы на Линуксе я тоже не делал. Полагаю, что CAN драйвер надо настроить (или дописать), чтобы использовал механизм NAPI. Если вы не работали с кернелом, то вам будет непросто выполнить эту задачу.

 

Прежде чем начинать надо оценить насколько оно вам поможет.

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

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

 

Решение задачи я вижу только в одном из направлений:

1. Снижение интенсивности сообщений

2. Использование более мощного процессора.

3. Установка дополнительного устройства, ответственного за обработку (хотя бы частичную) сообщений.

 

В третьем случае может понадобится написать драйвер.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это я делал, находил две опции:

..

но как эти опции влияют на CAN не понимаю, я их не включал.

 

Эти - никак не влияют.

 

как необходимо переписать программу приема, чтоб использовать NAPI?

 

Ничего переписывать не надо - NAPI должен поддерживать драйвер, некоторые делают опциаональные настройки - выбор между обычным и New API, у вашего контроллера NAPI используется всегда

 

http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L860

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

почему поллинг не снижает количество прерываний - это надо разбираться с этим драйвером и контроллером
Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно...

 

Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно...

 

Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть...

Мда..

 

Вы линукс то видали?

Сколько там процессов/тредов бежит смотрели?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно...

 

Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть...

 

Цыплячья скорость UART в 10 раз ниже 115kBit/S. У UART сообщения однобайтовые и все. У CAN надо каждое сообщение обрабатывать. Значит ПДП не обойдешься как можно было бы на UART сделать.

 

Сколько времени занимает вход в в прерывание (~5uS)? Умножте это на 2000 (128000/64). Столько времени надо отдать на накладные расходы каждую секунду. Идет борьба за это время.

2000*5uS = 10mS. Что есть один процент. Похоже вы правы. Надо исследовать и найти что пожирает время.

 

Я честно боролся за оптимизацию :)

 

 

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

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

 

Могу помочь найти как сконфигурировать ножки и место куда вставить команды.

 

Мда..

 

Вы линукс то видали?

Сколько там процессов/тредов бежит смотрели?

 

Как я понял разница когда есть поток сообщений и когда нет отличаются на 60% занятости процессора.

Изменено пользователем Tarbal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Цыплячья скорость UART в 10 раз ниже 115kBit/S
Упс..., промашку давал... Утячья скорость получается - в полёте... :)

 

Сколько времени занимает вход в в прерывание (~5uS)? Умножте это на 2000 (128000/64)
Интересно. Т.е. 1 интеррапт на каждые 64 байта? Это облегчает задачу. EDMA же привязана к ивенту, она и сложит эти 64 байта в угол, т.е. в буфер...

 

5 микросек это 3000 клоков процессора. На вход многовато, вход прост (разумно предположить такое?), а вот выход сложнее из-за перепланировки (знать бы алгоритм...). Ну условно можно считать, что 5 на вход и выход - разумное число. Хотя, это же Ослинукс, кто его разберёт... При 0.8 загрузке 5,900*64 клоков на 64 байта это 377К, от коего числа 3К на оверхед интеррапта составляет 0.0079 - т.е. 8 промилле. Меньше, чем процент.

Изменено пользователем AndrewN

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...