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


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

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

Интересно то, что после while(TIM3->SR & TIM_IT_Update); bStopDSS все равно не обнуляется и TIM_IT_Update тоже не сбрасывается.
А таймер как сконфигурирован?

В данном случае наверно имело бы смысл использовать One-pulse mode. Если по прерыванию только выставляется флаг bStopDSS, то можно будет вообще без него обойтись.

Попробуйте проверять источник прерывания перед сбросом:

Флаг UEV установлен в обоих случаях, смотрел в железе. А как может быть иначе, если прерывание только по нему сконфигурено, поэтому даже не проверяю. Даташиты и примеры молчат по этому поводу.



В смысле, Вы это сами проверяли? Если так, то значит мне это не приглючилось.. Именно так и происходило.

Просто Upcounting (инициализирую прескалер, ARR, обнуляю CNT, разрешаю прерывания по UEV и вперёд).


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

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

Однако же может :-)

Мдя, спасибо за ссылку. Понял, как нужно, но не понял, зачем. Многовато туману. Где ещё ожидают грабли? А то у меня ещё один необъяснимый и сильно напрягающий случай имеется - тоже таймер, тоже прерывание (с частотой 100кГц), в котором данные с группы из 6 каналов АЦП (АЦП в непрерывном режиме, с использованием ДМА в CircularMode, собирает данные в фиксированное место 6*2 байт) аккуратненько складывает эти 6 отсчётов в большой накопительный буфер, с инкрементом указателя ессно. Если перевести в требуемую скорость по каналу передачи 100кГц*6каналов*16бит = 9600кБит/c. Как только заполнен буфер, нужно его отправлять. Отправляю по Ethernet-у при помощи lwIP udp_send(). Пробовал 2 варианта:
1) В основном цикле программы (от чего очень хотелось бы избавиться, т.к. там коду есть чем другим заняться). Помечаем буфер как готовый для отправки, в основном цикле флажок готовности проверяется, буфер через lwIP udp_send() отправляется. Скорость наблюдаю на приёмном конце - на компе - соответсвует расчётной.
п.с. Процесс отправки чуть сложнее описанного, но сути не меняет - используются очереди, процедуры push в обработчике и "пока pop != 0" в основном цикле.
2) Поручаем отправку программному прерыванию:


Так вот при отправке через программное прерывание скорость передачи падает! примерно до 9200кБит. Как такое может быть? Ведь скорость однозначно определяется периодом работы таймера. При этом переполнения/опустошения очередей буферов не происходит. Ощущение, что замедляется бег таймера, как ни идиотски это звучит. Если закомментировать строчку udp_send(upcb, p);, всё приходит в норму (ориентируюсь по кол-ву отправленных буферов bufs за период времени time_elapsed). Ещё не до конца расковырял udp_send, но в конечном итоге она через memcpy копирует данные в буфер для Ethernet-а и отмечает к отправке. Чем может отличаться исполнение кода в конексте прерывания от кода в контексте главного цикла, что может приводить к такому эфф(де)фекту?

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

Победил. Не была задана группировка с вытеснением в NVIC, т.е. 0 preemption групп, 16 приоритетов. Задал приоритет 0 для таймера (типа выше всех остальных в системе), и думал ни одна собака его не прервёт, зато он у всех будет проц вырывать, как приспичит, и гарантированно не пропустит ни одного сэмпла. Ан нет - почитал про preemption, прозрел, разделил на группы, таймер определил в гордом одиночестве в 0-ю группу, 0-й приоритет - и теперь всё в норме.
Что взять с начинающего?

Так и есть. Без групп, нулевой приоритет - высший.
Разве нет?

Высший-то высший, но тут речь о возможности вытеснения текущего прерывания, и предаче управления другому. Например, если сейчас исполняется прерывание 0-й группы и, скажем, приоритет 2, то пришедший запрос на прерывание из той-же 0-й группы с более высоким приоритетом=1 НЕ прервёт исполнение текущего обработчика, т.к. они оба относятся к одной (0-й) группе, а станет в очередь (pending). А вот если мы разделим приоритеты по группам, подгруппам, обработчик прерывания 1-й группы, любой приоритет будет вытеснен запросом на прерывание из 0-й группы, любой приоритет. Такая вот иерархия. Описание NVIC контроллера и регистра SCB_AIRCR к прочтению.
В одной группе приоритетом определяется только очерёдность передачи управления тому или иному вектора, а если они ещё и с одинаковым приоритетом, то аппаратным порядковым номером вектора.

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

По умолчанию, после аппаратного сброса, NVIC в STM32 работает в режиме одной единственной группы, без подгрупп.
То есть любому прерыванию можно присвоить лишь простой приоритет 0, 1, 2 и т.д.

Ноль будет высшим и будет прерывать выполнение любого другого прерывания (кроме системных).

Ненене! Внутри одной группы прерывания друг друга не вытесняют:-)

Так ведь группы-то разные!
Приоритет 0 - нулевая группа.
Приоритет 1 - первая группа и т.д.

Это если PRIGROUP = 0.

Или нет?

Нет, одна группа - 0-я, и в ней 15 ПОДприоритетов, к-е друг друга не вытесняют.

Кстати, не совсем понял один момент: после сброса поле групп = 000, если верить описанию регистра SCB_AIRCR:

Такого сочетания этих конфигурационных бит нет. И какая схема приоритетов имеет место после ресета?

Так одна-единственная, или разная для каждого приоритета?
Я так понимаю, что при старте (PRIGROUP == 0) получается, что все биты приоритета определяют Preempt Priority (если нет нулевого бита у Priority Level). То есть, разные приоритеты находятся в разных группах, и могут вытеснять друг друга.
Но ведь они по умолчанию одинаковые, приоритеты-то?

Хм, я тогда приведу другую картинку:

В случае с STM32 используются только 4 бита регистра, поэтому отбрасываем 4 младших бита.

Что получается?
Читаем верхнюю строчку: кол-во вытесняющих приоритетов - 128 (в нашем случае - 16), кол-во подприоритетов - 2 (у нас - 1).

Когда происходит вытеснение? Когда вытесняющий приоритет больше.

1. Записываем в регистр 0: вытесняющий приоритет = 0, максимальный, подприоритет = 0.
2. Записываем в регистр 1: вытесняющий приоритет = 1, следующий за максимальным, подприоритет = 0.

Неужели не правильно рассуждаю?