jcxz 235 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба И еще: кто-нить пользуется SVC? Может, лучше через SVC, раз "лишние" прерывания KnightIgor не напрягают? Я пользуюсь :) Да элементарно. Представим себе модем. Скорость rs232 115200, скорость по линии 33600. И ваш fifo по определению переполняется. Дабы этого не происходило, вам надо при заполнении фифо на 90% управлять потоком. То есть высылать XOFF либо снимать RTS. А при освобождении буфера необходимо опять разрешать подгрузку. В целом так будет происходить в любом случае, когда скорость обработки информации меньше чем скорость заполнения буфера. Так вот в момент определения уровня заполнения буфера, необходимо сравнивать 2 указателя. В общем случае требуется критическая секция. Фловконтроль для согласования скоростей каналов и программный фифо - несколько разные вещи. Да, управлять потоком можно от уровня заполненности программного FIFO. Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна :) На чтение обе стороны могут использовать оба указателя FIFO. На запись - каждая сторона только свой указатель. Это видимо имелось в виду программное прерывание. Правильнее его называть SWI. Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна :) Я написал "в общем случае". :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба Проще использовать мютексы и не городить сложных систем с критическими секциями и платформозависимой атомарностью. Не разделяю любви с неблокирующим алгоритмам - их очень трудно поддерживать и очень легко сломать. Интересно - как вы с помощью мьютексов и прочих блокирующих методов синхронизируете работу фоновой задачи с ISR-ами? Научите! К тому-же - реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба Интересно - как вы с помощью мьютексов и прочих блокирующих методов синхронизируете работу фоновой задачи с ISR-ами? Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания. реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе. Кто же спорит. Но мы этого не видим и туда без необходимости не лезем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба Я пользуюсь :) На чистом C или с ASM-вставками? В Keil или GCC? Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). :) Насколько я понял, разработчики Cortex-M изменили название инструкции (сохранив числовое значение) при переходе с ARM7, чтобы программист, который портирует код уделил внимание особенностям новой системы исключений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания. Фифо - это не блокирующий метод. И что толку от сигнализации если нужно эксклюзивное чтение-модификация-запись некоей области памяти в ISR и фоновой задаче (критическая секция)? Хорошо если можно в ISR тупо писать/читать в фифо. А если нужна работа с более сложной структорой данных в памяти? Или то же самое фифо, но несколько писателей или несколько читателей? Как вы тут без критической секции обойдётесь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба Тут достаточно не критической секции, а запрета конкретного источника прерывания перед установкой семафора. При работе с ISR так или иначе запрещать прерывания придётся. Но но уровне операционки можно написать тонны софта ни разу не встретившись с прерыванием. В линуксе скажем они где-то глубоко запрятаны. В таком случае городить всякие lock-free и критические секции нет никакой нужды до тех пор, пока реально не понадобится улучшить производительность. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 апреля, 2014 Опубликовано 3 апреля, 2014 · Жалоба На чистом 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 4 апреля, 2014 Опубликовано 4 апреля, 2014 · Жалоба Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания. Кто же спорит. Но мы этого не видим и туда без необходимости не лезем. А если существует более чем один источник часто повторяющихся прерываний, то эти ваши "невидимые" семафоры в прерываниях уронят всю систему. И в сервисах осей как раз стопроцентно используются критические секции. Уже два раза напоролся на такое - сейчас принципиально стараюсь в прерываниях не юзать осевые сервисы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться