SysTick в STM32F4xx Опции

[Sidoroff]

Здравствуйте!
Как настроить SysTick, чтобы можно было на время, значительно меньшее периода таймера,
в фоновой программе запрещать и потом разрешать прерывания SysTick, чтобы при этом они не терялись?
Т.е. если в данный момент прерывание запрещено а событие таймера приходит, то оно должно
обработаться сразу же в момент разрешения прерываний таймера.

Ну и соответственно как разрешать/запрещать прерывания SysTick?

Инициализация сейчас стандартная: SysTick_Config(SystemCoreClock / частота);

Для запрета/разрешения пробовал такие варианты:

//такой вариант не запрещает прерывания SysTick вообще
NVIC_DisableIRQ(SysTick_IRQn); // запрет
NVIC_EnableIRQ(SysTick_IRQn); // разрешение

//тоже не запрещает прерывания SysTick
int t = RCC->CIR; RCC->CIR = 0; // запрет
RCC->CIR = t; // разрешение

// запрещает и разрешает, но прерывания теряются
SysTick->CTRL &= (~SysTick_CTRL_TICKINT_Msk); // запрет
SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk; // разрешение

[jcxz]

Ну и соответственно как разрешать/запрещать прерывания SysTick?

См. SysTick Control and Status Register [0xE000E010] бит 1.

[adnega]

См. SysTick Control and Status Register [0xE000E010] бит 1.

Будут теряться прерывания.

Правильнее сделать менеджер SPI. Завести для него очередь заданий. Из разных источников помещать задания в очередь с указанием calback-функции (когда задание выполнено и результат получен).

[jcxz]

Будут теряться прерывания.
Правильнее сделать менеджер SPI. Завести для него очередь заданий. Из разных источников помещать задания в очередь с указанием calback-функции (когда задание выполнено и результат получен).

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

Но правильней конечно пересмотреть структуру программы, чтобы обмен по SPI не вызывался изнутри обработчика прерывания и снаружи.
Сделать нормальный менеджер службы SPI и API доступа к нему.

[adnega]

Сделать нормальный менеджер службы SPI и API доступа к нему.

Предлагал. Но для доступа к очереди все равно придется городить критические секции (запрещать прерывания).
То, что было нужно ТС - это отложенные прерывания. Но я бы подумал над архитектурой. Cortex-M это не AVR))) Возможности богаче.

[jcxz]

Предлагал. Но для доступа к очереди все равно придется городить критические секции (запрещать прерывания).

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

То, что было нужно ТС - это отложенные прерывания. Но я бы подумал над архитектурой. Cortex-M это не AVR))) Возможности богаче.

Да, у ТС естественно детский, АВР-ский подход. Думаю он ещё не скоро вырастет из детских штанишек

[adnega]

Во-первых: очереди возможно и не нужны. Если доступ к службе делать с блокировкой (задачи), до достаточно для каждой задачи иметь флаг и задаче ждать
на этом флаге снятия его ISR-ом. ISR знает все флаги.

Deadlock: в фоне сделали блокировку, в Systick ждем освобождения.

Во-вторых: очереди легко строятся без всяких критических секций, если писатель (в очередь) только один (задача или ISR) и читатель - только один.

Сам так пользуюсь. Но к сожалению, писателей у ТС два(

[jcxz]

Deadlock: в фоне сделали блокировку, в Systick ждем освобождения.

Какой дидлок? В ISR-ах никогда не должно быть никаких ожиданий!