[jcxz 235]

И еще: кто-нить пользуется SVC? Может, лучше через SVC, раз "лишние" прерывания KnightIgor не напрягают?

Я пользуюсь :)

 

Да элементарно. Представим себе модем. Скорость rs232 115200, скорость по линии 33600. И ваш fifo по определению переполняется. Дабы этого не происходило, вам надо при заполнении фифо на 90% управлять потоком. То есть высылать XOFF либо снимать RTS. А при освобождении буфера необходимо опять разрешать подгрузку. В целом так будет происходить в любом случае, когда скорость обработки информации меньше чем скорость заполнения буфера.

Так вот в момент определения уровня заполнения буфера, необходимо сравнивать 2 указателя. В общем случае требуется критическая секция.

Фловконтроль для согласования скоростей каналов и программный фифо - несколько разные вещи.

Да, управлять потоком можно от уровня заполненности программного FIFO.

Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна :)

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

 

Это видимо имелось в виду программное прерывание. Правильнее его называть SWI.

Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). :)

[SapegoAL 0]

Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна :)

Я написал "в общем случае". :rolleyes:

 

[jcxz 235]

Проще использовать мютексы и не городить сложных систем с критическими секциями и платформозависимой атомарностью. Не разделяю любви с неблокирующим алгоритмам - их очень трудно поддерживать и очень легко сломать.

Интересно - как вы с помощью мьютексов и прочих блокирующих методов синхронизируете работу фоновой задачи с ISR-ами?

Научите!

 

К тому-же - реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе.

[andrewlekar 0]

Интересно - как вы с помощью мьютексов и прочих блокирующих методов синхронизируете работу фоновой задачи с ISR-ами?

Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.

 

реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе.

Кто же спорит. Но мы этого не видим и туда без необходимости не лезем.

[adnega 11]

Я пользуюсь :)

На чистом C или с ASM-вставками?

В Keil или GCC?

 

Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). :)

Насколько я понял, разработчики Cortex-M изменили название инструкции (сохранив числовое значение) при переходе с ARM7,

чтобы программист, который портирует код уделил внимание особенностям новой системы исключений.

[jcxz 235]

Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.

Фифо - это не блокирующий метод.

И что толку от сигнализации если нужно эксклюзивное чтение-модификация-запись некоей области памяти в ISR и фоновой задаче (критическая секция)?

Хорошо если можно в ISR тупо писать/читать в фифо. А если нужна работа с более сложной структорой данных в памяти?

Или то же самое фифо, но несколько писателей или несколько читателей? Как вы тут без критической секции обойдётесь?

[andrewlekar 0]

Тут достаточно не критической секции, а запрета конкретного источника прерывания перед установкой семафора. При работе с ISR так или иначе запрещать прерывания придётся. Но но уровне операционки можно написать тонны софта ни разу не встретившись с прерыванием. В линуксе скажем они где-то глубоко запрятаны. В таком случае городить всякие lock-free и критические секции нет никакой нужды до тех пор, пока реально не понадобится улучшить производительность.

[jcxz 235]

На чистом C или с ASM-вставками?

В Keil или GCC?

В IAR. Вызовы - на си, обработчик SVC - на асме.

Вот так декларирую:

#define SVCF_trap0       0
#define SVCF_trap1       1
#define SVCF_trap2       2
#define SVCF_trap3       3
#define SVCF_trapMax     SVCF_trap3
#define SVCF_AppRestart  (SVCF_trapMax+1)
#pragma swi_number=SVCF_trap0
__swi void trap(u32);
#pragma swi_number=SVCF_trap1
__swi void trap(u32, u32);
#pragma swi_number=SVCF_trap2
__swi void trap(u32, u32, u32);
#pragma swi_number=SVCF_trap3
__swi void trap(u32, u32, u32, u32);
#pragma swi_number=SVCF_AppRestart
__swi void AppRestart();

Как видите - SVC использую для вызова обработчика критических ошибок. Вызовов таких в коде - тьма-тьмущая (одних только ASSERT-ов...).

А с использованием SVC вызов получается очень компактным.

И что самое важное - в этом обработчике у меня сохраняется дамп прерванного контекста CPU, а обычный BL в этом случае даёт меньше возможностей.

[kostyan1 0]

Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.

 

 

Кто же спорит. Но мы этого не видим и туда без необходимости не лезем.

 

А если существует более чем один источник часто повторяющихся прерываний, то эти ваши "невидимые" семафоры в прерываниях уронят всю систему. И в сервисах осей как раз стопроцентно используются критические секции. Уже два раза напоролся на такое - сейчас принципиально стараюсь в прерываниях не юзать осевые сервисы.