Оно необъективно ровно настолько же, насколько и чужие заявления. Если есть желание их пересмотреть или обсудить более конкретно и объективно, то возможно, что я заберу свои слова обратно.

Все имеющиеся, а имеется 8. DMA поочереди читает данные с enabled каналов.

Отлично. Даже SAM ситуацию не спасёт. Остаётся единственно правильное решение

"Ну помогай Вам Бох" © Никифоровна
Мультиплексор внешний поставили, а счетчик внешний для автоматической смены адреса по пульсу таймера который тактирует АЦП слабо поставить?

Это я произнесено, как я понимаю, исключительно по той причине, что на, повторяю:

ответить-то по существу и нечего.

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

Решения с вложенными прерываниями имеют право на жисть, и Ваше не такое уж и плохое,
но ИМХО, оно применено в условиях когда и без него можно обойтись.
Вложенность нужна когда прерывания идут очень неравномерно, т.е. бывают ситуации что идет много
одновременно от разных источников и главное успеть зарегестрировать все(т.е. не пропустить ни одного),
ну и еще довольно быстро минимально реагировать.
У Вас же оба прерывания АЦП и ЦАП вполне себе переодичны.
Значит главное обеспечить маленький джитер вывода в ЦАП при работующем FIQ АЦП

Ну вот просто вставьте в FIQ АЦП пару раз проверку на то не пора ли обслужить ЦАП,
и обслужите его не отходя от кассы.
И джитер можно сделать необходимо малым.

Я извиняюсь, но что такое "псевдопроцесс продолжения обработки" ?
Нельзя ли то же самое, но сформулировать конкретней?

Можно. Уберите приставку 'псевдо'. Останется процесс обработки. Все в терминах операционных систем. Вы просто организовали процесс НЕ средствами операционной системы, по этой причине я и назвал его 'псевдопроцесс'. Но суть осталась - вложенного прерывания нет - произведена оптимизация обработчика FIQ прерывания и часть его вынесена из этого обработчика. Так и надо строить системы БЕЗ вложенных прерываний.

Сейчас средний джиттер 0.3 мкс (@24 MHz). Мне что, на каждые 10 тактов внутри FIQ вставлять проверку на флаг от таймера для DAC ? А Вы в курсе, что только чтение из T0IR занимает 8 тактов плюс ещё загрузка адреса T0IR ? У меня времени просто не останется собственно для чтения АЦП и действий над оцифрованными данными. Вот! Типичный случай из-за боязни вложенности предлагать заведомо неэффективное решение

Я не понимаю альтернативу. Предложите конкретный другой вариант. Что такое умеет делать ОС применительно к моему случаю о чём я не знаю?

Сообщение отредактировал GetSmart - Nov 13 2009, 19:15

В этом наверное есть некий скрытый глубокий смысл, который я боюсь ниасилю.


Опишите ваш случай вначале, а то получается разговор ни о чем.

Я не понимаю какое действие из трех перечисленных может занимать существенное время:
1. прочитать АЦП;
2. сменить канал;
3. записать результат в память.

Все три в купе @24Mhz должны занимать отсилы 1мкс.
Я не понимаю, что мешает семплировать АЦП на одинаковой (или хотя бы кратной) частоте с ЦАПом, тогда будем иметь одно прерывание и порядок операций:

1. Вывести данные в ЦАП;
2. прочитать АЦП;
3. сменить канал;
4. записать рез-тат в приемный буфер.

Вероятно я не до конца понял организацию Вашей вложенности FIQ
поэтому вопрос, FIQ ЦАП может прерываться FIQ АЦП ?

Нет, у него обработка АЦП прерывается ЦАПом.

Именно так.


Осилите Смысл только в увеличении пропускной частотной способности быстродействующих каналов при одинаковой загруженности проца (одинаковом кол-ве FIQs). Когда проц умеет аппаратно складывать значения из АЦП в раму, то можно смело оцифровывать все каналы по очереди. Правда есть минус - требуется буфер (два!), достаточно большой, чтобы тред успевал его выгребать. Но опять же, в девайсе нет никакого счётчика и опять (!) проц не той системы Поэтому заказчик/работодатель идёт в ж..у. Или я?


Мешает заранее неизвестная частота сэмплирования в WAV файле, которая может оказаться совершенно некратной частоте сэмплирования следующего WAV файла. Во-вторых как я уже уточнил, длительнось расчётов некоторых каналов в FIQ АЦП достигает ~40 мкс. Неужели непонятно, что длительность отработки FIQ АЦП больше, чем период прерывания от ЦАП? Вашим алгоритмом можно обойти только джиттер, возникающий из-за вторичного короткого FIQа, но он бесполезен для вторичного длинного FIQа.


Плюс пункт
4. расчёт оцифрованного быстродействующего канала для выявления искомого события. (40 мкс)

Повторюсь ещё раз. Этот расчёт нельзя переносить в тред, т.к. скорость реакции будет непредсказуемой или черезмерно большой.

Сообщение отредактировал GetSmart - Nov 13 2009, 19:54

Понятно, то есть необходимы 3 уровня старшинства прерываний
IRQ, FIQ с разрешенным "Fast" FIQ и сам "Fast" FIQ
тогда наверное вложенные прерывания необходимы
хотя с другой стороны, кто Вам мешает рассчет перенести не в тред а в SoftIRQ ?
и иметь просто FIQ с двумя короткими ветками
или так тоже будет недостаточно оперативно ?

З.Ы. Если SoftInt слишком медленно, можно и какое-нить переферийное с максимальным приоритетом взводить...
прямо из FIQ АЦП