LINUX.ORG.RU

CAN шина и Linux

 , ,


6

2

Добрый день, господа. Скорее всего в сообществе lor есть люди, которые работали со связкой Linux+CAN, возможно кто-то поможет советами.

Я полностью 0 с шиной и не работал с не ни на стороне МК, ни на стороне Linux. Собственно в основном у меня следующие вопросы:

  • Краткий и сзажий, но информативный мануал ( это и вот это я уже видел, нифига не кратко и сжато). Киньте ссылкой, пожалуйста.
  • В каком направлении копать по интеграции linux<-->CAN? (очень бы хотелось мануал с простенькими примерами)
  • Среды разработки/Дебагер (НЕ обязательно open и под ontopic). Имеется в виду не только среды разработки ПО для МК, но и среды дебага схем, где можно мышкой натыкать компоненты и связи, залить прошивку в виртуальный контроллер и посмотреть как оно работает.

Задача: есть одноплатный компьютер Cubieboard (опционально. На его место может стать Эдисон или еще чего-нибудь). К нему, по CAN хочется подключить рассредоточеные контроллеры, которые будут собирать информацию с датчиков, отдавать управляющий сигнал на двигатели.

CAN выбрал по причинам: универсальность, помехозащищенность, популярность.
Ethernet НЕ выбрал по причине: overkill (в моем случае).

сексуальные предпочтения в основном работаю с PIC'ами, не люблю arduino

Вызываю владык ncrmnt, Puzan, Eddy_Em, Zubok и всех, кто может помочь

★★★

Последнее исправление: disee (всего исправлений: 1)
Ответ на: комментарий от anonymous

CAN - ништяк, а Linux говно - для CAN мало пригоден, потому что нужен реалтайм

Линукс прекрасно умеет риалтайм. Лучше чем все остальные мало-мальски доступные системы.

ты уверен ? чета я драйверов не наблюдаю

Гуглить не умеем? http://sourceforge.net/projects/can4linux/ Для Allwinner драйвер есть, работает без проблем. Ноги PH20 и PH21 если правильно помню.

Stanson ★★★★★
()
Ответ на: комментарий от disee

Всё это вешать на одну шину - дело гиблое. Группировать конечные девайсы по местонахождению, поключать к локальному контроллеру (в который вынести максимум логики и обработки) и соединять локальные контроллеры по Ethernet. По Ethernet гонять высокоуровневые команды локальным контроллерам. Будет и риалтайм и на помехи пофиг.

Stanson ★★★★★
()
Ответ на: комментарий от alx777

Ты жопу с пальцем не сравнивай. А CAN имеет довольно-таки узкую нишу: промышленное оборудование и сильные помехи. В остальных случаях CAN — оверхед.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Eddy_Em

Ты жопу с пальцем не сравнивай.

Похоже вы ни исходный пост не прочитали, ни ответы автора.
У автора как раз управление пальцем (точней всеми десятью). А пихать по eth в каждый контроллер и датчик, вот самый натуральный оверхед. А вот CAN тут как раз очень даже в жилу. Можно конечно и rs485 обойтись, но тогда руками придется делать и арбитраж и контроль целостности и прочее. А тут все встроенное.

yax123 ★★★★★
()
Ответ на: комментарий от alx777

на скорости 250км/ч подухи не помогут тело будет рваться под собственным весом от мгновенной или почти мгновенной остановки. Возьмем от фэйса идиота до руля расстояние в метр 1/70=14мс а мы тут про микросекундную посылку, еще раз повторюсь в автопроме времена огромные, вполне по силам микроконтроллерам и современным интерфейсам.

anonymous
()
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Да ты что. Микроконтроллеры вполне так жирные ныне. Про разбазаривание ресурсов вообще чушь несусветная, исключение составляет самый низший сегмент, когда нужна минимальная цена производства. Про библиотечки стандартных функций и прочую ерунду вообще поржал.
Я там выше писал, про что и как делается, большинство задач вполне крутятся внутри оси. Если время реакции совсем мелкое нужно, вывешиваем на прерывание, и пишем обработчик, кстати и такой финт можно описать внутри оси, да слегонца обдолбоное поведение ОС, но лучше его стандартизировать, чем каждый раз изобретать велосипед.
И уж простите, вы застряли в лохматых, раз у вас такие познания в ОС для МК

anonymous
()
Ответ на: комментарий от Stanson

Линукс прекрасно умеет риалтайм. Лучше чем все остальные мало-мальски доступные системы.

чушь полнейшая даже с патчем PREEMT_RT. Реалтайм в Linux возможен только через внешние костыли которые собственно к Linux никакого отношения не имеют, другое дело что совместить это все вполне доступно

Для Allwinner драйвер есть, работает без проблем.

бэкпорт на китайское ядро не встречал случайно ? а то ванильное ядро это конечно круто но там ничего толком не поддерживается - в первую очередь GPU и Cedar интересуют

anonymous
()
Ответ на: комментарий от anonymous

чушь полнейшая даже с патчем PREEMT_RT. Реалтайм в Linux возможен только через внешние костыли которые собственно к Linux никакого отношения не имеют, другое дело что совместить это все вполне доступно

Ну как бе PREEMT_RT - это для совсем неосиляторов, чтобы из реп поставить. И то, в приличном количестве случаев - вполне годно. У меня под ним linuxcnc работает, на фрезерный станок, всё отлично. А так - RTAI в зубы и вперёд.

бэкпорт на китайское ядро не встречал случайно ?

Оно ж вроде и под 3.4 собирается, там ничего такого нету. TARGET=BANANAPI и вперёд.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

anonymous
()
Ответ на: комментарий от yax123

Не обязательно именно CAN, можно хоть RS-232 с адресацией в 9-битном режиме.

Но желание барина — закон...

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

1.5метра 115200бод
тогда уж RS-485, но классика предполагает питание трешка, мостики есть и на двушечку.

anonymous
()
Ответ на: комментарий от anonymous

понятие «дорогой контроллер» не абсолютно, а относительно. зависит от цены проекта и от количества тех контроллеров в машине. когда надо сделать тысячи плат, тогда стоит задуматься. да даже на сотне плат если сэкономить по писят баксов - уже неплохая экономия выходит.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Stanson

Ну как бе PREEMT_RT - это для совсем неосиляторов, чтобы из реп поставить. И то, в приличном количестве случаев - вполне годно. У меня под ним linuxcnc работает, на фрезерный станок, всё отлично.

Разница между soft rt и hard rt обнаружится, только если станок оттяпает кому-нибудь палец, а до того момента все будет отлично.

А так - RTAI в зубы и вперёд.

Предыдущий оратор, по-видимому, и относил это к категории «внешние костыли которые собственно к Linux никакого отношения не имеют», так как работа приложения в юзерпейсе Linux очень сильно отличается от работы через такой специализированный интерфейс

annulen ★★★★★
()
Ответ на: комментарий от Iron_Bug

ну, я в реальном мире живу.

Несколько раз прочитал «в реальном времени живу»

disee ★★★
() автор топика
Ответ на: комментарий от anonymous

чушь полнейшая даже с патчем PREEMT_RT

Насколько я помню, процентов 90 фич PREEMPT_RT уже давно в ванильном ядре, да и по производительности вполне приемлемо для большинства применений, например для Zynq 79 usec maximal latency в обычном юзерспейсе без всяких костылей (cyclictest усыпляет тред на указанное время и меряет разницу когда тред проснется) вполне себе результат я считаю:

https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rb...

alx777 ★★
()
Ответ на: комментарий от alx777

Да, живое. С ARM правда у него не очень, но есть ещё Xenomai - у него с ARM лучше.

Stanson ★★★★★
()
Ответ на: комментарий от annulen

Разница между soft rt и hard rt обнаружится, только если станок оттяпает кому-нибудь палец, а до того момента все будет отлично.

Во-первых, станки разные бывают, во-вторых нехрен пальцы в станок совать, в-третьих, не одними станками применение rt ограничивается.

работа приложения в юзерпейсе Linux очень сильно отличается от работы через такой специализированный интерфейс

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

Stanson ★★★★★
()
Ответ на: комментарий от Iron_Bug

По скольку? по 50 баксов с платы? Вы там не зажрались? Мы тут в нижнем ценовом сегменте 24 32 серию микрочипа жуем и не жужжим, ценник вполне устраивает, при хороших объемах и почти прямых поставках. Чтоб не морозить деньги на складе комплектухи логистов надо или кормить хорошо или бить больно, выбирайте.

anonymous
()
Ответ на: комментарий от alx777

да и по производительности вполне приемлемо для большинства применений, например для Zynq 79 usec maximal latency в обычном юзерспейсе без всяких костылей

давай ближе к CAN а не абстрактные «большинство применений» - чтобы не особо напрягаться предположим пакет 100 бит, на скорости 1 мегабит линукса едва хватит чтобы в реалтайме на прерывания реагировать - на обработку этого пакета времени уже нет, ядро почти на 100% загрузит процессор только переключениями контекста.

anonymous
()
Ответ на: комментарий от anonymous

Не хочу влезать в холивар, но вы бы не могли, пожалуйста, скинуть какой-нибудь материал связанный с ограничениями по производительности (обычно в таком случае на ЛОРе принято говорить «Гони пруфы»).

Собственно просьба только потому, что этот аспект меня действительно интересует

disee ★★★
() автор топика
Ответ на: комментарий от disee

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

anonymous
()
Ответ на: комментарий от anonymous

С рт патчем задачи, драйвера и еще много чего должны иметь привилегии ядра

Что такое «привилегии ядра»? Если «исполняться в режиме ядра», то это не так.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Почитай доки, врать не буду но раньше планировщик у РТ был отдельный, а само ядро линукса крутилось как задача, если у рт не было обработчика для какого-то события, то оно переадресовывалось задаче линукс. Вот такое вот я не я и шапка не моя. Может что-то поменялось, не слежу плотно. Ну и не будем забывать, что железо общего назначения, это не обвяз микроконтроллера вокруг числодробилки, буферизация построена совсем иначе и секса с ней будет куда как больше.

anonymous
()
Ответ на: комментарий от anonymous

раньше планировщик у РТ был отдельный, а само ядро линукса крутилось как задача

Это очень давно было (хотя в RTAI и сейчас так, наверное). А патч PREEMPT_RT как раз и сделан для того, чтобы HRT можно было делать в юзерспейсе.

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

Ну это да, там своя атмосфера.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Realtime-Preempt патчи обеспечивают максимальное гарантированное время реакции порядка 2 микросекунд и максимальную задержку около 17 микросекунд.

И кто гарантировал, что задача из юзерспейса не дергает что-то чему не указан высокий приоритет, костыли костылики.

anonymous
()
Ответ на: комментарий от disee

Это конечно зависит от задачи. Если загрузка ЦПУ в нормальном режиме превышает 70% то тут уже ни о каком реалтайме речь не идет. Поэтому сначала надо определиться с требованиями по производительности и коммуникациям, потом выбирать железо с запасом

Если говорить о PREEMPT_RT то оно сильно помогает, разница хорошо видна при коротких пиковых нагрузках

Например в моем случае 100msec цикл опроса CAN шины в userspace приложении изменился со 100msec +/- 10msec до 100msec +/- 100usec что было весьма критично для heartbeat механизма

alx777 ★★
()
Ответ на: комментарий от anonymous

давай ближе к CAN а не абстрактные «большинство применений» - чтобы не особо напрягаться предположим пакет 100 бит, на скорости 1 мегабит линукса едва хватит чтобы в реалтайме на прерывания реагировать - на обработку этого пакета времени уже нет, ядро почти на 100% загрузит процессор только переключениями контекста.

Ну давай. 100 бит на 1мбит шине это 103 микросекунды с interframe spacing'ом, т.е. 9708 меседжей в секунду при 100% загрузке, не думаю что такое количество прерываний окажет значительное влияние на хоть сколько-нибудь современный микроконтроллер

Не говоря уже о том что грузить шину на 100% в таких случаях когда нужна быстрая реакция в здравом уме никто не будет

alx777 ★★
()
Ответ на: комментарий от anonymous

И кто гарантировал, что задача из юзерспейса не дергает что-то чему не указан высокий приоритет, костыли костылики.

Тот, кто эту систему дизайнил

alx777 ★★
()
Ответ на: комментарий от alx777

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

anonymous
()
Ответ на: комментарий от tailgunner

Что такое «привилегии ядра»? Если «исполняться в режиме ядра», то это не так.

В PREEMPT_RT насколько я понял можно с помощью sched_setscheduler() приоритет userspace треда сделать выше чем у kernel треда или даже прерывания

alx777 ★★
()
Ответ на: комментарий от anonymous

но живя в этом юзерспэйсе позаботься обо всем сам.

Каким образом планировщик должен догадаться что в твоей системе имеет наиывысший приоритет ?

alx777 ★★
()
Ответ на: комментарий от alx777

Речь о подходах в рт под линукс и рт под мк. В первом случае ты обязан все проконтролировать. Во втором случае секс с контролем ты имеешь только если хочешь меньше гарантированного времени.

anonymous
()
Ответ на: комментарий от alx777

Правильные вопросы задаешь, укажи и будет знать.

anonymous
()
Ответ на: комментарий от alx777

т.е. 9708 меседжей в секунду при 100% загрузке, не думаю что такое количество прерываний окажет значительное влияние на хоть сколько-нибудь современный микроконтроллер

ты чета совсем не догоняешь то что читаешь и пишешь

например для Zynq 79 usec maximal latency в обычном юзерспейсе

по русски - cyclictest показывает через какое время задача получает управление после того как происходит внешнее событие, для cyclictest это прерывания от таймера. При переключении контекста процессор не выполняет никакой полезной нагрузки и в нашем случае 79 микросекунд из 100 он будет выполнять бесполезную работу - о чем тут дальше говорить ? процессор на 80 % занят бесполезной нагрузкой. Если ты из современного топового процессора делаешь контроллер CAN то ты извини дебил.

anonymous
()
Ответ на: комментарий от anonymous

И кто гарантировал,

Руки.

что задача из юзерспейса не дергает что-то чему не указан высокий приоритет костыли костылики

man priority inheritance

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Just don't do it. If you really need it, your system is broken anyway.

Глупости. RT-часть в любом случае должна взаимодействовать с не-RT частью.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ога, должна, но что делать если не рт часть унаследовала лвл, а другая задача из рт части не может выдавить ее. Не вопрос решаем, костылями. Но твоя система поломана (:

anonymous
()
Ответ на: комментарий от anonymous

Just don't do it. If you really need it, your system is broken anyway.

Глупости. RT-часть в любом случае должна взаимодействовать с не-RT частью.

Ога, должна

Без PI это broken anyway.

что делать если не рт часть унаследовала лвл, а другая задача из рт части не может выдавить ее

Щито?

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.