Это мой первый опыт общёния с контроллерами на старости лет, так что прошу сильно не пинать.
Итак, делается управляющая часть для НЧ-генератора 5Гц-1МГц. Она должна выполнять следующие функции:
1) Опрос состояния органов управления - кнопки, энкодер, переключатели.
2) Выдачу команд по SPI на ЦАП, управляющий частотой и релюшки переключения диапазонов.
3) Измерение частоты генератора , алгоритм приведён здесь: алгоритм
4) Отображение частоты и другой информации на LCD 16x2

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

Сейчас написаны пункты №1, №2, №4, и приступаю к №3. Вот тут-то и встал вопрос об общей структуре программы.
Фактически параллельно должны выполняться несколько задачь
№1 требует периодического выполнения по таймеру с точностью ,скажем, +-20% от номинала. Сейчас написана по прерыванию одного из таймеров.
№2 требует значительного времени на исполнение команды (рэле-медленное устройство)
№3 требует максимально быстрой и всегда одинаковой по кол-ву циклов реакции на прерывание ICx, в противном случае возникают ошибки счёта.

Где можно посмотреть - почитать общие подходы к построению таких программ? Единственная книга по теме, котораю попалась в руки - embedded multitasking
Но методика, изложенная там, показалась мне малореальной в практическом смысле в условиях постоянного дописывания функционала.

Да, пишется всё под pic24h

А хватит ли вам ресурсов pic24H? Какая частота? У pic24h только 40 MIPS при 80MHZ. На мой взгляд, тут аппаратный вход таймер/счетчик можно задействовать. Также в pic24H имеется DMA, который поможет Вам сэкономить ресурсы процессора.

Да вроде пока хватает с большим запасом. Всё, что можно было сделать аппаратно - сделано аппаратно. Тактовая будет 20МГц (это высокостабильный генератор)

Поставьте еще один маленький контроллер только для измерения частоты - стоить будет меньше таблеток от головной боли.
P.S. Счетчик - Timer0 у пиков асинхронный до 50 Мгц.

Частотомер процессорного времени практически не занимает, одно измерение = 2 прерывания за период измерения (0.2 с) + прерывания переполнения 2-х таймеров, копейки даже при максимальной входной частоте.
Вопрос собсно не в конкретной реализации задачи, а в общем подходе к построению системы, в которой некоторые задачи должны выполнятся с фиксированной частотой, некоторые мгновенно, но по внешним событиям (т.е. в непредсказуемые моменты времени), некоторые без жёсткого тайминга.

медленные и некритичные по времени задачи (кнопки,индикация,работа с ЦАПом/реле) можно выполнять в основном цикле (на каждую задачу - state machine с программным счетчиком/флагом состояния), задачи требующие точного отсчета - в прерываниях таймеров с высоким приоритетом, энкодеры - на внешние прерывания с меньшим приоритетомрегистры ICx буферизированы или нет ?не нужно, один pic24h потянет с десяток таких приборов

ICх буферизированы, но там надо читать одновременно состояние 2-х таймеров. Или с небольшой задержкой, но время задержки должно быть точно одинаковым в начале и конце цикла измерения. Хотя можно второй ICх задействовать, но лишнюю ногу жалко, уже и так не хватает. О, кстати, а можно ли входы разных ICx сконфигурить на одну ногу?

Воспользуйтесь функцией Capture и тогда от задержки по обработке прерывания ничего зависеть не будет. Частотомер будет практически аппаратный. Алгоритм определения частоты у вас уж очень чудной. Два таймера для начала и окончания интервала замера...

Все названные 4 пункта представляют достаточно простой набор задач. Загрузка МК не превысит несколько процентов. Единственная критичная вещь - максимальная измеряемая частота. Помнится старинный частотомер на PIC16F84 легко мерил до 50Мгц. На 24h я думаю этот показатель будет выше 100Мгц . А вообще полагается ставить аппаратный прескалер.

ICx - это и есть input capture. Если использовать ОДИН IC, то от задержки зависит, если два - не зависит. IC в принципе не может измерять частоты, большие чем Fтакт\2, без прескейлера. Повторять здесь дискуссию по поводу алгоритма смысла не вижу - он единственно возможный на НЧ. PIC24H в асинхронном режиме может измерять до 50 МГц (но соответственно только при прямом счёте)

+1. Сам так делаю. Это и есть ответ на вопрос о подходе к построению системы.
При таком подходе ф-ция main() в общих чертах выглядит так:

Соответственно, ф-ции module_x_poll() возвращаются быстро, чтобы обеспечить гарантированное максимальное время выполнения одного цикла.
В такую конструкцию у меня помещаются кнопки, энкодер, GUI (480x272 LCD), HTTP, SNMP, SNTP, управление собственно устройством и т.д.

еще можно добавить синхронизацию по интервалу 1мс/10мс/100мс/1сек (например на базе таймера c пограммными делителями - в прерывании таймера выставляются соответствующие флаги таймеров) для более точной отработки задержек в задачах, и ложиться спать в конце рабочего блока (контроллер автоматически проснется по любому прерыванию):

ukpyr, спасибо, ответ максимально по делу. Пойду читать литературу по state machine.
Вот ещё какой вопрос возник: каким образом реализуются неблокирующие функции задержки в такой среде?
Если, допустим, использовать один из таймеров и по его прерыванию устанавливать флаг, то этот флаг должен в цикле читаться функцией, которой нужна эта задержка. Но при этом чем точнее нужно отсчитать интервал, тем чаще нужно проверять флаг, т.е. в пределе опять получаем блокирующую функцию. Или же управление из прерывания таймера нужно возвращать не в ту задачу, в которая исполнялась во время вызова прерывания, а в ту, которая использовала функцию задержки, но это как-то очень по-хакерски выглядит.

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

ОК, как я понял, таким образом можно реализовать задержки не короче системного тика (10 мс в данном случае) ?

Только надо напомнить, что эта синхронизация будет с точностью до времени прохода одного цикла. Так что, к примеру, 1 мс будет проблематично сделать :-) 1 мс - это почти наверняка в обработчик прерывания таймера.

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

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

Прогноз неправильный, максимальная частота работы таймера1 по даташиту - 50 МГц, в асинхронном режиме естессно.
Требования по верхней частоте в этом конкретном приборе - до 2 МГц, но "если делать, то делать по-большому" - почему бы и сразу не сделать максимально возможную (без внешних прескейлеров).
Поскольку задающий генератор работает на частоте 20МГц и имеет точность порядка +-1ppm, при предполагаемом времени гейта 0.2с выше 2 МГц уже можно использовать внутренний прескейлер без досчёта,
не ухудьшая точность измерений.