Глава 8. Прерывания
void foo(void) {
int current_cpu_ipl;
SET_AND_SAVE_CPU_IPL(current_cpu_ipl,7); /* запрет прерываний с приоритетом ниже 7 */
/* здесь защищенный код */ RESTORE_CPU_IPL(current_cpu_ipl);
}
8.9.Разделение памяти между основной программой и ISR
Следует проявить осторожность при модификации одной и той же переменной в |
|
пределах основной программы или низкоприоритетной ISR и высокоприоритетной |
|
A |
создает многокомандную |
ISR. Когда функция с низким приоритетом. |
|
последовательность чтение-модификация-запись, то прерывания с более высоким приоритетом, будучи разрешены, могут прервать ее, что даст неожиданные результаты при доступе к той жеWilsonпеременной. Следовательно, встроенные системы должны применять атомарные операции для предотвращения вмешательства высокоприоритетных ISR, записывающих информацию в ту же переменную, из которой низкоприоритетная ISR уже прочитала, а записать еще не успела.
Атомарная операция — та, которая не может быть разбита на составные части, т.е. не может быть прервана. В зависимости от конкретных особенностей архитектуры, не все выражения Cи переводятся в атомарные операции. В устройствах dsPIC, эти выражения главным образом подразделяются на следующие категории: 32-битовые выражения, арифметика с плавающей точкой, деление и операции над многобитовыми полями битов. На то, будет ли сгенерирована атомарная операция или нет, влияют и другие факторы,by как например, установки модели памяти, уровень оптимизации и доступность ресурсов.
Рассмотрим обычное выражение:
Оператор (op) может быть или не быть атомарным, в зависимости от архитектуры устройства. Так или иначе, компилятор может быть не способен сгенерировать атомарную операцию во всех случаях — это будет сильно зависеть от нескольких причин:
• наличие подходящей атомарной машинной команды
• доступность ресурса — специальные регистры или другие ограничения
• уровень оптимизации и другие опции, которые влияют на размещение данных и кода
Без знания архитектуры разумно предположить, что обычное выражение требует двух операций чтения, по одной на каждый операнд, и одной операции записи для сохранения результата. Некоторые трудности могут возникнуть в присутствии последовательностей прерываний, это сильно зависит от конкретного приложения.
8.9.1. Разработка проблем
Translatedfoo = bar op baz;
Вот некоторые примеры:
ПРИМЕР 8-1. BAR ДОЛЖНА СООТВЕТСТВОВАТЬ BAZ
Если требуется, чтобы bar и baz соответствовали, (т.е. обновлялись синхронно друг другу), есть возможный риск, когда bar или baz может быть скорректирована выражением в пределах прерывания с более высоким приоритетом. Вот некоторые примеры последовательности событий:
1.Безопасный: чтение bar чтение baz
© 2008 Microchip Technology Inc. |
DS51284H(ru) стр. 8-15 |
16-битовый компилятор Си. Руководство
выполнение операции запись результата в foo
2. Небезопасный: чтение bar
прерывание модифицирует baz
чтение baz выполнение операции
запись результата в foo
3. Безопасный: |
|
. |
чтение bar |
|
|
|
A |
|
чтение baz |
|
|
прерывание модифицирует bar или baz |
||
выполнение операции |
Wilson |
|
запись результата в foo |
|
|
|
|
|
Первая ситуация безопасна, поскольку прерывание происходит за пределами выражения. Вторая — небезопасна, поскольку приложение требует, чтобы bar и baz корректировалась синхронно друг с другом. Третья — вероятно безопасна, foo возможно будет получать старую величину, но она будет соответствовать данным, которые были доступны в начале вычисления выражения.
ПРИМЕР 8-2. ТИП FOO, BAR И BAZ
Другая разновидность происходит от типов foo, bar и baz. Операции «чтение bar», «чтение baz» или «запись результата в foo» могут не быть атомарными в зависимости от архитектурыby целевого процессора. Например, устройства dsPIC могут прочитать или записать 8-битовую, 16-битовую или 32-битовую величину одной командой (атомарно). Но 32-битовое значение может потребовать две команды в зависимости от выбора команд (который в свою очередь будет зависеть от
данным. Тогда доступ становится таким:
оптимизацииTranslatedи установленных параметров модели памяти). Предположим, что типы данных long и компилятор не может выбирать атомарные операции для доступа к
чтение младшего слова bar чтение старшего слова bar чтение младшего слова baz чтение старшего слова baz
выполнение операции (над младшим и старшим словами) запись младшего слова результата в foo
запись старшего слова результата в foo
Здесь появляется масса возможностей, когда обновление bar или baz приводит к непредсказуемым результатам.
ПРИМЕР 8-3. БИТОВЫЕ ПОЛЯ
Третья причина для беспокойства — битовые поля. Cи допускает распределение памяти на битовом уровне, но не определяет какие-либо битовые операции. В буквальном смысле, любая операция на битом будет рассматриваться, как операция над основным типом битового поля, и обычно будет требовать операции извлечения поля из bar и baz или вставки поля в foo. Следует отметить важное соображение, что (опять же в зависимости от архитектуры команд, уровня оптимизации и настроек памяти) прерываемая программа, которая пишет в любую часть битового поля, где располагается foo, может быть ненадежной. Это особенно явно в случае, когда один из операндов также является приемником.
Набор команд dsPIC может оперировать над 1 битом атомарно. Компилятор может выбрать эти команды в зависимости от уровня оптимизации, установочных параметров памяти и доступности ресурсов.
DS51284H(ru) стр. 8-16 |
© 2008 Microchip Technology Inc. |
Глава 8. Прерывания
ПРИМЕР 8-4. КЭШИРОВАНИЕ ЗНАЧЕНИЙ ПАМЯТИ В РЕГИСТРАХ
Наконец, компилятор может выбрать кеширование величин из памяти в регистрах. Они часто называются регистровыми переменными и являются особенно уязвимыми для повреждения прерыванием, даже тогда, когда операция с участием переменной не прервана. Убедитесь, что ресурсы памяти, разделяемые между ISR и прерываемой функцией определены как volatile. Этим вы сообщите компилятору, что ячейка памяти может быть скорректирована извне кодовой последовательности. Это не защитит против эффекта неатомарных операций, но является все же важным.
8.9.2. Разработка решений |
|
Здесь приведено несколько стратегий для снижения потенциальных рисков: |
|
|
. |
• Разрабатывайте программную систему так, чтобыA конфликтующие события не могли произойти. Не разделяйте память между ISR и другими функциями. Делайте ISR по возможности простыми и переносите реальную работу в основной код.
•Будьте аккуратны при разделении памяти и, если возможно, избегайте разделения битовых полей, содержащих много битов.
•Защищайте не атомарное обновление разделяемой памяти от прерываний, как вы должны защищать критические участки кода. Для этого может использоваться следующий макрос:
#define INTERRUPT_PROTECT(x) { |
\ |
|
char saved_ipl; |
Wilson |
\ |
|
\ |
|
|
|
|
SET_AND_SAVE_CPU IPL(saved_ipl,7); |
\ |
|
x; |
|
\ |
RESTORE_CPU_IPL(saved_ipl); } |
|
|
|
by |
|
Этот макрос запрещает все прерывания с приоритетом ниже 7 путем подъема уровняTranslatedприоритета процессора до 7, исполняет необходимые действия, а затем восстанавливает предыдущий уровень приоритета.
8.9.3. Пример приложения
Следующий пример иллюстрирует некоторые аспекты, обсужденные в данном подразделе:
void attribute__((interrupt)) HigherPriorityInterrupt(void) { /* Здесь код пользователя */
LATGbits.LATG15 = 1; /* Установка бита 15 LATG */ IPC0bits.INT0IP = 2; /* Смена 0 уровня приоритета на 2
(используется несколько битов) */
}
int main(void) {
/* Еще код пользователя */
LATGbits.LATG10 ^= 1; /* Потенциальный РИСК — Сначала LATG читается в W, выполняется операция XOR,
затем результат пишется в LATG */
LATG = 0x1238; /* Проблем не возникнет, это просто запись в операции присваивания */
LATGbits.LATG5 = 1; /* Вероятно, проблем не будет,
это просто присваивание одного бита, которое будет выполнено единственной
командой установки бита */
© 2008 Microchip Technology Inc. |
DS51284H(ru) стр. 8-17 |