Перейти к содержанию
    

Общая структура программы?

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

Итак, делается управляющая часть для НЧ-генератора 5Гц-1МГц. Она должна выполнять следующие функции:

1) Опрос состояния органов управления - кнопки, энкодер, переключатели.

2) Выдачу команд по SPI на ЦАП, управляющий частотой и релюшки переключения диапазонов.

3) Измерение частоты генератора , алгоритм приведён здесь: алгоритм

4) Отображение частоты и другой информации на LCD 16x2

 

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

 

Сейчас написаны пункты №1, №2, №4, и приступаю к №3. Вот тут-то и встал вопрос об общей структуре программы.

Фактически параллельно должны выполняться несколько задачь

№1 требует периодического выполнения по таймеру с точностью ,скажем, +-20% от номинала. Сейчас написана по прерыванию одного из таймеров.

№2 требует значительного времени на исполнение команды (рэле-медленное устройство)

№3 требует максимально быстрой и всегда одинаковой по кол-ву циклов реакции на прерывание ICx, в противном случае возникают ошибки счёта.

 

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

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

 

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

Изменено пользователем shkal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Итак, делается управляющая часть для НЧ-генератора 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-х таймеров, копейки даже при максимальной входной частоте.

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

Изменено пользователем shkal

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

№3 требует максимально быстрой и всегда одинаковой по кол-ву циклов реакции на прерывание ICx, в противном случае возникают ошибки счёта.
регистры ICx буферизированы или нет ?
Поставьте еще один маленький контроллер только для измерения частоты
не нужно, один pic24h потянет с десяток таких приборов
Изменено пользователем ukpyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

№3 требует максимально быстрой и всегда одинаковой по кол-ву циклов реакции на прерывание ICx, в противном случае возникают ошибки счёта.

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

+1. Сам так делаю. Это и есть ответ на вопрос о подходе к построению системы.

При таком подходе ф-ция main() в общих чертах выглядит так:

int main(void)
{
    module_a_init();
    module_b_init();
    ...
    for (;;)
    {
        module_a_poll();
        module_b_poll();
        ...
    }
}

Соответственно, ф-ции module_x_poll() возвращаются быстро, чтобы обеспечить гарантированное максимальное время выполнения одного цикла.

В такую конструкцию у меня помещаются кнопки, энкодер, GUI (480x272 LCD), HTTP, SNMP, SNTP, управление собственно устройством и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

int main(void)
{
    module_a_init();
    module_b_init();
    ...
    for (;;)
    {
        if (flag_1ms) {
            flag_1ms = 0;
            module_a_poll();
            module_b_poll();
            ...
        }
                ...
        if (flag_1s) {
                       flag_1s = 0;
            ...
        }
        sleep();
    }
}

Изменено пользователем ukpyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ukpyr, спасибо, ответ максимально по делу. Пойду читать литературу по state machine.

Вот ещё какой вопрос возник: каким образом реализуются неблокирующие функции задержки в такой среде?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если, допустим, использовать один из таймеров и по его прерыванию устанавливать флаг, то этот флаг должен в цикле читаться функцией, которой нужна эта задержка.
флаг читается, только в основном цикле. Когда установлен - вызываются функции, привязанные к данному периоду опроса, в функции обрабатывается свой таймер и текущее состояние. При переходе к следующему состоянию таймер функции заряжается новым значением.
        ...
        if (flag_10ms) {
            flag_10ms = 0;
            module_a_poll();
            module_b_poll();
            ...
        }
        ...

    // функция вызывается с периодом 10мс
    void module_a_poll(void) {
        static unsigned int module_a_tmr; // таймер задачи
        static char module_a_state; // текущее состояние задачи
        if (module_a_tmr) module_a_tmr--; // таймер текущего состояния не закончился 
        else { // таймер закончился - обработка текущего состояния, переход к следующим и т.д.
            if (module_a_state == 0) {
                ... // выполнили действия для состояния 0
                module_a_state = 1; // загрузили новое состояние и таймер задержки на 1 сек
                module_a_tmr = 100;
            else if (module_a_state == 1) {
            }
            ...
        }
    }

Изменено пользователем ukpyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

еще можно добавить синхронизацию по интервалу 1мс/10мс/100мс/1сек

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...