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

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

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

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

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

Сообщение отредактировал shkal - May 30 2011, 13:03

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

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

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

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

Сообщение отредактировал shkal - May 30 2011, 15:28

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

Сообщение отредактировал ukpyr - May 30 2011, 16:57

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 - May 31 2011, 16:12

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

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

Сообщение отредактировал ukpyr - Jun 1 2011, 12:38

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

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