sluttish 0 21 сентября, 2013 Опубликовано 21 сентября, 2013 · Жалоба У любого устройства есть свои пределы. CAN довольно неудобно обрабатывать на Линуксе. Она довольно неоднородна (имею ввиду сложность сообщений) и на каждое сообщение может требоваться индивидуальная реакция. Поэтому классический подход разгрузки прерываний в Линусе -- ПДП применить непросто, а может и невозможно. Я уверен что процессор без ОС или с какой-нибудь реал-тайм ОС покажет лучшие результаты чем Линукс. Дело в том, что в Линуксе плата за универсальность долгий вход в обработчик прерывания. Если вам будет интересно сделать CAN на другом процессоре, я лет 10 назад писал драйверы для RTOS SALVO на микрочипе. Причем там есть как с внутренним контроллером так и с подключенным как в статье по SPI. Mогу дать код. Прерывание тупо кладет (если нет ошибок) в очередь, а тред уже забирает оттуда и обрабатывает. Система быстро выходит из прерывания, а значит имет лучше динамические характеристики. Сейчас поставлена задача реализовать все под Linux, к тамуже там еще будет графическое приложение на Qt. Да к томуже сейчас мне работодатель не даст возможности эксперементировать с другими операционными системами, в целом интересно, но пока нет времени рассматривать это направление, а вот на исходники интересно будет посмотреть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 3 21 сентября, 2013 Опубликовано 21 сентября, 2013 · Жалоба Сейчас поставлена задача реализовать все под Linux, к тамуже там еще будет графическое приложение на Qt. Да к томуже сейчас мне работодатель не даст возможности эксперементировать с другими операционными системами, в целом интересно, но пока нет времени рассматривать это направление, а вот на исходники интересно будет посмотреть. Ну тогда я вижу только один способ уменьшить нагрузку. Сделать меньше сообщений. Не знаю насколько это приемлимо. Дайте ваш емайл адрес в приватном сообщении и я пошлю вам примеры кода драйвера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewn 0 21 сентября, 2013 Опубликовано 21 сентября, 2013 · Жалоба Кстати - в ванильном ядре и HECC NAPI поддерживает http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L604 Ну и жуткий же акцент в комментариях, страх божий... Не зря весельчаки так странно контроллер назвали, от комментариев так и хочется спросить "what the heck?!"... :))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sluttish 0 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Кстати - в ванильном ядре и 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? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sluttish 0 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Ну тогда я вижу только один способ уменьшить нагрузку. Сделать меньше сообщений. Не знаю насколько это приемлимо. Дайте ваш емайл адрес в приватном сообщении и я пошлю вам примеры кода драйвера. Мне форум не дает послать вам сообщение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 3 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Мне форум не дает послать вам сообщение. Я попробовал послать вам, но получил такую ошибку: "Обнаружены следующие ошибки Невозможно отправить это сообщение, так как получатель отключил свой личный ящик, или он попросту переполнен. Это личное сообщение не отправлено" Может у вас есть сообщения, которые можно стереть? Я не знаю правил функционирования личной почты. Может хранятся посланные сообщения и их предел достигнут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sluttish 0 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Я попробовал послать вам, но получил такую ошибку: "Обнаружены следующие ошибки Невозможно отправить это сообщение, так как получатель отключил свой личный ящик, или он попросту переполнен. Это личное сообщение не отправлено" Может у вас есть сообщения, которые можно стереть? Я не знаю правил функционирования личной почты. Может хранятся посланные сообщения и их предел достигнут. У меня такая же ошибка, у меня сообщений вообще нет, так же пробовал настраивать обмен сообщениями, ни к чему положительному не привело, помощь тоже не работает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 3 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Все верно, но как задействовать NAPI? Для ARM архитектуры, я делаю так В корне кернела исполнить команду: make ARCH=arm menuconfig Нажмите прмяой слеш : '/' в строке поиска введите NAPI Получите список всех возможных функций имэущих NAPI в названии ключа компиляции. Там будет отражено состояние ключа, разрешающего функцию, путь к нему и зависимость его от других ключей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sluttish 0 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Для 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? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 3 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба но как эти опции влияют на CAN не понимаю, я их не включал. Если их включить как они повлияют на обработку приема по интерфейсу CAN и как необходимо переписать программу приема, чтоб использовать NAPI? Я не знаком с NAPI и CAN драйверы на Линуксе я тоже не делал. Полагаю, что CAN драйвер надо настроить (или дописать), чтобы использовал механизм NAPI. Если вы не работали с кернелом, то вам будет непросто выполнить эту задачу. Прежде чем начинать надо оценить насколько оно вам поможет. Я отношусь скептически к использованию поллинга при большом количестве сообщений. Уменьшение нагрузки на процессор в случае поллинга возможно за счет потери сообщений. Возможно более короткий обработчик (чем прерывание) положительный фактор, однако частые обращения, когда не надо и запоздалые, когда надо -- это негативная сторона поллинга. Ведь вашему процессору все-равно необходимо работать над каждым сообщением в прерывании или нет. Он все равно потратит на обработку сообщений много времени. Использование поллинга не всегда гарантирует, что все сообщения будут приняты. Особенно в сложной обстановке с массовым потоком сообщений. Решение задачи я вижу только в одном из направлений: 1. Снижение интенсивности сообщений 2. Использование более мощного процессора. 3. Установка дополнительного устройства, ответственного за обработку (хотя бы частичную) сообщений. В третьем случае может понадобится написать драйвер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 11 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба Это я делал, находил две опции: .. но как эти опции влияют на CAN не понимаю, я их не включал. Эти - никак не влияют. как необходимо переписать программу приема, чтоб использовать NAPI? Ничего переписывать не надо - NAPI должен поддерживать драйвер, некоторые делают опциаональные настройки - выбор между обычным и New API, у вашего контроллера NAPI используется всегда http://lxr.free-electrons.com/source/drive.../ti_hecc.c#L860 почему поллинг не снижает количество прерываний - это надо разбираться с этим драйвером и контроллером. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewn 0 23 сентября, 2013 Опубликовано 23 сентября, 2013 · Жалоба почему поллинг не снижает количество прерываний - это надо разбираться с этим драйвером и контроллеромКоллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно... Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 24 сентября, 2013 Опубликовано 24 сентября, 2013 · Жалоба Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 128KB/s, т.е. цыплячья скорость UARTа, и это нагружает Ослинукс на 600 мегагерцовом процессоре???? Я или сам ослинукс или мне просто смешно... Интервал между двумя последовательными байтами 4,700 клоков - этого мало _один_ байт обработать???? А 0.8 на шине, т.е. 0.8*128 это уже 5,900 клоков на байт - за такое время не только пообедать, но и посуду можно вымыть... Мда.. Вы линукс то видали? Сколько там процессов/тредов бежит смотрели? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 3 24 сентября, 2013 Опубликовано 24 сентября, 2013 (изменено) · Жалоба Коллеги, никак не пойму, что за проблему вы тут обсуждаете? Один мегабит в секунду - это 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% занятости процессора. Изменено 24 сентября, 2013 пользователем Tarbal Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewn 0 24 сентября, 2013 Опубликовано 24 сентября, 2013 (изменено) · Жалоба Цыплячья скорость 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 промилле. Меньше, чем процент. Изменено 24 сентября, 2013 пользователем AndrewN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться