[klen 1]

интересненько почитал... а то как то вяло на электрониксе последние пол года

по существу думаю Вы оба правы! но каждый про свое.

механизмы прерываний реализованные в железе и ОСность вещи перпендикулярные.

на armv4 считаю что создть невозможно вложенные прерывания абсалютно надежно, вот их там и не любят. в armv7 это решили пофиксить но тоже не без придури, поэтому получилось полено папы Карло.

я традиционно из stm32 "ПЛИСину" выжимаю поэтому мне ближе механизмы заложенные в armv7 так как более детерминированая сисием получается.

ну и с наступающим всех!!!

желаю всем в НГ менее глючного кода и более быстрого железа.

[zltigo 0]

по существу думаю Вы оба правы! но каждый про свое.

механизмы прерываний реализованные в железе и ОСность вещи перпендикулярные.

Не совсем понимаю про перпендикулярность. Говорил только, что навороты воложенных прерываний с их приортиетами не надо смешивать с тем, что предоставляет операционная система. То есть при наличии операционной системы нужны более, чем веские основания для использования вложенных прерываний.

на armv4 считаю что создть невозможно вложенные прерывания абсалютно надежно, вот их там и не любят.

Слово "абсолютно" не понимаю. Но вложенные сам для маленькой маленькой штучки на LPC2101 в свое время делал руками. Без проблем. Как и еще на доброй полудюжине контроллеров и PC.

Какие вообще могут быть проблемы со вложенными прерываниями на той же v4, если они делаются софтово БЕЗ какой либо аппаратной поддержки.

Другое дело, то де-факто у самого контролера есть какие то глюки :(. Вот здесь спустя много лет наступил https://electronix.ru/forum/index.php?showt...t&p=1374580. Залатал. Но причину так и не понял.

в armv7 это решили пофиксить но тоже не без придури, поэтому получилось полено папы Карло.

Получился некий законченный универсальный вариант. Вполне тщательно продуманный. Но как любой универсальный не без недостатоков и избыточности.

[AVI-crak 0]

Вот здесь спустя много лет наступил https://electronix.ru/forum/index.php?showt...t&p=1374580. Залатал. Но причину так и не понял.

Это и есть проблема атомарности в чистом виде. Вам необходимо настроить регионы mpu, включить сквозную запись в адресном пространстве регистров управления мк. Собственно это должна быть самая первая операция на мк имеющим собственный кеш.

 

Далее, неважно насколько крута ось - важно что физические устройства должны иметь разный приоритет. Например банальный spi: при равных приоритетах на Rx и Tx - получим стабильный глюк. Причём приоритеты на тот-же spi имеются и в каналах dma и на само конечное прерывание.

Разные приоритеты обработки для включённой периферии. Например sd карта может и подождать звуковой кодек.

 

Может приведёте здесь Ваш переключатель задач для classic ARM? Чтобы не быть голословным.

 

Для cortex m7 переключатель получается жирным, необходимо сохранять много регистров. А точнее на 16 штук больше чем cortex m4.

Ничего сложного: сохранить в стек r4-r11, и математику s16-s31, сохранить адрес стека в структуру задачи, остальное автоматически сохраняется в текущем стеке задачи. Восстанавливать так-же.

Стеки под задачи разные, стек под прерывания один единственный.

https://bitbucket.org/AVI-crak/rtos-cortex-m3-gcc/src

[zltigo 0]

Это и есть проблема атомарности в чистом виде. Вам необходимо настроить регионы mpu, включить сквозную запись в адресном пространстве регистров управления мк.

....

Вы бредите :(. Советую для начала ознакомится с контроллером. Для начала нет у него кэшей. Совсем.

Например банальный spi: при равных приоритетах на Rx и Tx - получим стабильный глюк.

Ни банальный ни какой другой SPI не имеет никаких отдельных прерываний Rx/Tx по определению.

неважно насколько крута ось - важно что физические устройства должны иметь разный приоритет

Или не иметь. Как надо, так и делается. Это Вы с кем спорите? Кто-то утверждал, что все прерывания должны быть одного приоритета?

[jcxz 184]

Для cortex m7 переключатель получается жирным, необходимо сохранять много регистров. А точнее на 16 штук больше чем cortex m4.

Что за дополнительные регистры? В FPU? Ну так их сохранение опционально - я в своём порту под uCOS при переключении задач сохраняю S0-S31,FPSCR только для задач, использующих FPU. Большинство задач FPU не использует и для них размер сохраняемого контекст можно уменьшить.

И регистры S0-S31 были и в M4.

Вы ничего не напутали? :rolleyes:

[Obam 30]

"The code designed for other Cortex®-M processors is compatible with Cortex®-M7 as long as it does not rely on bit-banding." - STM32F7 Series Cortex®-M7 processor programming manual. DocID028474 Rev 2.

 

Аминь… ;)

[amiller 2]

В процессе переезда с bit-banding сделал несколько макросов, может кому будет интересно:

#define setw_amask(x,y)	{while(__STREXW(__LDREXW(&x) | (y), &x));__CLREX();}
#define clrw_amask(x,y)	{while(__STREXW(__LDREXW(&x) & ((int32u)~((int32u)y)), &x));__CLREX();}
#define seth_amask(x,y)	{while(__STREXH(__LDREXH(&x) | (y), &x));__CLREX();}
#define clrh_amask(x,y)	{while(__STREXH(__LDREXH(&x) & ((int32u)~((int32u)y)), &x));__CLREX();}
#define setb_amask(x,y)	{while(__STREXB(__LDREXB(&x) | (y), &x));__CLREX();}
#define clrb_amask(x,y)	{while(__STREXB(__LDREXB(&x) & ((int32u)~((int32u)y)), &x));__CLREX();}

Примеры применения:

seth_amask(flag, 0x10);
clrh_amask(flag, 0x20);

Вроде бы под IAR компилируется достаточно лаконично.

[scifi 1]

В процессе переезда с bit-banding сделал несколько макросов, может кому будет интересно:

Пишут же, что CLREX тут не нужен.

[zltigo 0]

В процессе переезда с bit-banding сделал несколько макросов...

CLREX тут лишние, поскольку STREX сбрасывает флаг доступа.

 

[KnightIgor 2]

В реальности это очистка регистра адреса, который используется для мониторинга атомарного адреса. Прикол в том что когда __LDREXW и __STREXW применяется в прерывании, и перебивается другим прерыванием ровно между командами - при возврате получается глюк.

Я тоже много думал и пытался найти подробнее, как работает LDREX/STREX пара, предполагая, что там какие-то адреса мониторятся. Все гораздо... тупее. Никаких адресов. Если между LDREX и STREX произошло хоть какое прерывание, считается, что оно МОГЛО что-то изменить в атомарной переменной, даже если обработчики ни сном, ни духом и нигде пальчиками не лазили, и операция экслюзивности отвергается. Так, на всякий случай. Я не подпишусь, как там с DMA, который может влезть на атомарную переменную. Не нашел упоминания по поводу (может, плохо искал), но по логике предполагаю, что если между LDREX и STREX хоть какое-то телодвижение со стороны DMA было, эффект будет аналогичный прерыванию. В этой связи есть у меня подозрение, что LDREX/STREX внутри прерывания может действительно приводить к странным эффектам.

 

P.S. Касаемо bit-banding, а точнее - его нужности, то дискуссия в ее нынешнем состоянии есть просто излишня. Здесь нужно принимать явление феноменологически: коль ARM такое замутил, то в этом был и есть глубинный смысл и польза. Не нравится - не ешь.

Изменено 9 января, 2017 пользователем KnightIgor

[zltigo 0]

В этой связи есть у меня подозрение, что LDREX/STREX внутри прерывания может действительно приводить к странным эффектам.

И каким образом лишний сброс флага эксклюзивности развеивает Ваши подозрения?

[scifi 1]

Я тоже много думал и пытался найти подробнее, как работает LDREX/STREX пара, предполагая, что там какие-то адреса мониторятся.

А что там думать? Всё же написано:

The Cortex-M3 includes an exclusive access monitor, that tags the fact that the processor has executed a Load-Exclusive instruction. If the processor is part of a multiprocessor system, the system also globally tags the memory locations addressed by exclusive accesses by each processor.

The processor removes its exclusive access tag if:

- It executes a CLREX instruction.

- It executes a Store-Exclusive instruction, regardless of whether the write succeeds.

- An exception occurs. This means the processor can resolve semaphore conflicts between different threads.

[KnightIgor 2]

И каким образом лишний сброс флага эксклюзивности развеивает Ваши подозрения?

Никак. Я высказал предположение. Ход со сбросом - не моя идея, а другого автора здесь.

 

А что там думать? Всё же написано:

Очень хорошо написано. Кратко. А кто спорит? Но мне в свое время недоставало в документации некой преамбулы, фразы о концепции, идее LDREX|STREX с точки зрения всей системы в процессоре. Вроде "если ход исполнения между LDREX и STREX будет прерыван, будем рассматривать такое ответвление как риск потерять целостность операции, потому, независимо от того, действительно ли изменилась атомарная переменная в результате прерывания или осталась нетронутой, атомарная операция отклоняется". Вроде того.

 

Кстати, ни слова про DMA, как я на сей момент и предполагал. То есть, надо чисто организационными методами предотвратить какие-либо доступы со стороны DMA в память семафоров. Иначе - защиты от дурака нет.

Изменено 9 января, 2017 пользователем KnightIgor

[scifi 1]

Но мне в свое время недоставало в документации некой преамбулы, фразы о концепции, идее LDREX|STREX с точки зрения всей системы в процессоре.

Мне тоже. Но тут ничего нового. У них там всё так написано - сухо и кратко. Видимо, не хотят отбирать хлеб у всяких писателей талмудов "кортекс-м3 за 10 простых уроков"...

 

Кстати, ни слова про DMA, как я на сей момент и предполагал. То есть, надо чисто организационными методами предотвратить какие-либо доступы со стороны DMA в память семафоров. Иначе - защиты от дурака нет.

Мне это кажется естественным. Дан простой инструмент, позволяющий реализовать исключительный доступ. А если у вас переполнение стека или кто-то подсунул DMA левые адреса - пеняйте на себя. Тот же MPU не везде присутствует.

[jcxz 184]

Кстати, ни слова про DMA, как я на сей момент и предполагал. То есть, надо чисто организационными методами предотвратить какие-либо доступы со стороны DMA в память семафоров. Иначе - защиты от дурака нет.

А нафиг оно нужно??? Кому взбредёт в голову работать с переменными эксклюзивного доступа через DMA (либо другим bus master нежели CPU)???

Единственный момент: исходя из выдержки, приведённой scifi, не очень понятно как оно работает в много процессорных системах.

Предполагаю, что возможно так: когда в каком-то из CPU возникает условие "removes its exclusive access tag", то он на внешний вывод выдаёт некий сигнал, по-которому этот флаг сбрасывается во всех остальных CPU.