Настройка прерываний в LPC1778, с полного нуля Опции

[ДЕЙЛ]

Листинг в общих чертах такой:

Инициализация и настройка тактирования

1: U0IER|=0x4; //Разрешение прерывания по приёму байта в RX
2: __enable_irq(); //Разрешаем прерывания (CMSIS)
3: __set_BASEPRI(0xFFFFFFFF); //Разрешаем все прерывания (CMSIS)
4: NVIC_EnableIRQ(UART0_IRQn); //Разрешение прерывания UART0 (CMSIS)

while(1)
{
Циклическая отправка данных на ПК
}


5: __irq void UART0_IRQ1(void)
{
for (k=0; k<200; k++)
{
FIO1SET=0x2000000; //Подёргаем ножкой 200 раз
FIO1CLR=0x2000000;
}
}

Хочу сделать так, чтобы при появлении байта в буфере приёма UART вызывалось прерывание. Вот с этим вызовом прерывания проблема и пока не знаю, с какой стороны к ней подходить. Вопросы такие:
1. Правильно ли я выполнил настройки? (строки 1-4)
в строке 4 в качестве параметра функции передаётся UART0_IRQn. Что значит эта n? Её так и нужно оставлять или вместо n нужно какое-то число стаить? Хотя компилятор ругается.

2. Правильно ли я оформил обработчик прерывания? (строка 5). В этой строке пробовал писать название функции от UART0_IRQ1 ло UART0_IRQ10. Компилятор не ругался, но и толку никакого не было, на осциллографе не видел дёрганий ножки после отправки байта с ПК.
На что влияет выделенное число?


Данные в буфер приёма однозначно приходят правильные с ПК.
На скрине моя программа в сыром виде. При нажатии кнопки "ТЕСТОВАЯ" с COM-порта отправляется 1 байт 0xAA, который я вижу принятым программой от МК (выделено). Т.е. с приёмом нормально всё, но не совсем удобно каждый раз смотреть на буфер, куда удобнее считывать из него байт по прерыванию. Ну и с настройкой прерываний разобраться нужно.

И ещё имеется такой регистр
//SETENA0=0xFFFFFFFF;
В описании написано, что каждый бит этого регистра разрешает или запрещает соответствующее прерывание. Как понять, к какому прерыванию относится конкретный бит?

Сообщение отредактировал ДЕЙЛ - Jul 7 2014, 19:46

Эскизы прикрепленных изображений

 

[ДЕЙЛ]

С уровнями приоритетов разобрался. Ошибка была в том, что я заблуждался относительно предустановки уровней приоритетов. По умолчанию все программируемые прерывания имеют приоритет 0, т.е. самый высокий. Выше только немаскируемые с приоритетами -1 -2 и -3. А у меня получилось, что прерывание от UART0 и от системного таймера имели одинаковый приоритет и поэтому не было вложенности.

Добавил две строки в коде при инициализации:

Код

AIRCR = 0x05FA0200;  //приоритет группы - поле [7:3], субприоритеты отключены, т.к. [2:0] не задействованы
IP1   = 0x800;           //уровень приоритета - 1, биты [2-0] не задействованы.

Остался открытым вопрос по настройке приоритета прерывания системного таймера. Он программируемый, судя по описанию ядра CORTEX-M3, но в даташите пока не откопал ничего по этому поводу. Ещё в описании рекомендуют указывать размер стека. Как он указывается?

Сообщение отредактировал ДЕЙЛ - Jul 17 2014, 17:46

[menzoda]

В даташите про него ничего не будет, надо искать в документации на ядро. Насчет размера стека, он указывается в единственном месте - в стартапе (точнее не размер, а границы), и то непонятно зачем, больше не знаю где его можно задать.

[ДЕЙЛ]

В даташите про него ничего не будет, надо искать в документации на ядро. Насчет размера стека, он указывается в единственном месте - в стартапе (точнее не размер, а границы), и то непонятно зачем, больше не знаю где его можно задать.

в описании ядра сказано, что при многоуровневой вложенности нужно думать о размере стека, вот и интересуюсь. Какая функция задаёт этот размер?
ПЫСЫ Имел ввиду не даташит, а user manual, т.е. руководство пользователя

[menzoda]

Никакая. Точнее так, можно сообщить библиотеке времени исполнения (CRT) границы стека, реализоваав _user_initial_stackheap, но имелось в виду не это. Размеры стека не указываются никакой функцией, под стек выделяется отдельная секция (какая - можно посмотреть в startup), размеры этой секции задаются в настроечном файле компоновщика (scatter-файл, *.sct). Проверить, хватает ли текущего размера стека не совсем тривиальная задача, никаких явных сообщений о переполнении стека не будет, нужно выкручиваться самому.

Например, перед началом работы программы заполняем стек одинаковым, по возможности редко встречающимся магическим значением. Запускаем программу и нагружаем ее как можно сильнее. После некоторого времени останавливаем и смотрим на область памяти со стеком: там где магические числа будут затерты - поработала наша программа. Считаем длину оставшейся незатертой части, если осталось совсем мало, или даже совсем не осталось, то лучше увеличить размер стека, иначе можно оставить все как есть.

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

Третий вариант - прикинуть эмперически, какова максимальная вложенность вызовов может наблюдаться в твоей программе. Например, в фоне крутиться функция Foo, использующая 12 байт стека, которая вызывает функцию Bar, использующую 15 байт стека. Получается, в фоне максимальная вложенность равна двум функцииям, при этом максимальное потребление стека 12 + 15 = 27 байт стека. Но есть еще прерывания: Tar и Gar, потребляющие 30 и 40 байт стека соответственно. Прерывания могут вытеснять друг-друга, а также прерывать фоновую задачу, в итоге имеем максимальную вложенность Foo + Bar + Tar + Gar и максимальное потребление стека 12 + 15 + 30 + 40 = 97 байт. Размер стека выбираем соответствующий, только нужно не забывать, что прерывания используют стек для сохранения текущих значений регистров ЦПУ, и учитывать это в вычислениях потребляемой памяти.

В общем то ARM имел в виду именно это - если у тебя прерывания начинают вытеснять друг-друга, то вложенность вызовов и соответственно потребление стека могут значительно увеличиться.

Сообщение отредактировал menzoda - Jul 18 2014, 05:08