SWI, Смысл использовать SWI Опции

[серый волк]

начал разбираться с армом
наткнулся на SWI
не понимаю смысл его использования
так из примера ничего не ясно
похоже на вызов обкновенной функции
спасибо

#include <LPC21xx.H>

void SWI_Call1(int pattern) //Software interrupt with passed parameters
{
IOCLR1 = 0x00FF0000; //set the leds
IOSET1 = pattern;
}

void SWI_Call2(void)
{
IOCLR1 = 0x00FF0000;
IOSET1 = 0x00AA0000;
}

void main(void)
{
int pattern = 0x00550000;
IODIR1 = 0x00FF0000;
IOCLR1 = 0x00FF0000;

SWI_Call1(pattern);
SWI_Call2();

while(1)
{
; //Loop forever
}
}

[Д_М]

Здравствуйте!
Выше много писали о том, что во время IRQ происходит SWI. На AVR я реализовал многозадачность, с использованием псевдо-SWI (аппаратное прерывание, как программное - INT0). Моя идея заключалась в том, чтобы при выполнении IRQ, в обработчике надо быть, как можно меньше времени. Только сохранение данных и инициация работы кода, который занимает нечто промежуточное по важности, между фоновой задачей (которая может длиться до единиц миллисекунд) и обработчиками прерываний. То есть, обработать данные надо, как можно скорее, но не в ущерб аппаратным прерываниям. Для этого обработчик IRQ инициирует SWI. После завершения IRQ вызывается SWI, который является диспетчером обработчиков, вызывающим наиболее важный обработчик. SWI, перед вызовом обработчика, разрешает прерывания, что позволит без ущерба отрабатывать обработчикам аппаратных прерываний. А как это работает на ARM? Правильно ли я понял, что если в обработчике IRQ вызвать SWI, то его код будет отработан после того, как отработают все IRQ? Если во время работы SWI произойдёт IRQ, управление сразу же будет передано IRQ, а по его завершению вернётся обратно в SWI?
Спасибо!

[jcxz]

Правильно ли я понял, что если в обработчике IRQ вызвать SWI, то его код будет отработан после того, как отработают все IRQ? Если во время работы SWI произойдёт IRQ, управление сразу же будет передано IRQ, а по его завершению вернётся обратно в SWI?

Неправильно. SWI - синхронное исключение, а не обычное асинхронное внешнее прерывание типа IRQ или FIQ. Т.е. - собственно для Вас это как простой вызов функции (с переключением CPU в привилегированный режим).
Если процессор перед вызовом SWI находился в режиме IRQ, то произойдёт переключение в режим SWI (с запретом FIQ и IRQ). При выходе из режима SWI произойдёт возврат в режим IRQ.
SWI например может использоваться для вызова функций OS из непривилегированного режима (режима пользователя).

[Д_М]

Неправильно. SWI - синхронное исключение, а не обычное асинхронное внешнее прерывание типа IRQ или FIQ. Т.е. - собственно для Вас это как простой вызов функции (с переключением CPU в привилегированный режим).
Если процессор перед вызовом SWI находился в режиме IRQ, то произойдёт переключение в режим SWI (с запретом FIQ и IRQ). При выходе из режима SWI произойдёт возврат в режим IRQ.
SWI например может использоваться для вызова функций OS из непривилегированного режима (режима пользователя).

А как тогда оформить код, который активируется в прерывании, но исполняется после всех прерываний? То есть менее приоритетный, чем прерывания, но более приоритетный, чем фоновая задача.
Спасибо!

[jcxz]

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

Использовать RTOS.

[Д_М]

Использовать RTOS.

Из описания операционных систем я понял, что в них передача управления производится на системных тиках. Для некоторых задач одна миллисекунда - это слишком долго. Самый банальный пример - передача одного байта по UART, на скорости 9600, занимает примерно одну миллисекунду. Если в обработчике прерывания передачи делать только сохранения данных, а CRC считать в RTOS-задаче, то новый байт будет поступать до того, как будет посчитано CRC предыдущего байта. Вычислять CRC в обработчике прерывания - грубовато. Если бы можно было дать команду вызова диспетчера сразу же, а не по пришествию ближайшего тика, то было бы то, что нужно.

[DmitryM]

Из описания операционных систем я понял, что в них передача управления производится на системных тиках. Для некоторых задач одна миллисекунда - это слишком долго. Самый банальный пример - передача одного байта по UART, на скорости 9600, занимает примерно одну миллисекунду. Если в обработчике прерывания передачи делать только сохранения данных, а CRC считать в RTOS-задаче, то новый байт будет поступать до того, как будет посчитано CRC предыдущего байта. Вычислять CRC в обработчике прерывания - грубовато. Если бы можно было дать команду вызова диспетчера сразу же, а не по пришествию ближайшего тика, то было бы то, что нужно.

scmRTOS, FreeRTOS так умеют делать, Вы невнимательно читали скорее всего.