Всё же нет, 16 групп, в каждой по одному уровню приоритета.

0b011. Ибо все значения, меньше либо равные этому (вплоть до нуля) дают одинаковый результат при имеющихся битах приоритета.

Ваша картинка красивее у меня про сочетание b000 умалчивается. Черпал знания из "STM32F10xxx Cortex-M3 programming manual.pdf" с сайта ST.

Вот именно, подприоритет одинаковый, а вот вытесняющий приоритет (pre-emption priority) разный!
Поэтому получается 16 групп (с одной подгруппой внутри), каждая группа будет вытеснять более младшую.

То есть получается максимум 16 уровней вложенности.

А моя практика подсказывает, что нифига. Почему? Пока не конфигурил группы, имел место, как я теперь уже понял, пропуск прерываний от таймера, т.к. он хоть и имел 0-й приоритет, но не мог когда нужно вытеснить программное прерывание, к-е копировало порядка 1200байт, один раз в
200 отсчётов (раз в 2мс). После явного конфигуривания групп всё стало на свои места. Каким документом по поводу работы NVIC руководствуетесь?

Вот состояния NVIC на реальном железе STM32F107 сразу после сброса, и после конфигурирования приоритетов. К сожалению, у кейла нет для 107-го в периферии регистров NVIC.

Так если не конфигурили, то у всех прерываний был одинаковый приоритет, потому и не вытесняло.

Главный документ касательно ядра Cortex-M3 -- Cortex-M3 Technical Reference Manual.

Разобрался. sonycman прав. 15 подгрупп после ресета.
У меня в коде инициализации, т.к. делал не с нуля проект, а взял шаблон, было вот это:



Т.е. переключался на 0 групп.
Сейчас вот так:




Ненене (с) ПОДприоритеты назначал разные. Группа была одна. Из шаблона проекта унаследовал - там переключался NVIC на 0 групп.

Угумс, первоисточник-с.

И что ж это получается, господа - NVIC у STM32 - кастрированный??? В армовской спецификации у него вон скока бит для приоритетов!

И моя практика такое же подсказала, когда я ту же шишку набил на заре использования Cortex. После этого любой мой проект начинается с вызова NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); в процессе инициализации системы. Тогда при инициализации тех или иных прерываний вытесняющий приоритет в диапазоне [0..15] можно задать в поле "NVIC_IRQChannelPreemptionPriority" записи "NVIC_InitTypeDef", то есть (пример для UART1):

Пока 16-ти вытесняющих приоритетов хватало. На 51-х процессорах и двух было достаточно

Воистину, теперь и у меня эту будет самый главный после main(), вызов
Да уж, на 8-,16-разрядных, с коими достаточно имел дело, понятие приоритета однозначно подразумевало вытеснение. Придётся ломать сознание.

У LPC17xx 5 битов приоритета - не намного больше


В этом нет необходимости, это является значением по умолчанию

.....если в моей программе будет использоваться более одного прерывания

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

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

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

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


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

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

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

Ах вот оно что, тогда понятно

На счет проверки бита. Вообще-то там не должно быть "чтение-наложение маски-сравнение", наложение маски + сравнение делается хитрее, команд столько же, надо смотреть, что генерит компилятор. Разница в том, что для TIM3->SR может генериться немного другая инструкция чтения, которая длиннее. Можно предварительно положить &TIM3-SR в регистр (присвоить указателю).
Сомнения больше на счет детерминированного времени выполнения команд, если оно действительно нужно, то стоило ли выбирать стм32...
А что там такого хитрого в цикле, если не секрет?

Вы наверное имеете ввиду доступ к bit-banding региону, вместо чтения регистра целиком+маска нужного бита? За пару недель тяжело стать гуру в армах, и ассемблер ихний тяжеловат, ещё и компилятор просто так не позволяет __asm вставки делать для thumb-кода. Я в процессе
В цикле - подобие вот этого: DDS на AVR. Там должно стать понятным, почему этот код внутри должен исполняться за детерминированное кол-во тактов - им определяется частота дискретизации, и как следствие, частота самого генерируемого сигнала. Основное отличие моего проекта - вместа резистивного делителя для формирования аналогового сигнала используются бортовые ЦАП-ы, причём оба, и формируют прямой и инверсный формы сигнала, чтобы затем завести их на входы компаратора и получить целевые прямоугольные импульсы с малым джиттером (и у программной, и у аппаратной реализаций DDS на предельных частотах проблема явственная - сильно дрожат фронта, если формировать напрямую прямоугольник). По сути, программная замена DDS от Analog devices, AD9854 можно глянуть для примера.
Выбран был скажем так, не STM32, а в целом АРМ - по критерию скорости, потому что в моём проекте максимальная генерируемая частота (синус) требуется выше, чем в ссылке (до 450...500кГц). Код DDS получился 20 тактов, при 72МГц тактвовой ядра Fd=72/20=3.6МГц - 5-6 отсчётов за период 500кГц - приемлемо, без усложнения аналогового фильтра на выходе ЦАП-ов. Я всё ещё не определился окончательно с MCU, потому что
к задаче подходят и довольно шустрые C8051F12x, к тому же имеющие нужные 2 ЦАП-а на борту.

Нет, bit-banding тут не при чем. Просто если посмотреть код, генерируемый компилятором, то видно, что маску он не делает. Делается либо сдвиг + проверка <0, либо используется команда TST, которая как раз и делает AND.

А что надо получить в конечном итоге, прямоугольник заданной частоты? Может быть как-то на таймерах это сделать, неужели синус + компаратор лучше (не спорю, просто не сталкивался).
На счет цапов я бы предложил попробовать реализовать используя возможности стм32, а именно дма + синхр. по таймеру.