@Balkana: Аз нещо се ОЗАДАЧИХ
Ако искам да забраня прекъсванията (IRQ)

1. На ниво процесор

MRS R0, CPSR
ORR R0, R0, #I_Bit /*disable IRQ*/
MSR CPSR, R0 /* и ако прекъсването от VIC дойде по време на изпълнение на тази интср. отиваме на exception въпреки, че прекъсванията ще са забранени*/

или

2. През VIC

LDR R0, = VIC_BASE
MOV R1, #DISABLE_THE_ENABLED_INTERRUPTS
STR R1, [R0, #VIC_INT_ENABLE_CLEAR_OFFSET]
Доколкото разбирам от теб обаче след STR инструкцията трябва да има NOP? Иначе пак отиваме на exception със забранени прекъсвания?



AAAAAAAAA Ето значи защооооооо, pipeline effect значи, аааааааааа писна ми от тия работи, заминавам за Тибет!!!
http://www.keil.com/support/docs/2888.asp?bhcp=1

@СМ600: точно така, само че с първия си вариант, ако помня правилно, ако го направиш от user mode, няма да се се запише бита I - записа в CPSR е забранен.

за втория вариант, да. И мисля точно пайплайна е причината.

Мисля че тука нещо остава недобре изяснено.
Добавяйки един NOP ти не предотвратяваш влизането в exeption. Само изместваш критичната секция по-назад.
Поради пайплайна и асинхронната работа на VIC е нормално да очакваш че може да влезеш в ексепшън малко след забрана на прекъсванията. Но дали това ще разбози нещата зависи от организацията на цялата програма, а не само от един NOP.
Или аз нещо не разбирам ...

Това много прилича на прословутия бъг(всъщност това не е бъг) на Микрочип, който много нищихме в форума. И май при Арм-а е също толкоз зле документрина цялата ситуация.

До колкото разбирам, проблема е че може да влезем в прекъсване по време на критична секция ли? И тогава критичната секция явно няма да е защитена.

Balkana, ако разбирам правилно с нопа си гарантираш, че ако прекъсването въпреки всичко дойде в кофти момент, ще се изпълни нопа, ще влезе в прекъсване, след това ще излезе и ще започне работата по критичната секция. А при излизането прекъсванията ще бъдат ли вече забранени?

Цецо : "До колкото разбирам, проблема е че може да влезем в прекъсване по време на критична секция ли? И тогава критичната секция явно няма да е защитена"

Не, пич. Критичната секция ще е защитена ( стоката ще я има ), ама трябва по-отрано да се поръча. Срокът за доставка е 2 инструкции.

??? Как ще е защитена, ако се изпълни първата инструкция от критичната секция и после се влезе в прекъсване. Хич не те разбирам.

Относно поръчването по отрано - не ли това точно нопа?

@Zdrav, Цецо: В дейташийта на Микронас пише буквално:

".. при забрана на прекъсванията от регистър еди-кой си на контролера на прекъсванията е възможно да се обработи прекъсване след изпълнението на инструкцията която записва в регистъра. За да се гарантира забраната за кода който следва, при използване на този подход, е необходимо след инструкцията която записва в регистъра, да се постави един NOP. Така, ако има прекъсване, което ще се обслужва, то ще се обслужи между инструкциите за запис в регистъра и NOP-a, при което за кода след NOP, прекъсванията гарантирано ще са забранени ..."

След което описват и другия възможен начин за забрана (I-бита в CPSR), за който говорихме по-горе;
За мен е по-удобно от контролера да си забранявам прекъсванията, тъй като работя в User режим.

Въпросната ситуация, както казах е тествана с други 2 вида АРМ ефекта е същия, с тази разлика че там по дейташийтовете не го пише. След разсъжденията дето минаха по темата, мисля че това ще се наблюдава като ефект във всичките ARM7TDMI, тъй като контролера на прекъсванията не е част от ядрото, а е просто периферия, която е каскада между процесора и останалите източници на прекъсвания, т.е. няма общо с управлението на пайплайна.

Ами в такъв случай на мене ми изглежда най - добър начина да се изпълни подпрограмата, която трябва да е в критична секция през викане на SWI, както Zdrav каза. Така IRQ - тата поне ще са забранени.

@Balkan Точно това имах впредвид.
Изглежда че от самото начало на темата всички казваме едни и същи неща, но по различен начин, по който всеки ги разбира.

Ето два примера кога горният ефект оказва влияние върху работата на програмата:

Пример 1.
Ако веднага след инструкцията:
STR R1, [R0, #VIC_INT_ENABLE_CLEAR_OFFSET]
следва нещо от сорта
STR R2, R3
където в R3 се помни адреса на някаква променлива в която се пише и от главната програма и от процедура за обработка на прекъсване. Какъвто е случаят с посочения от CM600 пример от KEIL) Тогава може да се наблюдава ефект когато стойността на тази променлива получава странни стойности. Както е и в примера ISR трябва да нулира брояча, но тъй като инкремента не е от една инструкция а от няколко то е възможно прекъсването да се намеси между тези отделни инструкции ето как:
count++;
(всъщност като инструкции представлява нещо от сорта)
LDR R3,=COUNT_ADDR
LDR R2, [R3]
ADD R2, R2, #1
STR R2, [R3]
Ако ISR, в който имаме count = 0; (както е в примера на KEIL) се намеси между ADD и STR инструкциите какво ще стане? Главната програма тъкмо се е приготвила да запише инкрементираната стойност, хоп намесва се прекъсването "нулира" count. Програмата се връща на STR инструкцията и записва инкрементираната стойност. Пропуска се едно нулиране на count. Вместо регулярното нулиране от таймер на count, в count продължава да се натрупва.
Причините за това са:
1. count++; е изпълнен на няколко инструкции не като една както е при някои други процесори( тук пайплайна няма никаква вина за получените лайна)
2. Заявките във VIC се обработват асинхронно;
3. В една и съща променлива се пише и от главната програма и от ISR без необходимата синхронизация;
4. Програмистът не е взел впредвид горните съображения;
Е тук според мен това което можем ние да направим е да поработим върху причина #4 или да сменим процесора.

Пример 2
Критичната секция ако е критична и по време и ако въобще не е желателно намесването на асинхронни събития "ни в клин ни в ръкав" тогава не бива да си въобразяваме че "забранявайки" прекъсванията в дадена част от програмата сме си решили задачата.
Най добре е да преразгледаме принципите на които сме базирали цялата програма и например да заменим ако можем прекъсването с "полиране".

Има и още един пример описан подробно в документацията на ARM и user manual-ите на LPC2000 затова няма да го повтарям тука.

Та според мен причините са ясни остава само да се пишат адекватно програмите и подобни ефекти няма да се забелязват.
И не забравяйте дефинирайте си DefaultISR и поставете адреса и в VICDefVectAddr иначе стават изцепки.

@CM600: Това е стандартната методика за забраняване на прекъсванията през I-бита в CPSR от User режим:

Написват се подпрограми за разрешаване и забраняване на прекъсванията от бита I, които се изпълнават от заявката за софтуерно прекъсване SWI ХХ, където ХХ е число, което обработчика на прекъсване може да види; съвсем подобно на INT XX в х86.

Програмата в User режим си вика по-висшия (ОС, БИОС или просто някаква системна част от кода), с помощта на SWI, който се изпълнява в съответния по-високоприоритетен режим, свършва желаната работа и се връща.

На практика за малка система обаче подхода е тежък и май много малко се използва.

@Zdrav: Да, за това говорим значи все пак Филипс са го описали.
Примера с брояча който споменаваш е абсолютно аналогичен на кода, с който имах проблеми аз.

Zdrav, я обясни малко по - подробно какво имаш предвид в пример 2. Защото според мен процесор без прекъсвания е като кола с квадратни колела.

В тоя ред на мисли - АРМ-а определно не е пример за добре организирана система за прекъсвания. Лично мнение.

Ако държиш сметка за времето за изпълнение на критичната секция и ако се намеси малко след влизането в нея някоя процедура която се вика от прекъсване може да се объркат сметките. На мен това точно не ми се е случвало, но да заменям прекъсванията с полиране ми се случва. Последният път имах 4 векторни IRQ и един FIQ времето за реакция беше критично защото трябваше да се поддържа непрекъснат трансфер на данни 500 kbps с декодиране. А трансфера се управляваше от 3 сигнала на единия от които трябваше да се реагира в рамките на 10-15 us. От друга страна периодично се прехвърляха данни по SPI. Така и не можах да намеря надеждно решение с прекъсвания за SPI трансфера и го направих с полиране. В определен момент главната програма стартира четене на байт от SPI и се полира до приемането на байта. После се преминава към други задачи, обработват се прекъсвания и като дойде момент отново се изчита байт по SPI с полиране и т. н. По време на полирането останалите прекъсвания са добре дошли. Така всичко заспа.
Нямам впредвид да се отказваме от прекъсванията по принцип.
А специално за ARM-а за който говорим какво ти липсва?

Ами излишно сложен е според мен - контролера за прекъсвания имам предвид. Освен това определено не е кой знае колко бърз в прекъсванията, даже и в FIQ.
Един пиклив 8 битов контролер при еднаква честота го прави смешен в реакцията си.

Но то по принцип на тия (армовете) силата им определено не е в входно изходните операции. Направо са си бавни в това отношение. Виж за сметки...

Цецо кой мислиш ги прави тези ядра, тези контролери ...?
Дали хора, които изобщо не са в час щото мозъците им са оплетени в неясни абстракции и безсмислени главоблъсканици? Или са хора, които знаят какво правят и си разбират от занаята?
Дали във PHILIPS са възложили бойна задача на екипа, който прави електрическите самобръсначки Philishave да се заеме и с 32-битовите микроконтролери?

Е ти пък го прие лично.

Ами то следвайки твойта логика една корейска тенекия и нея я правят инженери - ама като си купуваш кола ги заобикаляш отдалеч.

Не съм искал да обиждам контролера. Казвах само че определено времето за реакция не е най силната черта на тая архитектура. Но си има редица други предимства.

Нема са да си мерим пишките на тема ядра. Още повече че и аз сериозно съм се заел с АРМ (или поне така си мисля, зависи от края на тоя проект)