ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
21 ноября
150088 Топик полностью
Сергей Борщ (05.03.2009 12:08, просмотров: 625) ответил Alex B. на хм, у меня тоже непонятка в смысле претензий
Это не претензии. Вы просили "зацените"? Зацениваем. Вы пишете
Теперь представьте, что после выполнения инструкции 0288 202C41 mov.w #0x2c4,0x0002 возникло прерывание
и в методах борьбы запрещением прерываний указываете
Такое решение нельзя использовать в системах с вытесняющей RTOS (там есть свои методы).
Я прошу вас ответить: Почему в системах с RTOS _нельзя_ организовывать атомарный доступ запрещением прерываний? Далее вы пишете, что в RTOS должны применяться мутексы и критические секции. Вы не забыли, что речь все еще идет о борьбе с прерыванием? Мутекс никоем образом прерывания не запрещает, значит в этом конкретном случае не проходит. Критическая секция, в вашем конкретном случае с TNKernel также не запрещает прерывание, и значит тоже в этом конкретном случае не подходит. Ваша же статья утверждает обратное. Я прошу вас объяснить, в чем я не прав.
Там, по-моему, все ясно написано. Оператор условия используется чтобы реализовать в одном макросе как вычисление выражения, так и возврат значения. Я такое вижу первый раз, поэтому обратил на это внимание.
Чуть выше текста про условный оператор вы пишете:
Контроль передачи параметров в макрос сделан интересным способом: в заголовочном файле объявлены уникальные для каждого параметра типы: ... которые используются в макросах для объявления локальной переменной:
Тут вы приводите отрыки из исходника, иллюстрирующие текст. Текст понятен. В разделе, озаглавленном "Условный оператор ?:" вы также приводите отрывки кода, в которых этот самый условный оператор, именем которого озаглавлен раздел, и не встречается. У меня при чтении этого раздела возникло недумение "а где же, собственно, он?". Это недоумение я и высказал.
А вот про то, что промежуточные (после первого xor) значения в полях SFR могут приводить к нежелательным эффектам, вы не упомянули
поясните?
Я не сильный знаток пиковского ассемблера, поэтому руководствовался вашим комментарием к приведенному коду:
вторая инструкция атомарно и безопасно модифицирует четыре младших бита; TRISB = 0xFFF5; третья инструкция накладывает на регистр W0 маску, выделяя 4 младших бита последняя инструкция атомарно и безопасно (не трогая остальных битов!) модифицирует TRISB;
Согласно этому описанию значение TRISB модифицируется дважды. Сейчас внимательно посмотрев код я вижу, что на самом деле модифицируется оно один раз, а промежуточные инструкции формируют маску, которая одной последней инструкцией xor модифицирет TRISB.