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
}
}

[Д_М]

В описании операционной системы RL-ARM от Keil углядел очень интересный механизм

В ОС предусмотрен системный вызов для установки флагов событий, предназначенный для вызова из обработчика прерывания:
void isr_evt_set(unsigned short event_flags, 0S_TID task);
Таким образом, типичный процесс, выполняющий обработку прерывания,
будет выглядеть следующим образом:

Код

void Task3(void) {
while(1)
{
os_evt_wait_or(0x0001, 0xFFFF); /* Ждем установки флага
события обработчиком */
......... // Обрабатываем прерывание
} // В следующем проходе цикла снова засыпаем
}
Обработчик прерывания в данном случае будет содержать минимальное
количество кода:
void FIQ_Handler (void) __fiq
{
isr_evt_set(0x0001,tsk3); /* Сообщаем процессу tsk3 о возникновении
прерывания */
EXTINT = 0x00000002; // Сбрасываем флаг прерывания
}

Можно ли быть уверенным в том, что управление будет сразу же передано обработчику, а не с наступлением системного тика?

Сообщение отредактировал IgorKossak - Mar 25 2015, 18:30

Причина редактирования: [codebox] для длинного кода, [code] - для короткого

[jcxz]

Можно ли быть уверенным в том, что управление будет сразу же передано обработчику, а не с наступлением системного тика?

Во-первых: в embedded RTOS как правило можно легко менять значение системного тика. В uCOS при необходимости можете хоть 10кГц поставить. Только не нужно это, ибо - пустая трата ресурсов на работу шедулера.
Во-вторых: тот же uCOS может переключать задачи как только по сис.таймеру, так и по любому прерыванию. Это будет зависеть от того как Вы эти самые ISR оформите. Всё очень гибко.

Вам надо садиться и изучать работу RTOS. Они все многозадачные. Кроме "фоновой задачи" там можно создать сколько нужно других задач, одна из которых и будет обрабатывать ваши события от ISR UART
(заводите задачу с приоритетом выше фоновой, которая всё время сидит в ожиднаии некоторого мэйлбокса/семафора/или другого средства синхронизации ОС; от ISR посылаете событие в этот объект;
задача обрабатывает событие и опять переходит к ожиданию этого объекта). Это стандартный механизм работы задач под ОС, начиная от виндовых задач кончая embedded-областью.

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

Уже сколько народу тут талдычат ТС об этом, а он всё своё гнёт... Тяжкое наследие AVR?
А CRC можно хоть по приходу всего кадра считать, хоть на лету в ISR. Больших затрат ресурсов на ARM это не требует.

[mantech]

Уже сколько народу тут талдычат ТС об этом, а он всё своё гнёт... Тяжкое наследие AVR?

А что, в аврках нельзя было повесить уарт на свой обработчик прерывания??
Я конечно не ставил rtosы на авр, но использовал приоритетный метод с системой распределения вложенных прерываний, виртуальные таймеры и пр. няшки, все работало как надо...

Сообщение отредактировал mantech - Mar 25 2015, 19:08