STM32F10x, не перестаёт удивлять Опции

[pr0m]

Полдня чесал репу и разлохматил бубен на казалоь бы ровном месте... А именно: имеем некий код в основном цикле, с временем исполнения, определяемым периодом таймера. Таймер запускается перед контролируемым кодом, тот в цикле делает свои дела, а выходит по флагу, к-й устанавливается в обработчике прерывания (Update Event) этого таймера. Таймер запускается перед этим блоком. По так и невыясненным причинам, всё работало после ресета до того момента, пока не происходило некое внешнее прерывание (с приоритетом ниже таймера), делающее быстро другие примитивные дела, не относящиеся к интересующему участку кода. После этого начинались чудеса - на очередном внешнем цикле после запуска таймера код лихо проскакивал проверку while(!bStopDSS), даже не заглянув внутрь, и происходило 2! прерывания от таймера, одно из которых видимо и устанавливало bStopDSS=1 до входа во внутренний цикл. Вылечил проверкой флага прерывания перед включением таймера. Перекорячивается конвейер команд? При включении таймера (строка TIM3->CR1 |= TIM_CR1_CEN) ещё не сброшен бит прерывания?

Код

volatile uint8_t bStopDSS;
while(1) // внешний цикл
{
bStopDSS = 0;
TIM3->CNT = 0;
TIM3->SR = ~TIM_IT_Update;
while(TIM3->SR & TIM_IT_Update); // без этой проверки - чудеса
TIM3->CR1 |= TIM_CR1_CEN;

while(bStopDSS == 0)
{
// Внутренний цикл, выходим по таймеру.    
}
//
...готовимся к следующему циклу
//
}

void TIM3_IRQHandler (void)
{
    // Сбрасываем флаг прерывания
    TIM3->SR = ~TIM_IT_Update;
    // Останавливаем таймер
       TIM3->CR1 &= ~TIM_CR1_CEN;
    // Флаг окончания внутреннего цикла
    bStopDSS = 1;
}

Такие дела. В голове смятение.

Сообщение отредактировал pr0m - Feb 6 2011, 20:05

[akimych]

1) Для детерминированности времени исполнения код должен исполняться из ОЗУ, что и сделал. Хотя исполняется медленнее, чем из флэш - что подтверждает высказывания по поводу отсутствия преимуществ исполнения кода из ОЗУ в сравнении с флэш для STM32F10...
2) Проверка флага UEV как признака окончания внутреннего цикла (while(!(TIMx->CR1 & UEV))увеличивает общее время исполнения блока на 2 такта, в сравнении c флагом в ОЗУ (bStopDSS), что в принципе понятно - чтение регистра+наложение маски бита UEV-сравнение, вместо чтение-сравнение). Поэтому bStopDSS.

Странные выводы. Вызов прерывания + установка флага займет куда больше 2х тактов + вход в прерывание можеть занимать разное время.
На счет кода в озу тоже есть большие сомнения. Имхо, вы рискуете нарваться на новые грабли.

Приоритеты - это все хорошо, теперь таймер будет выключаться в прерывании стабильно (хотя он это и сам умеет делать, достаточно лишт включить OPM). Но в этом ли была проблема изначально? Ведь получается, что код не успевает обрабатывать данные на заданной скорости, во всяком случае при возникновении того самого прерывания, которое "быстро выполняет другие дела".

[pr0m]

Странные выводы. Вызов прерывания + установка флага займет куда больше 2х тактов + вход в прерывание можеть занимать разное время.
На счет кода в озу тоже есть большие сомнения. Имхо, вы рискуете нарваться на новые грабли.

Я видимо путано высказался. 2 варианта проверки окончания внутреннего цикла:
1) проверять флаг UEV. Прерывания от таймера в этом случае конечно отключены. Polling классический, та-скать.
2) проверять переменную в ОЗУ bStopDSS, к-я устанавливается в обработчике прерывания таймера.
Так вот, практика показала, что мой внутренний цикл DDS, в который ессно входит проверка:

Код

while(один из 2-х вариантов окончания){зело критичный по времени код DDS}

выполняется на 2 такта быстрее во 2-м случае. Время установки флага кем-то извне (в моём случае в обработчике таймера bStopDSS или сам битик UEV анализируем) значения не имеет.
Какие именно сомнения по поводу кода в ОЗУ? Располагаю конкретными цифрами кол-ва тактов для 1)флэш-кода и 2)ОЗУ-кода. 2-й - медленнее, но абсолютно детерминированное кол-во тактов. 1-й быстрее, но с этим конвейером, IBUS-DBUS-ами может исполняться то 14 тактов, то 18, на одной прошивке ессно. После 8-,16-разрядников для меня это был шок. Недавно поднимал вопрос в какой-то ветке пониже.

Приоритеты - это все хорошо, теперь таймер будет выключаться в прерывании стабильно (хотя он это и сам умеет делать, достаточно лишт включить OPM). Но в этом ли была проблема изначально? Ведь получается, что код не успевает обрабатывать данные на заданной скорости, во всяком случае при возникновении того самого прерывания, которое "быстро выполняет другие дела".

В этой ветке переплелись мои вопросы по двум разным проектам. В этом сообщении Вы их тоже переплели Там где речь зашла о приоритетах - другая проблема. Была. Решена.
Кстати, включил OPM. Понравилось - изящнее. То что нужно для 1-го проекта.

Ещё кстати, "того самого прерывания, которое "быстро выполняет другие дела"" - эти дела заключаются в приёме конфигурации по I2C от внешнего контроллера, код DDS-цикла конечно останавливается (более того, я его явно останавливаю при начале обмена по I2C, установив флаг окончания цикла), чтобы затем войти в цикл вновь, обновившись из принятой конфигурации.

Сообщение отредактировал pr0m - Feb 7 2011, 19:57