реклама на сайте
подробности

 
 
3 страниц V  < 1 2 3  
Reply to this topicStart new topic
> Атомарность чтения, в Cortex M3
jcxz
сообщение Apr 3 2014, 08:24
Сообщение #31


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(adnega @ Apr 3 2014, 12:23) *
И еще: кто-нить пользуется SVC? Может, лучше через SVC, раз "лишние" прерывания KnightIgor не напрягают?

Я пользуюсь sm.gif

Цитата(SasaVitebsk @ Apr 3 2014, 12:32) *
Да элементарно. Представим себе модем. Скорость rs232 115200, скорость по линии 33600. И ваш fifo по определению переполняется. Дабы этого не происходило, вам надо при заполнении фифо на 90% управлять потоком. То есть высылать XOFF либо снимать RTS. А при освобождении буфера необходимо опять разрешать подгрузку. В целом так будет происходить в любом случае, когда скорость обработки информации меньше чем скорость заполнения буфера.
Так вот в момент определения уровня заполнения буфера, необходимо сравнивать 2 указателя. В общем случае требуется критическая секция.

Фловконтроль для согласования скоростей каналов и программный фифо - несколько разные вещи.
Да, управлять потоком можно от уровня заполненности программного FIFO.
Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна sm.gif
На чтение обе стороны могут использовать оба указателя FIFO. На запись - каждая сторона только свой указатель.

Цитата(andrewlekar @ Apr 3 2014, 12:58) *
Это видимо имелось в виду программное прерывание. Правильнее его называть SWI.

Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). sm.gif
Go to the top of the page
 
+Quote Post
SasaVitebsk
сообщение Apr 3 2014, 10:23
Сообщение #32


Гуру
******

Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521



Цитата(jcxz @ Apr 3 2014, 11:24) *
Так вот - для вычисления уровня заполненности FIFO критическая секция совсем не нужна sm.gif

Я написал "в общем случае". rolleyes.gif
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 3 2014, 11:45
Сообщение #33


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(andrewlekar @ Apr 3 2014, 12:58) *
Проще использовать мютексы и не городить сложных систем с критическими секциями и платформозависимой атомарностью. Не разделяю любви с неблокирующим алгоритмам - их очень трудно поддерживать и очень легко сломать.

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

К тому-же - реализация мьютексов в ОС имхо всегда основывается внутри на критических секциях и/или атомарном доступе.
Go to the top of the page
 
+Quote Post
andrewlekar
сообщение Apr 3 2014, 13:29
Сообщение #34


Знающий
****

Группа: Участник
Сообщений: 837
Регистрация: 8-02-07
Пользователь №: 25 163



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

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

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

Кто же спорит. Но мы этого не видим и туда без необходимости не лезем.
Go to the top of the page
 
+Quote Post
adnega
сообщение Apr 3 2014, 14:23
Сообщение #35


Гуру
******

Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702



Цитата(jcxz @ Apr 3 2014, 12:24) *
Я пользуюсь sm.gif

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

Цитата(jcxz @ Apr 3 2014, 12:24) *
Может и правильнее, но в документации Cortex оно называется SVC (SuperVisor Call). sm.gif

Насколько я понял, разработчики Cortex-M изменили название инструкции (сохранив числовое значение) при переходе с ARM7,
чтобы программист, который портирует код уделил внимание особенностям новой системы исключений.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 3 2014, 14:38
Сообщение #36


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(andrewlekar @ Apr 3 2014, 19:29) *
Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.

Фифо - это не блокирующий метод.
И что толку от сигнализации если нужно эксклюзивное чтение-модификация-запись некоей области памяти в ISR и фоновой задаче (критическая секция)?
Хорошо если можно в ISR тупо писать/читать в фифо. А если нужна работа с более сложной структорой данных в памяти?
Или то же самое фифо, но несколько писателей или несколько читателей? Как вы тут без критической секции обойдётесь?
Go to the top of the page
 
+Quote Post
andrewlekar
сообщение Apr 3 2014, 15:08
Сообщение #37


Знающий
****

Группа: Участник
Сообщений: 837
Регистрация: 8-02-07
Пользователь №: 25 163



Тут достаточно не критической секции, а запрета конкретного источника прерывания перед установкой семафора. При работе с ISR так или иначе запрещать прерывания придётся. Но но уровне операционки можно написать тонны софта ни разу не встретившись с прерыванием. В линуксе скажем они где-то глубоко запрятаны. В таком случае городить всякие lock-free и критические секции нет никакой нужды до тех пор, пока реально не понадобится улучшить производительность.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Apr 3 2014, 15:21
Сообщение #38


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(adnega @ Apr 3 2014, 20:23) *
На чистом 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 в этом случае даёт меньше возможностей.
Go to the top of the page
 
+Quote Post
kostyan
сообщение Apr 4 2014, 01:26
Сообщение #39


Частый гость
**

Группа: Участник
Сообщений: 121
Регистрация: 8-11-05
Пользователь №: 10 577



Цитата(andrewlekar @ Apr 3 2014, 19:29) *
Поллинг и фифо решают 90% задач связанных с прерываниями. Если надо из ISR сигнализировать приложению, то можно в задаче захватывать семафор, а в прерывании отпускать. Это позволит заблокировать задачу до прихода прерывания.


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


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

3 страниц V  < 1 2 3
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 25th July 2025 - 11:23
Рейтинг@Mail.ru


Страница сгенерированна за 0.01439 секунд с 7
ELECTRONIX ©2004-2016