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