TNKernel, вопросец по THUMB и по запрету прерываний Опции

[DASM]

Файл порта например tn_port_asm_armcc.s
строка 300

Код

tn_cpu_save_sr

        mrs    r0,CPSR;-- Disable both IRQ & FIQ interrupts
        orr    r1,r0,#NOINT
        msr    CPSR_c,r1
;-- Atmel add-on
        mrs    r1,CPSR;-- Check CPSR for correct contents
        and    r1,r1,#NOINT
        cmp    r1,#NOINT
        bne    tn_cpu_save_sr;-- Not disabled - loop to try again
;--------

Не очень понял причем тут Atmel , вроде как это вообще особенность ядра такая...
Я так понял вот эта http://www.arm.com/support/faqip/3677.html
Так вот.. подобный код мне кажется вставить надо тогда и в других местах... например в tn_switch_context.. Или я не то что-то говорю ?
Просто вторые сутки сижу, если завалить операционку прерываниями ( в моем случае USB) - ось через определенное место рушится. Довольно хитро так рушится, и концов не найти, почему в abort вылетели.
А если сей код привести в соответсвие с вышесказанным - то все нормально (кажется).
Вопрос - я брежу или нет ?

PS ... все равно где-то что-то еще не так.. может и у меня.. щас с катушек съеду :-(
В догонку - я правильно понял, что Тумб кода быть не должно ?

PPS2 с глюками разобрался, виноват конечно я, одной задаче дал мало стека.. но ничего, зато в кишках оси порылся всласть =))
Но все же вопрос остается - откуда ноги растут у этого Atmel addon ?

PPS3
А вот наличие THUMB кода точно вешает все.. То есть в Keil надо галку enable arm/thumb interworking снимать, иначе некоторые библиотеки иду тумбовые (sprintf напрмер)

Сообщение отредактировал DASM - Mar 27 2007, 09:32

[zltigo]

Не очень понял причем тут Atmel , вроде как это вообще особенность ядра такая...

Сия проблема описана только в одном из Atmel-овских документов, является-ли она общей - вопрос.

[DASM]

Сия проблема описана только в одном из Atmel-овских документов, является-ли она общей - вопрос.

Тогда к филипсу это тоже относится - ставил "ловушку" после сравнения - иногда выходит в неё (то есть после запрещения прерываний считанные назад флаги отличались). Но вот как это может повлиять на работоспособность оси - пока в голове не устаканилось.
Так а документ по моей ссылке от arm.com - он что-то другое описывает чем Атмель ?
Вот 5 гиг по USB прокачал - полет нормальный. Кажется все хорошо :-)) Не, все таки операционка - это здорово :-)

[yuri_t]

В статье на сайте ARM описывается ситуация, когда флаг запрета прерывания
находится в процессе выставления, а прерывание произошло.
Тот факт, что процессор обрабатывает IRQ после завершения инструкции MSR,
которая запрещает IRQ, в TNKernel не вызывает проблем, т.к. любое прерывание,
которое появилось бы лишь чуть-чуть раньше, было бы нормально обработано.
Когда происходит возврат из процедуры обработки прерывания, SPSR_IRQ
возвращается в CPSR. В CPSR теперь биты I и F выставлены и, соответственно,
работа продолжается с запрещенными прерываниями.
В некоторых (вполне определенных) случаях это может привести к проблемам, но
в TNKernel процедура входа в прерывания нигде, кроме этого места, не вызывается,
прерывание FIQ не используется, и поэтому проблем быть не должно.

Atmel add-on код обрабатывает другую ситуацию (или, если угодно, туже самую,
но с другого бока) - в прерывания попали, запрет прерываний сделали, а запрет
не прошел (флаги не выставились). Я не знаю, насколько типична эта ситуация для
не-Atmel ARMов, но этот код добавил.

THUMB режим в ТNKernel не проверялся и вряд ли будет работать. Если THUMB
режим очень нужен, то можно посмотреть, как это сделано в eCOS и доработать
ассемблерные файлы в ТNKernel.

[VslavX]

В статье на сайте ARM описывается ситуация, когда флаг запрета прерывания
находится в процессе выставления, а прерывание произошло.
Тот факт, что процессор обрабатывает IRQ после завершения инструкции MSR,
которая запрещает IRQ, в TNKernel не вызывает проблем, т.к. любое прерывание,

Тут нашелся такой проблемс - tn_switch_context() всегда разрешает прерывания в задаче на которую происходит переключение

Код

tn_switch_context:
...
tn_sw_restore:
...
        mrs    r4, CPSR
        bic    r4, r4, #NOINT             <- здеся собака и порылася :)
        msr    CPSR_c, r4
        ldmfd  sp!, {r0-r12,lr,pc}

Если бы не было "атмеловского" патча, то был бы возможен такой сценарий:
- некоторая задача хочет запретить прерывания
- вызывает tn_save_cpu_sr()
- выполняется инструкция msr CPSR_c,R0
- сразу после нее происходит прерывание
- при выходе из прерывания происходит переключение на другую задачу (типовой случай - на высокоприоритетную таймерную задачу)
- более приоритетная задача делает свои дела и "отходит от дел" по tn_switch_context() - типично для таймерной задачи
- итого - исходная задача, которая запрещала прерывания выполняется теперь с разрешенными, поскольку tn_switch_context() вбросил ее после вытеснения по прерыванию

"Атмеловский" патч сам по себе надежен, но увеличивает время с запрещенными прерываниями , было бы неплохо от него избавиться

[DASM]

что-то как-то коряво для оси то.. "- некоторая задача хочет запретить прерывания" Гнать её в шею. Чего этой запрещаться понадобилось А вообще в этой точке мы всегда с разрешенными прерываниями оказываемся - и в новой версии TNKernel этих строчек нет

[VslavX]

что-то как-то коряво для оси то.. "- некоторая задача хочет запретить прерывания" Гнать её в шею.

Здесь под задачей понимался не код написанный пользователем, а код исполняемый в контексте задачи. Когда Ваша программа вызывает практически любой сервис операционки, та и производит запрещения прерываний для своих нужд, и ессно, делает это в контекстве Вашей задачи.
Ну и в пользовательском коде тоже вполне может быть врЕменное запрещение прерываний -
для синхронизации это иногда бывает намного эффективнее механизмов OС.