Если Вы обратили внимание, то могли заметить, что сохраняется не в регистр, а в память. :-Р И с чего это у АРМа так плохо с памятью? Обычное дело для любого фон неймана. В случае со счетчиком тоже в память надо лазить и еще больше, т.к. чтение-модификация-запись. Если так плохо при работе с памятью, то в результате этот подход вообще плохо для АРМа подходит.


Зачем что-то выделять руками? Внутри функции выделяется локальная переменная. Она и работа с ней скрыты внутри и совершенно не касаются пользователя. Внешне все выглядит так же - функция-вход и функция-выход. С++ позволяет лишь автоматизировать вызов фунции-выхода, чтобы не забыть ее вызвать в нужном месте.


Что-то Вы не про то. Вот пример:

CritEnter() // 1 раз вызвали, прерывания запретили
...
CritEnter() // 2 раз вызвали
...
CritEnter() // 3 раз вызвали
...
...
CritExit() // это соответствует 3
...
CritExit() // это соответствует 2
...
CritExit() // а это по ошибке вызвали, здесь разрешились прерывания, а не должны!
...
CritExit() // а здесь должны были быть разрешены прерывания
...

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

Позволю себе заметить, что у всех 100 экземпляров классов КОД их функций-членов - ОДИН И ТОТ ЖЕ! Будете с этим спорить?


Запрещение прерываний - это один из способов реализации. Наверное, самый простой. Предложите другой способ защитить код, выполняемый в планировщике, где изменяются состояния объектов ядра и все изменения должны быть выполненны атомарно?

1) У всех этих экземпляров естественно один и тотже код.
2) Вы собираетесь похоже говорить именно то что я хотел сказать и сказал но другими словами.

Дело все в том,что понятие критическая секция ( монопольное исполнение операции
над ресурсом) и ее реализация - это разные вещи. Реализована критическая секция
может быть не только зарещением прерываний(что обычно делается в небольших
системах),но и другими способами. Все объекты синхронизации более высокого
уровня(семафоры, мьютексы и т.д.) уже используют внутри себя критические секции
(в вышеуказанном понимании).

Что же касается сохранения одного из статусных регистров при прерываниях в ARM,
то это надо делать дополнительно(что и делается в VxWorks,ThreadX,uC-OS,TNKernel
и т.д.) - либо в стеке вызываемой ф-ции(ThreadX,uC-OS,TNKernel),либо в специальном
фрейме стека/памяти (VxWorks). За это спасибо разработчикам архитектуры ARMа.

И еще:

IMHO, пользователь любой ОS от Windows/Linux до TNKernel никогда
не должен запрещать/разрешать прерывания в своей программе - OS делает это для него в своих семафорах, очередях и т.д.
Если прикладной программе требуется запрещать/разрешать прерывания
напрямую - это плохо написанная программа.
Единственное исключение из вышесказанного - это когда программа
пользователя фактически является расширением ОС - драйвером (USB,networks etc.).

одобрям-с =)

Вот это я категорически поддерживаю!!!

Вообще, в ОСях, IMHO, должна быть такая немаловажная деталь, как синтетический порт под Win32 (или Linux) или на пЫсюк. В начале почти каждого проекта важно отладить его структуру, форматы данных и пр. А такие вещи пишутся на palin С, и им пофиг, на какой платформе работать.

Это просто лично моя мечта - взять синтетический порт ОСи на Win32, запустить
http://www.mingw.org
http://www.bloodshed.net/devcpp.html
http://www.codeblocks.org/

И написать там весь проект без дров. Дрова на таком этапе удобно заменять консолью, файлами, IP и именованными каналами (для связи с другими процессами и машинами). Все-таки аппаратно независимую алгоритмику отлаживать на целевой платформе - глуповатое занятие А на пЫсюке test units писать - самое то! Тут для тестирования Python, Matlab и другие мощные тулзы подрубить можно.

Что касается ассемблерных вставок для эффективной реализации критических кусков - для этого препроцессор есть. Все равно такой кусок имеет вход и выход, да еще рабочую память. Вот и пишется вначале C прототип такого куска, чтобы отладить его взаимодействие с другими частями (и пусть он будет в 100 раз медленнее оптимальнго асмового кода - на этом этапе это не важно, "точность попадания компенсируется диаметром изделия", будет пЫсюк тормозить - возьмем мощнее ), и только потом переводитсмя на асм.

А другой человек (или ты, но в другой момент времени) самозабвенно JTAG'ит дрова на целевой платформе. Затем на эти дрова одевается основной каркас, и делается тонкая доводка.

IMHO, за счет общей оптимизации проекта можно добиться гораздо большего (главное - фантазию на этом этапе включить по полной, полностью раскрепоститься), чем за счет сверхоптимального асмового и С кодинга (как справделиво учит методология XP программизма - опитимизировать надо потом, когда станет очевидно, что именно этот кусок и надо оптимизировать!). А решать все задачи сразу - так только клиенты Кащенко умеют.

Именно их этих соображений я и выбрал eCos (порт на PC (готовая загрузочная дискета) и синтетический порт на Linux), котрый потихоньку изучаю.

В связи с колоссальным ростом возможностей SOC, IMHO, именно такой методологический подход будет эффекивнее на перспективу. Ибо после выхода STR91xxx "ограничений для фантазии" в плане ОС почти не останется - в 512К FLASH и 96k SRAM влезет почти все!

2 yuri_t о TNKernel

в текущем релизе

int tn_cpu_save_sr(void);
void tn_cpu_restore_sr(int sr);

#define TN_INTSAVE_DATA int tn_save_status_reg = 0;
#define tn_disable_interrupt() tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg)

как насчёт такого варианта
возможно, удалить int tn_save_status_reg = 0;
ну и прописать
#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg); }

В какую-то параною скатывается разговор.
Почему _Я_ начал этот разговор -я уже 'оправдывался'.


- не обратил, поскольку с Atmel не имел дела и уже не буду, а увидев явное указание регистра
предположил сохранение в регистре, при этом естественно, должен отметить Ваше лукавство заключающееся в отсутствии занесения регистра, ну да бог с ним....

Вот как раз по причине "плохого Неймана" и по причине кривизны SAMовской реализации блокировки
прерываний, и по причине возможности условного выполнения команд на ARM, как-раз для
ARM сие подходит, ибо даже не особо длиннее и пожалуй быстрее ввиду отсутствия необходимости
всегда бездумно выполнять кучку команд для разблокировки и особенно блокировки.
Если это типа x86
pushf
cli
.....
popf

То тогда еще можно говорить о введении вместо этого глобального счетчика, как о заметном усложнении и торможении процесса, но не для ARM.


Это мы о какой функции? Если о той из которой вызывается, то создание локальной переменной
я и называю 'руками', а если из нее еще вызвать, то создать еще одну локальную и.....
Cкрыть-то можно в функции 'entercritical' - но там она не может быть локальной :-)
по определению, так что о чем мы это говорим - я не понял. (Это я все НЕ о C++)


А Вы поменяйте в своем примере две последние строчки местами и..... ошибки НЕ произойдет.
Таким образом, есть ситуация, когда эти "лишние" навороты приносят пользу.
И уж как минимум, эти навороты если и длинее чуть-чуть для ARM платформы, то уж НЕ ХУЖЕ
справляются со своими обязаностями, нежели принятая в TNKernel реализация. И уж точно
не могут быть причиной НЕ ИСПОЛЬЗОВАНИЯ FreeRTOS. Ну и "дуракоустойчивость"
на мой взгляд получше.

Закончим???

2 zltigo

У меня насчёт правильности запрещения/разрешения прерываний вопрос к Вам остался.
Представьте себе, что пишет подпрограмму с критической секцией не Вы, а коллега. Вы эту подпрограмму интегрируете в свой проект.
Ответьте, пожалуйста, на каком основании Ваш коллега имеет право разрешать прерывания (при выходе из критической секции), если он не узнаЁт при запрещении (при входе в критическую секцию), были ли они (прерывания) разрешены?

Я не понял :-( Вообще ничего из вышеизложенного не понял.
Если речь идет о том, что Вы имеете некоторую процедуру,которая для обеспечения ее непрерывности
обрамлена critical и по этой причине ее нельзя вызывать из обработчика прерывания, то
0. Нужно делать вещи максимально близкие к естественным.
1. Делается процедура без запретов.
2. Для работы в прерывании вызывается прямо или через прямую макроподстановку
3. Для прочего использования через макрос-обертку с __disable/enable.
Если обработчики прерываний в отдельном файле, то макроимена могут быть вообще одинаковыми.
В результате начисто отпадают все ненужные навороты как в виде 'счетчиков', так и ввиде 'сохранений', заодно не надо вникать в реализацию critical в каждой конкретной операционке.

Все выглядит (живой пример) примерно так:


Если всенеприменнейше хотите critical, то можете добавить свой critical для обработчиков прерываний,
единственной функцией которого будет наращивание/уменьшение 'счетчика'.


Так они и не будут разрешены если Вы вызвали его из критической секции и соответственно
счетчик на входе в подпрограмму колеги уже не будет 0. Ежели коллега, или Вы пожелает в _прикладной_ программе воспользоваться прямым запретом/разрешением вместо critical , то, как здесь уже было замечено, надо наказывать, ибо против лома нет приема.

Сообщение отредактировал zltigo - Apr 21 2006, 16:26

Читаю, нервно хихикаю :-) Надеюсь автор поста получил полный ответ на свой вопрос

Я о варианте, когда в основной программе прерывания в какой-то прекрасный момент выключены не в критической секции. Как быть с разрешением в подпрограмме коллеги?

Мне казалось, что я ответил. У меня, тогда больше нет слов для обьяснения :-(.
Попробуйте перечитать написанное в моем предыдущем посте.

To sensor_ua
-------------------

Учитывая Ваш искренний интерес и желание все понять "до последнего винтика",
отвечу:

Во первых,такое выражение просто не будет работать:

#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg); }

Если следовать этим путем, то должно быть, наверное, так:

#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr(); }
#define tn_enable_interrupt() { tn_cpu_restore_sr(tn_save_status_reg); }

Теперь, если Вы вызовете это выражение внутри одной функции несколько
раз, то согласно стандарта на язык С, локальная переменная int tn_save_status_reg
будет видна только внутри блока, где она объявлена, следовательно,
сколько раз вы вызвали tn_disable_interrupt(), столько раз она
и будет создаваться.
Далее, при вызове tn_enable_interrupt() компилятор не увидит
tn_save_status_reg - блок, где было определение, уже завершился.
(а если бы не завершился - то пришлось бы иметь несколько переменных
с одним именем - что всех бы запутало(и компилятор, и программиста) и
поэтому невозможно).

Поэтому давайте оставим это место в коде так, как оно существует сейчас.

И в заключение - при использовании ОС стоит работать на уровне семафоров,
очередей и т.д.
ОС для того и создается,чтобы избавить пользователя от всей этой возни с
сохранением регистров, запрещением/разрешением преываний, etc.

C уважением, yuri_t

Сообщение отредактировал yuri_t - Apr 21 2006, 16:48