периферийные шины

встраиваемые модели

Модераторы: Olej, vikos

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 13 мар 2019, 00:33

littlegene писал(а): Просто в копилку данной ветки сети: видео о том, в чем проблематика работы SPI в режиме slave на Linux.
https://youtu.be/tCa_ydVwKhM
Я изучу, потом выскажу свои соображения по этому поводу.

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 13 мар 2019, 11:49

Olej писал(а):
Urry писал(а): 2. Сигналы квитирования микросхем АЦП можно подвести через GPIO, используя встроенные в процессоре таймеры (DMA). Это позволяет также минимизировать аналоговую измерительную часть.
Да, сигнал синхронизации через GPIO для считывания данных с АЦП, или синхронизации любого внешнего устройства, или инициирования какого-то события на периферии - это как-раз хорошие примеры того где и как используется подсистема GPIO Linux.

Но тут нужно всегда иметь в виду одно обстоятельство, которое всегда упускают из виду разработчики аппаратных вещей, привыкшие к hard-реализациям:
- Linux - многозадачная/многопоточная система, в которой постоянно выполняются, конкурируя между собой, достаточно много параллельных ветвей (потоков) ... даже в то время, когда вам кажется что система простаивает и ничего вообще не делает;
- и многие из этих потоков имеют достаточно высокий приоритет, с которым они всегда вытеснят, прервут и отложат выполнение любого вашего пользовательского приложения;
- в результате ваши синхроимпульсы (как и всякие и любые действия в системе) будут "плавать" по временной шкале, то что аппаратчики часто называют джитер: если вы заказываете повторяющееся событие с периодом, скажем, в 1 мс, то реально интервалы будут носить случайное распределение, некоторые (редкие) отсчёты будут "затягиваться" на 2 мс, ещё некоторые (ещё более редкие) - на 5 мс., а некоторые (особо редкие, 1:1000000) - на 10 мс.

Эта особенность приводит к тому, что это требует иногда просто пересмотреть архитектуру проекта, а не бороться упорно за жёсткую детерминированность во времени событий.
Сможете посоветовать?
Немного другая ситуация. Есть микросхема АЦП (работающая по SPI) в режиме мастер, промежуточный микроконтроллер, который подключен тоже через SPI к Orange через его "гребенку". У Orange на гребенке всего один интерфейс SPI. Orange под linux. В этой версии линукса, по словам программиста, SPI может быть только мастером. Поэтому назначение микроконтроллера - подружить два мастера, сделать предварительное накопление данных АЦП в двухбуферном режиме с последующей поочередной отсылкой их в Orange. Со стороны АЦП в микроконтроллер данные поступают со скоростью 16 Мбит/с, скорость SPI интерфейса со стороны Orange 50 Мбит/c. В Orange под процесс сбора данных можно специально выделить одно ядро. Размер буферов 64 кБайт. Эот максимальный размер буфера при использовании DMA. Итого: с АЦП буфер наполняется за 32.7 мс, вычитывается за 10 мс. Т.е. есть примерно до 20 мс запаса при каждом считывании данных.
Рассматриваю два варианта считывания данных:
1. В случае использования только SPI сигналов готовность данных к отсылке (заполнение одного буфера) должна выполняться командой, отсылаемой ORANGEм в микроконтроллер, т.е по сути выполнять опрос через какой-то интервал времени, скажем, несколько мс. При готовности выполняется считывание данных. Заняты три сигнала. SPI в режиме полный дуплекс.
2. В случае использования SPI c дополнительным выводом GPIO готовности данных. Orange может использовать как опрос этого вывода, так и прерывание. Используются также три линии, т.к. SPI интерфейс работает в полудуплексном режиме.

Оба варианта рабочие. Второй вариант - стандартный, требует меньших временных затрат на обработку.
По джитеру... Мне кажется, что в обоих вариантах, использующих опрос, джитер между опросами будет одинаков.
Мне кажется, что вариант 2 более "рабочий" и использование вывода GPIO оправдано, особенно если используется прерывание.

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

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 13 мар 2019, 12:25

Urry писал(а): Есть микросхема АЦП (работающая по SPI) в режиме мастер, промежуточный микроконтроллер, который подключен тоже через SPI к Orange через его "гребенку". У Orange на гребенке всего один интерфейс SPI. Orange под linux.
Во-первых, Orange-ей существует великое множество разных. Какой?
Urry писал(а): В этой версии линукса, по словам программиста, SPI может быть только мастером.
С этим нужно разбираться (вам). Нет линуксов в котором что-то так, и линуксов в котором что-то иначе, все Linux - одинаковы. И если что-то там есть или нет, то везде.
Urry писал(а): В Orange под процесс сбора данных можно специально выделить одно ядро.
Это очень плохая идея!
И за которую все аппаратчики хватаются в первую очередь. :-o
Многопоточная система Linux умеете управляться своими ядрами гораздо эффективнее, чем вы это можете привязать вручную.
Urry писал(а): Рассматриваю два варианта считывания данных:
1. В случае использования только SPI сигналов готовность данных к отсылке (заполнение одного буфера) должна выполняться командой, отсылаемой ORANGEм в микроконтроллер, т.е по сути выполнять опрос через какой-то интервал времени, скажем, несколько мс. При готовности выполняется считывание данных. Заняты три сигнала. SPI в режиме полный дуплекс.
2. В случае использования SPI c дополнительным выводом GPIO готовности данных. Orange может использовать как опрос этого вывода, так и прерывание. Используются также три линии, т.к. SPI интерфейс работает в полудуплексном режиме.

Оба варианта рабочие. Второй вариант - стандартный, требует меньших временных затрат на обработку.
По джитеру... Мне кажется, что в обоих вариантах, использующих опрос, джитер между опросами будет одинаков.
Мне кажется, что вариант 2 более "рабочий" и использование вывода GPIO оправдано, особенно если используется прерывание.
Всё сказанное выглядит разумным, по первому поверхностному взгляду.
Хотя ... вообще то говоря, в АСУТП и технике программируемых логических контроллеров (PLC) всегда отдают предпочтение именно периодическому программному пулингу. Особенно если этот опрашивающий процесс (поток) запустить а). с приоритетом реального времени + б). с высоким приоритетом.
При этом не нужно систему дёргать асинхронными прерываниями, что всегда повергает её в хаотическое поведение.
Кроме того, на обработке прерываний в Linux ... "забодаетесь пыль глотать": а). только в ядре, в модуле, б). с большой вероятностью ошибки и краха всей системы (мёртвого подвисания!).
Urry писал(а): Хотелось бы спросить о джитере прерывания. В случае с выделенным ядром процессора Orange для сбора данных и в случае если такого выделения нет за какое время прерывание дойдет до обработчика прерывания? Думаю, в первом случае не более чем за несколько десятков микросекунд? Во втором, понятное дело, зависит от приоритетности приложений, надеюсь что не более нескольких мс. Как Вы считаете?
Цифр предсказать не могу, всё зависит от железа - смотрите ссылки по Xenomai, я давал выше - там есть картинки и графики.
Что могу сказать точно, что тут вы ошибаетесь - в обоих ваших случаях время реакции будет практически одинаковым, неразличимым!

P.S. Ещё раз обращу ваше внимание на то (см. цифры в моём сообщении на предыдущей странице), что в системе у вас будут параллельно, конкурируя выполняться порядка 70 потоков внутри ядра ... да ещё с потоками в пользовательском пространстве - до 100 суммарным итогом. Не пытайтесь спрогнозировать их поведение детерминировано (кто за кем и после кого) - ничего из этого не получится.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 13 мар 2019, 12:35

Urry писал(а):В Orange под процесс сбора данных можно специально выделить одно ядро.
Как вы собираетесь это сделать?
Я сильно предполагаю, что вы не знаете способа и не сможете это сделать вообще ... что даже такого способа не существует вообще в природе.
Вы можете запустить свой критический процесс (приложение) командой taskset, и такой же командой раскидать свои остальные приложения по другим ядрам... См.:

Код: Выделить всё

olej@ACER:~/2019_WORK/Bilety$ taskset --help
Usage: taskset [options] [mask | cpu-list] [pid|cmd [args...]]


Show or change the CPU affinity of a process.

Options:
 -a, --all-tasks         operate on all the tasks (threads) for a given pid
 -p, --pid               operate on existing given pid
 -c, --cpu-list          display and specify cpus in list format
 -h, --help              display this help
 -V, --version           display version

The default behavior is to run a new command:
    taskset 03 sshd -b 1024
You can retrieve the mask of an existing task:
    taskset -p 700
Or set it:
    taskset -p 03 700
List format uses a comma-separated list instead of a mask:
    taskset -pc 0,3,7-11 700
Ranges in list format can take a stride argument:
    e.g. 0-31:2 is equivalent to mask 0x55555555

Для более детальной информации смотрите taskset(1).
Но вы не сможете убрать из этого критического ядра те из 70-ти потоков ядра, которые туда распределены, тем более, что они, время от времени, "перескакивают" с одного процессора на другой.
Более того! Я думаю, что вы не сможете убрать (или это чрезвычайно хлопотно) даже сервисы пользовательского пространства, работающие в системе!

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 13 мар 2019, 13:38

Olej писал(а):
Urry писал(а):В Orange под процесс сбора данных можно специально выделить одно ядро.
Как вы собираетесь это сделать?
Я сильно предполагаю, что вы не знаете способа и не сможете это сделать вообще ... что даже такого способа не существует вообще в природе.
Вы можете запустить свой критический процесс (приложение) командой taskset, и такой же командой раскидать свои остальные приложения по другим ядрам... См.:

Код: Выделить всё

olej@ACER:~/2019_WORK/Bilety$ taskset --help
Usage: taskset [options] [mask | cpu-list] [pid|cmd [args...]]


Show or change the CPU affinity of a process.

Options:
 -a, --all-tasks         operate on all the tasks (threads) for a given pid
 -p, --pid               operate on existing given pid
 -c, --cpu-list          display and specify cpus in list format
 -h, --help              display this help
 -V, --version           display version

The default behavior is to run a new command:
    taskset 03 sshd -b 1024
You can retrieve the mask of an existing task:
    taskset -p 700
Or set it:
    taskset -p 03 700
List format uses a comma-separated list instead of a mask:
    taskset -pc 0,3,7-11 700
Ranges in list format can take a stride argument:
    e.g. 0-31:2 is equivalent to mask 0x55555555

Для более детальной информации смотрите taskset(1).
Но вы не сможете убрать из этого критического ядра те из 70-ти потоков ядра, которые туда распределены, тем более, что они, время от времени, "перескакивают" с одного процессора на другой.
Более того! Я думаю, что вы не сможете убрать (или это чрезвычайно хлопотно) даже сервисы пользовательского пространства, работающие в системе!
Как я писал ранее я не программист под Linux. Как работать с отдельным ядром действительно не умею. По словам нашего программиста (я доверяю ему) он умеет настраивать ядра на конкретные процессы. Ещё раз спасибо, особенно за разъяснение с временем реакции на прерывания.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 13 мар 2019, 13:48

Urry писал(а): По словам нашего программиста (я доверяю ему) он умеет настраивать ядра на конкретные процессы.
Он вам врёт :lol:
P.S. Неважный у вас программист, судя по всему.

Может оказаться вам полезной следующая свежая (вчерашняя) публикация: Как ограничить загрузку процессора в Ubuntu Linux с помощью CPULimit.

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 13 мар 2019, 14:07

Olej писал(а):
Urry писал(а): Рассматриваю два варианта считывания данных:
1. В случае использования только SPI сигналов готовность данных к отсылке (заполнение одного буфера) должна выполняться командой, отсылаемой ORANGEм в микроконтроллер, т.е по сути выполнять опрос через какой-то интервал времени, скажем, несколько мс. При готовности выполняется считывание данных. Заняты три сигнала. SPI в режиме полный дуплекс.
2. В случае использования SPI c дополнительным выводом GPIO готовности данных. Orange может использовать как опрос этого вывода, так и прерывание. Используются также три линии, т.к. SPI интерфейс работает в полудуплексном режиме.

Оба варианта рабочие. Второй вариант - стандартный, требует меньших временных затрат на обработку.
По джитеру... Мне кажется, что в обоих вариантах, использующих опрос, джитер между опросами будет одинаков.
Мне кажется, что вариант 2 более "рабочий" и использование вывода GPIO оправдано, особенно если используется прерывание.
Всё сказанное выглядит разумным, по первому поверхностному взгляду.
Хотя ... вообще то говоря, в АСУТП и технике программируемых логических контроллеров (PLC) всегда отдают предпочтение именно периодическому программному пулингу. Особенно если этот опрашивающий процесс (поток) запустить а). с приоритетом реального времени + б). с высоким приоритетом.
При этом не нужно систему дёргать асинхронными прерываниями, что всегда повергает её в хаотическое поведение.
Кроме того, на обработке прерываний в Linux ... "забодаетесь пыль глотать": а). только в ядре, в модуле, б). с большой вероятностью ошибки и краха всей системы (мёртвого подвисания!).
Если правильно понял, то под Linux лучше всегда делать опрос. И стараться избегать работу по прерываниям?

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 13 мар 2019, 14:11

Olej писал(а):
Urry писал(а): По словам нашего программиста (я доверяю ему) он умеет настраивать ядра на конкретные процессы.
Он вам врёт :lol:
P.S. Неважный у вас программист, судя по всему.

Может оказаться вам полезной следующая свежая (вчерашняя) публикация: Как ограничить загрузку процессора в Ubuntu Linux с помощью CPULimit.
Программист хороший. Скорее всего, я его неправильно понял. Я не программист.
Ещё раз спасибо.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 13 мар 2019, 14:38

Urry писал(а): Программист хороший. Скорее всего, я его неправильно понял. Я не программист.
Обратите внимание ещё на такую деталь ... может вам чем-то поможет в будущем: для успешного выполнения реального проекта по разработке нового изделия или системы (не всяких WEB- или мультимедиа- свистелок с перделками) с использованием Linux - нужны специалисты 3-х не совпадающих специальностей, категорий:
1. аппаратчики - разрабатывающие hard, периферию, обвязку...
2. программисты - пишущие целевое ПО проекта
3. администраторы Linux - выбирающие и настраивающие механизмы Linux: протоколы, сетевые возможности, модули ядра и т.д. (можете его и системотехником считать и называть)

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

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 13 мар 2019, 15:03

Olej писал(а):
Urry писал(а): Программист хороший. Скорее всего, я его неправильно понял. Я не программист.
Обратите внимание ещё на такую деталь ... может вам чем-то поможет в будущем: для успешного выполнения реального проекта по разработке нового изделия или системы (не всяких WEB- или мультимедиа- свистелок с перделками) с использованием Linux - нужны специалисты 3-х не совпадающих специальностей, категорий:
1. аппаратчики - разрабатывающие hard, периферию, обвязку...
2. программисты - пишущие целевое ПО проекта
3. администраторы Linux - выбирающие и настраивающие механизмы Linux: протоколы, сетевые возможности, модули ядра и т.д. (можете его и системотехником считать и называть)

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

Ответить

Вернуться в «Одноплатные компьютеры»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей